स्ट्राइप के साथ रेंटल सॉफ़्टवेयर: डिपॉज़िट, भुगतान और रिफंड ऑनलाइन लेना

हर किराये में तीन अलग-अलग मौके होते हैं जब पैसा हाथ बदलता है, और ज़्यादातर रेंटल कंपनियां हर एक को अलग तरीके से संभालती हैं। सामान बाहर जाने से पहले लिया जाने वाला, या रोका जाने वाला, डिपॉज़िट होता है, काम कन्फ़र्म या पूरा होने पर खुद किराये का भुगतान होता है, और — अक्सर — सामान वापस आने पर, उसकी हालत के हिसाब से, रिफंड या आंशिक अतिरिक्त शुल्क होता है।

कागज़ पर यह सब व्यवस्थित लगता है। असल में, डिपॉज़िट काउंटर पर कार्ड मशीन से लिया जाता है, इनवॉइस ईमेल से भेजा जाता है और अलग से याद दिलाया जाता है, और अगर रिफंड देना हो तो कोई दिनों बाद पेमेंट डैशबोर्ड में लॉगिन करके इसे हाथ से प्रोसेस करता है, उम्मीद है सही ग्राहक और सही ऑर्डर के लिए। इनमें से कोई भी तीन पल एक-दूसरे से बात नहीं करता। कार्ड मशीन को नहीं पता कि डिपॉज़िट किस ऑर्डर का है। डैशबोर्ड को नहीं पता कि इनवॉइस अब चुक गया है। और दफ़्तर को तभी पता चलता है जब कोई पूछता है, "क्या हमने वह डिपॉज़िट कभी वापस किया था?"

यह असल में तकनीक की समस्या नहीं है, यह ऑर्डर-ट्रैकिंग की समस्या है जिसमें संयोग से पैसा भी शामिल है। एक किराये के ऑर्डर में पहले से ही एक ग्राहक, सामान की सूची, जाने और वापस आने की तारीख़ें, और एक राशि होती है। अगर भुगतान उस ऑर्डर से अलग किसी सिस्टम में रहते हैं, तो किसी को हर बार याददाश्त से या स्प्रेडशीट पर दोनों को मिलाना पड़ता है। इसी मिलान में डिपॉज़िट भुला दिए जाते हैं, रिफंड छूट जाते हैं, और इनवॉइस दो बार याद दिलाए जाते हैं।

किराये के तीनों भुगतान पल तभी उपयोगी हैं जब हर एक उस ऑर्डर से जुड़ा हो जिससे वह संबंधित है, न कि एक अलग लेन-देन की तरह तैरता रहे जिसे बाद में किसी को मिलाना पड़े।

ऑर्डर रिकॉर्ड से जुड़ा डिपॉज़िट इसका मतलब है कि उस किराये को देखने वाला कोई भी व्यक्ति — सिर्फ़ भुगतान लेने वाला नहीं — देख सकता है कि वह लिया गया था, कितना था, और वह वापस किया गया या रोका गया। खुद किराये के लिए भुगतान, उसी तरह जुड़ा हुआ, इसका मतलब है कि जब ग्राहक असल में भुगतान कर चुका है तब भी इनवॉइस खातों में "अवैतनिक" नहीं दिखता; वित्त टीम असल ऑर्डर स्थिति के आधार पर काम करती है, न कि कार्ड मशीन की रसीद रोल पर।

अंत में रिफंड या अतिरिक्त शुल्क सबसे ज़्यादा मायने रखता है, क्योंकि अलग से संभालने पर यही सबसे ज़्यादा गलत होने की संभावना रखता है। अगर ऑर्डर के बाहर डिपॉज़िट से नुकसान की कटौती की जाती है, तो किराये पर ही कोई रिकॉर्ड नहीं बचता कि क्या रोका गया, क्या वापस किया गया, या क्यों — ज़्यादा से ज़्यादा किसी के इनबॉक्स में एक नोट। तीनों पलों को ऑर्डर से जोड़े रखना सफ़ाई से कम और इस क्षमता से ज़्यादा जुड़ा है कि बिना फ़ोन किए यह ठीक-ठीक बताया जा सके कि किसी खास किराये पर ग्राहक के पैसे का क्या हुआ।

हर भुगतान पल ग्राहक के आपके सामने खड़े होने पर नहीं होता। बहुत सारा किराये का कारोबार फ़ोन पर, ईमेल से, या ऑनलाइन पूछताछ के ज़रिए बुक होता है, और उस स्थिति में भुगतान लेने का पारंपरिक तरीका — काउंटर पर कार्ड मशीन — बस वहां होता ही नहीं।

आम विकल्प, जो अब ऑनलाइन भुगतान में सामान्य हो चुका है, वह है पेमेंट लिंक या होस्टेड चेकआउट पेज: फ़ोन पर कार्ड नंबर बताने या बैंक ट्रांसफ़र का इंतज़ार करने की बजाय, ग्राहक को एक सुरक्षित लिंक मिलता है, वह भुगतान प्रदाता द्वारा चलाए जा रहे पेज पर खुद अपने कार्ड की जानकारी डालता है, और भुगतान की पुष्टि हो जाती है बिना दफ़्तर को कभी कार्ड नंबर देखे। Renttix ठीक इसी वजह से Stripe से जुड़ता है, ताकि जिस ऑर्डर का कोटेशन दिया गया हो या जिसे कन्फ़र्म किया गया हो, उसे प्लेटफ़ॉर्म के अंदर ही, नेटिव तरीके से भुगतान तक ले जाया जा सके, न कि बाद में जोड़ी गई अलग इनवॉइस-और-डैशबोर्ड प्रक्रिया के ज़रिए। यही Stripe इंटीग्रेशन का मक़सद है — भुगतान ऑर्डर के अपने वर्कफ़्लो का एक कदम है, न कि कोई समानांतर काम जिसे किसी को याद रखना पड़े।

एक रेंटल कंपनी के लिए, यह उस अंतर को पाटता है जिसे कार्ड मशीन नहीं पाट सकती: यह सामान डिपो से निकलने से पहले ही, ऐसे ग्राहक से जो कहीं आसपास भी नहीं है, डिपॉज़िट या भुगतान लेने देता है — बिना उससे कार्ड नंबर ज़ोर से बताने या ट्रांसफ़र रेफ़रेंस के सही जगह पहुंचने पर भरोसा करने को कहे।

बहुत सारा किराया एक बार का लेन-देन होता है: बुक करना, लेना, वापस लाना, भुगतान करना। लेकिन बढ़ता हुआ हिस्सा ऐसा नहीं है — लंबी अवधि का सामान बिना तय अंत वाले किराये में, वेलफ़ेयर यूनिट्स सब्सक्रिप्शन जैसे साइकिल में, या ऐसा ग्राहक जो हर महीने आपसे किराये पर लेता है और हर बार कार्ड डालना नहीं चाहता।

इस तरह के इंतज़ाम के लिए, Renttix कार्ड को सेव करके रखने का समर्थन करता है ताकि बिना तय अंत वाले किराये और सब्सक्रिप्शन को बार-बार चलने वाले साइकिल में बिल किया जा सके, बिना किसी को हर बार हाथ से भुगतान लेना पड़े। यही सेव्ड-कार्ड तरीका मीटर्ड यूसेज बिलिंग का आधार भी बनता है, जहां राशि तय अवधि की बजाय असल इस्तेमाल पर निर्भर करती है, और यही देर से भुगतान पर बढ़ते जुर्माने को बिना अलग से पीछे भागे वसूलने देता है। ग्राहक कार्ड को एक बार अधिकृत करता है, और उसके बाद बिलिंग साइकिल खुद ही सब संभाल लेता है।

यह कैश फ़्लो के लिए उतना ही मायने रखता है जितना सुविधा के लिए। जिस कारोबार को लंबे समय तक चलने वाले किराये के लिए हर महीने सक्रिय रूप से कार्ड भुगतान के पीछे भागना पड़ता है, वह देर-सवेर एक साइकिल चूक ही जाएगा — किसी कर्मचारी की छुट्टी होने से, ग्राहक तक पहुंचना मुश्किल होने से, या इनवॉइस का सूची में नीचे खिसक जाने से। सेव्ड-कार्ड बिलिंग किसी के याद रखकर पूछने पर इस निर्भरता को हटा देती है।

किराये का अंत वह पल है जहां अलग-अलग सिस्टम सबसे ज़्यादा नुकसान पहुंचाते हैं, क्योंकि यह सबसे ज़्यादा अपवादों वाला पल होता है: सामान एक दिन देरी से वापस आता है, कुछ गुम है, किसी खरोंच के लिए अतिरिक्त शुल्क लेना है, या सब ठीक है और डिपॉज़िट बस वापस करना है।

Renttix आपको मूल इनवॉइस के खिलाफ़ क्रेडिट नोट बनाने और वहां से पूरा या आंशिक रिफंड जारी करने देता है, जो आपके खातों से सिंक होकर वापस जाता है, न कि एक अलग लेन-देन की तरह प्रोसेस होता है जिसे वित्त टीम को अलग से नोटिस करके मिलाना पड़े। यह अंतर — पूरा या आंशिक — ही अतिरिक्त शुल्क को असल में संभालने लायक बनाता है। खराब हुए सामान का मतलब यह नहीं होना चाहिए कि या तो पूरा डिपॉज़िट वापस करके मरम्मत का खर्च बट्टे खाते में डाल दिया जाए, या सब कुछ रोककर उस पर बहस की जाए; आंशिक रिफंड आपको वह वापस करने देता है जो बकाया है और यह बताने देता है कि क्या रोका गया, उसी इनवॉइस पर जिस पर डिपॉज़िट लिया गया था।

क्योंकि क्रेडिट नोट और रिफंड दोनों मूल ऑर्डर का हवाला देते हैं, बाद में उस किराये की समीक्षा करने वाला कोई भी व्यक्ति — कोई विवाद जांचने वाला मैनेजर, महीना बंद करने वाला अकाउंटेंट — पूरा क्रम देख सकता है: डिपॉज़िट लिया गया, किराये का बिल बना, कटौती हुई, बाकी रिफंड हुआ। यह किसी इनबॉक्स के उस नोट से बिल्कुल अलग स्थिति है जिसमें लिखा हो "सुलझा दिया, ज़्यादातर पैसे उसे वापस कर दिए"।

ऊपर बताया हर भुगतान पल अब भी यह मानता है कि आपके दफ़्तर में कोई इसे शुरू करता है। ग्राहक पोर्टल उन लेन-देन के लिए यह धारणा हटा देता है जिनमें आपकी तरफ़ से किसी इंसान की ज़रूरत ही नहीं होती।

पोर्टल के ज़रिए, ग्राहक अपने सेव किए गए कार्ड खुद प्रबंधित कर सकते हैं, बकाया इनवॉइस का भुगतान कर सकते हैं, किराये के समझौते पर हस्ताक्षर कर सकते हैं, और सामान वापस करने का अनुरोध कर सकते हैं जब उनका काम पूरा हो जाए — इनमें से किसी के लिए भी दफ़्तर को फ़ोन किए बिना। पहले से सही इनवॉइस पर एक साधारण भुगतान के लिए, इसमें बातचीत की ज़रूरत पड़ने की कोई वजह नहीं है; ग्राहक इसे खुद निपटा सकता है, जब भी उसे सही लगे, और शाम सात बजे यह पूछने के लिए फ़ोन कि कार्ड भुगतान "हुआ या नहीं" — यह वह कॉल है जो आपके दफ़्तर को लेने की ज़रूरत नहीं है।

यह ऊपर बताए डिपॉज़िट, भुगतान और रिफंड के तरीकों की जगह नहीं लेता — यह बस बदलता है कि बटन कौन दबाता है। ऑर्डर, इनवॉइस, और भुगतान रिकॉर्ड बिल्कुल वहीं रहते हैं जहां थे; पोर्टल एक और रास्ता है, कोई अलग मंज़िल नहीं।

इसे स्पष्ट करने के लिए: सोचिए एक पार्टी हायर कंपनी जो टेंट, टेबल और कुर्सियों की बुकिंग लेती है — यह एक उपयोगी उदाहरण है, यह दावा नहीं कि हर रेंटल कंपनी को इसी तरह काम करना चाहिए।

एक ग्राहक छह हफ़्ते पहले वीकेंड के किसी इवेंट के लिए टेंट के बारे में पूछता है। बुकिंग के समय, कंपनी बैंक ट्रांसफ़र मांगकर उसके आने का इंतज़ार करने की बजाय, पेमेंट लिंक के ज़रिए ऑनलाइन डिपॉज़िट लेती है। वह डिपॉज़िट भुगतान होते ही ऑर्डर से जुड़ जाता है। इवेंट से एक हफ़्ते पहले, किराये की बाकी राशि का इनवॉइस बनाया जाता है और उसी तरह भुगतान किया जाता है — एक लिंक, कार्ड मशीन नहीं, क्योंकि डिलीवरी के दिन तक कंपनी का कोई भी व्यक्ति ग्राहक के सामने नहीं होता।

इवेंट के बाद, टेंट फटे हुए पैनल के साथ वापस आता है। पूरा डिपॉज़िट रोकने या इसे पूरा वापस करके खुद खर्च उठाने की बजाय, कंपनी आंशिक रिफंड करती है: मरम्मत की लागत घटाई जाती है, और बाकी पैसा उसी इनवॉइस पर क्रेडिट नोट के रूप में ग्राहक के कार्ड में वापस चला जाता है जिस पर डिपॉज़िट लिया गया था। ग्राहक को यह साफ़ वजह दिखती है कि क्या रोका गया, कंपनी के पास ऑर्डर से जुड़ा रिकॉर्ड होता है न कि किसी की न लिखी गई बातचीत, और कार्ड मशीन, बैंक स्टेटमेंट और इनवॉइस के बीच कुछ भी हाथ से मिलाने की ज़रूरत नहीं पड़ती।

इनमें से किसी के लिए भी हर ग्राहक के लिए एक ही भुगतान तरीका चुनना ज़रूरी नहीं है। Stripe उन कई भुगतान प्रदाताओं में से एक है जिनसे Renttix जुड़ता है, जैसे PayPal, Square, Razorpay, Xendit, Mercado Pago, Alipay+ और Airwallex के साथ, और इनमें से किसी के भी ज़रिए किए गए भुगतान पर, जहां लागू हो, क्लास, ज़ोन और छूट के आधार पर गणना किया गया टैक्स लग सकता है — यह अपने आप में एक अलग विषय है, जिसे ग्लोबल पेमेंट्स एंड टैक्स पेज पर बताया गया है, न कि कुछ ऐसा जिसे यह लेख पूरी तरह समझाने की कोशिश करता है।

डिपॉज़िट-भुगतान-रिफंड साइकिल के लिए विशेष रूप से जो मायने रखता है वह यह है कि तीनों में से हर पल उस ऑर्डर से जुड़ा हो जहां से वह आया है, चाहे पैसा कोई भी प्रदाता ले। सही तरीके से सेट होने पर, एक Stripe इंटीग्रेशन यह सुनिश्चित करता है कि डिपॉज़िट, इनवॉइस भुगतान, और रिफंड एक ही किराये रिकॉर्ड पर तीन एंट्री हों, न कि तीन अलग-अलग कहानियां जो तभी मेल खाती हैं जब किसी को उन्हें एक-दूसरे को बताना याद रहे।

अगर आपके मौजूदा सेटअप में एक कार्ड मशीन शामिल है जिसे आपकी बुकिंग के बारे में कुछ नहीं पता, और एक पेमेंट डैशबोर्ड जिसे महीने के अंत तक कोई नहीं देखता, तो इस अंतर को पाटना इससे पहले उचित है कि इसकी कीमत आपको किसी छूटे रिफंड या विवादित डिपॉज़िट के रूप में चुकानी पड़े। अपने खुद के किराये के कारोबार में यह कैसे फ़िट बैठता है, यह देखने के लिए संपर्क करें।