يربط تكامل اشتراكات Stripe دورة الفوترة بقواعد الوصول داخل تطبيقك. تحصيل أول دفعة جزء واحد من هذا العمل فقط. يحتاج المنتج أيضا إلى تقرير ما يحدث بعد التجديد أو إخفاق الدفع أو تغيير الخطة أو الإلغاء أو تأخر الإشعار.
صمّم تكامل الاشتراكات حول ربط صريح بين حالة الفوترة واستحقاق استخدام المنتج. تحقق من توقيعات خطافات الويب، وتحمّل الأحداث المتكررة والخارجة عن الترتيب، وطابق الوصول المحلي مع السجلات المرجعية. اختبر دورة العميل الكاملة قبل اعتبار دفع ناجح نظام فوترة مكتملًا.
تأمل منتجا باشتراك يفتح مساحة عمل لفريق. يدفع عميل ويغلق المتصفح ثم يدعو زملاء لاحقا. يلغي عميل آخر في نهاية فترته المدفوعة. يحتاج التطبيق سياسة وصول متسقة لكليهما، بما في ذلك عندما تغيب إعادة توجيه المتصفح أو خطاف الويب.
تصف الأمثلة التالية قرارات تنفيذ. لا تفرض سياسة موحدة لإخفاق الدفع، ولا تذكر رسوم Stripe، ولا تدعي أن كل منتج يحتاج بنية الفوترة نفسها.
اربط تكامل اشتراكات Stripe بالوصول إلى المنتج
دوّن ما يشتريه العميل بمصطلحات التطبيق. هل الاستحقاق مساحة عمل أو حزمة ميزات أو عدد مقاعد أو فترة خدمة؟ حدد الحساب الداخلي الذي يملكه والشخص المخول بتغيير الاشتراك.
تصف نظرة Stripe العامة على الاشتراكات الكائنات والدورة التي تدخل في الفوترة المتكررة. ما زال منتجك يحتاج قاعدة مقصودة تربط هذه الحالات بعملياته الخاصة. يجب ألا يصبح معرّف عميل خارجي بديلا عرضيا لنموذج المستأجر.
افصل السياسة التجارية عن آليات الأحداث. قرر أثر التجارب والفواتير المتأخرة والإلغاء في نهاية الفترة على استخدام المنتج. يحتاج موظفو الدعم شرح هذه القواعد للعملاء، ويحتاجها المهندسون قبل كتابة منطق الوصول.
حافظ على ربط ثابت بين حساب التطبيق وسجلات الفوترة المعنية. تجنب المطابقة على عنوان بريد وحده يمكن أن يتغير أو يظهر في عدة سياقات. سجّل كيفية التحقيق في التكرار ونقل الحسابات والاشتراكات التاريخية.
اعتبر إتمام الدفع نقطة بداية
قد توفر صفحة عودة المتصفح تجربة مفيدة للعميل، لكنها ليست المسار الوحيد عبر الدورة. يستطيع العميل إغلاق علامة التبويب أو فقد الاتصال أو العودة قبل اكتمال المعالجة غير المتزامنة. صمّم المنتج لإثبات الوصول من أدلة متحقق منها على الخادم.
| وضع العميل | سؤال التكامل | قرار المنتج |
|---|---|---|
| اكتمل الدفع | أي حساب داخلي يملك الاشتراك؟ | امنح الاستحقاق المتفق عليه بعد التحقق |
| لم يعد المتصفح | هل يمكن مطابقة حالة الفوترة رغم ذلك؟ | لا تشترط إعادة التوجيه لاستكمال التجهيز |
| نجح التجديد | أي فترة خدمة أصبحت مغطاة؟ | حافظ على الوصول المستمر المقصود |
| يحتاج الدفع اهتماما | ما سياسة السماح أو التقييد المتفق عليها؟ | طبّق المعاملة الموثقة للعميل |
| جرت جدولة الإلغاء | متى يجب أن يتغير الاستحقاق؟ | ميّز الجدولة عن الإنهاء الفعلي |
اجعل الحالة المعلقة مفهومة. إذا كان التجهيز ما زال يخضع للفحص، فأخبر العميل بما يعرفه المنتج وقدم مرجع دعم. تجنب منح وصول غير مقيد بناء على ادعاء متصفح غير موثوق، أو ترك العميل أمام رسالة إخفاق غير مفسرة.
أنشئ حدودا متحققًا منها لاستقبال الأحداث
تصف وثائق Stripe لخطافات الويب التحقق من التوقيع والتسليم المكرر وترتيب الأحداث. ابن نقطة الاستقبال حول هذه العقود. يجب أن يتحقق التكامل من الطلب بالمكتبة المدعومة ويحافظ على تمثيل المدخلات الذي يحتاجه التحقق.
افصل الاستلام عن معالجة العمل عندما يحتاج سير العمل عملا غير متزامن محفوظا بصورة دائمة. سجّل ما استُلم وتأكد من إمكانية معالجة الحدث المقبول دون الاعتماد على طلب مفتوح. يجب أن يكون للإقرار معنى محدد، لا أن يخفي استثناء من المرسل فقط.
لا تسجّل أسرار التوقيع أو بيانات دفع غير مقيدة أو بيانات عميل لمجرد أن مثالا لتصحيح الأخطاء فعل ذلك. احتفظ بمراجع كافية لربط حدث فوترة بالحساب الداخلي ونتيجة المعالجة. اتفق على سياسة احتفاظ ووصول للأدلة.
اختبر مسار الاستقبال المماثل للإنتاج في بيئة مضبوطة، بما يشمل إعدادات البرمجيات الوسيطة والوكيل. معالج يعمل مع جسم JSON ملصق يدويا قد يفشل عندما يحول إطار العمل المنشور الطلب قبل التحقق.
اجعل المعالجة تتحمل التكرار وتغير الترتيب
لا يضمن Stripe وصول الأحداث بترتيب إنشائها. وينصح أيضا بمعالجة التسليمات المكررة. يجب ألا يعتمد التطبيق على سبق حدث إنشاء الاشتراك دائما لحدث دفع الفاتورة، أو يفترض أن رؤية حدث مجددا تعني استحقاقا ثانيا.
خزّن أدلة معالجة الأحداث وحدد هوية عملية العمل نفسها. إزالة تكرار الأحداث ومنع آثار العمل المكررة مرتبطان لكنهما مختلفان. قد تشير عدة أحداث متميزة إلى انتقال الاشتراك نفسه، بينما يستطيع معالج انقطع أن يتلقى الحدث نفسه مرة أخرى.
| الآلية | ما تثبته | ما لا تثبته وحدها |
|---|---|---|
| التحقق من التوقيع | يمر الطلب بفحص الأصالة المهيأ | ربط الحساب الداخلي صحيح |
| إزالة تكرار الحدث | يُتعرف على تسليم معروف | كل حدث متميز يمثل عملا تجاريا جديدا |
| البحث عن كائن مرجعي | يمكن فحص معلومات الفوترة الحالية | سياسة الوصول مناسبة |
| تحديث لا يكرر أثر العمل | تتجنب إعادة المعالجة أثرا غير مقصود آخر | ستُكتشف الأحداث الغائبة في النهاية |
يتعلق دليل Stripe للطلبات التي لا تكرر الأثر بسلوك طلبات API. اقرأه للعمليات الصادرة، لكن لا تخلط مفتاح منع التكرار الصادر بتصميم متكامل لمعالجة خطافات الويب الواردة. تحتاج كل حدود إلى معالجتها الخاصة.
احسم عدم اليقين قبل تغيير الوصول مجددا
عندما تنتهي مهلة معالج بعد تحديث الوصول المحلي، افحص الانتقال المسجل قبل تكرار الآثار الجانبية. قد تحتاج إشعارات البريد وتجهيز المقاعد وإنشاء الحسابات الخارجية مراجع عمليات ثابتة خاصة بها. تكرار تحديث قاعدة البيانات الداخلية لا يجعل كل إجراء لاحق غير ضار.
استخدم كائن الفوترة المرجعي الحالي عندما يكون ذلك مناسبا لمطابقة حالة متنازع عليها. تجنب استخدام وقت الوصول كدليل على أن حدثا قديما يمثل الحالة التجارية الأحدث. احتفظ بتاريخ كاف لشرح القرار للمشغّل.
اختبر الدورة وحدود المستأجر
يسرد دليل Stripe لخطافات ويب الاشتراك أحداث الدورة وأسباب تعامل التكامل معها. اختر الأحداث التي يحتاجها المنتج فعليا، ثم اكتب حالات قبول لأثرها في سياسة الوصول الخاصة بك.
أدرج التجهيز الأولي والتجديد ومشكلات الدفع وتغيير الخطط والإلغاء الفعلي. أضف حالات الإشعار المتكرر والمتأخر والغائب. اختبر ما يراه موظفو الدعم عندما تختلف الفوترة والوصول المحلي، لا ما يراه العميل بعد شراء سليم فقط.
يشرح دليلنا لعزل المستأجرين في SaaS الحدود المنفصلة للسجلات. يجب ألا يغير تحديث اشتراك صحيح لحساب واحد وصول مؤسسة أخرى لأن التطبيق وثق بمرجع حساب قدمه العميل.
استخدم بيئات فوترة مضبوطة وبيانات اختبار حسابات ممثلة. اجعل وضع الاختبار ووضع الإنتاج صريحين في الإعدادات والوثائق التشغيلية. احتفظ بأدلة ما اختُبر، بما يشمل إصدارات API ومخطط الأحداث المعنية بالتنفيذ.
امنح الدعم مسارا للمطابقة
قد يبلغ عميل أنه دفع لكنه لا يستطيع استخدام ميزة. يحتاج المشغّل تحديد الحساب الداخلي وفحص حالة الفوترة المعنية وشرح قرار الاستحقاق المحلي. يجعل سجل أحداث دون مراجع حساب التحقيق أصعب دون داع.
حدد إجراء إصلاح مدعوما. قد يعيد تقييم اشتراك معين وفق السياسة الحالية، أو يعيد إنشاء مهمة تجهيز غائبة بمرجع عملية معروف. تجنب إلزام موظفي الدعم بتعديل مؤشرات قاعدة البيانات يدويا دون سجل لسبب تغير الوصول.
نفّذ المطابقة بما يتناسب مع احتياجات المنتج. ينبغي أن تكتشف العملية الاختلافات وتحيلها إلى مسؤول؛ لا أن تستبدل استثناءات الدعم المقصودة مرارا دون فهم غرضها. سجّل الاستثناءات وانتهاءها أو شروط مراجعتها.
راقب عمر الأحداث غير المعالجة واختلافات الاستحقاق غير المحسومة. لا تستطيع أعداد الطلبات وحدها إخبارك إن كان عميل دفع لا يزال محروما من الوصول. يحدد التنبيه المفيد الحساب المتأثر ومسار تحقيق دون كشف معلومات مالية غير ضرورية.
حدد تكاليف التطوير والصيانة
اطلب عرضا بعملة GBP يغطي قواعد الفوترة الفعلية للمنتج. نطاق استحقاق بسيط لخطة واحدة يختلف عن مساحات عمل متعددة وتغييرات مقاعد ونقل تاريخي واستثناءات دعم. مقارنة واجهة الدفع وحدها تخفي كثيرا من عمل التكامل.
| حزمة العمل | المخرج المطلوب | عامل النطاق |
|---|---|---|
| السياسة والربط | قرارات الفوترة والوصول وهوية الحساب | الخطط والمقاعد وبنية الحساب |
| معالجة الأحداث | استلام متحقق منه ومعالجة قابلة للتكرار | آثار خارجية وتعاف |
| القبول | اختبارات الدورة وحدود المستأجر | تغييرات مدعومة ومسارات إخفاق |
| العمليات | مطابقة وأدوات دعم | معاملة العملاء وقواعد الاستثناء |
| التسليم | إعدادات وإصدارات ومسؤولية | مسؤوليات الصيانة |
يمكن أن تبدأ خدمتنا لتطوير البرمجيات بقواعد الوصول التي يحتاجها منتجك. أرسل لنا دورة الاشتراك وفجوات التكامل الحالية لمناقشة تنفيذ أو إصلاح محدد مع أدلة قبول صريحة.
الأسئلة الشائعة
ماذا يشمل تكامل اشتراكات Stripe؟ يربط سجلات وأحداث الفوترة المتكررة بقواعد الحساب والاستحقاق في منتجك. يشمل النطاق الكامل التجهيز والتجديد ومشكلات الدفع والتغييرات والإلغاء والمطابقة ومسؤولية الدعم.
هل تستطيع صفحة نجاح الدفع منح الوصول؟ تستطيع عرض النتيجة للعميل، لكن يجب أن يعتمد الوصول على أدلة متحقق منها على الخادم. يستطيع العملاء إغلاق المتصفح أو العودة قبل انتهاء المعالجة غير المتزامنة.
هل تصل أحداث خطافات الويب بالترتيب؟ يذكر Stripe أن ترتيب التسليم غير مضمون. صمّم المعالجة للتعامل مع الأحداث المعنية دون الاعتماد على تسلسل وصول ثابت، واسترجع الكائنات المرجعية عند الحاجة.
هل تكفي إزالة تكرار الأحداث لمنع عمل مكرر؟ ليس دائما. قد تتعلق أحداث مختلفة بانتقال العمل نفسه، وتحتاج الآثار الجانبية اللاحقة معالجتها القابلة للتكرار. حدد هوية تحديث الاستحقاق أو عملية التجهيز إلى جانب استلام الحدث.
هل يجب إيقاف الوصول فور إخفاق الدفع؟ هذا قرار منتج وسياسة تجارية. حدد قواعد السماح والتقييد وإشعار العميل المقصودة قبل التنفيذ. يجب أن يطبق التكامل السياسة المتفق عليها باتساق، لا أن يخترعها من اسم حدث.
ماذا إذا غاب خطاف ويب؟ وفر مسار مطابقة يقارن حالة الفوترة المرجعية بالاستحقاق المحلي. سجّل الاختلافات وحقق فيها بمراجع حساب واشتراك ثابتة. يجب أن يكون الإصلاح قابلا للتكرار والتدقيق، مع معالجة مقصودة لاستثناءات الدعم.
هل نستطيع إصلاح تكامل قائم؟ غالبا. ابدأ بإخفاق دورة قابل لإعادة الإنتاج وربط الحساب الحالي وأدلة الفوترة والوصول المحلي. قد لا يحتاج عيب معالجة أو سياسة محدود استبدال نظام الفوترة كله.
كيف نقارن عروض الموردين؟ قارن الدورة وبنية الحساب وحالات التعافي ومخرجات الدعم نفسها. افصل تكلفة التطوير عن رسوم المزود والتشغيل المستمر. سعر للدفع وحده لا يقارن بتكامل استحقاق كامل.