क्या मुझे billing engine बनाना पड़ेगा?

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

ग्राहक का कार्ड एक्सपायर हो जाए तो क्या होता है?

सेव किया गया कार्ड एक network token होता है, जो री-इश्यू और एक्सपायरी के बाद भी कार्डधारक के साथ चलता है — इसलिए जो सब्सक्रिप्शन पहले टूट जाता, वह चार्ज होता रहता है।

क्या ग्राहक वॉलेट से सब्सक्रिप्शन का भुगतान कर सकता है?

हाँ। Apple Pay या Google Pay के पीछे का कार्ड रिकरिंग चार्ज के लिए टोकनाइज़ किया जा सकता है, इसलिए एक टैप से शुरू हुआ सब्सक्रिप्शन ग्राहक को checkout पर लौटाए बिना चलता रहता है।

सब कुछ नहीं, सिर्फ़ एक महीने का रिफंड कैसे करूँ?

हर साइकिल अपना ऑर्डर है, इसलिए आप उसी ऑर्डर का पूरा या आंशिक रिफंड करते हैं — बाकी किसी साइकिल या सब्सक्रिप्शन पर कोई असर नहीं पड़ता।

तरीका · रिकरिंग

ऐसे सब्सक्रिप्शन जो चुपचाप नहीं टूटते।

रिकरिंग रेवेन्यू दो साधारण वजहों से रुकता है: कार्ड री-इश्यू हो जाता है और चार्ज काम करना बंद कर देता है, या रिन्यूअल soft decline हो जाता है और ग्राहक के जाने तक किसी को पता नहीं चलता। Network tokens पहली समस्या हल करते हैं, शेड्यूल्ड रीट्राई दूसरी, और इसके लिए आपकी टीम को billing engine नहीं बनाना पड़ता।

Protocore Gateway देखें सभी पेमेंट मेथड

आपका

शेड्यूल और राशि

ऑटो

Soft decline पर रीट्राई

Token

कार्ड री-इश्यू के बाद भी चालू

हर साइकिल का ऑर्डर

यह कैसे चलता है

साइनअप से रिन्यूअल तक, चार चरण।

01
AUTHORIZE
ग्राहक checkout पर एक बार भुगतान करता है; कार्ड network token के रूप में vault में सुरक्षित हो जाता है।
02
SCHEDULE
राशि, अंतराल, शुरुआत और अंत आप तय करते हैं — या इसे खुला छोड़ देते हैं।
03
CHARGE
हर साइकिल का अपना ऑर्डर, अपनी रसीद और अपना webhook बनता है।
04
RECOVER
Soft decline को churn मानकर छोड़ने के बजाय शेड्यूल के अनुसार दोबारा आज़माया जाता है।

हर साइकिल एक असली ऑर्डर है

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

01हर साइकिल पर एक ऑर्डर, एक रसीद और एक webhook
02बाकी साइकिल को छुए बिना किसी एक साइकिल का रिफंड
03एक बार के भुगतानों वाली उसी सूची में मिलान

वे दो विफलताएँ जिनसे असल में पैसा जाता है

Involuntary churn की ज़्यादातर वजह दो हैं: एक्सपायर या री-इश्यू हुए कार्ड, और ऐसे soft decline जिन्हें किसी ने दोबारा नहीं आज़माया। Network tokens री-इश्यू के बाद भी कार्डधारक के साथ चलते हैं, इसलिए नया कार्ड आने पर भी चार्ज चलता रहता है। शेड्यूल्ड रीट्राई अस्थायी decline पर फिर से कोशिश करते हैं, ऐसे समय पर जिनके सफल होने की संभावना पहली कोशिश से बेहतर हो।

01Network tokens री-इश्यू और एक्सपायरी के बाद भी चलते हैं
02Soft decline छोड़े नहीं जाते, शेड्यूल पर दोबारा आज़माए जाते हैं
03ग्राहक को तभी बताया जाता है जब सच में ज़रूरी हो

चालू करने के लिए क्या चाहिए

पहले भुगतान पर कार्ड vault करने के लिए एक फ़्लैग, और एक शेड्यूल। जोड़ने के लिए कोई अलग billing प्रोडक्ट नहीं है, और सब्सक्रिप्शन के चार्ज आपकी बाकी कमाई की तरह उसी बैक ऑफ़िस और उसी payout में आते हैं।

FAQ

आवर्ती भुगतान — मर्चेंट्स के सवाल।

नहीं। शेड्यूल, रीट्राई और टोकन मैनेजमेंट इस तरीके का हिस्सा हैं। आपकी तरफ़ से बस पहला भुगतान और राशि व अंतराल का फ़ैसला चाहिए।
सेव किया गया कार्ड एक network token होता है, जो री-इश्यू और एक्सपायरी के बाद भी कार्डधारक के साथ चलता है — इसलिए जो सब्सक्रिप्शन पहले टूट जाता, वह चार्ज होता रहता है।
हाँ। Apple Pay या Google Pay के पीछे का कार्ड रिकरिंग चार्ज के लिए टोकनाइज़ किया जा सकता है, इसलिए एक टैप से शुरू हुआ सब्सक्रिप्शन ग्राहक को checkout पर लौटाए बिना चलता रहता है।
हर साइकिल अपना ऑर्डर है, इसलिए आप उसी ऑर्डर का पूरा या आंशिक रिफंड करते हैं — बाकी किसी साइकिल या सब्सक्रिप्शन पर कोई असर नहीं पड़ता।