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 product को one-time products के साथ जोड़ सकते हैं। इससे setup fees, SaaS के साथ hardware bundles और इसी तरह के उपयोग संभव होते हैं। उदाहरणों के लिए Checkout Sessions देखें।आप एक ही checkout में दो या अधिक subscription products भी बेच सकते हैं। ग्राहक एक बार भुगतान करता है और प्रत्येक product के लिए एक स्वतंत्र subscription प्राप्त करता है, जिसका अपना billing cycle होता है। ऐसे cart में one-time products नहीं रखे जा सकते। Multi-Subscription Cart देखें।

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 को manage करने के लिए इन events को track करें:
  1. subscription.active — Subscription सक्रिय हो गई
  2. subscription.updated — Subscription का कोई field बदल गया
  3. subscription.on_hold — Renewal या plan-change charge विफल हो गया
  4. subscription.failed — Subscription creation विफल हुआ (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 cancel कर दी गई
  9. subscription.expired — Subscription अपनी अवधि के अंत तक पहुँच गई
ये मुख्य events हैं। पूरी सूची के लिए, जिसमें paused, unpaused और update_payment_method शामिल हैं, Subscription Webhooks देखें।
किसी भी subscription बदलाव के बारे में real-time notifications पाने के लिए subscription.updated का उपयोग करें। इससे API को poll किए बिना आपका application state sync में रहता है।

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. At trial start (checkout): Payment method authorize होने के बाद subscription.active fire होता है। अभी कोई recurring charge नहीं लिया जाता। पहला वास्तविक charge trial समाप्त होने तक स्थगित रहता है।
  2. At trial end: Recurring amount charge किया जाता है और आपको payment.succeeded के साथ subscription.renewed प्राप्त होता है।
Every subsequent renewal:
  • subscription.renewed: प्रत्येक billing cycle पर fire होता है, जब renewal payment काटा जाता है, और हमेशा payment.succeeded के साथ आता है। इसमें updated next_billing_date भी शामिल होता है।
जब भी subscription product के लिए वास्तव में धन काटा जाता है, आपको subscription.renewed और payment.succeeded प्राप्त होते हैं। अगले cycle के लिए access बढ़ाने के signal के रूप में केवल subscription.renewed का उपयोग करें, payment.succeeded का अकेले नहीं।
Payment Failure Scenarios
  1. Subscription Failure
  • subscription.failed - Mandate create न हो पाने के कारण subscription creation विफल हुआ।
  • payment.failed - Failed payment दर्शाता है।
  1. Subscription On Hold
  • subscription.on_hold - Failed renewal payment या failed plan change charge के कारण subscription को on hold कर दिया गया है। यदि आपके business में grace period है, तो failed 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 manage करते समय मुख्य रूप से subscription events को track करने की सलाह दी जाती है।
error_code/error_message को पढ़ने, retry कब करना है यह तय करने और failures को customers तक पहुँचाने के पूरे walkthrough के लिए Handle Payment Failures देखें।

subscription.failed vs. 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 होती हैं और उन्हें कैसे handle करना है।

When Subscriptions Go On Hold

Subscription को on hold किया जाता है जब:
  • Renewal payment fails: अपर्याप्त funds, expired card या bank decline के कारण automatic renewal charge विफल हो जाता है
  • Plan change charge fails: Plan upgrade/downgrade के दौरान immediate charge विफल हो जाता है
  • Payment method authorization fails: Payment method को recurring charges के लिए authorize नहीं किया जा सकता
on_hold state में subscriptions अपने-आप renew नहीं होंगी। Subscription को फिर से सक्रिय करने के लिए आपको payment method update करना होगा।

Reactivating Subscriptions from On Hold

Subscription को on_hold state से फिर से सक्रिय करने के लिए Update Payment Method API का उपयोग करें। यह अपने-आप:
  1. शेष dues के लिए charge बनाता है
  2. Charge के लिए invoice generate करता है
  3. नए payment method का उपयोग करके payment process करता है
  4. Payment सफल होने पर subscription को active state में फिर से सक्रिय करता है
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 पर नज़र रखें:
  1. payment.succeeded - शेष dues का charge सफल हुआ
  2. subscription.active - Subscription फिर से सक्रिय हो गई

Sample Subscription Event Payload


Changing Subscription Plans

आप change plan API endpoint का उपयोग करके subscription plan को upgrade या downgrade कर सकते हैं। इससे आप subscription के product, quantity को संशोधित कर सकते हैं और proration handle कर सकते हैं।

Change Plan API Reference

Subscription plans बदलने की विस्तृत जानकारी के लिए हमारी Change Plan API documentation देखें।

Proration Options

Subscription plans बदलते समय immediate charge handle करने के लिए आपके पास चार options होते हैं:

1. prorated_immediately

  • वर्तमान billing cycle के unused हिस्से का समय शेष रहने के आधार पर prorated credit देता है। Credit base plan, quantity और किसी भी add-ons को cover करता है
  • फिर नए plan, quantity और add-ons पर एक full cycle का charge लेता है। Charge स्वयं कभी prorated नहीं होता
  • Net immediate charge = (full new cycle) minus (remaining fraction x full old cycle)। यदि credit बड़ा है, तो अंतर future renewals के लिए subscription-scoped credit के रूप में रखा जाता है
  • Trial period के दौरान यह user को तुरंत नए plan पर switch कर देता है और customer से तुरंत charge लेता है

2. full_immediately

  • Previous cycle के लिए कोई credit दिए बिना नए plan की पूरी subscription amount customer से charge करता है
  • Upgrade या downgrade दोनों में customer नए plan की पूरी price शुरू से चुकाता है
  • तब उपयोगी है जब पुराने plan में कितना समय बचा है, इसकी परवाह किए बिना पूरी amount charge करनी हो

3. difference_immediately

  • Customer पुराने plan की price और नए plan की price के बीच का केवल अंतर चुकाता है
  • Amount इस पर निर्भर नहीं करती कि cycle में बदलाव कब किया गया। Day 1 और day 29 पर एक ही upgrade की cost समान रहती है
  • Upgrade करते समय customer से अंतर तुरंत charge किया जाता है। उदाहरण के लिए, $30/month → $80/month = तुरंत $50 charge
  • Downgrade करते समय price difference subscription-scoped credit के रूप में store होता है और future renewals पर अपने-आप apply होता है। उदाहरण के लिए, $50/month → $20/month = $30 credit के रूप में store

4. do_not_bill

  • Plan change तुरंत apply करता है, लेकिन बदलाव के समय कुछ भी charge नहीं करता। नया plan, quantity और add-ons तुरंत उपयोग किए जा सकते हैं
  • क्योंकि अभी कोई charge नहीं लिया जाता, इसलिए upgrade customer को वर्तमान cycle के शेष समय के लिए higher plan free देता है। Downgrade तुरंत प्रभावी होता है और पहले से भुगतान किए गए cycle के unused हिस्से के लिए कोई credit नहीं मिलता
  • do_not_bill के माध्यम से दिए गए add-ons को बाद के plan change पर credit नहीं किया जाता, क्योंकि उनका कभी billing नहीं हुआ। अगला change नई add-on quantity को पूरी तरह bill करता है
  • Updated plan (और quantity/add-ons) को अगले scheduled renewal पर bill किया जाता है और original billing date सुरक्षित रहती है
सभी तीन “charge now” modes billing cycle को reset करते हैं। prorated_immediately, difference_immediately और full_immediately subscription की next_billing_date को change date पर ले जाते हैं। केवल do_not_bill original renewal date को बनाए रखता है, लेकिन यह कोई immediate charge apply नहीं करता।

Behavior

  • जब आप इस API को invoke करते हैं, तो Dodo Payments आपके चुने हुए proration option के आधार पर तुरंत charge शुरू करता है
  • prorated_immediately के साथ, current cycle के unused हिस्से का credit हर change पर calculate किया जाता है, चाहे upgrade हो या downgrade। यदि credit नए cycle के charge से अधिक है, तो शेष राशि subscription के credit balance में जोड़ दी जाती है। ये credits उसी subscription के लिए specific होते हैं और केवल उसी subscription के future recurring payments को offset करने के लिए उपयोग किए जाएंगे
  • difference_immediately के साथ net हमेशा exact price difference होता है। Downgrade के लिए excess को subscription-scoped credit के रूप में store किया जाता है, ठीक prorated_immediately की तरह
  • full_immediately option credit calculations को bypass करता है और नए plan की पूरी amount charge करता है
  • do_not_bill option बदलाव को तुरंत apply करता है, लेकिन billing को preserved next renewal date तक स्थगित करता है
Proration mode चुनना:
  • difference_immediately — customer price difference चुकाता है। सबसे predictable option; cycle में बदलाव कब किया गया, इसकी परवाह किए बिना charge समान रहता है।
  • prorated_immediately — customer को current cycle के केवल unused time का credit मिलता है। Cycle में बदलाव कब होता है, इसके आधार पर charge बदलता है।
  • full_immediately — customer नए plan की पूरी amount चुकाता है। Previous cycle के लिए कोई credit नहीं।
  • do_not_bill — अभी कोई charge नहीं। नए plan को अगले renewal पर bill किया जाता है। Original billing date को preserve करने वाला एकमात्र mode।

Charge Processing

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

On-Demand Subscriptions

On-demand subscriptions आपको customers से केवल fixed schedule पर ही नहीं, बल्कि flexible तरीके से charge करने देती हैं। यह feature सभी accounts के लिए उपलब्ध है।
On-demand subscription बनाने के लिए: On-demand subscription बनाने के लिए POST /checkouts API endpoint का उपयोग करें और अपने request body में subscription_data.on_demand field शामिल करें। इससे आप बिना immediate 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 करने के लिए: 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 के बारे में जानने योग्य मुख्य बातें

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) सेट करें।
पहले successful charge पर currency lock हो जाती है। Checkout बनाते समय हमेशा billing_currency और billing_address.country explicitly pass करें। यदि इन्हें छोड़ दिया जाता है, तो वे customer के IP (Adaptive Currency) से detect होते हैं और subscription का पहला charge होने के बाद currency उसके पूरे lifetime के लिए fixed हो जाती है। बाद में यात्रा करने वाला customer इसे बदल नहीं सकता।
Trials में charge नहीं, बल्कि $0 authorization होती है। जब subscription में trial होता है, तो trial start पर card save करने के लिए $0 mandate authorization बनाई जाती है; पहला वास्तविक charge trial समाप्त होने पर होता है। Payments list में free trial वाली subscription में total_amount की exactly एक payment दिखाई देती है, जिसकी amount 0 होती है। Paid trial इसके बजाय अपनी trial_amount upfront charge करती है।
Subscription lifecycle: past_due = renewal विफल हुई और grace period चल रही है (customer को access मिलता रहता है)। on_hold = renewal विफल हुई (recoverable: customer को payment method update करने के लिए prompt करें; dunning retries लागू होते हैं)। expired = term बिना renewal के समाप्त हो गई और इसे फिर से सक्रिय नहीं किया जा सकता। Customer को फिर से subscribe करना होगा। cancelled = customer या merchant द्वारा समाप्त की गई। अधिकांश renewal failures issuer-side declines होते हैं (insufficient funds, card declined), Dodo error नहीं।
Indian cards RBI e-mandate पर चलते हैं। Off-session charges (renewals और plan-change charges) settle होने में लगभग 48 घंटे तक ले सकते हैं, और ₹15,000 से अधिक के recurring auto-debits के लिए fresh customer authentication आवश्यक है (इसलिए उस सीमा को पार करने वाला upgrade मौजूदा mandate पर नहीं चल सकता)। जब एक charge अभी भी processing हो, तो उसी subscription पर दूसरा charge इस संदेश के साथ विफल हो जाता है: “Cannot create new charge as previous payment is not successful yet.” Non-Indian cards लगभग तुरंत confirm हो जाते हैं।
Subscriptions की USD में न्यूनतम राशि $1.00 है। इससे कम total होने पर Checkout TOTAL_PAYMENT_AMOUNT_BELOW_MINIMUM_AMOUNT के साथ reject करता है। USD, EUR और GBP के अलावा अन्य currencies की value भी कम से कम $1.00 होनी चाहिए; Minimum Amounts देखें। Smallest currency unit में 100 से कम का on-demand charge product_price, 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
अंतिम संशोधन 8 अक्टूबर 2026