ربط الدفع والشحن والمحاسبة بنظامك: ما الذي يجب التخطيط له؟

قد يتأكد الدفع ثم يفشل إنشاء الشحنة، أو يصل الحدث نفسه مرتين فتتكرر محاولة تسجيله في المحاسبة. تحتاج هذه الحالات إلى قرارات قبل تشغيل الربط بين الأنظمة. سنحدد مصدر كل معلومة ومعرفها وحالتها، ثم نضع طريقة لاستئناف المعالجة ومطابقة السجلات من دون مضاعفة الأثر التجاري.

ارسم مصادر الحقيقة ومعرّفاتها

لا تربط الأنظمة باسم العميل أو وقت العملية وحده؛ الأسماء قد تتكرر والوقت قد يختلف بين الأنظمة. استخدم معرّفات صريحة، وحدد العملة ووحدات المبلغ والمنطقة الزمنية ودلالة كل حالة. كما يجب الاتفاق على التعديل والإرجاع وإلغاء الشحنة، لا البيع الناجح فقط.

افصل حالة الطلب عن الدفع والشحن

قد يكون الطلب مؤكدًا والدفع قيد المعالجة والشحن غير مطلوب بعد. جمع كل ذلك في حقل واحد مثل «تم» يخفي الفشل الجزئي. احتفظ بحالات منفصلة أو نموذج حالات واضح، واعرض للمسؤول الإجراء التالي: انتظار تأكيد، إعادة محاولة، أو مراجعة بشرية. لا ترسل أمر شحن لمجرد عودة المستخدم إلى صفحة «شكرًا» في المتصفح.

راجع عقد الجهة وحدد الإشارة الموثوقة لتأكيد العملية. تؤكد وثائق Stripe للأحداث ضرورة التحقق من التوقيع باستخدام جسم الطلب الخام، وتوضح احتمال التكرار وعدم ضمان ترتيب وصول الأحداث. هذه خصائص موثقة لهذا المثال؛ تُراجع واجهة كل مزود آخر بدل افتراض أنها متطابقة.

منع التكرار مسؤولية تخزين ومعالجة

أنشئ سجل أحداث بمفتاح فريد للحدث لدى المزود، واحفظ حالة المعالجة. إن وصل الحدث نفسه مرة ثانية فلا تُنشئ فاتورة ثانية. وفي العمليات التي يمكن أن تمثلها أحداث مختلفة، اربط كذلك معرّف المورد ونوع الأثر التجاري. البحث أولًا ثم الإدخال لاحقًا دون قيد فريد لا يحمي من وصول نسختين متزامنتين.

بعد التحقق من الرسالة، احفظها أو سلّمها إلى طابور دائم بصورة يمكن استعادتها، ثم أقر بالاستلام وفق عقد المزود. إذا أرسلت نجاحًا قبل حفظها الدائم ثم توقف التطبيق، فقد تُفقد العملية. أما الاتصال البطيء بالمحاسبة داخل مسار الاستقبال فقد يؤدي إلى تكرار التسليم. نفّذ المعالجة المؤثرة بحيث يمكن استئنافها بأمان، مع ربط القيد التجاري وسجل الحدث في معاملة مناسبة حيثما أمكن.

خطة للفشل الجزئي

أعد المحاولة بفواصل وحدود عندما يكون الخطأ مؤقتًا ويجيز العقد ذلك. لا تعالج كل خطأ 4xx كتوقف عابر، ولا تكرر عملية مالية بلا آلية منع تكرار واضحة. واجهة موثقة بعقد تجعل الحقول والحالات أوضح، لكنها لا تلغي الحاجة إلى سياسة التعافي.

اختبارات ما قبل التشغيل

1. نجاح المسار كاملًا في بيئات الجهات التجريبية المصرح بها.
2. وصول الحدث مرتين ومتزامنًا، مع أثر تجاري واحد فقط.
3. توقيع غير صحيح وبيانات مبلغ أو عملة لا تطابق الطلب.
4. فشل الطرف الآخر بعد نجاح طرف أول، ثم استئناف المعالجة.
5. تشغيل تسوية تقارن الطلبات بالعمليات المعلقة والمفقودة.
6. الإلغاء والاسترداد والتعديل وفق المتطلبات والعقود الفعلية.

احمِ مفاتيح الربط وقلل بيانات العميل التي تنتقل بين الأنظمة. وعند طلب تنفيذ تكاملات API، أرفق خريطة المعرفات ووثائق الجهات وحالات الفشل المطلوبة. سجّل في التسليم ما اختُبر فعلاً في كل جهة، وكيف تُتابع العمليات العالقة، وما الذي بقي دون اختبار لغياب الوصول.