Skip to main content

पूर्वापेक्षाएँ

डोडो पेमेंट्स API को एकीकृत करने के लिए, आपको आवश्यकता होगी:
  • एक डोडो पेमेंट्स व्यापारी खाता
  • डैशबोर्ड से API क्रेडेंशियल्स (API कुंजी और वेबहुक गुप्त कुंजी)
पूर्वापेक्षाओं पर अधिक विस्तृत गाइड के लिए, इस अनुभाग की जांच करें।

API एकीकरण

चेकआउट सत्र

Use Checkout Sessions to sell subscription products with a secure, hosted checkout. Pass your subscription product in product_cart and redirect customers to the returned checkout_url.
Mixed Checkout: आप एक ही चेकआउट सत्र में subscription उत्पादों को एक-बार के उत्पादों के साथ मिला सकते हैं। यह सेटअप शुल्क के साथ subscription, हार्डवेयर बंडल्स के साथ SaaS, और अन्य उपयोग-मामलों को सक्षम करता है। उदाहरणों के लिए Checkout Sessions guide देखें।

API प्रतिक्रिया

निम्नलिखित प्रतिक्रिया का एक उदाहरण है:
ग्राहक को checkout_url पर रीडायरेक्ट करें।

Webhooks

सब्सक्रिप्शन को एकीकृत करते समय, आपको सब्सक्रिप्शन जीवनचक्र को ट्रैक करने के लिए वेबहुक प्राप्त होंगे। ये वेबहूक आपको सब्सक्रिप्शन स्थितियों और भुगतान परिदृश्यों को प्रभावी ढंग से प्रबंधित करने में मदद करते हैं। अपना वेबहुक एंडपॉइंट सेट अप करने के लिए, कृपया हमारे विस्तृत इंटीग्रेशन गाइड का पालन करें।

सब्सक्रिप्शन इवेंट प्रकार

निम्नलिखित वेबहूक इवेंट्स सब्सक्रिप्शन स्थिति परिवर्तनों को ट्रैक करते हैं:
  1. subscription.active - सब्सक्रिप्शन सफलतापूर्वक सक्रिय है।
  2. subscription.updated - सब्सक्रिप्शन ऑब्जेक्ट अपडेट किया गया था (किसी भी फ़ील्ड में बदलाव पर फायर होता है)।
  3. subscription.on_hold - असफल रिन्यूअल के कारण सब्सक्रिप्शन होल्ड पर है।
  4. subscription.failed - मैंडेट निर्माण के दौरान सब्सक्रिप्शन निर्माण विफल रहा।
  5. subscription.renewed - अगली बिलिंग अवधि के लिए सब्सक्रिप्शन का नवीनीकरण किया गया।
विश्वसनीय सब्सक्रिप्शन जीवनचक्र प्रबंधन के लिए, हम इन सब्सक्रिप्शन इवेंट्स को ट्रैक करने की सिफारिश करते हैं।
समय पर सब्सक्रिप्शन परिवर्तनों के बारे में सूचनाएं प्राप्त करने के लिए subscription.updated का उपयोग करें, API के बिना पोलिंग के अपने एप्लिकेशन की स्थिति को समकालिक रखने के लिए।

भुगतान परिदृश्य

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

subscription.failed बनाम subscription.on_hold

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

Subscription On Hold को संभालना

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

On Hold से Subscriptions को फिर से सक्रिय करना

Subscription को on_hold state से फिर से सक्रिय करने के लिए Update Payment Method API का उपयोग करें। यह अपने-आप:
  1. शेष dues के लिए 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 करें और 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


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 बरकरार रहती है
तीनों “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 शुरू करता है
  • यदि plan change downgrade है और आप prorated_immediately का उपयोग करते हैं, तो credits अपने-आप calculate होकर subscription के credit balance में जोड़े जाएंगे। ये credits उसी subscription के लिए specific हैं और केवल उसी subscription के future recurring payments को offset करने के लिए उपयोग किए जाएंगे
  • full_immediately option credit calculations को bypass करता है और नए plan की पूरी amount charge करता है
अपना proration option सावधानी से चुनें: unused time को ध्यान में रखते हुए fair billing के लिए prorated_immediately का उपयोग करें, या मौजूदा billing cycle की परवाह किए बिना नए plan की पूरी amount charge करने के लिए full_immediately का उपयोग करें।

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 subscription बनाने के लिए: On-demand subscription बनाने के लिए, POST /subscriptions API endpoint का उपयोग करें और अपने request body में 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 के बारे में मुख्य बातें

Subscription period को payment frequency से अधिक लंबा रखें। यदि subscription period payment frequency के बराबर है (जैसे period = 1 month, frequency = 1 month), तो subscription एक single cycle के लिए valid रहती है और renew होने के बजाय expired में चली जाती है। लगातार चलने वाले monthly plan के लिए, monthly payment frequency के साथ लंबी subscription period (जैसे 20 years) set करें।
पहले successful charge पर currency lock हो जाती है। Checkout बनाते समय हमेशा billing_currency और billing_address.country को explicitly pass करें। यदि इन्हें omit किया जाता है, तो ये customer के IP (Adaptive Currency) से detect किए जाते हैं और subscription का पहला charge लेने के बाद currency उसके पूरे lifetime के लिए fixed हो जाती है। बाद में यात्रा करने वाला customer इसे switch नहीं कर सकता।
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 नहीं।
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 “Cannot create new charge as previous payment is not successful yet.” error के साथ विफल हो जाता है। Non-Indian cards लगभग तुरंत confirm हो जाते हैं।
Subscription charges के लिए $1 minimum है (या currency equivalent)। $0.01–$0.99 की amounts को product_price: value out of range के साथ reject किया जाता है; केवल $0 की अनुमति है, वह भी on-demand mandate_only setup के माध्यम से।

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
अंतिम संशोधन 31 जुलाई 2026