अवलोकन
ऑन-डिमांड सब्सक्रिप्शन आपको एक ग्राहक के भुगतान विधि को एक बार अधिकृत करने और फिर जब भी आवश्यकता हो, परिवर्तनीय राशि चार्ज करने की अनुमति देता है, बजाय इसके कि एक निश्चित कार्यक्रम पर। यह सुविधा सभी खातों के लिए उपलब्ध है—कोई अनुमोदन आवश्यक नहीं। इस गाइड का उपयोग करें:- एक ऑन-डिमांड सब्सक्रिप्शन बनाएं (वैकल्पिक प्रारंभिक मूल्य के साथ एक जनादेश अधिकृत करें)
- कस्टम राशियों के साथ बाद के चार्ज को ट्रिगर करें
- वेबहुक का उपयोग करके परिणामों को ट्रैक करें
पूर्वापेक्षाएँ
- डोडो पेमेंट्स व्यापारी खाता और API कुंजी
- वेबहुक गुप्त कुंजी कॉन्फ़िगर की गई और घटनाओं को प्राप्त करने के लिए एक एंडपॉइंट
- आपके कैटलॉग में एक सब्सक्रिप्शन उत्पाद
ऑन-डिमांड कैसे काम करता है
- आप एक सब्सक्रिप्शन बनाते हैं जिसमें
on_demandऑब्जेक्ट का उपयोग करके एक भुगतान विधि को अधिकृत करते हैं और वैकल्पिक रूप से एक प्रारंभिक चार्ज एकत्र करते हैं। - बाद में, आप समर्पित चार्ज एंडपॉइंट का उपयोग करके उस सब्सक्रिप्शन के खिलाफ कस्टम राशियों के साथ चार्ज बनाते हैं।
- आप वेबहुक (जैसे,
payment.succeeded,payment.failed) को सुनते हैं ताकि अपने सिस्टम को अपडेट कर सकें।
एक ऑन-डिमांड सब्सक्रिप्शन बनाएं
एंडपॉइंट: POST /checkouts मुख्य अनुरोध फ़ील्ड (शरीर):कृपया उन्हें चेकआउट सत्र बनाएं में देखें।
एक ऑन-डिमांड सब्सक्रिप्शन बनाएं
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
एक ऑन-डिमांड सब्सक्रिप्शन चार्ज करें
जब जनादेश अधिकृत हो जाए, तो आवश्यकतानुसार चार्ज बनाएं। एंडपॉइंट: POST /subscriptions/{subscription_id}/charge मुख्य अनुरोध फ़ील्ड (शरीर):चार्ज अनुरोध शरीर पैरामीटर
चार्ज अनुरोध शरीर पैरामीटर
चार्ज करने के लिए राशि (सबसे छोटे मुद्रा इकाई में)। उदाहरण: $25.00 चार्ज करने के लिए,
2500 पास करें।चार्ज के लिए वैकल्पिक मुद्रा ओवरराइड।
इस चार्ज के लिए वैकल्पिक विवरण ओवरराइड।
यदि सत्य है, तो
product_price के भीतर अनुकूलनात्मक मुद्रा शुल्क शामिल हैं। यदि गलत है, तो शुल्क ऊपर जोड़े जाते हैं।भुगतान के लिए अतिरिक्त मेटाडेटा। यदि छोड़ा गया, तो सब्सक्रिप्शन मेटाडेटा का उपयोग किया जाता है।
- Node.js SDK
- Python SDK
- Go SDK
- cURL
Success
भुगतान पुनः प्रयास
हमारी धोखाधड़ी पहचान प्रणाली आक्रामक पुनः प्रयास पैटर्न को अवरुद्ध कर सकती है (और उन्हें संभावित कार्ड परीक्षण के रूप में चिह्नित कर सकती है)। एक सुरक्षित पुनः प्रयास नीति का पालन करें।सुरक्षित पुनः प्रयास नीतियों के लिए सिद्धांत
- बैकऑफ तंत्र: पुनः प्रयासों के बीच गुणात्मक बैकऑफ का उपयोग करें।
- पुनः प्रयास सीमाएँ: कुल पुनः प्रयासों को सीमित करें (3-4 प्रयास अधिकतम)।
- बुद्धिमान फ़िल्टरिंग: केवल पुनः प्रयास करने योग्य विफलताओं पर पुनः प्रयास करें (जैसे, नेटवर्क/जारीकर्ता त्रुटियाँ, अपर्याप्त धन); कभी भी कठिन अस्वीकृतियों पर पुनः प्रयास न करें।
- कार्ड परीक्षण रोकथाम: ऐसी विफलताओं पर पुनः प्रयास न करें जैसे
DO_NOT_HONOR,STOLEN_CARD,LOST_CARD,PICKUP_CARD,FRAUDULENT,AUTHENTICATION_FAILURE। - मेटाडेटा में भिन्नता (वैकल्पिक): यदि आप अपनी स्वयं की पुनः प्रयास प्रणाली बनाए रखते हैं, तो मेटाडेटा (जैसे,
retry_attempt) के माध्यम से पुनः प्रयासों में भिन्नता करें।
सुझाई गई पुनः प्रयास अनुसूची (सब्सक्रिप्शन)
- 1st प्रयास: जब आप चार्ज बनाते हैं तो तुरंत
- 2nd प्रयास: 3 दिन बाद
- 3rd प्रयास: 7 और दिनों के बाद (कुल 10 दिन)
- 4th प्रयास (अंतिम): 7 और दिनों के बाद (कुल 17 दिन)
बर्स्ट पुनः प्रयासों से बचें; प्राधिकरण समय के अनुसार संरेखित करें
- अपने पोर्टफोलियो में “बर्स्ट” व्यवहार से बचने के लिए पुनः प्रयासों को मूल प्राधिकरण टाइमस्टैम्प से जोड़ें।
- उदाहरण: यदि ग्राहक आज 1:10 बजे एक परीक्षण या जनादेश शुरू करता है, तो अपने बैकऑफ के अनुसार अगले प्रयासों को 1:10 बजे अगले दिनों में शेड्यूल करें (जैसे, +3 दिन → 1:10 बजे, +7 दिन → 1:10 बजे)।
- वैकल्पिक रूप से, यदि आप अंतिम सफल भुगतान समय को स्टोर करते हैं
T, तो समय-समय पर संरेखण बनाए रखने के लिए अगला प्रयासT + X daysपर शेड्यूल करें।
समय क्षेत्र और DST: अनुसूची के लिए एक सुसंगत समय मानक का उपयोग करें और केवल प्रदर्शित करने के लिए परिवर्तित करें ताकि अंतराल बनाए रखा जा सके।
अस्वीकृति कोड जिन पर आपको पुनः प्रयास नहीं करना चाहिए
STOLEN_CARDDO_NOT_HONORFRAUDULENTPICKUP_CARDAUTHENTICATION_FAILURELOST_CARD
अस्वीकृति कारणों की एक व्यापक सूची और क्या वे उपयोगकर्ता-सुधार योग्य हैं, के लिए देखें
लेनदेन विफलताएँ दस्तावेज़।
कार्यान्वयन दिशानिर्देश (कोई कोड नहीं)
- सटीक टाइमस्टैम्प को बनाए रखने के लिए एक शेड्यूलर/क्यू का उपयोग करें; अगले प्रयास को समय-समय पर ऑफसेट पर सटीक समय पर गणना करें (जैसे,
T + 3 daysउसी HH:MM पर)। - अंतिम सफल भुगतान टाइमस्टैम्प
Tको बनाए रखें और संदर्भित करें ताकि अगले प्रयास की गणना की जा सके; एक ही समय में कई सब्सक्रिप्शन को एकत्रित न करें। - हमेशा अंतिम अस्वीकृति कारण का मूल्यांकन करें; ऊपर दिए गए स्किप सूची में कठिन अस्वीकृतियों के लिए पुनः प्रयास रोकें।
- ग्राहक और प्रति खाता समवर्ती पुनः प्रयासों को सीमित करें ताकि आकस्मिक वृद्धि से बचा जा सके।
- सक्रिय रूप से संवाद करें: अगले निर्धारित प्रयास से पहले ग्राहक को उनके भुगतान विधि को अपडेट करने के लिए ईमेल/SMS करें।
- केवल अवलोकन के लिए मेटाडेटा का उपयोग करें (जैसे,
retry_attempt); कभी भी धोखाधड़ी/जोखिम प्रणालियों से “बचने” के लिए तुच्छ फ़ील्ड को घुमाने का प्रयास न करें।
वेबहुक के साथ परिणामों को ट्रैक करें
ग्राहक यात्रा को ट्रैक करने के लिए वेबहुक हैंडलिंग लागू करें। वेबहुक लागू करना देखें।- subscription.active: जनादेश अधिकृत और सब्सक्रिप्शन सक्रिय
- subscription.failed: निर्माण विफल (जैसे, जनादेश विफलता)
- subscription.on_hold: सब्सक्रिप्शन होल्ड पर रखा गया (जैसे, अनपेक्षित स्थिति)
- payment.succeeded: चार्ज सफल
- payment.failed: चार्ज विफल
परीक्षण और अगले कदम
परीक्षण मोड में बनाएं
अपने परीक्षण API कुंजी का उपयोग करके जनादेश के साथ सब्सक्रिप्शन बनाएं
payment_link: true, फिर लिंक खोलें और जनादेश पूरा करें।चार्ज ट्रिगर करें
एक छोटे
product_price (जैसे, 100) के साथ चार्ज एंडपॉइंट को कॉल करें और सत्यापित करें कि आपको payment.succeeded प्राप्त होता है।समस्या निवारण
- 422 अमान्य अनुरोध: सुनिश्चित करें कि निर्माण पर
on_demand.mandate_onlyप्रदान किया गया है और चार्ज के लिएproduct_priceप्रदान किया गया है। - मुद्रा त्रुटियाँ: यदि आप
product_currencyको ओवरराइड करते हैं, तो सुनिश्चित करें कि यह आपके खाते और ग्राहक के लिए समर्थित है। - कोई वेबहुक प्राप्त नहीं हुआ: अपने वेबहुक URL और सिग्नेचर गुप्त कुंजी कॉन्फ़िगरेशन की पुष्टि करें.