تكامل دفع وشحن داخل نظام تشغيل قائم

ربط بوابة دفع تدعم Apple Pay، وتكامل مع أكثر من شركة شحن لإصدار بوالص الشحن وتتبّعها آلياً من داخل النظام — بدل خطوات يدوية بين ثلاثة أنظمة منفصلة.

المتطلب

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

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

تكامل الدفع

• ربط بوابة دفع مع دعم Apple Pay — المهم فيه أن التجربة تُنهى داخل النظام بدل تحويل العميل لمكان آخر
• التحقق من نتيجة العملية من جهة الخادم، لا من رد المتصفح الذي يمكن التلاعب به
• الحالات غير الناجحة (رفض، انقطاع، تكرار الضغط) تُعالَج صراحة بدل افتراض النجاح

تكامل الشحن

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

الموثوقية — الجزء الذي يحدّد نجاح التكامل

التكامل مع طرف خارجي يعني أن نظامك يعتمد على شيء خارج سيطرتك. المعالجة الصحيحة للأخطاء هنا ليست تفصيلاً:

• التفريق بين العطل المؤقت والعطل الدائم: انقطاع لحظي يُعاد معه المحاولة، أما رفض الحساب فيحتاج تدخلاً بشرياً ويُبلَّغ عنه فوراً
• عدم تكرار العملية: إعادة المحاولة يجب ألا تُنشئ بوليصة مكرّرة أو تُحصّل المبلغ مرتين
• فشل واضح بدل فشل صامت: الطلب الذي تعذّر شحنه يظهر بحالته الحقيقية بدل أن يبدو مكتملاً
• تسجيل كافٍ للتشخيص عند مراجعة أي عملية لاحقاً

النتيجة التشغيلية

• دورة الطلب صارت متصلة: الدفع والشحن والتتبع كلها من داخل النظام
• اختفت خطوات النسخ اليدوي بين ثلاثة أنظمة، ومعها فرص الخطأ المصاحبة
• حالة الطلب صارت معروفة في أي لحظة بدون فتح موقع شركة الشحن

المكدس التقني