دراسة حالة · منصة B2B SaaS عالمية (سرّية)
كيف سلّمت UnlockLive منظومة مدفوعات واشتراكات من Airwallex بمستوى الإنتاج على Python وFastAPI — خمس عملات مفعّلة خلال 12 أسبوعاً، وتسليم webhooks بنسبة 99.99%، ومتوافقة مع PCI-DSS، وانخفاض بنسبة 65% في فقدان العملاء بسبب فشل المدفوعات.
كانت منصة B2B SaaS تتوسع من أمريكا الشمالية إلى آسيا والمحيط الهادئ وأوروبا والشرق الأوسط وأفريقيا وتحتاج إلى بنية مدفوعات قادرة على التحصيل بخمس عملات وتشغيل فوترة الاشتراكات ومعالجة إعادة المحاولة بسلاسة واجتياز مراجعة أمنية. فقد تجاوزت إعداد معالج الدفع الواحد — إذ كانت هوامش الصرف الأجنبي تستهلك 1.8% من الإيرادات، وكانت التسوية تستغرق أياماً، وكان معالج webhooks الحالي يُسقط الأحداث تحت الحمل. أراد المدير المالي Airwallex لقنوات الصرف الأجنبي والمدفوعات العالمية، وأراد المدير التقني الإبقاء على حزمة FastAPI الحالية وعدم تحويل المدفوعات إلى خدمة منفصلة لا يستطيع الفريق تشغيلها.
المطلوب: تسليم تكامل Airwallex بمستوى الإنتاج على FastAPI + PostgreSQL خلال ربع سنة واحد، مع موثوقية webhooks لا تشوبها شائبة، وآلة حالات حقيقية للاشتراكات، وبنية متوافقة مع PCI-DSS، وتجربة تشغيلية واضحة بحيث لا يضطر مهندس المناوبة في الثانية صباحاً إلى استدعاء المدير التقني.
بنينا تكامل Airwallex مركّزاً حول ثلاث أفكار هندسية: نموذج نطاق مدفوعات مكتوب الأنواع، وخط أنابيب webhooks بنمط outbox، وآلة حالات لدورة حياة الاشتراك يمكن لبقية التطبيق قراءتها لكن لا يكتبها إلا كود المدفوعات.
على جانب API، تُجمع كل بيانات البطاقات عبر عناصر الدفع المستضافة من Airwallex بحيث لا تلمس الواجهة الخلفية للتطبيق رقم البطاقة (PAN) إطلاقاً — ويبقى نطاق PCI عند SAQ A. تعرض خدمة FastAPI واجهة API صغيرة مكتوبة الأنواع للمدفوعات (نماذج Pydantic v2 وموثّقة بـ OpenAPI) يستهلكها فريق المنتج؛ وتُغلَّف استدعاءات Airwallex API في عميل واحد بمفاتيح عدم التكرار (idempotency) وإعادة محاولات أسية وقاطع دائرة.
على جانب webhooks، يصل كل حدث من Airwallex إلى نقطة نهاية موقّعة ومتحقق منها تؤدي مهمة واحدة: حفظ الحدث الخام في جدول `inbox` ضمن معاملة واحدة. ويعالج عامل منفصل صندوق الوارد بالترتيب، مع تسليم مرة واحدة على الأقل ومعالجات غير مكررة الأثر. وقد حل هذا النمط وحده مشكلة الأحداث المفقودة تماماً — حتى أثناء ارتفاع حركة المرور 4 أضعاف عند الإطلاق.
تتعامل آلة حالات الاشتراك مع الحالات: تجريبي ونشط ومتأخر السداد والمطالبة (dunning) وموقوف ومُلغى ومُعاد تفعيله، مع انتقالات مسموحة صريحة وسجل تدقيق لكل تغيير حالة. وتعمل المدفوعات الفاشلة الآن وفق جدول إعادة محاولة ذكي (وليس التراجع الأسي الافتراضي) مضبوط على أنماط يوم الفوترة لدى العميل، وهو ما أدى إلى انخفاض بنسبة 65% في فقدان العملاء بسبب فشل المدفوعات.
رسمنا خريطة لتدفقات الدفع والاشتراك والتحصيل المتأخر (dunning) والاسترداد القائمة، ووثّقنا كل موضع يلمس الأموال أو بيانات البطاقات، وأعددنا وثيقة تحديد نطاق PCI من صفحة واحدة حددت بدقة الأسطح التي ستبقى ضمن SAQ A. كما أجرينا حسابات الصرف الأجنبي على مزيج العملات المخطط له للتأكد من جدوى Airwallex قبل كتابة سطر واحد من الكود.
صمّمنا نطاق مدفوعات مكتوب الأنواع (Pydantic v2 + نمط مستودع صغير)، وخط معالجة webhooks بنمط inbox/outbox، وآلة حالات الاشتراك، وعقد idempotency لعميل Airwallex. يحصل كل استدعاء خارجي على مفتاح idempotency مشتق من حدث العمل، فلا تؤدي إعادة المحاولة أبدًا إلى تكرار الخصم.
أطلقنا عملة واحدة وتدفق اشتراك واحدًا في كل مرة خلف علامات الميزات (feature flags)، بدءًا بالسوق الجديدة الأقل مخاطرة. وسُلّم كل معالج webhook مع اختبار إعادة تشغيل؛ فكنا نلتقط أحداث Airwallex الحقيقية من بيئة sandbox، ثم نثبت أن المعالج يبقى صحيحًا عند إعادة الترتيب والتكرار والفشل الجزئي.
قبل الإطلاق، عرضنا على مراجع الأمن نطاق PCI ونموذج التهديدات، ونشرنا لوحات Datadog لتأخر webhooks ومعدل إعادة المحاولة ومسار تحصيل المتأخرات (dunning) والتعرض لتقلبات الصرف، وكتبنا دليل مناوبة حقيقياً يستطيع المهندس اتباعه في الثانية صباحاً دون استدعاء المسؤول. وبقينا معهم بعقد دعم مستمر لمدة 8 أسابيع من الضبط بعد الإطلاق.
“انتقلنا من إعداد بمعالج دفع واحد كان يفقد webhooks تحت الحمل إلى تكامل مع Airwallex يثق به فريقنا المالي ووافق عليه مراجع الأمن من أول مرة. وأثبتت إعادة بناء مسار تحصيل المتأخرات (dunning) جدواها وغطّت تكلفة المشروع بمفردها.”
استخدم نمط صندوق الوارد (inbox). تقوم نقطة نهاية HTTP بأمرين فقط: التحقق من توقيع Airwallex وحفظ الحدث الخام في جدول قاعدة بيانات ضمن معاملة واحدة. ثم يقوم عامل منفصل بتصريف الجدول بالترتيب، مع تسليم مرة واحدة على الأقل ومعالجات متماثلة الأثر (idempotent). ويعني هذا الفصل أن بطء المعالج أو عملية نشر أو انقطاع في نظام لاحق لن يتسبب أبداً في فقدان webhook أو معالجته مرتين.
اجمع جميع بيانات البطاقات باستخدام عناصر الدفع المستضافة من Airwallex (أو Drop-in / Hosted Payment Page). لا يرى الخادم الخلفي لديك سوى معرّفات ورموز Airwallex، ولا يرى أبدًا رقم البطاقة (PAN) أو CVV أو تاريخ الانتهاء. نوثّق هذا النطاق في مذكرة تحديد نطاق PCI من صفحة واحدة يمكن لمراجع الأمن لديك اعتمادها، ثم نضع ضوابط في الكود حتى لا يتمكن مهندس مستقبلًا من إدخال بيانات البطاقات إلى الخادم الخلفي عن طريق الخطأ.
نعم — نموذج FastAPI غير المتزامن ممتاز لطبيعة واجهات الدفع المعتمدة على الإدخال والإخراج. وتأتي الموثوقية من الأنماط المحيطة به: مفاتيح idempotency في كل استدعاء Airwallex، ونمط inbox للـ webhooks، وقاطع دائرة (circuit breaker) لعميل Airwallex، وآلة حالات حقيقية للاشتراكات. وقد سلّمنا حزم دفع على FastAPI تعالج عشرات الآلاف من عمليات الدفع يوميًا مع تسليم webhooks بموثوقية خمس تسعات.
يميل Airwallex إلى التفوق للأعمال التي تحصّل بأربع عملات أو أكثر بفضل هوامش صرف أفضل وتسوية أسرع عبر الحدود. ويتفوق Stripe عادةً لمنتجات SaaS المقتصرة على أمريكا الشمالية التي تقدّر منظومته الأكبر بكثير من الأطراف الثالثة. ندمج كليهما وساعدنا عملاء على تشغيلهما جنباً إلى جنب لكل منطقة، وأنماط التكامل التي نستخدمها (نطاق مُنمّط، وwebhooks بنمط صندوق الوارد، وآلة حالات) لا تعتمد على معالج دفع بعينه.
من 10 إلى 16 أسبوعًا لتكامل بمستوى الإنتاج يغطي الدفع والاشتراكات وwebhooks وتحصيل المتأخرات (dunning) والمبالغ المستردة والتقارير لعملة واحدة ومنتج واحد. وكل عملة أو مسار اشتراك إضافي بعد ذلك يضيف عادةً من أسبوع إلى أسبوعين. نعمل بشرائح محكمة خلف مفاتيح الميزات (feature flags) بحيث يمكنك إطلاق العملة الأولى قبل اكتمال الثانية.
SaaS8x انخفاض زمن الاستجابة p95 على نقاط النهاية الكثيفة الاستخدام (1.8 ث → 220 مللي ث)كيف أعدنا تصميم واجهة API ساخنة بـ Python/FastAPI بطبقة تخزين مؤقت متعددة المستويات عبر Redis لخفض زمن الاستجابة p95 من 1.8 ثانية إلى 220 مللي ثانية مع تقليل حمل PostgreSQL بنسبة 70% لمنصة B2B SaaS في أمريكا الشمالية.
التعليم50K+ استدعاءات Canvas API اليومية — ضمن حصة الجامعة بارتياحكيف استبدلت UnlockLive مزامنة ليلية هشة مع Canvas LMS بتكامل قائم على الأحداث بـ Python وFastAPI يعالج أكثر من 50 ألف استدعاء API يومياً، دون أي حوادث تجاوز لحدود المعدل، ونافذة مزامنة أصغر بنسبة 90% — دون تعطيل أي نظام لاحق.
التجميل / SaaS لإدارة عمليات الاستوديوهات12+ ساعة وُفّر شهريًا في تسوية العمولاتكيف دمجت UnlockLive ثلاث أدوات منفصلة — حجوزات التقويم ونقطة البيع داخل الاستوديو وجدول بيانات العمولات — في منصة SaaS واحدة متكاملة لاستوديو أمريكي للمكياج الدائم. حجز عام مع عربون عبر Stripe، ودفع داخل الاستوديو عبر Stripe، وتقسيم تلقائي لأرباح الفنانين عبر Stripe Connect، ولوحة مالية للمالك، وبوابة ذاتية الخدمة للفنانين لمتابعة أرباحهم — ما وفّر أكثر من 12 ساعة شهرياً في المطابقة وأنهى نزاعات الأرباح منذ الإطلاق.
تحدّث إلى الفريق نفسه الذي بنى مدفوعات واشتراكات متعددة العملات على FastAPI + Airwallex لـ SaaS عالمي لقطاع B2B. سنحدد نطاق مشروعك، ونقدّم لك عرضًا بسعر ثابت، ونُريك أقرب مثال من أعمالنا.
احجز مكالمة استراتيجيةUnlockLive IT Limited — المقر الرئيسي في Toronto المواجه للعملاء وإدارة المشاريع؛ ومركز هندسي مخصص في Dhaka، Bangladesh. شركة مسجلة في المملكة المتحدة برقم #15563368 (UnlockLive IT Limited، لندن).
حقوق النشر© UnlockLive . جميع الحقوق محفوظة 2008 - 2026