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
- غير متوفر /
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
- منح/إلغاء الميزات بناءً على الخطة الجديدة
- تحديث لوحة تحكم العميل بتفاصيل الخطة الجديدة
- إرسال رسائل تأكيد عبر البريد الإلكتروني حول تغييرات الخطة
- تسجيل تغييرات الفوترة لأغراض التدقيق
معاينة تغييرات الخطة
قبل الالتزام بتغيير الخطة، استخدم واجهة برمجة التطبيقات للمعاينة لعرض تكلفة العملاء بدقة:- Node.js SDK
- Python SDK
واجهة برمجة التطبيقات لتغيير الخطة
استخدم واجهة برمجة التطبيقات لتغيير الخطة لتعديل المنتج والكمية وسلوك القسمة للاشتراك النشط.أمثلة سريعة للبدء
- 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 | السلوك |
|---|---|
غير متوفر / 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
أفضل الممارسات
اتبع هذه التوصيات لتغييرات موثوقة في خطة الاشتراك:استراتيجية تغيير الخطة
- اختبر بدقة: اختبر دائمًا تغييرات الخطة في وضع الاختبار قبل الإنتاج
- اختر القسمة بعناية: اختر وضع القسمة الذي يتماشى مع نموذج عملك
- تعامل مع الفشل برفق: طبق معالجة أخطاء مناسبة ومنطق إعادة المحاولة
- راقب معدلات النجاح: تتبع معدلات نجاح/فشل تغيير الخطة وقم بالتحقيق في المشكلات
تنفيذ الويب هوك
- تحقق من التوقيعات: تحقق دائمًا من توقيعات الويب هوك لضمان الأصالة
- طبق معالجة التكرار: تعامل مع أحداث الويب هوك المكررة برفق
- عالج بشكل غير متزامن: لا تحظر ردود الويب هوك بعمليات ثقيلة
- سجل كل شيء: احتفظ بسجلات مفصلة لأغراض التصحيح والتدقيق
تجربة المستخدم
- تواصل بوضوح: أبلغ العملاء عن تغييرات الفوترة والتوقيت
- قدم تأكيدات: أرسل تأكيدات بالبريد الإلكتروني لتغييرات الخطة الناجحة
- تعامل مع الحالات الحرجة: فكر في فترات التجربة، القسمة، وفشل المدفوعات
- قم بتحديث الواجهة تلقائيًا: عكس تغييرات الخطة في واجهة التطبيق الخاصة بك
المشكلات الشائعة والحلول
حل المشاكل الشائعة عند تغيير خطط الاشتراك: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
- معرف اشتراك غير صالح أو معرف منتج غير صحيح
- الاشتراك ليس في حالة نشطة
- المعلمات المطلوبة مفقودة
- المنتج غير متاح لتغييرات الخطة
- تحقق من وجود الاشتراك وأنه نشط
- تأكد من أن معرف المنتج صالحة ومتاحة
- تأكد من توفير جميع المعلمات المطلوبة
- راجع مستندات API لمتطلبات المعلمات
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 بعد فشل تغيير الخطة:- قم بتحديث طريقة الدفع باستخدام API لتحديث طريقة الدفع
- إنشاء شحنة تلقائية: API ينشئ شحنة للديون المتبقية تلقائيًا
- إنشاء فاتورة: يتم إنشاء فاتورة للشحنة
- معالجة الدفع: يتم معالجة الدفع باستخدام طريقة الدفع الجديدة
- إعادة التفعيل: عند نجاح الدفع، يتم إعادة تفعيل الاشتراك إلى حالة
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
- اختبر باستخدام معرفات اشتراك غير صالحة
- اختبر باستخدام طرق دفع منتهية الصلاحية
- اختبر فشل الشبكة وانقطاع الوقت
- اختبر عند عدم كفاية الأموال
معالجة الأخطاء
تعامل مع الأخطاء الشائعة في API برفق في تنفيذك:رموز حالة 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 - اطلع على دليل الاندماجات عبر الويب هوك