क्रिप्टो सब्सक्रिप्शन और आवर्ती भुगतान: ये वास्तव में कैसे काम करते हैं

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

क्यों क्रिप्टो में ऑटो-चार्ज नहीं है (और क्यों यह ठीक है)

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

लोग कभी-कभी ऑन-चेन "सब्सक्रिप्शन" प्राइमिटिव्स की ओर इशारा करते हैं — ERC-20 approve()भत्ते, खाता-एब्स्ट्रैक्शन सत्र कुंजी, या Sablier जैसे स्ट्रीमिंग प्रोटोकॉल। ये मौजूद हैं, लेकिन ये विशेष, श्रृंखला-विशिष्ट हैं, उपयोगकर्ता को खर्च की सीमा को पूर्व-स्वीकृत करने की आवश्यकता होती है, और वास्तविक UX और सुरक्षा सतह को जोड़ते हैं। अमेरिका में USDT या BTC में ग्राहकों को बिलिंग करने वाले 99% व्यवसायों के लिए, व्यावहारिक मॉडल प्रीपेड नवीनीकरण है। यह सरल, सुरक्षित है, और यह हर सिक्के और नेटवर्क पर समान रूप से काम करता है जिसे आप समर्थन करते हैं।

प्रीपेड मॉडल: चार्ज करें, फिर +30 दिन जोड़ें

यह पूरा पैटर्न है। एक सदस्यता बस एक access_untilग्राहक के खाते पर टाइमस्टैम्प। प्रत्येक सफल भुगतान इसे बढ़ाता है।

• नई साइनअप: ग्राहक 30-दिन की योजना के लिए भुगतान करता है। आपके पुष्टि किए गए वेबहुक पर, सेट करें access_until = now() + 30 days.
• नवीनीकरण: ग्राहक फिर से भुगतान करता है। आप उस समय से बढ़ाते हैं जो भी बाद में है - वर्तमान access_until यदि उन्होंने जल्दी भुगतान किया, या now() यदि उन्होंने इसे लापरवाह छोड़ दिया। यह "+30 दिन जोड़ें" नियम है: access_until = max(access_until, now()) + 30 days.
• समाप्ति: एक निर्धारित कार्य (या अनुरोध पर एक साधारण जांच) की तुलना करता है access_until अब से। इसके बाद, पहुँच निलंबित कर दी जाती है जब तक अगला भुगतान नहीं आता।

का उपयोग करना max()महत्वपूर्ण है। यदि कोई तीन दिन पहले नवीनीकरण करता है, तो आप उन तीन दिनों को बर्बाद नहीं करना चाहते — उनके मौजूदा समाप्ति तिथि से बढ़ाएँ। यदि वे एक सप्ताह देर से नवीनीकरण करते हैं, तो आप आज से बढ़ाते हैं। यह एकल पंक्ति दो सबसे सामान्य बिलिंग शिकायतों को रोकती है।

एक ठोस उदाहरण

मान लीजिए कि आप $15/महीने की सदस्यता बेचते हैं और TRC-20 पर USDT स्वीकार करते हैं क्योंकि शुल्क बहुत कम हैं। प्रवाह इस प्रकार है:

// on confirmed payment webhook (HMAC-verified)
$sub = getSubscription($userId);
$base = max($sub->access_until, now());
$sub->access_until = $base->addDays(30);
$sub->last_paid_at = now();
save($sub);
grantAccess($userId);

यह क्रिप्टो सदस्यता बिलिंग का मूल है। कोई संग्रहीत कार्ड नहीं, कोई वॉल्ट नहीं, कोई चार्जबैक नहीं। ग्राहक को समाप्ति से कुछ दिन पहले एक चालान या भुगतान लिंक मिलता है, वह इसका भुगतान करता है, और वेबहुक बाकी का काम करता है। यदि वे भुगतान नहीं करते हैं, तो पहुँच बस समाप्त हो जाती है — कोई असफल-चार्ज पुनः प्रयास, कोई मृत कार्ड के लिए डनिंग ईमेल नहीं।

कार्ड आवर्ती बिलिंग बनाम आवर्ती क्रिप्टो भुगतान

कोई भी मॉडल सख्ती से बेहतर नहीं है; वे विभिन्न चीजों के लिए अनुकूलित हैं। कार्ड बिना किसी रुकावट के बनाए रखने में जीतते हैं। क्रिप्टो अंतिमता, पहुँच, और लागत में जीतता है। यहाँ ईमानदार तुलना है:

समझौता स्पष्ट है: कार्ड चुपचाप नवीनीकरण करते हैं लेकिन अस्वीकृतियों और चार्जबैक के कारण राजस्व लीक करते हैं; क्रिप्टो आपको कभी भी उलटफेर से आश्चर्यचकित नहीं करता लेकिन हर चक्र में ग्राहक से कार्रवाई करने की अपेक्षा करता है। यही कारण है कि अनुस्मारक ईमेल वैकल्पिक नहीं है - यह आपका पूरा नवीनीकरण फ़नल है।

जब प्रत्येक मॉडल वास्तव में फिट बैठता है

प्रीपेड क्रिप्टो सब्सक्रिप्शन तब चमकते हैं जब:

• आपका दर्शक वैश्विक या क्रिप्टो-नैटिव है और पहले से ही स्थिरकॉइन रखता है।
• चार्जबैक धोखाधड़ी एक वास्तविक लागत है - डिजिटल सामान, SaaS, वयस्क, गेमिंग, उच्च-जोखिम वाले क्षेत्र।
• आप उन संपत्तियों में निपटान चाहते हैं जिन्हें आप नियंत्रित करते हैं न कि एक प्रोसेसर जो आपका बैलेंस रखता है।
• वार्षिक या त्रैमासिक योजनाएँ व्यवहार्य हैं - कम नवीनीकरण का मतलब है निष्क्रियता पर चर्न होने के कम मौके।

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

साफ-सुथरे तरीके से एक्सेस नियंत्रण लागू करना

एक्सेस निर्णय को बहुत सरल रखें और इसे केंद्रीकृत करें। हर संरक्षित अनुरोध को एक सवाल पूछना चाहिए: क्या now() < access_until? अपनी कोडबेस में सब्सक्रिप्शन लॉजिक को बिखेरें नहीं।

1. राज्य को स्टोर करें, घटनाओं को नहीं।सत्य का स्रोत है access_until, भुगतान की पंक्तियों का ढेर नहीं। भुगतान परिवर्तित करें वह क्षेत्र; आपका ऐप पढ़ता है यह।
2. एक ग्रेस विंडो जोड़ें।एक पुष्टि की गई ऑन-चेन भुगतान में मिनट लग सकते हैं। एक छोटा बफर दें (मान लीजिए, समाप्ति के 2-3 दिन बाद) ताकि अंतिम दिन भुगतान करने वाला ग्राहक लेनदेन की पुष्टि होने पर बाहर न हो जाए।
3. सभी कुछ साइन किए गए वेबहुक से चलाएं।केवल तब पहुंच बढ़ाएं जब Payora एक पुष्टि की गई भुगतान घटना भेजे, और आप इसे भरोसा करने से पहले HMAC-SHA256हस्ताक्षर की पुष्टि करें। विवरण में वेबहुक सिग्नेचर सत्यापन.
4. समाप्ति से पहले नवीनीकरण चालान भेजें।कुछ दिन पहले एक भुगतान लिंक उत्पन्न करें और इसे ईमेल करें। यह वही चालान प्रवाह है जिसका उपयोग फ्रीलांसर करते हैं - देखें क्रिप्टो में ग्राहकों को चालान करना.
5. नवीनीकरण को एक क्लिक में करें।ग्राहक की पसंदीदा मुद्रा और नेटवर्क का पुनः उपयोग करें ताकि एक लौटने वाले सदस्य को हर महीने चेन के बीच पुनः चयन नहीं करना पड़े।

नवीनीकरण के लिए, पुष्टि किए गए फंड आपके कॉन्फ़िगर किए गए निपटान मोड के तहत क्रेडिट किए जाते हैं: डिफ़ॉल्ट रूप से आप आंतरिक देख सकते हैं बैलेंस पर होल्ड और रिलीज़ देख सकते हैं। और इसे अपने कार्यक्रम पर बाहर ले जा सकते हैं, एक का भुगतान करते हुए आपकी योजना का शुल्क (फ्री पर 1.5%) केवल तब जब आप निकालते हैं (न्यूनतम $50), जब आप स्वीकार करते हैं तब नहीं। स्वीकृत प्रत्यक्ष निपटान खाता-विशिष्ट है जहां समर्थित है। नवीनीकरण के दौरान शुल्क को कम रखना भी पढ़ने लायक है: क्रिप्टो भुगतान शुल्क को कम करना.

बचने के लिए सामान्य गलतियाँ

• से बढ़ाना now() प्रारंभिक नवीनीकरण पर — आप उन दिनों को चुरा रहे हैं जिनका भुगतान ग्राहकों ने किया है। हमेशा max(access_until, now()).
• घड़ी के टिकने के साथ ही पहुंच को रद्द करना — एक पुष्टि करने वाला लेनदेन गैर-भुगतान जैसा दिखता है। कृपया ग्रेस विंडो का उपयोग करें।
• एक बिना हस्ताक्षर वाले वेबहुक पर भरोसा करना — कोई भी आपके एंडपॉइंट पर POST कर सकता है। हस्ताक्षर की पुष्टि करें या आप मुफ्त सदस्यता बांट देंगे।
• UI में "स्वतः नवीनीकरण" का वादा करना — यह पूर्व-भुगतान है। कहें "आपके भुगतान पर नवीनीकरण"; यहां ईमानदारी समर्थन टिकटों को रोकती है।

शुरू करें

क्रिप्टो सब्सक्रिप्शन कम जादुई और अधिक अनुशासन हैं: प्रीपेड अवधि, एकल access_until क्षेत्र, और एक साइन किया हुआ वेबहुक जो समय को जोड़ता है। यह एक ऐसा मॉडल है जिसे आप एक दोपहर में शिप कर सकते हैं और हमेशा के लिए इसके बारे में सोच सकते हैं। एक मुफ्त Payora खाता बनाएं एपीआई कुंजी प्राप्त करने के लिए, अपने नवीनीकरण को SDK और वेबहुक दस्तावेज़ों के खिलाफ वायर करें, या पहले लाइव चेकआउट डेमो को आजमाएं ताकि आप देख सकें कि आपके सदस्य किस भुगतान प्रवाह का उपयोग करेंगे। जब आप तैयार हों, होस्टेड चेकआउट, चालान, और भुगतान लिंक सेट करें और 20+ सिक्कों में बिलिंग शुरू करें जो आपके ग्राहक पहले से ही रखते हैं।