अवलोकन
ऑन-डिमांड सब्सक्रिप्शन आपको एक ग्राहक के भुगतान विधि को एक बार अधिकृत करने और फिर जब भी आवश्यकता हो, परिवर्तनीय राशि चार्ज करने की अनुमति देता है, बजाय कि एक निश्चित कार्यक्रम पर।ऑन-डिमांड सब्सक्रिप्शन अब सभी व्यवसायों के लिए उपलब्ध हैं। यह सुविधा उपयोग-आधारित और मापी गई सेवाओं के लिए लचीले बिलिंग नियंत्रण को सक्षम बनाती है।
- एक ऑन-डिमांड सब्सक्रिप्शन बनाएं (वैकल्पिक प्रारंभिक मूल्य के साथ एक जनादेश अधिकृत करें)
- कस्टम राशि के साथ बाद के चार्ज को ट्रिगर करें
- वेबहुक का उपयोग करके परिणामों को ट्रैक करें
पूर्वापेक्षाएँ
- डोडो पेमेंट्स व्यापारी खाता और API कुंजी
- वेबहुक गुप्त कॉन्फ़िगर किया गया और घटनाओं को प्राप्त करने के लिए एक एंडपॉइंट
- आपके कैटलॉग में एक सब्सक्रिप्शन उत्पाद
ऑन-डिमांड कैसे काम करता है
- आप
on_demandऑब्जेक्ट के साथ एक सब्सक्रिप्शन बनाते हैं ताकि एक भुगतान विधि को अधिकृत किया जा सके और वैकल्पिक रूप से एक प्रारंभिक शुल्क एकत्र किया जा सके। - बाद में, आप समर्पित चार्ज एंडपॉइंट का उपयोग करके उस सब्सक्रिप्शन के खिलाफ कस्टम राशि के साथ चार्ज बनाते हैं।
- आप वेबहुक (जैसे,
payment.succeeded,payment.failed) को सुनते हैं ताकि अपने सिस्टम को अपडेट कर सकें।
एक ऑन-डिमांड सब्सक्रिप्शन बनाएं
एंडपॉइंट: POST /subscriptions मुख्य अनुरोध फ़ील्ड (शरीर):अनुरोध शरीर पैरामीटर
अनुरोध शरीर पैरामीटर
सब्सक्रिप्शन के लिए उत्पाद ID।
इकाइयों की संख्या। न्यूनतम 1।
ग्राहक के लिए बिलिंग पता।
या तो एक मौजूदा ग्राहक को संलग्न करें या ग्राहक विवरण प्रदान करें।
यदि सत्य है, तो जनादेश प्राधिकरण और वैकल्पिक प्रारंभिक भुगतान के लिए एक होस्टेड चेकआउट लिंक बनाता है।
होस्टेड चेकआउट पूरा करने के बाद ग्राहक को पुनर्निर्देशित करने के लिए।
यदि सत्य है, तो निर्माण के दौरान ग्राहक को चार्ज किए बिना भुगतान विधि को अधिकृत करता है।
प्रारंभिक शुल्क राशि (सबसे छोटे मुद्रा इकाई में)। यदि निर्दिष्ट किया गया है, तो यह मान उत्पाद निर्माण के दौरान सेट की गई उत्पाद की मूल कीमत को ओवरराइड करता है। यदि छोड़ा गया, तो उत्पाद की संग्रहीत कीमत का उपयोग किया जाता है। उदाहरण: $1.00 चार्ज करने के लिए,
100 पास करें।प्रारंभिक शुल्क के लिए वैकल्पिक मुद्रा ओवरराइड। उत्पाद मुद्रा पर डिफ़ॉल्ट।
बिलिंग और लाइन आइटम के लिए वैकल्पिक विवरण ओवरराइड।
यदि सत्य है, तो
product_price के भीतर अनुकूलनात्मक मुद्रा शुल्क शामिल हैं। यदि गलत है, तो शुल्क ऊपर जोड़े जाते हैं। जब अनुकूलनात्मक मूल्य निर्धारण अक्षम होता है तो अनदेखा किया जाता है।एक ऑन-डिमांड सब्सक्रिप्शन बनाएं
- Node.js SDK
- Python SDK
- Go SDK
- cURL
payment_link: true सेट करें, ग्राहक को payment_link पर पुनर्निर्देशित करें ताकि जनादेश प्राधिकरण पूरा हो सके।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
अस्वीकृति कारणों की एक व्यापक सूची और क्या वे उपयोगकर्ता-सुधार योग्य हैं, के लिए देखें
Transaction Failures दस्तावेज़।
कार्यान्वयन दिशानिर्देश (कोई कोड नहीं)
- एक शेड्यूलर/क्यू का उपयोग करें जो सटीक टाइमस्टैम्प को बनाए रखता है; अगले प्रयास को समय-समय पर ऑफसेट पर सटीक समय पर गणना करें (जैसे,
T + 3 daysउसी HH:MM पर)। - अंतिम सफल भुगतान टाइमस्टैम्प
Tको बनाए रखें और संदर्भित करें ताकि अगले प्रयास की गणना की जा सके; एक ही समय में कई सब्सक्रिप्शन को एकत्रित न करें। - हमेशा अंतिम अस्वीकृति कारण का मूल्यांकन करें; ऊपर दिए गए स्किप सूची में कठिन अस्वीकृतियों के लिए पुनः प्रयास रोकें।
- आकस्मिक वृद्धि को रोकने के लिए प्रति ग्राहक और प्रति खाता समवर्ती पुनः प्रयासों को सीमित करें।
- सक्रिय रूप से संवाद करें: ग्राहक को अगले निर्धारित प्रयास से पहले उनके भुगतान विधि को अपडेट करने के लिए ईमेल/SMS करें।
- केवल अवलोकन के लिए मेटाडेटा का उपयोग करें (जैसे,
retry_attempt); कभी भी धोखाधड़ी/जोखिम प्रणालियों से “बचने” के लिए तुच्छ फ़ील्ड को घुमाने की कोशिश न करें।
वेबहुक के साथ परिणामों को ट्रैक करें
ग्राहक यात्रा को ट्रैक करने के लिए वेबहुक हैंडलिंग लागू करें। वेबहुक लागू करना देखें।- subscription.active: जनादेश अधिकृत और सब्सक्रिप्शन सक्रिय
- subscription.failed: निर्माण विफल (जैसे, जनादेश विफलता)
- subscription.on_hold: सब्सक्रिप्शन होल्ड पर रखा गया (जैसे, अनपेक्षित स्थिति)
- payment.succeeded: चार्ज सफल
- payment.failed: चार्ज विफल
परीक्षण और अगले कदम
1
परीक्षण मोड में बनाएं
अपने परीक्षण API कुंजी का उपयोग करके
payment_link: true के साथ सब्सक्रिप्शन बनाएं, फिर लिंक खोलें और जनादेश पूरा करें।2
चार्ज ट्रिगर करें
एक छोटे
product_price (जैसे, 100) के साथ चार्ज एंडपॉइंट को कॉल करें और सत्यापित करें कि आपको payment.succeeded प्राप्त होता है।3
लाइव जाएं
एक बार जब आप घटनाओं और आंतरिक स्थिति अपडेट को मान्य कर लें, तो अपने लाइव API कुंजी पर स्विच करें।
समस्या निवारण
- 422 अमान्य अनुरोध: सुनिश्चित करें कि निर्माण पर
on_demand.mandate_onlyप्रदान किया गया है और चार्ज के लिएproduct_priceप्रदान किया गया है। - मुद्रा त्रुटियाँ: यदि आप
product_currencyको ओवरराइड करते हैं, तो सुनिश्चित करें कि यह आपके खाते और ग्राहक के लिए समर्थित है। - कोई वेबहुक प्राप्त नहीं हुए: अपने वेबहुक URL और हस्ताक्षर गुप्त कॉन्फ़िगरेशन की जांच करें.