Change Plan API
Plan Change Preview
Integration Guide
What is a subscription upgrade or downgrade?
Changing plans lets you move a customer between subscription tiers or quantities. Use it to:- Align pricing with usage or features
- Move from monthly to annual (or vice versa)
- Adjust quantity for seat-based products
When to use plan changes
- Upgrade when a customer needs more features, usage, or seats
- Downgrade when usage decreases
- Migrate users to a new product or price without cancelling their subscription
Plan Change Flow
Prerequisites
Before implementing subscription plan changes, ensure you have:- A Dodo Payments merchant account with active subscription products
- API credentials (API key and webhook secret key) from the dashboard
- An existing active subscription to modify
- Webhook endpoint configured to handle subscription events
Step-by-Step Implementation Guide
Follow this comprehensive guide to implement subscription plan changes in your application:Understand Plan Change Requirements
- Which subscription products can be changed to which others
- What proration mode fits your business model
- How to handle failed plan changes gracefully
- Which webhook events to track for state management
Choose Your Proration Strategy
- prorated_immediately
- difference_immediately
- full_immediately
- do_not_bill
- Calculates exact prorated amount based on remaining cycle time
- Charges a prorated amount based on unused time remaining in the cycle
- Provides transparent billing to customers
Implement the Change Plan API
prorated_immediately, full_immediately, difference_immediately, or do_not_bill.prevent_change: Keep subscription on current plan until payment succeedsapply_change(default): Apply plan change immediately regardless of payment outcome
- Not provided /
null— मौजूदा छूटेंpreserve_on_plan_change=trueके साथ सुरक्षित रहती हैं यदि नए उत्पाद पर लागू होती हैं। [](खाली ऐरे) — सदस्यता से सभी मौजूदा छूटें हटा देता है।["CODE_A", "CODE_B", ...]— किसी भी मौजूदा छूट को इस स्टैक्ड सेट के साथ बदल देता है।
discount_codes को प्राथमिकता दें। यह फ़ील्ड बैकवर्ड संगतता के लिए अभी भी काम करता है, लेकिन इसे उसी अनुरोध में discount_codes के साथ संयोजित नहीं किया जा सकता।immediately(डिफ़ॉल्ट): प्लान परिवर्तन तुरंत लागू करेंnext_billing_date: अगले बिलिंग दिनांक के लिए परिवर्तन शेड्यूल करें। ग्राहक अपना वर्तमान प्लान बिलिंग अवधि समाप्त होने तक बनाए रखता है।
next_billing_date का उपयोग करें ताकि ग्राहक अपनी वर्तमान प्लान लाभों को बिलिंग अवधि के अंत तक रख सकें।Handle Webhook Events
subscription.active: प्लान परिवर्तन सफल, सदस्यता अपडेट हुईsubscription.plan_changed: सदस्यता प्लान बदला (अपग्रेड/डाउनग्रेड/एडऑन अपडेट)subscription.on_hold: प्लान परिवर्तन चार्ज विफल, सदस्यता रुकीpayment.succeeded: प्लान परिवर्तन के लिए तत्काल चार्ज सफलpayment.failed: तत्काल चार्ज विफल
Update Your Application State
- नए प्लान के आधार पर सुविधाएं प्रदान/रद्द करें
- नए प्लान विवरण के साथ ग्राहक डैशबोर्ड अपडेट करें
- प्लान परिवर्तनों के बारे में पुष्टिकरण ईमेल भेजें
- ऑडिट उद्देश्यों के लिए बिलिंग परिवर्तन लॉग करें
Test and Monitor
- विभिन्न परिदृश्यों के साथ सभी प्ररोशन मोड का परीक्षण करें
- वेबहूक हैंडलिंग सही ढंग से काम करता है यह सुनिश्चित करें
- प्लान परिवर्तन सफलता दर की निगरानी करें
- असफल प्लान परिवर्तनों के लिए अलर्ट सेट करें
प्लान परिवर्तन पूर्वावलोकन
प्लान परिवर्तन के लिए प्रतिबद्ध होने से पहले, ग्राहकों को सही ढंग से दिखाने के लिए प्रीव्यू API का उपयोग करें कि उनसे कितना शुल्क लिया जाएगा:- Node.js SDK
- Python SDK
प्लान चेंज API
एक सक्रिय सदस्यता के लिए उत्पाद, मात्रा और प्ररोशन व्यवहार को संशोधित करने के लिए प्लान चेंज API का उपयोग करें।त्वरित प्रारंभ उदाहरण
- Node.js SDK
- Python SDK
- Go SDK
- HTTP
invoice_id और payment_id जैसी फ़ील्ड्स केवल तभी रिटर्न की जाती हैं जब प्लान परिवर्तन के दौरान तत्काल चार्ज और/या इनवॉइस बनाई जाती है। परिणामों की पुष्टि के लिए हमेशा वेबहूक घटनाओं पर भरोसा करें (उदा., payment.succeeded, subscription.plan_changed)।एडऑन्स का प्रबंधन
जब आप सदस्यता प्लानों को बदलते हैं, तो आप एडऑन्स को भी संशोधित कर सकते हैं:छूट कोड लागू करना
सदस्यता प्लानों में परिवर्तन करते समय आप एक या अधिक स्टैक्ड छूट कोड लागू कर सकते हैं (अधिकतम 20, ऐरे क्रम में लागू)। यह अपग्रेड या माइग्रेशन पर प्रोमोशनल मूल्य पेश करने के लिए उपयोगी है।- Node.js SDK
- Python SDK
- HTTP
प्लान परिवर्तन पर छूट व्यवहार
discount_codes मान | व्यवहार |
|---|---|
Not provided / null | मौजूदा छूटें preserve_on_plan_change=true के साथ स्वतः सुरक्षित रहती हैं यदि नए उत्पाद पर लागू होती हैं। |
[] (खाली ऐरे) | सभी मौजूदा छूटें सदस्यता से हटा दी जाती हैं। |
["CODE_A", "CODE_B", ...] | इस स्टैक्ड सेट के साथ किसी भी मौजूदा छूट को बदल देता है, अनुक्रम में मान्य और लागू। |
discount_code फ़ील्ड अप्रचलित है लेकिन अभी भी बैकवर्ड संगतता के लिए काम करता है — मौजूदा इंटीग्रेशन को तुरंत बदलने की आवश्यकता नहीं है। इसे उसी अनुरोध में discount_codes के साथ संयोजित नहीं किया जा सकता। जब सुविधाजनक हो तब ऐरे रूप में माइग्रेट करें।प्ररोशन मोड्स
जब प्लान बदलते हैं तो ग्राहक से कैसे बिल करें, यह चुनें:prorated_immediately
- वर्तमान चक्र में आंशिक अंतर के लिए चार्ज करता है
- यदि परीक्षण में है, तो तुरंत चार्ज करता है और अब नए प्लान पर स्विच करता है
- डाउनग्रेड: भविष्य के नवीनीकरणों पर लागू होने के लिए एक प्ररोक्षित क्रेडिट उत्पन्न कर सकता है
full_immediately
- नए प्लान की पूरी राशि को तुरंत चार्ज करता है
- पुराने प्लान के शेष समय की उपेक्षा करता है
difference_immediately का उपयोग करके डाउनग्रेड्स द्वारा बनाए गए क्रेडिट सदस्यता-स्कोप्ड होते हैं और क्रेडिट-आधारित बिलिंग अधिकारों से भिन्न होते हैं। वे स्वतः उसी सदस्यता के भविष्य के नवीनीकरणों पर लागू होते हैं और सदस्यताओं के बीच हस्तांतरणीय नहीं होते।difference_immediately
- अपग्रेड: पुराने और नए प्लान के बीच मूल्य अंतर को तुरंत चार्ज करें
- डाउनग्रेड: शेष मूल्य को सदस्यता के लिए आंतरिक क्रेडिट के रूप में जोड़ें और नवीनीकरणों पर ऑटो-लागू करें
do_not_bill
- कोई चार्ज या क्रेडिट की गणना नहीं की जाती
- ग्राहक बिना किसी बिलिंग समायोजन के तुरंत नए प्लान पर स्विच करता है
- बिलिंग चक्र अपरिवर्तित रहता है
- शिष्टाचार माइग्रेशन, मुफ्त प्लान स्विच, या लागत अंतर को अवशोषित करने के लिए सबसे अच्छा
| फ़ीचर | prorated_immediately | difference_immediately | full_immediately | do_not_bill |
|---|---|---|---|---|
| अपग्रेड चार्ज | शेष दिनों के लिए प्रायोजित अंतर | प्लानों के बीच पूरी मूल्य दूरी | नए प्लान की पूरी कीमत | कोई चार्ज नहीं |
| डाउनग्रेड क्रेडिट | शेष दिनों के लिए प्रायोजित क्रेडिट | पूर्ण मूल्य दूरी को क्रेडिट के रूप में जोड़ें | कोई क्रेडिट नहीं | कोई क्रेडिट नहीं |
| बिलिंग चक्र | अपरिवर्तित | अपरिवर्तित | आज तक रीसेट | अपरिवर्तित |
| परीक्षण व्यवहार | ट्रायल समाप्त होता है, तुरंत चार्ज करता है | ट्रायल समाप्त होता है, तुरंत चार्ज करता है | ट्रायल समाप्त होता है, पूरी राशि चार्ज करता है | ट्रायल समाप्त होता है, कोई चार्ज नहीं |
| के लिए सबसे अच्छा | उचित समय-आधारित बिलिंग | सरल अपग्रेड/डाउनग्रेड गणित | बिलिंग चक्रों को रीसेट करना | मुफ्त माइग्रेशन्स या शिष्टाचार स्विच |
| जटिलता | मध्यम (दिन गणना) | कम (सरल घटाव) | कम (पूर्ण चार्ज) | कोई नहीं |
उदाहरण परिदृश्य
इन आदर्श संख्याओं का निरंतर उपयोग करें:- वर्तमान प्लान: बेसिक $30/माह
- अपग्रेड लक्ष्य: प्रो $80/माह
- डाउनग्रेड लक्ष्य (प्रो से): स्टार्टर $20/माह
- बिलिंग चक्र: 30 दिन जनवरी 1 को शुरू हुआ
- प्लान परिवर्तन जनवरी 16 को होता है (15 दिन बचे हुए, 15 दिन उपयोग किए गए)
Upgrade: Basic ($30) → Pro ($80) with prorated_immediately
Upgrade: Basic ($30) → Pro ($80) with prorated_immediately
Downgrade: Pro ($80) → Starter ($20) with prorated_immediately
Downgrade: Pro ($80) → Starter ($20) with prorated_immediately
Upgrade: Basic ($30) → Pro ($80) with difference_immediately
Upgrade: Basic ($30) → Pro ($80) with difference_immediately
Downgrade: Pro ($80) → Starter ($20) with difference_immediately
Downgrade: Pro ($80) → Starter ($20) with difference_immediately
Upgrade: Basic ($30) → Pro ($80) with full_immediately
Upgrade: Basic ($30) → Pro ($80) with full_immediately
Mid-cycle upgrade with add-ons using prorated_immediately
Mid-cycle upgrade with add-ons using prorated_immediately
प्रत्येक मोड कैसे बिलिंग प्रोसेस करता है
भुगतान विफलताओं को संभालना
जब प्लान परिवर्तन भुगतान विफल होता है तो क्या होता है इसे नियंत्रित करने के लिएon_payment_failure पैरामीटर का उपयोग करें।
भुगतान विफलता मोड
- prevent_change (Recommended for critical upgrades)
- apply_change (Default)
- प्लान परिवर्तन को “लंबित” के रूप में चिह्नित किया जाता है
- ग्राहक अपनी वर्तमान योजना तक पहुंच बनाए रखता है
- सदस्यता सफल भुगतान के बाद ही
activeस्थिति में जाती है - तब उपयोगी जब आप उन्नत सुविधाओं को प्रदान करने से पहले भुगतान सुनिश्चित करना चाहते हैं
on_payment_failure पैरामीटर आपके डैशबोर्ड में कॉन्फ़िगर किए गए व्यवसाय-स्तरीय डिफ़ॉल्ट सेटिंग का उपयोग करता है।कब प्रत्येक मोड का उपयोग करना चाहिए
| परिदृश्य | अनुशंसित मोड | कारण |
|---|---|---|
| प्रीमियम सुविधाओं के लिए अपग्रेड | prevent_change | पहुंच प्रदान करने से पहले भुगतान सुनिश्चित करें |
| मात्रा में वृद्धि (अधिक सीटें) | prevent_change | भुगतान के बिना उपयोग को रोकें |
| योजनाएं डाउनग्रेड करना | apply_change | ग्राहक खर्च को कम कर रहा है |
| विश्वसनीय एंटरप्राइज़ ग्राहक | apply_change | गैर-भुगतान का जोखिम कम है |
| परीक्षण से भुगतान परिवर्तन | prevent_change | महत्वपूर्ण भुगतान क्षण |
वेबहूक हैंडलिंग
प्लान परिवर्तन और भुगतान की पुष्टि करने के लिए वेबहूक के माध्यम से सदस्यता स्थिति ट्रैक करें।इवेंट प्रकार जिन्हें संभालना है
subscription.active: सदस्यता सक्रिय की गईsubscription.plan_changed: सदस्यता प्लान बदला गया (अपग्रेड/डाउनग्रेड/एडऑन परिवर्तन)subscription.on_hold: चार्ज विफल, सदस्यता रुकीsubscription.renewed: नवीनीकरण सफलpayment.succeeded: प्लान परिवर्तन या नवीनीकरण के लिए भुगतान सफलpayment.failed: भुगतान विफल
संकेतों को सत्यापित करें और इरादों को संभालें
- Next.js Route Handler
- Express.js
सर्वोत्तम अभ्यास
विश्वसनीय सदस्यता प्लान परिवर्तनों के लिए इन अनुशंसाओं का पालन करें:प्लान परिवर्तन रणनीति
- पूरी तरह से परीक्षण करें: हमेशा उत्पादन से पहले परीक्षण मोड में प्लान परिवर्तनों का परीक्षण करें
- प्ररोशन को सावधानी से चुनें: उस प्ररोशन मोड को चुनें जो आपके व्यवसाय मॉडल के साथ मेल खाता है
- त्रुटियों को अनुग्रहपूर्वक संभालें: उचित त्रुटि प्रबंधन और पुनः प्रयास करने का तर्क लागू करें
- सफलता दर की निगरानी करें: प्लान परिवर्तन सफलता/विफलता दर को ट्रैक करें और समस्याओं की जांच करें
वेबहूक कार्यान्वयन
- संकेतों को सत्यापित करें: प्रमाणीकरण सुनिश्चित करने के लिए हमेशा वेबहूक संकेतों को सत्यापित करें
- आइडंपोटेंसी लागू करें: डुप्लिकेट वेबहूक घटनाओं को अनुग्रहपूर्वक संभालें
- असिंक्रोनस रूप से प्रक्रिया करें: भारी परिचालन के साथ वेबहूक प्रतिक्रिया को अवरोधित न करें
- सब कुछ लॉग करें: डीबगिंग और ऑडिट उद्देश्यों के लिए विस्तृत लॉग्स रखें
उपयोगकर्ता अनुभव
- स्पष्ट रूप से संवाद करें: ग्राहकों को बिलिंग परिवर्तनों और समय की जानकारी दें
- पुष्टीकरण प्रदान करें: सफल प्लान परिवर्तनों के लिए ईमेल पुष्टिकरण भेजें
- एज केस को संभालें: परीक्षण अवधि, प्ररोशन, और विफल भुगतान को ध्यान में रखें
- UI को तुरंत अपडेट करें: अपनी एप्लिकेशन इंटरफ़ेस में प्लान परिवर्तन को प्रतिबिंबित करें
सामान्य समस्याएं और समाधान
सदस्यता प्लान परिवर्तनों के दौरान आने वाली सामान्य समस्याओं का समाधान करें:Charge created but subscription not updated
Charge created but subscription not updated
- वेबहूक प्रोसेसिंग विफल हो गई या विलंबित हुई
- वेबहूक प्राप्त करने के बाद अनुप्रयोग की स्थिति अपडेट नहीं हुई
- स्थिति अपडेट के दौरान डेटाबेस लेनदेन की समस्याएं
- पुनः प्रयास लॉजिक वाले मजबूत वेबहूक हैंडलिंग को लागू करें
- स्थिति अपडेट के लिए आइडंपोटेंट कार्यों का उपयोग करें
- मिस्ड वेबहूक घटनाओं का पता लगाने और अलर्ट जोड़ने के लिए निगरानी करें
- सत्यापित करें कि वेबहूक एंडपॉइंट पहुंच योग्य है और सही से जवाब दे रहा है
Credits not applied after downgrade
Credits not applied after downgrade
- प्ररोशन मोड अपेक्षाएँ: डाउनग्रेड्स पूरा प्लान मूल्य अंतर को
difference_immediatelyके साथ क्रेडिट करता है, जबकिprorated_immediatelyचक्र में शेष समय के आधार पर प्ररोक्षित क्रेडिट बनाता है - क्रेडिट्स सदस्यता विशेष हैं और सदस्यताओं के बीच स्थानांतरित नहीं होते
- ग्राहक डैशबोर्ड में क्रेडिट बैलेंस नहीं दिखाई देता
- डाउनग्रेड्स के लिए
difference_immediatelyका उपयोग करें जब आप ऑटोमैटिक क्रेडिट चाहते हैं - ग्राहकों को समझाएं कि क्रेडिट्स उसी सदस्यता के भविष्य के नवीनीकरणों पर लागू होते हैं
- क्रेडिट बैलेंस दिखाने के लिए ग्राहक पोर्टल को लागू करें
- लागू क्रेडिट्स को देखने के लिए अगला इनवॉइस पूर्वावलोकन करें
Webhook signature verification fails
Webhook signature verification fails
- गलत वेबहूक गुप्त कुंजी
- हस्ताक्षर सत्यापन से पहले कच्चे अनुरोध बॉडी को संशोधित किया गया
- गलत हस्ताक्षर सत्यापन एल्गोरिदम
- सुनिश्चित करें कि आप डैशबोर्ड से सही
DODO_WEBHOOK_SECRETका उपयोग कर रहे हैं - किसी भी JSON पार्सिंग मिडलवेयर से पहले कच्चे अनुरोध बॉडी को पढ़ें
- अपने प्लेटफ़ॉर्म के लिए मानक वेबहूक सत्यापन पुस्तकालय का उपयोग करें
- विकास वातावरण में वेबहूक हस्ताक्षर सत्यापन का परीक्षण करें
Plan change fails with 422 error
Plan change fails with 422 error
- अमान्य सदस्यता आईडी या उत्पाद आईडी
- सदस्यता सक्रिय स्थिति में नहीं है
- आवश्यक पैरामीटर गायब हैं
- प्लान परिवर्तनों के लिए उत्पाद उपलब्ध नहीं है
- सत्यापित करें कि सदस्यता मौजूद है और सक्रिय है
- जांचें कि उत्पाद आईडी मान्य और उपलब्ध है
- सुनिश्चित करें कि सभी आवश्यक पैरामीटर प्रदान किए गए हैं
- पैरामीटर आवश्यकताओं के लिए एपीआई दस्तावेज़ की समीक्षा करें
Immediate charge fails during plan change
Immediate charge fails during plan change
- ग्राहक के भुगतान विधि पर अपर्याप्त धन
- भुगतान विधि समाप्त या अमान्य
- बैंक ने लेन-देन को अस्वीकार कर दिया
- धोखाधड़ी का पता लगाना चार्ज को अवरुद्ध करता है
payment.failedवेबहूक घटनाओं को ठीक से संभालें- ग्राहक को भुगतान विधि को अपडेट करने के लिए सूचित करें
- अस्थायी विफलताओं के लिए पुनः प्रयास लॉजिक लागू करें
- असफल तत्काल शुल्क के साथ प्लान परिवर्तन की अनुमति देने पर विचार करें
Subscription on hold after plan change
Subscription on hold after plan change
on_hold स्थिति में जाती हैक्या होता है:
जब प्लान परिवर्तन चार्ज विफल होता है, तो सदस्यता स्वतः on_hold स्थिति में डाल दी जाती है। सदस्यता तब तक स्वतः नवीनीकरण नहीं करेगी जब तक कि भुगतान विधि को अपडेट नहीं किया जाता।समाधान: सदस्यता को पुनः सक्रिय करने के लिए भुगतान विधि को अपडेट करेंएक असफल प्लान परिवर्तन के बाद on_hold स्थिति से सदस्यता को पुनः सक्रिय करने के लिए:- अपडेट भुगतान विधि अपडेट भुगतान विधि एपीआई का उपयोग करके
- स्वतः चार्ज निर्माण: एपीआई बकाया राशि के लिए स्वतः चार्ज बनाता है
- इनवॉइस जेनरेशन: चार्ज के लिए एक इनवॉइस जेनरेट की जाती है
- भुगतान प्रोसेसिंग: नई भुगतान विधि का उपयोग करके भुगतान की प्रक्रिया की जाती है
- पुनः सक्रियता: सफल भुगतान पर, सदस्यता
activeस्थिति में पुनः सक्रिय होती है
subscription.on_hold: सदस्यता होल्ड में रखी गई (जब प्लान परिवर्तन चार्ज विफल प्राप्त होता है)payment.succeeded: बकाया राशि के लिए भुगतान सफल (भुगतान विधि अपडेट के बाद)subscription.active: सफल भुगतान के बाद सदस्यता पुनः सक्रिय की गई
- जब प्लान परिवर्तन चार्ज विफल होता है तो ग्राहकों को तुरंत सूचित करें
- अपनी भुगतान विधि को अपडेट करने के तरीके के स्पष्ट निर्देश प्रदान करें
- पुनः सक्रियता स्थिति को ट्रैक करने के लिए वेबहूक घटनाओं की निगरानी करें
- अस्थायी भुगतान विफलताओं के लिए स्वतः प्रयास लॉजिक को लागू करने पर विचार करें
Update Payment Method API Reference
अपने कार्यान्वयन को परीक्षण करें
अपनी सदस्यता प्लान परिवर्तन कार्यान्वयन का पूरी तरह से परीक्षण करने के लिए इन चरणों का पालन करें:Set up test environment
- परीक्षण API कुंजी और परीक्षण उत्पादों का उपयोग करें
- विभिन्न प्लान प्रकारों के साथ परीक्षण सदस्यताएं बनाएं
- परीक्षण वेबहूक एंडपॉइंट को कॉन्फ़िगर करें
- निगरानी और लॉगिंग सेट करें
Test different proration modes
- विभिन्न बिलिंग चक्र पदों के साथ
prorated_immediatelyका परीक्षण करें - अपग्रेड और डाउनग्रेड के लिए
difference_immediatelyका परीक्षण करें - बिलिंग चक्रों को रीसेट करने के लिए
full_immediatelyका परीक्षण करें - कोई चार्ज/कोई क्रेडिट प्लान स्विच के लिए
do_not_billका परीक्षण करें - क्रेडिट गणनाओं को सही से सत्यापित करें
Test webhook handling
- सुनिश्चित करें कि सभी प्रासंगिक वेबहूक घटनाएं प्राप्त हुई हैं
- वेबहूक हस्ताक्षर सत्यापन का परीक्षण करें
- डुप्लिकेट वेबहूक घटनाओं को अनुग्रहपूर्वक संभालें
- वेबहूक प्रोसेसिंग विफलता परिदृश्यों का परीक्षण करें
Test error scenarios
- अमान्य सदस्यता आईडी के साथ परीक्षण करें
- समाप्त भुगतान विधियों के साथ परीक्षण करें
- नेटवर्क विफलताओं और टाइमआउट के साथ परीक्षण करें
- अपर्याप्त धन के साथ परीक्षण करें
त्रुटि हैंडलिंग
अपने कार्यान्वयन में सामान्य एपीआई त्रुटियों को अनुग्रहपूर्वक संभालें:HTTP स्थिति कोड
200 OK
200 OK
400 Bad Request
400 Bad Request
401 Unauthorized
401 Unauthorized
404 Not Found
404 Not Found
422 Unprocessable Entity
422 Unprocessable Entity
500 Internal Server Error
500 Internal Server Error
त्रुटि प्रतिक्रिया प्रारूप
अगले कदम
- प्लान चेंज API की समीक्षा करें
- क्रेडिट-आधारित बिलिंग का अन्वेषण करें
subscription.on_holdके लिए अलर्ट लागू करें- हमारे वेबहूक इंटीग्रेशन गाइड देखें