पूर्वापेक्षाएँ
डोडो पेमेंट्स API को एकीकृत करने के लिए, आपको आवश्यकता होगी:- एक डोडो पेमेंट्स व्यापारी खाता
- डैशबोर्ड से API क्रेडेंशियल्स (API कुंजी और वेबहुक गुप्त कुंजी)
API एकीकरण
चेकआउट सत्र
Use Checkout Sessions to sell subscription products with a secure, hosted checkout. Pass your subscription product inproduct_cart and redirect customers to the returned checkout_url.
- Node.js SDK
- Python SDK
- REST API
API प्रतिक्रिया
निम्नलिखित प्रतिक्रिया का एक उदाहरण है:checkout_url पर रीडायरेक्ट करें।
Webhooks
सब्सक्रिप्शन को एकीकृत करते समय, आपको सब्सक्रिप्शन जीवनचक्र को ट्रैक करने के लिए वेबहुक प्राप्त होंगे। ये वेबहूक आपको सब्सक्रिप्शन स्थितियों और भुगतान परिदृश्यों को प्रभावी ढंग से प्रबंधित करने में मदद करते हैं। अपना वेबहुक एंडपॉइंट सेट अप करने के लिए, कृपया हमारे विस्तृत इंटीग्रेशन गाइड का पालन करें।सब्सक्रिप्शन इवेंट प्रकार
निम्नलिखित वेबहूक इवेंट्स सब्सक्रिप्शन स्थिति परिवर्तनों को ट्रैक करते हैं:subscription.active- सब्सक्रिप्शन सफलतापूर्वक सक्रिय है।subscription.updated- सब्सक्रिप्शन ऑब्जेक्ट अपडेट किया गया था (किसी भी फ़ील्ड में बदलाव पर फायर होता है)।subscription.on_hold- असफल रिन्यूअल के कारण सब्सक्रिप्शन होल्ड पर है।subscription.failed- मैंडेट निर्माण के दौरान सब्सक्रिप्शन निर्माण विफल रहा।subscription.renewed- अगली बिलिंग अवधि के लिए सब्सक्रिप्शन का नवीनीकरण किया गया।
भुगतान परिदृश्य
सफल भुगतान प्रवाह आपको मिलने वाले webhooks और उनका समय इस बात पर निर्भर करता है कि product में trial है या नहीं। तत्काल billing (0 trial days):subscription.active: mandate अधिकृत हो जाता है और subscription सक्रिय हो जाती है।payment.succeeded: पहले charge की पुष्टि करता है। checkout के 2–10 मिनट के भीतर इसकी अपेक्षा करें।
- Trial शुरू होने पर (checkout): payment method अधिकृत होने के बाद
subscription.activefire होता है। अभी कोई recurring charge नहीं लिया जाता। पहला वास्तविक charge trial समाप्त होने तक टाल दिया जाता है। - Trial समाप्त होने पर: recurring amount charge किया जाता है और आपको
payment.succeededके साथ-साथsubscription.renewedभी मिलता है।
subscription.renewed: हर billing cycle पर fire होता है, जब renewal payment काटा जाता है, और यह हमेशाpayment.succeededके साथ होता है। इसमें updatednext_billing_dateभी शामिल होता है।
जब भी subscription product के लिए वास्तव में money काटा जाता है, आपको
subscription.renewed और payment.succeeded मिलते हैं। अगले cycle के लिए access बढ़ाने के संकेत के रूप में केवल subscription.renewed का उपयोग करें, न कि अकेले payment.succeeded का।- Subscription Failure
subscription.failed- mandate बनाने में विफलता के कारण subscription creation विफल हुआ।payment.failed- विफल payment को दर्शाता है।
- Subscription On Hold
subscription.on_hold- renewal payment या plan change charge विफल होने के कारण subscription को on hold कर दिया गया है।- जब subscription on hold हो जाती है, तो payment method update किए जाने तक वह अपने-आप renew नहीं होगी।
Best Practice: implementation को सरल बनाने के लिए, हम subscription lifecycle को manage करने हेतु मुख्य रूप से subscription events को track करने की सलाह देते हैं।
subscription.failed बनाम subscription.on_hold
इन दोनों events को आसानी से भ्रमित किया जा सकता है, लेकिन इनके लिए बहुत अलग handling आवश्यक है:
Subscription On Hold को संभालना
जब subscriptionon_hold state में प्रवेश करती है, तो उसे फिर से सक्रिय करने के लिए आपको payment method update करना होगा। यह section बताता है कि subscriptions कब on hold होती हैं और उन्हें कैसे handle करना है।
Subscriptions कब On Hold होती हैं
Subscription को on hold कर दिया जाता है जब:- Renewal payment विफल हो: अपर्याप्त funds, expired card या bank decline के कारण automatic renewal charge विफल हो जाता है
- Plan change charge विफल हो: plan upgrade/downgrade के दौरान किया गया तत्काल charge विफल हो जाता है
- Payment method authorization विफल हो: recurring charges के लिए payment method को authorize नहीं किया जा सकता
On Hold से Subscriptions को फिर से सक्रिय करना
Subscription कोon_hold state से फिर से सक्रिय करने के लिए Update Payment Method API का उपयोग करें। यह अपने-आप:
- शेष dues के लिए charge बनाता है
- Charge के लिए invoice बनाता है
- नए payment method का उपयोग करके payment process करता है
- Payment सफल होने पर subscription को
activestate में फिर से सक्रिय करता है
1
Handle subscription.on_hold webhook
जब आपको
subscription.on_hold webhook मिले, तो अपने application state को update करें और customer को सूचित करें:2
Update payment method
जब customer अपना payment method update करने के लिए तैयार हो, तो Update Payment Method API call करें:
यदि customer ने payment methods save किए हैं, तो आप मौजूदा payment method ID का भी उपयोग कर सकते हैं:
3
Monitor webhook events
Payment method update करने के बाद, इन webhook events पर नज़र रखें:
payment.succeeded- शेष dues का charge सफल रहाsubscription.active- subscription फिर से सक्रिय हो गई
Sample Subscription event payload
Subscription Plans बदलना
आप change plan API endpoint का उपयोग करके subscription plan को upgrade या downgrade कर सकते हैं। इससे आप subscription के product और quantity को modify कर सकते हैं और proration handle कर सकते हैं।Change Plan API Reference
Subscription plans बदलने की विस्तृत जानकारी के लिए, हमारे Change Plan API documentation को देखें।
Proration Options
Subscription plans बदलते समय, तत्काल charge को handle करने के लिए आपके पास दो options होते हैं:1. prorated_immediately
- मौजूदा billing cycle में बचे समय के आधार पर prorated amount calculate करता है
- Customer से पुराने और नए plan के बीच का अंतर ही charge करता है
- Trial period के दौरान, यह user को तुरंत नए plan पर switch कर देगा और customer से तुरंत charge लेगा
2. full_immediately
- नए plan के लिए customer से पूरी subscription amount charge करता है
- पिछले plan के बचे समय या credits को अनदेखा करता है
- तब उपयोगी है जब आप billing cycle reset करना चाहते हैं या proration की परवाह किए बिना पूरी amount charge करना चाहते हैं
3. difference_immediately
- Upgrade करते समय, customer से दोनों plan amounts के बीच का अंतर तुरंत charge किया जाता है।
- उदाहरण के लिए, यदि वर्तमान plan 30 Dollars का है और customer 80 Dollars वाले plan पर upgrade करता है, तो उससे तुरंत $50 charge किए जाते हैं।
- Downgrade करते समय, वर्तमान plan की unused amount को internal credit के रूप में जोड़ा जाता है और future subscription renewals पर अपने-आप लागू किया जाता है।
- उदाहरण के लिए, यदि वर्तमान plan 50 Dollars का है और customer 20 Dollars वाले plan पर switch करता है, तो शेष $30 credit के रूप में जोड़े जाते हैं और अगले billing cycle में उपयोग किए जाते हैं।
4. do_not_bill
- Plan change को तुरंत लागू करता है, लेकिन change के समय कुछ भी charge नहीं करता।
- Updated plan (और quantity/add-ons) को अगले scheduled renewal पर bill किया जाता है और मूल billing date बरकरार रहती है।
Behavior
- जब आप इस API को invoke करते हैं, तो Dodo Payments आपके चुने हुए proration option के आधार पर तुरंत charge शुरू करता है
- यदि plan change downgrade है और आप
prorated_immediatelyका उपयोग करते हैं, तो credits अपने-आप calculate होकर subscription के credit balance में जोड़े जाएंगे। ये credits उसी subscription के लिए specific हैं और केवल उसी subscription के future recurring payments को offset करने के लिए उपयोग किए जाएंगे full_immediatelyoption credit calculations को bypass करता है और नए plan की पूरी amount charge करता है
Charge Processing
- Plan change पर शुरू किया गया तत्काल charge आमतौर पर 2 मिनट से कम समय में processing पूरी कर लेता है
- यदि यह तत्काल charge किसी भी कारण से विफल होता है, तो issue हल होने तक subscription को अपने-आप on hold कर दिया जाता है
On-Demand Subscriptions
On-demand subscriptions आपको customers से केवल fixed schedule पर ही नहीं, बल्कि flexible तरीके से charge लेने देती हैं। यह feature सभी accounts के लिए उपलब्ध है।
on_demand field शामिल करें। इससे आप बिना तत्काल charge के payment method को authorize कर सकते हैं या custom initial price set कर सकते हैं।
On-demand subscription charge करने के लिए:
Subsequent charges के लिए, POST /subscriptions//charge endpoint का उपयोग करें और उस transaction के लिए customer से charge की जाने वाली amount specify करें।
पूरी step-by-step guide (जिसमें request/response examples, safe retry policies और webhook handling शामिल हैं) के लिए On-Demand Subscriptions Guide देखें।
Subscription Billing के बारे में मुख्य बातें
Trials में charge नहीं, बल्कि $0 authorization होता है। जब subscription में trial होता है, तो trial शुरू होने पर card save करने के लिए $0 mandate authorization बनाया जाता है; पहला वास्तविक charge trial समाप्त होने पर होता है। Payments list में trial पर मौजूद subscription के लिए
amount: 0 के साथ ठीक एक payment दिखाई देता है।Subscription lifecycle:
on_hold = renewal विफल हुआ (recoverable: customer से अपना payment method update करने को कहें; dunning retries लागू होती हैं)। expired = term बिना renewal के समाप्त हो गया और इसे फिर से सक्रिय नहीं किया जा सकता। Customer को फिर से subscribe करना होगा। cancelled = customer या merchant द्वारा समाप्त की गई। अधिकांश renewal failures issuer-side declines होते हैं (insufficient funds, card declined), Dodo की error नहीं।Related API Reference
Create Subscription
Subscription products बनाने और subscription lifecycle manage करने के लिए API reference
Change Subscription Plan
Proration options के साथ subscription plans को upgrade, downgrade या change करने के लिए API reference
Update Payment Method
Payment methods update करने और on-hold subscriptions को फिर से सक्रिय करने के लिए API reference
Patch Subscription
Subscription details और configuration update करने के लिए API reference