Skip to main content

आवश्यकताएँ

शुरू करने से पहले, आपके पास ये होना चाहिए:
  • 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
अधिक जानकारी के लिए Integration Guide Prerequisites देखें।

API Integration

Checkout Sessions

अपने subscription product के साथ checkout session बनाकर subscription बनाएँ। ग्राहक payment method को authorize करता है और checkout पूरा करने पर subscription सक्रिय हो जाती है।
आप उसी checkout session में subscription products को one-time products के साथ जोड़ सकते हैं। इससे setup fees, SaaS के साथ hardware bundles और इसी तरह के उपयोग संभव होते हैं। उदाहरणों के लिए Checkout Sessions देखें।

API Response

Response में एक checkout_url शामिल है:
ग्राहक को इस URL पर redirect करें। वह payment method को authorize करता है और subscription सक्रिय हो जाती है।

Webhooks

Subscription events होने पर webhooks आपके server को सूचित करते हैं। Dashboard में Developer → Webhooks के अंतर्गत अपना endpoint सेट अप करें। अपने webhook endpoint को सेट अप करने के लिए Webhooks देखें।

Subscription Event Types

Subscription lifecycle प्रबंधित करने के लिए इन events को track करें:
  1. subscription.active — Subscription सक्रिय हो गई
  2. subscription.updated — Subscription का कोई field बदल गया
  3. subscription.on_hold — Renewal या plan-change charge विफल हो गया
  4. subscription.failed — Subscription बनाना विफल हुआ (terminal; ग्राहक को फिर से subscribe करना होगा)
  5. subscription.renewed — Recurring charge सफल हुआ
  6. subscription.past_due — Renewal विफल हुआ और grace period शुरू हुआ; ग्राहक को past_due_ends_at तक access मिलता रहेगा
  7. subscription.plan_changed — Plan को upgrade, downgrade या बदला गया
  8. subscription.cancelled — Subscription रद्द कर दी गई
  9. subscription.expired — Subscription अपनी अवधि के अंत तक पहुँच गई
ये मुख्य events हैं। पूरी सूची के लिए, जिसमें paused, unpaused और update_payment_method शामिल हैं, Subscription Webhooks देखें।
किसी भी subscription बदलाव की real-time notifications पाने के लिए subscription.updated का उपयोग करें। इससे API को poll किए बिना आपका application state समन्वित रहता है।

Payment Scenarios

Successful Payment Flow Webhook sequence इस बात पर निर्भर करता है कि subscription में trial है या नहीं। Immediate billing (0 trial days):
  1. subscription.active: mandate authorize होता है और subscription सक्रिय हो जाती है।
  2. payment.succeeded: पहला charge confirm करता है। इसकी अपेक्षा checkout के 2–10 मिनट के भीतर करें।
With a trial period:
  1. Trial शुरू होने पर (checkout): Payment method authorize होने के बाद subscription.active fire होता है। अभी कोई recurring charge नहीं लिया जाता। पहला वास्तविक charge trial समाप्त होने तक टाल दिया जाता है।
  2. Trial समाप्त होने पर: Recurring amount charge किया जाता है और आपको payment.succeeded, subscription.renewed के साथ प्राप्त होता है।
Every subsequent renewal:
  • subscription.renewed: प्रत्येक billing cycle पर renewal payment कटने के समय fire होता है और हमेशा payment.succeeded के साथ आता है। इसमें updated next_billing_date भी शामिल होता है।
जब भी subscription product के लिए वास्तव में money deduct किया जाता है, आपको subscription.renewed और payment.succeeded मिलते हैं। अगले cycle के लिए access बढ़ाने के संकेत के रूप में केवल payment.succeeded के बजाय subscription.renewed का उपयोग करें।
Payment Failure Scenarios
  1. Subscription Failure
  • subscription.failed - Mandate बनाने में विफलता के कारण subscription बनाना विफल हुआ।
  • payment.failed - विफल payment को दर्शाता है।
  1. 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 करने की सलाह दी जाती है।
error_code/error_message को पढ़ने, retry करने का समय तय करने और failures को ग्राहकों के सामने दिखाने की पूरी जानकारी के लिए Handle Payment Failures देखें।

subscription.failed बनाम subscription.on_hold

इन दोनों events में आसानी से भ्रम हो सकता है, लेकिन इनके लिए बहुत अलग handling आवश्यक है:
subscription.failed terminal है। Subscription फिर से सक्रिय नहीं की जा सकती। ग्राहक को नई subscription बनानी होगी। यह event fire होने पर कभी भी entitlements न दें।

Handling Subscription On Hold

जब subscription on_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 नहीं किया जा सकता
on_hold state में subscriptions अपने-आप renew नहीं होंगी। Subscription को फिर से सक्रिय करने के लिए आपको payment method update करना होगा।

Reactivating Subscriptions from On Hold

Subscription को on_hold state से फिर से सक्रिय करने के लिए Update Payment Method API का उपयोग करें। यह अपने-आप:
  1. बकाया शेष राशि के लिए charge बनाता है
  2. Charge के लिए invoice बनाता है
  3. नए payment method से payment process करता है
  4. सफल payment के बाद subscription को active state में फिर से सक्रिय करता है
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 करें:
  1. payment.succeeded - शेष बकाया राशि का charge सफल हुआ
  2. 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 सुरक्षित रहती है
तीनों “charge now” modes billing cycle को reset करते हैं। prorated_immediately, difference_immediately और full_immediately subscription की next_billing_date को change date पर ले जाते हैं। केवल do_not_bill मूल renewal date बनाए रखता है, लेकिन इसमें तत्काल charge नहीं लिया जाता।

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_immediately option credit calculations को bypass करता है और नए plan की पूरी amount charge करता है
  • do_not_bill option change को तुरंत लागू करता है, लेकिन billing को अगली renewal date तक टालता है, जो सुरक्षित रहती है
Proration mode चुनना:
  • difference_immediately — ग्राहक price difference चुकाता है। यह सबसे predictable option है; cycle में बदलाव कब किया गया, charge समान रहता है।
  • prorated_immediately — ग्राहक को current cycle के केवल अप्रयुक्त समय का credit मिलता है। Cycle में बदलाव कब होता है, इसके अनुसार charge बदलता है।
  • full_immediately — ग्राहक नए plan की पूरी amount चुकाता है। पिछले cycle का कोई credit नहीं।
  • do_not_bill — अभी कोई charge नहीं। नए plan का billing अगली renewal पर होता है। मूल billing date सुरक्षित रखने वाला एकमात्र mode।

Charge Processing

  • Plan change पर शुरू किया गया immediate charge आमतौर पर 2 मिनट से कम समय में processing पूरी कर लेता है
  • यदि यह immediate charge किसी भी कारण से विफल होता है, तो समस्या हल होने तक subscription अपने-आप on hold कर दी जाती है

On-Demand Subscriptions

On-demand subscriptions आपको केवल fixed schedule पर ही नहीं, बल्कि लचीले तरीके से ग्राहकों से charge लेने देती हैं। यह सुविधा सभी accounts के लिए उपलब्ध है।
On-demand subscription बनाने के लिए: On-demand subscription बनाने के लिए POST /checkouts API endpoint का उपयोग करें और अपने request body में subscription_data.on_demand field शामिल करें। इससे आप बिना तत्काल charge के payment method authorize कर सकते हैं या custom initial price सेट कर सकते हैं।
POST /subscriptions deprecated है। यह मौजूदा integrations के लिए काम करता है, लेकिन नए integrations को subscription_data.on_demand के साथ Checkout Session (POST /checkouts) के माध्यम से on-demand subscriptions बनानी चाहिए। वर्तमान flow के लिए On-Demand Subscriptions Guide देखें।
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 के बारे में मुख्य बातें

Subscription period को payment frequency से अधिक लंबा रखें। यदि subscription period payment frequency के बराबर है (जैसे period = 1 month, frequency = 1 month), तो subscription एक single cycle के लिए valid रहती है और renew होने के बजाय expired में चली जाती है। Ongoing monthly plan के लिए monthly payment frequency के साथ लंबा subscription period (जैसे 20 years) सेट करें।
पहले सफल charge पर currency lock हो जाती है। Checkout बनाते समय हमेशा billing_currency और billing_address.country स्पष्ट रूप से pass करें। यदि इन्हें छोड़ा गया, तो वे ग्राहक के IP (Adaptive Currency) से detect किए जाते हैं और subscription का पहला charge होने के बाद currency उसके पूरे lifetime के लिए fix हो जाती है। बाद में यात्रा करने वाला ग्राहक इसे बदल नहीं सकता।
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 नहीं।
Indian cards RBI e-mandate पर चलते हैं। Off-session charges (renewals और plan-change charges) settle होने में लगभग 48 घंटे तक ले सकते हैं, और ₹15,000 से अधिक recurring auto-debits के लिए नए customer authentication की आवश्यकता होती है (इसलिए उस सीमा को पार करने वाला upgrade मौजूदा mandate का उपयोग नहीं कर सकता)। जब कोई charge अभी भी processing हो, तो उसी subscription पर दूसरा charge इस message के साथ विफल होता है: “Cannot create new charge as previous payment is not successful yet.” Non-Indian cards लगभग तुरंत confirm हो जाते हैं।
Subscription charges का minimum $1 (या currency equivalent) है। $0.01–$0.99 की amounts product_price: value out of range के साथ reject की जाती हैं। ठीक $0 price वाला subscription product allowed है; Card-Optional at Zero Price देखें। Card को charge किए बिना authorize करने के लिए on-demand mandate_only setup का उपयोग करें।

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
अंतिम संशोधन 26 सितंबर 2026