يحول إذن الراية المميزة Dodo Payments إلى متجر راية مميزة يعى بالفواتير. أرفق راية مثل
advanced_reports بمنتج، وكل عميل مدفوع يحصل على منحة يمكن لتطبيقك التحقق منها عبر API أو الاحتفاظ بالتزامن مع webhooks. لا منصة خارجية، لا OAuth، لا خطوة تسليم - المنحة نفسها هي القدرة.ما يتم تسليمه
لا يغادر أي شيء Dodo Payments — المنحة هي ما يتم تسليمه:- عند الشراء، تُنشأ المنحة وتنتقل مباشرة إلى
delivered. لا يوجد مرحلةpending، ولا إجراء من العميل، ولا طريقة للفشل في التسليم. - تحمل المنحة حمولة بطابع
feature:{ "feature_type": "boolean", "feature_id": "advanced_reports" }. يقرأ تطبيقكfeature_idلتحديد ما يجب فتحه. - الإلغاء أو الاسترداد أو الإلغاء اليدوي ينقل المنحة إلى
revoked، ويختفي العلم من تطبيقك.
feature_id هو معرف يختاره التاجر، وليس فريداً عبر الأذونات. يمكن أن يمنح اثنان من الأذونات نفس feature_id — على سبيل المثال، خطة Pro الشهرية وخطة Pro السنوية كلاهما يمنح advanced_reports.إنشاء راية مميزة
Open Entitlements
في لوحة التحكم Dodo Payments، اذهب إلى الأذونات وانقر على + لبدء إذن جديد، ثم اختر الرايات المميزة.
Name the flag
أعط الراية اسم عرض للوحة التحكم الخاصة بك، ومعرف ميزة ستتحقق منه تطبيقك (تقترح لوحة التحكم واحدًا من الاسم)، ووصف حتى يعرف فريقك ماذا يتحكم.

Optionally add metadata
تبديل البيانات الوصفية لإرفاق تكوين المفاتيح والقيم — الحدود، أسماء المستويات، الحصص — التي يتم تسليمها إلى تطبيقك جنبًا إلى جنب مع الراية. انظر إرفاق الحدود بالبيانات الوصفية.
إرفاق بمنتج
افتح منتجًا (أو قم بإنشائه)، وابحث عن بطاقة الأذونات، وانقر على + لإرفاق الأذونات الموجودة. حدد راية الميزة الخاصة بك وانقر على تم.

التكوين المطلوب
| الحقل | مطلوب | الوصف |
|---|---|---|
feature_id | نعم | معرف تتحقق منه تطبيقك، مثل advanced_reports. ليس فريداً عبر الأذونات. |
feature_type | نعم | نوع القدرة الممنوحة. يدعم اليوم فقط boolean. |
الإنشاء عبر API
إرفاق الحدود بالبيانات الوصفية
تجيب الراية البوليانية “هل لدى هذا العميل الميزة؟”. تجيب البيانات الوصفية “مع أي تكوين؟”. تقبل البيانات الوصفية للأذونات القيم النصية والعددية والرقمية والبولينيانية، وكل منحة تأخذ لقطة مجمدة من بيانات الإذن عند إنشائها. ذاك السلوك اللقطة هو ما يجعل البيانات الوصفية آمنة للاستخدام بالنسبة لحدود الخطط:- تحرير البيانات الوصفية للإذن لاحقًا يؤثر فقط على المنح المستقبلية. يحتفظ العملاء بالحدود التي اشتروا تحتها.
- يتم إرجاع اللقطة على كل منحة كحقلها
metadata، لذا يتيح لك اتصال API واحد الحصول على الراية وتكوينها.
advanced_reports بتكوين { "tier": "pro", "monthly_report_limit": 100 } لتطبيقك فتح لوحة العدادات وتنفيذ حصة 100 تقرير بدون بحث ثانٍ. إذا قمت لاحقًا بزيادة الحد إلى 250، فإن العملاء الحاليين يبقون عند 100 حتى يحصلوا على منحة جديدة (على سبيل المثال، بعد تغيير الخطة).
تحقق من ميزات العميل
سرد منح الرايات المميزة المسلمة للعميل وبناء مجموعة الميزات الممكنة. يعيد نقطة النهاية صفًا واحدًا لكل منحة عبر جميع الأذونات، يمكن تصفيتها بواسطةintegration_type وstatus.
يتم تعبئة حمولة
feature فقط على منح feature_flag؛ إنها null لكل نوع تكامل آخر. انظر إلى مرجع API قائمة منح العملاء للحصول على شكل الاستجابة الكامل.دورة الحياة
تتبع منح الراية المميزة دورة الحياة القياسية للمنح مع تبسيط واحد: لا توجد خطوة تسليم، لذا لا تجلس المنح فيpending ولا تنتقل إلى failed.
| الزناد | التأثير |
|---|---|
| نجح الدفع لمرة واحدة / أصبحت الاشتراك نشطًا | تم إنشاء المنحة مع status: delivered وdelivered_at مضبوطة. |
| وضعت الاشتراك على الانتظار، أو ألغيت، أو انتهت صلاحيتها | تم إلغاء المنحة مع revocation_reason المطابقة. |
| رد الأموال عن دفع لمرة واحدة | تم إلغاء المنحة مع revocation_reason: refund. |
| تعافت الاشتراك (على سبيل المثال، نجحت عملية dunning) | تم استعادة المنحة الملغاة إلى delivered - نفس id للمنحة، مساحات الإلغاء مفرغة. |
| إلغاء API يدوي | تم إلغاء المنحة مع revocation_reason: manual. لا يتم استعادته تلقائيًا عند التجديد. |
خدمات الويب
اشترك فيentitlement_grant.* الأحداث لتعكس الرايات في قاعدة البيانات الخاصة بك بدلاً من الاستطلاع:
entitlement_grant.created— تصل بالفعلdeliveredمع حمولةfeature. قم بتمكين الميزة.entitlement_grant.delivered— يتم تشغيلها عندما يتم استعادة منحة ملغاة مسبقًا. قم بإعادة تمكين الميزة.entitlement_grant.revoked— الوصول محظور. قم بتعطيل الميزة وتحقق منrevocation_reasonلتحديد رسائلك.
TypeScript
entitlement_grant.failed للرايات المميزة — يحدث التسليم بالكامل داخل Dodo Payments ولا يمكن أن يفشل.
مثال: خطة Pro تفتح التقارير المتقدمة
- أنشئ الراية.
feature_id: advanced_reportsمع البيانات الوصفية{ "tier": "pro", "monthly_report_limit": 100 }. - قم بإرفاقها بمنتج الاشتراك في خطة Pro الخاصة بك.
- اشتراك العميل. ينشئ Dodo Payments منحة
deliveredويطلقentitlement_grant.created؛ يقوم معالج الويب هوك الخاص بك بتمكينadvanced_reportsللعميل بحد 100. - تطبيقك يبوّب الميزة. عند تحميل لوحة العدادات، تحقق من مجموعة الميزات المخبأة (أو اتصل بـ
listEntitlementGrants) وعرض علامة التبويب للتقارير فقط عند توفرadvanced_reports. - قام العميل بالإلغاء. يقوم Dodo Payments بإلغاء المنحة ويطلق
entitlement_grant.revoked؛ يقوم معالجك بتعطيل الميزة. إذا تعافى العميل لاحقًا عبر عملية dunning،entitlement_grant.deliveredتستعيدها - لا حاجة لتغيير التعليمات البرمجية.
أفضل الممارسات
- استخدم معرفات السمات الثابتة، الsnake_case. تتحقق تطبيقك من هذه السلاسل؛ تغيير الاسم يعد تغييرًا كسرًا على كلا الجانبين.
-
علم واحد لكل قدرة. فضل
advanced_reports+api_accessكأذونات اثنين على راية واحدةpro_bundle— تظل المخالفة وخليط الخطط نظيفة. - ادفع الحالة من خلال خدمات الويب، وتحقق من خلال API. تجعل الخدمات المعطاة قاعدة بياناتك محدثة؛ قائمة النقاط تكون مصدر الحقيقة لأعمال التوفيق والأخطاء في التخزين المؤقت.
-
تعامل مع
revokedعلى أنها فورية. يعني العلم الذي تم إلغاؤه أن العميل لم يعد يدفع مقابل الميزة. اعتمد على الطلب التالي، وليس الجلسة التالية. - ضع الحدود في البيانات الوصفية، وليس في الكود. يؤدي تغيير الحصة بعد ذلك فقط إلى تحرير الإذن - يلتقط العملاء الجدد تلقائيًا بينما تحتفظ المنح الحالية بلقطة الشراء الخاصة بهم.
- Use stable, snake_case feature ids. Your application code checks these strings; renaming one is a breaking change on both sides.
-
One flag per capability. Prefer
advanced_reports+api_accessas two entitlements over a singlepro_bundle— revocation and plan mixes stay clean. - Drive state from webhooks, verify with the API. Webhooks keep your database current; the list endpoint is the source of truth for reconciliation jobs and cache misses.
-
Treat
revokedas immediate. A revoked flag means the customer is no longer paying for the feature. Gate on the next request, not the next session. - Put limits in metadata, not in code. Changing a quota then only requires editing the entitlement — new customers pick it up automatically while existing grants keep their purchased snapshot.
