आवश्यकताएँ
शुरू करने से पहले, आपके पास ये होना चाहिए:- Dodo Payments merchant account
- Dashboard में Developer → API Keys से API key, जिसे
DODO_PAYMENTS_API_KEYमें संग्रहीत किया गया हो - Developer → Webhooks से webhook secret, जिसे
DODO_PAYMENTS_WEBHOOK_KEYमें संग्रहीत किया गया हो - Products के अंतर्गत बनाया गया कम से कम एक subscription product
API Integration
Checkout Sessions
अपने subscription product के साथ checkout session बनाकर subscription बनाएँ। ग्राहक payment method को authorize करता है और checkout पूरा करने पर subscription सक्रिय हो जाती है।- Node.js SDK
- Python SDK
- REST API
API Response
Response में एकcheckout_url शामिल है:
Webhooks
Subscription events होने पर webhooks आपके server को सूचित करते हैं। Dashboard में Developer → Webhooks के अंतर्गत अपना endpoint सेट अप करें। अपने webhook endpoint को सेट अप करने के लिए Webhooks देखें।Subscription Event Types
Subscription lifecycle प्रबंधित करने के लिए इन events को track करें:subscription.active— Subscription सक्रिय हो गईsubscription.updated— Subscription का कोई field बदल गयाsubscription.on_hold— Renewal या plan-change charge विफल हो गयाsubscription.failed— Subscription बनाना विफल हुआ (terminal; ग्राहक को फिर से subscribe करना होगा)subscription.renewed— Recurring charge सफल हुआsubscription.past_due— Renewal विफल हुआ और grace period शुरू हुआ; ग्राहक कोpast_due_ends_atतक access मिलता रहेगाsubscription.plan_changed— Plan को upgrade, downgrade या बदला गयाsubscription.cancelled— Subscription रद्द कर दी गईsubscription.expired— Subscription अपनी अवधि के अंत तक पहुँच गई
paused, unpaused और update_payment_method शामिल हैं, Subscription Webhooks देखें।
Payment Scenarios
Successful Payment Flow Webhook sequence इस बात पर निर्भर करता है कि subscription में trial है या नहीं। Immediate billing (0 trial days):subscription.active: mandate authorize होता है और subscription सक्रिय हो जाती है।payment.succeeded: पहला charge confirm करता है। इसकी अपेक्षा checkout के 2–10 मिनट के भीतर करें।
- Trial शुरू होने पर (checkout): Payment method authorize होने के बाद
subscription.activefire होता है। अभी कोई recurring charge नहीं लिया जाता। पहला वास्तविक charge trial समाप्त होने तक टाल दिया जाता है। - Trial समाप्त होने पर: Recurring amount charge किया जाता है और आपको
payment.succeeded,subscription.renewedके साथ प्राप्त होता है।
subscription.renewed: प्रत्येक billing cycle पर renewal payment कटने के समय fire होता है और हमेशाpayment.succeededके साथ आता है। इसमें updatednext_billing_dateभी शामिल होता है।
जब भी subscription product के लिए वास्तव में money deduct किया जाता है, आपको
subscription.renewed और payment.succeeded मिलते हैं। अगले cycle के लिए access बढ़ाने के संकेत के रूप में केवल payment.succeeded के बजाय subscription.renewed का उपयोग करें।- Subscription Failure
subscription.failed- Mandate बनाने में विफलता के कारण subscription बनाना विफल हुआ।payment.failed- विफल payment को दर्शाता है।
- Subscription On Hold
subscription.on_hold- Renewal payment या plan change charge विफल होने के कारण subscription on hold कर दी गई। यदि आपके business में grace period है, तो विफल renewal पहले subscription कोpast_due(subscription.past_due) में ले जाता है और grace period समाप्त होने पर ही इसेon_hold(या आपकी grace period settings के अनुसारcancelled) में ले जाता है। Subscription States देखें।- जब subscription on hold हो जाती है, तब payment method update होने तक वह अपने-आप renew नहीं होगी।
Best Practice: Implementation को सरल बनाने के लिए, subscription lifecycle प्रबंधित करने हेतु मुख्य रूप से subscription events को track करने की सलाह दी जाती है।
subscription.failed बनाम subscription.on_hold
इन दोनों events में आसानी से भ्रम हो सकता है, लेकिन इनके लिए बहुत अलग handling आवश्यक है:
Handling Subscription On Hold
जब subscriptionon_hold state में जाती है, तो उसे फिर से सक्रिय करने के लिए payment method update करना आवश्यक है। यह section बताता है कि subscriptions कब on hold होती हैं और उन्हें कैसे संभालना है।
When Subscriptions Go 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 नहीं किया जा सकता
Reactivating Subscriptions from On Hold
Subscription कोon_hold state से फिर से सक्रिय करने के लिए Update Payment Method API का उपयोग करें। यह अपने-आप:
- बकाया शेष राशि के लिए charge बनाता है
- Charge के लिए invoice बनाता है
- नए payment method से payment process करता है
- सफल payment के बाद subscription को
activestate में फिर से सक्रिय करता है
1
Handle subscription.on_hold webhook
जब आपको
subscription.on_hold webhook मिले, तो अपना application state update करें और ग्राहक को सूचित करें:2
Update payment method
जब ग्राहक अपना payment method update करने के लिए तैयार हो, तो Update Payment Method API call करें:
यदि ग्राहक ने payment methods save किए हैं, तो आप मौजूदा payment method ID का भी उपयोग कर सकते हैं:
3
Monitor webhook events
Payment method update करने के बाद, इन webhook events को monitor करें:
payment.succeeded- शेष बकाया राशि का charge सफल हुआsubscription.active- Subscription फिर से सक्रिय हो गई
Sample Subscription Event Payload
Changing Subscription Plans
आप change plan API endpoint का उपयोग करके subscription plan को upgrade या downgrade कर सकते हैं। इससे आप subscription का product और quantity बदल सकते हैं तथा proration संभाल सकते हैं।Change Plan API Reference
Subscription plans बदलने की विस्तृत जानकारी के लिए हमारे Change Plan API documentation को देखें।
Proration Options
Subscription plans बदलते समय तत्काल charge संभालने के लिए आपके पास चार options होते हैं:1. prorated_immediately
- वर्तमान billing cycle के अप्रयुक्त हिस्से का credit देता है, शेष समय के अनुसार prorate करके। Credit में base plan, quantity और add-ons शामिल होते हैं
- इसके बाद नए plan, quantity और add-ons के लिए पूर्ण cycle का charge लेता है। Charge स्वयं कभी prorate नहीं होता
- Net immediate charge = (पूर्ण नया cycle) minus (शेष fraction x पूर्ण पुराना cycle)। यदि credit बड़ा है, तो अंतर future renewals के लिए subscription-scoped credit के रूप में रखा जाता है
- Trial period के दौरान यह user को तुरंत नए plan पर switch करता है और ग्राहक से तुरंत charge लेता है
2. full_immediately
- पिछले cycle के लिए कोई credit दिए बिना नए plan की पूरी subscription amount charge करता है
- Upgrade या downgrade, दोनों में ग्राहक नए plan की पूरी कीमत शुरू से चुकाता है
- तब उपयोगी है जब आप पुराने plan में बचे समय की परवाह किए बिना पूरी amount charge करना चाहते हैं
3. difference_immediately
- ग्राहक पुराने plan price और नए plan price के बीच का केवल अंतर चुकाता है
- Amount इस पर निर्भर नहीं करती कि cycle में बदलाव कब किया गया। Day 1 और day 29 पर किया गया समान upgrade समान लागत रखता है
- Upgrade करते समय ग्राहक से अंतर तुरंत charge किया जाता है। उदाहरण: $30/month → $80/month = तुरंत $50 charge
- Downgrade करते समय price difference को subscription-scoped credit के रूप में रखा जाता है और future renewals में अपने-आप लागू किया जाता है। उदाहरण: $50/month → $20/month = $30 credit के रूप में रखा जाता है
4. do_not_bill
- Plan change तुरंत लागू करता है, लेकिन बदलाव के समय कोई charge नहीं लेता। नया plan, quantity और add-ons तुरंत उपयोग किए जा सकते हैं
- अभी charge न होने के कारण, upgrade ग्राहक को वर्तमान cycle के शेष समय के लिए higher plan निःशुल्क देता है। Downgrade तुरंत लागू होता है और पहले से भुगतान किए गए cycle के अप्रयुक्त हिस्से का कोई credit नहीं मिलता
do_not_billके माध्यम से दिए गए add-ons को बाद के plan change पर credit नहीं किया जाता, क्योंकि उनका कभी billing नहीं हुआ। बाद का change नए add-on quantity का पूरा charge लेता है- Updated plan (और quantity/add-ons) का billing अगले scheduled renewal पर होता है और मूल billing date सुरक्षित रहती है
Behavior
- इस API को invoke करने पर Dodo Payments आपके चुने हुए proration option के आधार पर तुरंत charge शुरू करता है
prorated_immediatelyके साथ, upgrade या downgrade दोनों में हर change पर current cycle के अप्रयुक्त हिस्से का credit calculate किया जाता है। यदि credit नए cycle charge से अधिक है, तो शेष राशि subscription के credit balance में जोड़ दी जाती है। ये credits उसी subscription के लिए विशिष्ट होते हैं और केवल उसी subscription के future recurring payments को offset करने के लिए उपयोग किए जाते हैंdifference_immediatelyके साथ net हमेशा exact price difference होता है। Downgrade के लिए अतिरिक्त राशि कोprorated_immediatelyकी तरह subscription-scoped credit के रूप में रखा जाता हैfull_immediatelyoption credit calculations को bypass करता है और नए plan की पूरी amount charge करता हैdo_not_billoption change को तुरंत लागू करता है, लेकिन billing को अगली renewal date तक टालता है, जो सुरक्षित रहती है
Charge Processing
- Plan change पर शुरू किया गया immediate charge आमतौर पर 2 मिनट से कम समय में processing पूरी कर लेता है
- यदि यह immediate charge किसी भी कारण से विफल होता है, तो समस्या हल होने तक subscription अपने-आप on hold कर दी जाती है
On-Demand Subscriptions
On-demand subscriptions आपको केवल fixed schedule पर ही नहीं, बल्कि लचीले तरीके से ग्राहकों से charge लेने देती हैं। यह सुविधा सभी accounts के लिए उपलब्ध है।
subscription_data.on_demand field शामिल करें। इससे आप बिना तत्काल charge के payment method authorize कर सकते हैं या custom initial price सेट कर सकते हैं।
On-demand subscription से charge लेने के लिए:
बाद के charges के लिए POST /subscriptions//charge endpoint का उपयोग करें और उस transaction के लिए ग्राहक से ली जाने वाली amount निर्दिष्ट करें।
पूरी 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 में free trial वाली subscription के लिए
total_amount 0 का ठीक एक payment दिखाई देता है। Paid trial इसके बजाय अपनी trial_amount upfront charge करती है।Subscription lifecycle:
past_due = renewal विफल हुआ और grace period चल रहा है (ग्राहक को access मिलता रहता है)। on_hold = renewal विफल हुआ (recoverable: ग्राहक से payment method update करने को कहें; dunning retries लागू होते हैं)। expired = term बिना renewal के समाप्त हुई और इसे फिर से सक्रिय नहीं किया जा सकता। ग्राहक को फिर से subscribe करना होगा। cancelled = ग्राहक या merchant द्वारा समाप्त की गई। अधिकांश renewal failures issuer-side declines होते हैं (अपर्याप्त funds, card declined), Dodo की error नहीं।Related API Reference
Create Subscription (Deprecated)
Subscription सीधे बनाने के लिए Legacy API। नए integrations के लिए Checkout Sessions का उपयोग करें
Change Subscription Plan
Proration options के साथ subscription plans को upgrade, downgrade या बदलने के लिए API reference
Update Payment Method
Payment methods update करने और on-hold subscriptions को फिर से सक्रिय करने के लिए API reference
Patch Subscription
Subscription details और configuration update करने के लिए API reference