الانتقال إلى المحتوى الرئيسي

Change Plan API

Full API docs for updating subscriptions.

Plan Change Preview

See charge amounts before changing plans.

Integration Guide

Step-by-step subscription setup.

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
Plan changes can trigger an immediate charge depending on the proration mode you choose.

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
For detailed setup instructions, see our Integration Guide.

Step-by-Step Implementation Guide

Follow this comprehensive guide to implement subscription plan changes in your application:
1

Understand Plan Change Requirements

Before implementing, determine:
  • 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
Test plan changes thoroughly in test mode before implementing in production.
2

Choose Your Proration Strategy

Select the billing approach that aligns with your business needs:
Best for: SaaS applications wanting to charge fairly for unused time
  • 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
3

Implement the Change Plan API

Use the Change Plan API to modify subscription details:
subscription_id
string
مطلوب
The ID of the active subscription to modify.
product_id
string
مطلوب
The new product ID to change the subscription to.
quantity
integer
افتراضي:"1"
Number of units for the new plan (for seat-based products).
proration_billing_mode
string
مطلوب
How to handle immediate billing: prorated_immediately, full_immediately, or difference_immediately.
addons
array
Optional addons for the new plan. Leaving this empty removes any existing addons.
on_payment_failure
string
Controls behavior when the plan change payment fails:
  • prevent_change: Keep subscription on current plan until payment succeeds
  • apply_change (default): Apply plan change immediately regardless of payment outcome
إذا لم يتم تحديده، يستخدم إعداد الإفتراضي للمستوى التجاري.
discount_code
string
رمز الخصم الاختياري لتطبيقه على الخطة الجديدة. إذا تم توفيره، يتم التحقق من صلاحية الخصم وتطبيقه على تغيير الخطة. إذا لم يتم تقديمه وكان الاشتراك يحتوي على خصم قائم مع preserve_on_plan_change=true، فسيتم الحفاظ على الخصم الحالي (إذا كان قابلاً للتطبيق على المنتج الجديد).
4

Handle Webhook Events

إعداد معالجة webhook لتتبع نتائج تغيير الخطة:
  • subscription.active: تغيير الخطة ناجح، تم تحديث الاشتراك
  • subscription.plan_changed: تم تغيير خطة الاشتراك (ترقية/ تخفيض/ تحديث إضافات)
  • subscription.on_hold: فشل شحن تغيير الخطة، تم إيقاف الاشتراك مؤقتاً
  • payment.succeeded: نجاح شحن فوري لتغيير الخطة
  • payment.failed: فشل الشحن الفوري
تأكد دائماً من توقيعات webhook وقم بتنفيذ معالجة أحداث متكررة.
5

Update Your Application State

بناءً على أحداث webhook، قم بتحديث تطبيقك:
  • منح/إلغاء الميزات استناداً إلى الخطة الجديدة
  • تحديث لوحة تحكم العملاء بتفاصيل الخطة الجديدة
  • إرسال رسائل بريد إلكتروني تأكيدية حول تغيير الخطة
  • تسجيل تغييرات الفواتير لأغراض التدقيق
6

Test and Monitor

اختبر تنفيذك بدقة:
  • اختبر جميع أوضاع النسبة مع السيناريوهات المختلفة
  • تحقق من أن معالجة webhook تعمل بشكل صحيح
  • راقب معدلات نجاح تغيير الخطة
  • قم بإعداد تنبيهات لتغييرات الخطة الفاشلة
تنفيذ تغيير خطة الاشتراك الخاص بك جاهز الآن للاستخدام الإنتاجي.

معاينة تغييرات الخطة

قبل الالتزام بتغيير الخطة، استخدم الـ Preview API لعرض ما سيتم تحصيله من العملاء بالتحديد:
const preview = await client.subscriptions.previewChangePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
});

// Show customer the charge before confirming
console.log('Immediate charge:', preview.immediate_charge.summary);
console.log('New plan details:', preview.new_plan);
استخدم Preview API لإنشاء حوارات تأكيد تعرض للعملاء المبلغ الدقيق الذي سيتم خصمه قبل تأكيد تغيير الخطة.

API تغيير الخطة

استخدم API تغيير الخطة لتعديل المنتج والكمية وسلوك النسبة للاشتراك النشط.

أمثلة بداية سريعة

import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode', // defaults to 'live_mode'
});

async function changePlan() {
  const result = await client.subscriptions.changePlan('sub_123', {
    product_id: 'prod_new',
    quantity: 3,
    proration_billing_mode: 'prorated_immediately',
    on_payment_failure: 'prevent_change', // Optional: control behavior on payment failure
  });
  console.log(result.status, result.invoice_id, result.payment_id);
}

changePlan();
Success
{
  "status": "processing",
  "subscription_id": "sub_123",
  "invoice_id": "inv_789",
  "payment_id": "pay_456",
  "proration_billing_mode": "prorated_immediately"
}
الحقول مثل invoice_id وpayment_id تُرجع فقط عند إنشاء شحن فوري و/أو فاتورة أثناء تغيير الخطة. اعتمد دائماً على أحداث webhook (مثل payment.succeeded، subscription.plan_changed) لتأكيد النتائج.
إذا فشل الشحن الفوري، قد ينتقل الاشتراك إلى subscription.on_hold حتى ينجح الدفع.

إدارة الإضافات

عند تغيير خطط الاشتراك، يمكنك أيضاً تعديل الإضافات:
// Add addons to the new plan
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [
    { addon_id: 'addon_123', quantity: 2 }
  ]
});

// Remove all existing addons
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [] // Empty array removes all existing addons
});
تشمل الإضافات في حساب النسبة وستُحسّب وفقًا لنمط النسبة المحدد.

تطبيق رموز الخصم

يمكنك تطبيق رمز خصم عند تغيير خطط الاشتراك. هذا مفيد لتقديم أسعار ترويجية على الترقيات أو النقل.
// Apply a discount code during plan change
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  discount_code: 'UPGRADE20'
});

سلوك الخصم عند تغيير الخطة

السيناريوالسلوك
discount_code تم تقديمهيتم التحقق وتطبيق الخصم على الخطة الجديدة.
لم يتم تقديم أي رمز، الخصم الحالي مع preserve_on_plan_change=trueيتم تلقائياً الحفاظ على الخصم الحالي إذا كان قابلاً للتطبيق على المنتج الجديد.
لم يتم تقديم أي رمز، لا يوجد خصم قابل للحفظلا يتم تطبيق أي خصم على الخطة الجديدة.
استخدم Preview Plan Change API مع discount_code لعرض المبلغ الذي سيوفره العملاء بدقة قبل تأكيد تغيير الخطة.

أوضاع النسبة

اختر كيفية فوترت العميل عند تغيير الخطط:

prorated_immediately

  • تفرض رسوم على الفرق الجزئي في الدورة الحالية
  • إذا كانت تحت التجربة، تفرض الرسوم فوراً وتتحول إلى الخطة الجديدة الآن
  • خفض: قد يُنشئ رصيداً بنسبة معينة يُطبق على التجديدات القادمة

full_immediately

  • تفرض الرسوم الكاملة للخطة الجديدة فوراً
  • تتجاهل الوقت المتبقي من الخطة القديمة
الأرصدة التي تُنشأ عن طريق التخفيض باستخدام difference_immediately مخصصة للاشتراك ومتميزة عن الفوترة القائمة على الائتمان. تُطبق تلقائياً على التجديدات المستقبلية لنفس الاشتراك ولا يمكن نقلها بين الاشتراكات.

difference_immediately

  • ترقية: تُفرض رسوم الفروق السعرية بين الخطط القديمة والجديدة فوراً
  • تخفيض: تُضاف القيمة المتبقية كرصيد داخلي للاشتراك وتُطبق تلقائياً على التجديدات
الميزةprorated_immediatelydifference_immediatelyfull_immediately
رسوم الترقيةالفرق النسبي لأيام الباقيةالفرق السعري الكامل بين الخططالسعر الكامل للخطة الجديدة
رصيد التخفيضرصيد نسبي لأيام الباقيةالفرق السعري الكامل كرصيدلا رصيد
دورة الفوترةلم يتغيرلم يتغيريعيد الضبط إلى اليوم
سلوك التجربةينهي التجربة، يفرض الرسوم فوراًينهي التجربة، يفرض الرسوم فوراًينهي التجربة، يفرض المبلغ الكامل
الأفضل لـفوترة عادلة مستندة إلى الوقتحساب بسيط للترقية/التخفيضإعادة ضبط دورات الفوترة
التعقيدمتوسط (حساب اليوم)منخفض (الطرح البسيط)منخفض (الرسوم الكاملة)

سيناريوهات مثال

استخدم هذه الأرقام القياسية باستمرار:
  • الخطة الحالية: أساسي بسعر 30 دولار/شهراً
  • هدف الترقية: محترف بسعر 80 دولار/شهراً
  • هدف التخفيض (من المحترف): مبتدئ بسعر 20 دولار/شهراً
  • دورة الفوترة: 30 يوماً، بدأت في 1 يناير
  • تغيير الخطة يحدث في 16 يناير (15 يوماً متبقة، 15 يوماً مستخدمة)
Step 1: Calculate unused credit from current plan
  Unused days = 15 out of 30 days
  Credit = $30 × (15/30) = $15.00

Step 2: Calculate prorated cost of new plan
  Remaining days = 15 out of 30 days
  New plan cost = $80 × (15/30) = $40.00

Step 3: Calculate immediate charge
  Charge = New plan cost − Credit
  Charge = $40.00 − $15.00 = $25.00

→ Customer pays $25.00 now
→ Next renewal (Feb 1): $80.00/month
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
})
Step 1: Calculate unused credit from current plan
  Unused days = 15 out of 30 days
  Credit = $80 × (15/30) = $40.00

Step 2: Calculate prorated cost of new plan
  Remaining days = 15 out of 30 days
  New plan cost = $20 × (15/30) = $10.00

Step 3: Calculate credit balance
  Credit = $40.00 − $10.00 = $30.00

→ No charge — $30.00 credit added to subscription
→ Credit auto-applies to future renewals
→ Next renewal (Feb 1): $20.00 − $30.00 credit = $0.00
→ Following renewal (Mar 1): $20.00 − $10.00 remaining credit = $10.00
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_starter',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
})
Immediate charge = New plan price − Old plan price
                 = $80 − $30
                 = $50.00

→ Customer pays $50.00 now (regardless of cycle position)
→ Next renewal (Feb 1): $80.00/month
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})
Credit = Old plan price − New plan price
       = $80 − $20
       = $60.00

→ No charge — $60.00 credit added to subscription
→ Credit auto-applies to future renewals
→ Next renewal: $20.00 − $20.00 (from credit) = $0.00
→ Following renewal: $20.00 − $20.00 (from credit) = $0.00
→ Third renewal: $20.00 − $20.00 (from remaining credit) = $0.00
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_starter',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})
Immediate charge = Full new plan price = $80.00

→ Customer pays $80.00 now
→ No credit for unused time on old plan
→ Billing cycle resets to today (January 16)
→ Next renewal: February 16 at $80.00/month
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'full_immediately'
})
Current: Basic plan ($30/month), no add-ons
New: Pro plan ($80/month) + Extra Seats add-on ($10/seat × 3 seats = $30/month)
Change on day 16 of 30 (15 days remaining)

Step 1: Credit from current plan
  Credit = $30 × (15/30) = $15.00

Step 2: Prorated cost of new plan + add-ons
  New plan = $80 × (15/30) = $40.00
  Add-ons = $30 × (15/30) = $15.00
  Total new = $55.00

Step 3: Immediate charge
  Charge = $55.00 − $15.00 = $40.00

→ Customer pays $40.00 now
→ Next renewal: $80.00 + $30.00 = $110.00/month
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  addons: [
    { addon_id: 'addon_seats', quantity: 3 }
  ]
})

كيف يعالج كل نمط الفوترة

اختر prorated_immediately للمحاسبة العادلة للوقت؛ اختر full_immediately لإعادة بدء الفوترة؛ استخدم difference_immediately للترقيات البسيطة والائتمان التلقائي عند التخفيضات.

التعامل مع فشل الدفع

تحكم فيما يحدث عندما يفشل دفع تغيير الخطة باستخدام المعلمة on_payment_failure.

أوضاع فشل الدفع

إذا لم يتم تحديده، تستخدم معلمة on_payment_failure إعدادك الافتراضي للمستوى التجاري الذي تم تهيئته في لوحة التحكم.

متى تستخدم كل نمط

السيناريوالنمط الموصى بهالسبب
الترقية إلى ميزات مميزةprevent_changeضمان الدفع قبل منح الوصول
زيادة الكمية (مزيد من المقاعد)prevent_changeمنع الاستخدام بدون الدفع
تخفيض الخططapply_changeالعميل يقلل الإنفاق
العملاء المؤسسيون الموثوق بهمapply_changeمخاطر عدم الدفع منخفضة
التحويل من تجربة إلى مدفوعprevent_changeلحظة دفع حرجة

التعامل مع webhooks

تتبع حالة الاشتراك من خلال webhooks لتأكيد تغييرات الخطة والمدفوعات.

أنواع الأحداث للتعامل معها

  • subscription.active: تفعيل الاشتراك
  • subscription.plan_changed: تم تغيير خطة الاشتراك (ترقية/تخفيض/تغييرات الإضافات)
  • subscription.on_hold: فشل الشحن، تم إيقاف الاشتراك مؤقتاً
  • subscription.renewed: تجديد نجاح
  • payment.succeeded: دفعة ناجحة لتغيير الخطة أو التجديد
  • payment.failed: فشل الدفع
نوصي بقيادة المنطق التجاري من أحداث الاشتراك واستخدام أحداث الدفع للتأكيد والتوفيق.

التحقق من التوقيعات ومعالجة النوايا

import { NextRequest, NextResponse } from 'next/server';

export async function POST(req) {
  const webhookId = req.headers.get('webhook-id');
  const webhookSignature = req.headers.get('webhook-signature');
  const webhookTimestamp = req.headers.get('webhook-timestamp');
  const secret = process.env.DODO_WEBHOOK_SECRET;

  const payload = await req.text();
  // verifySignature is a placeholder – in production, use a Standard Webhooks library
  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });

  switch (event.type) {
    case 'subscription.active':
      // mark subscription active in your DB
      break;
    case 'subscription.plan_changed':
      // refresh entitlements and reflect the new plan in your UI
      break;
    case 'subscription.on_hold':
      // notify user to update payment method
      break;
    case 'subscription.renewed':
      // extend access window
      break;
    case 'payment.succeeded':
      // reconcile payment for plan change
      break;
    case 'payment.failed':
      // log and alert
      break;
    default:
      // ignore unknown events
      break;
  }

  return NextResponse.json({ received: true });
}
لمخططات الحمولة المفصلة، انظر إلى حمولات webhook للاشتراك وحمولات webhook للدفع.

أفضل الممارسات

اتبع هذه التوصيات لإجراء تغييرات موثوقة في خطط الاشتراك:

إستراتيجية تغيير الخطة

  • اختبر بدقة: دائما اختبر تغييرات الخطة في وضع الاختبار قبل الإنتاج
  • اختر النسبة بعناية: حدد نمط النسبة الذي يتماشى مع نموذج عملك
  • تعامل مع الفشل برشاقة: نفذ معالجة الأخطاء المناسبة ومنطق المحاولة مرة أخرى
  • راقب معدلات النجاح: تتبع معدلات نجاح/فشل تغيير الخطة وتحقيق في المشاكل

تنفيذ Webhook

  • تحقق من التوقيعات: تحقق دائماً من توقيعات webhook لضمان الأصالة
  • نفذ التفرد: تعامل بلطف مع أحداث webhook المكررة
  • معالجة غير متزامنة: لا تعيقة استجابات webhook بعمليات ثقيلة
  • سجل كل شيء: حافظ على سجلات مفصلة لأغراض التصحيح والتدقيق

تجربة المستخدم

  • تواصل بوضوح: أعلم العملاء بتغييرات الفوترة والوقت
  • قدّم التأكيدات: أرسل تأكيدات بريد إلكتروني لتغييرات الخطة الناجحة
  • تعامل مع الحالات الحدية: استخدم فترات التجربة، النسب، والمدفوعات الفاشلة
  • حدّث الواجهة فوراً: عكس تغييرات الخطة في واجهة تطبيقك

مشكلات شائعة وحلول

حل المشكلات الشائعة التي تواجهها أثناء تغييرات خطط الاشتراك:
الأعراض: يتم نجاح الاتصال API لكن يظل الاشتراك على الخطة القديمةالأسباب الشائعة:
  • فشل أو تأخرت معالجة webhook
  • لم يتم تحديث حالة التطبيق بعد تلقي webhooks
  • مشاكل في معاملات قاعدة البيانات أثناء تحديث الحالة
الحلول:
  • تنفيذ معالجة webhook قوية مع منطق المحاولة مرة أخرى
  • استخدام عمليات متكررة لتحديث الحالة
  • إضافة رصد للكشف عن أحداث webhook المفقودة وتنبيهها
  • تأكد من أن نقطة نهاية webhook قابلة للوصول وتستجيب بشكل صحيح
الأعراض: العميل يخفّض لكن لا يرى رصيد الحسابالأسباب الشائعة:
  • توقعات نمط النسبة: التخفيضات ترصد الفرق الكامل في سعر الخطة مع difference_immediately، بينما قالب prorated_immediately يُنشئ رصيداً نسبياً بناءً على الوقت المتبقي في الدورة
  • الأرصدة مخصصة للاشتراك ولا تنتقل بين الاشتراكات
  • رصيد الحساب غير مرئي في لوحة تحكم العميل
الحلول:
  • استخدم difference_immediately للتخفيضات عندما تريد الأرصدة التلقائية
  • اشرح للعملاء أن الأرصدة تنطبق على التجديدات المستقبلية لنفس الاشتراك
  • تنفيذ بوابة عملاء لعرض أرصدة الحسابات
  • تحقق من معاينة الفاتورة التالية لرؤية الأرصدة المطبقة
الأعراض: أحداث webhook تم رفضها بسبب توقيع غير صالحالأسباب الشائعة:
  • مفتاح سري غير صحيح لل webhook
  • تم تعديل جسم الطلب الخام قبل التحقق من التوقيع
  • خوارزمية تحقق التوقيع غير صحيحة
الحلول:
  • تأكد أنك تستخدم DODO_WEBHOOK_SECRET الصحيح من لوحة التحكم
  • اقرأ جسم الطلب الخام قبل أي وسيط JSON parsing
  • استخدم مكتبة التحقق القياسية لل webhook لمنصتك
  • اختبر التحقق من توقيع webhook في بيئة التطوير
الأعراض: API يعيد خطأ 422 Unprocessable Entityالأسباب الشائعة:
  • معرف اشتراك غير صالح أو معرف منتج
  • الاشتراك ليس في حالة نشطة
  • المعلمات المطلوبة مفقودة
  • المنتج غير متاح لتغييرات الخطة
الحلول:
  • تحقق من وجود الاشتراك وأنه نشط
  • تحقق من أن معرف المنتج صالح ومتاح
  • تأكد من تقديم جميع المعلمات المطلوبة
  • راجع وثائق API لمتطلبات المعاملات
الأعراض: تم بدء تغيير الخطة لكن فشل الشحن الفوريالأسباب الشائعة:
  • أموال غير كافية على طريقة دفع العميل
  • طريقة الدفع منتهية أو غير صالحة
  • البنك رفض المعاملة
  • كشف عن احتيال أوقف الشحن
الحلول:
  • تعامل مع أحداث payment.failed بشكل مناسب
  • قم بإخطار العميل لتحديث طريقة الدفع
  • تنفيذ منطق المحاولة مرة أخرى للفشل المؤقت
  • ضع في اعتبارك السماح بتغييرات الخطة مع الشحنات الفورية الفاشلة
الأعراض: فشل شحن تغيير الخطة والتحول إلى حالة on_holdماذا يحدث: عند فشل شحن تغيير الخطة، يتحول الاشتراك تلقائياً إلى حالة on_hold. لن يتم تجديد الاشتراك تلقائياً حتى يتم تحديث طريقة الدفع.الحل: تحديث طريقة الدفع لإعادة تفعيل الاشتراكلإعادة تفعيل الاشتراك من حالة on_hold بعد فشل تغيير الخطة:
  1. تحديث طريقة الدفع باستخدام API تحديث طريقة الدفع
  2. إنشاء شحن تلقائي: يقوم ال API تلقائياً بإنشاء شحن للمستحقات المتبقية
  3. توليد الفاتورة: يتم توليد فاتورة للشحن
  4. معالجة الدفع: يعالج الدفع باستخدام طريقة الدفع الجديدة
  5. إعادة التفعيل: عند النجاح في الدفع، يعاد تفعيل الاشتراك إلى الحالة active
// Reactivate subscription from on_hold after failed plan change
async function reactivateAfterFailedPlanChange(subscriptionId) {
  // Update payment method - automatically creates charge for remaining dues
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    type: 'new',
    return_url: 'https://example.com/return'
  });
  
  if (response.payment_id) {
    console.log('Charge created for remaining dues:', response.payment_id);
    console.log('Payment link:', response.payment_link);
    
    // Redirect customer to payment_link to complete payment
    // Monitor webhooks for:
    // 1. payment.succeeded - charge succeeded
    // 2. subscription.active - subscription reactivated
  }
  
  return response;
}

// Or use existing payment method if available
async function reactivateWithExistingPaymentMethod(subscriptionId, paymentMethodId) {
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    type: 'existing',
    payment_method_id: paymentMethodId
  });
  
  // Monitor webhooks for payment.succeeded and subscription.active
  return response;
}
أحداث webhook للمراقبة:
  • subscription.on_hold: تم وضع الاشتراك مؤقتاً (يُتلقى عند فشل شحن تغيير الخطة)
  • payment.succeeded: نجاح الدفع للمستحقات المتبقية (بعد تحديث طريقة الدفع)
  • subscription.active: إعادة تفعيل الاشتراك بعد الدفع الناجح
أفضل الممارسات:
  • قم بإخطار العملاء فوراً عند فشل شحن تغيير الخطة
  • تقديم تعليمات واضحة حول كيفية تحديث طريقة الدفع
  • راقب أحداث webhook لمتابعة حالة إعادة التفعيل
  • ضع في اعتبارك تنفيذ منطق المحاولة التلقائية لفشل الدفع المؤقت

Update Payment Method API Reference

عرض الوثائق الكاملة ل API لتحديث طرق الدفع وإعادة تفعيل الاشتراكات.

اختبار تنفيذك

اتبع هذه الخطوات لاختبار تنفيذ تغيير خطة الاشتراك الخاص بك بدقة:
1

Set up test environment

  • استخدم مفاتيح API التجريبية والمنتجات التجريبية
  • إنشئ اشتراكات تجريبية بأنواع خطط مختلفة
  • قم بتكوين نقطة نهاية webhook التجريبية
  • إعداد المراقبة وتسجيل البيانات
2

Test different proration modes

  • اختبار prorated_immediately مع مواضع مختلفة لدورة الفوترة
  • اختبار difference_immediately للترقيات والتخفيضات
  • اختبار full_immediately لإعادة ضبط دورات الفوترة
  • التحقق من صحة حسابات الرصيد
3

Test webhook handling

  • تحقق من استلام جميع أحداث webhook ذات الصلة
  • اختبار تحقق توقيع webhook
  • تعامل برفق مع أحداث webhook المكررة
  • اختبار سيناريوهات فشل معالجة webhook
4

Test error scenarios

  • اختبار باستخدام معرفات اشتراك غير صالحة
  • اختبار بطرق دفع منتهية
  • اختبار إخفاقات الشبكة والانقطاعات الزمنية
  • اختبار بأموال غير كافية
5

Monitor in production

  • إعداد تنبيهات لتغييرات الخطة الفاشلة
  • مراقبة أوقات معالجة webhook
  • تتبع معدلات نجاح تغيير الخطة
  • مراجعة تذاكر دعم العملاء لقضايا تغيير الخطة

معالجة الأخطاء

تعامل مع أخطاء API الشائعة برشاقة في تنفيذك:

رموز حالة HTTP

تمت معالجة طلب تغيير الخطة بنجاح. يتم تحديث الاشتراك وبدأ معالجة الدفع.
معلمات طلب غير صالحة. تحقق من تقديم جميع الحقول المطلوبة وتنسيقها بشكل صحيح.
مفتاح API غير صالح أو مفقود. تحقق من أن DODO_PAYMENTS_API_KEY صحيحة ولديها الأذونات المناسبة.
معرف الاشتراك غير موجود أو لا ينتمي إلى حسابك.
لا يمكن تغيير الاشتراك (مثلاً، تم إلغاؤه بالفعل، المنتج غير متاح، إلخ.).
حدث خطأ في الخادم. أعد المحاولة بعد فترة وجيزة.

تنسيق الاستجابة عن الخطأ

{
  "error": {
    "code": "subscription_not_found",
    "message": "The subscription with ID 'sub_123' was not found",
    "details": {
      "subscription_id": "sub_123"
    }
  }
}

الخطوات التالية

Last modified on March 24, 2026