ربط بوابة دفع بموقعك: خطة تقنية للاختبار والإطلاق

حدد الحدود بين موقعك والمزود

ارسم ثلاثة أجزاء: نظام الطلبات، طبقة التكامل، وواجهة الدفع التي يتعامل معها العميل. اكتب أين تُنشأ قيمة الطلب وأين تُحفظ حالة الدفع. لا تجعل المتصفح مصدراً نهائياً للمبلغ، لأن البيانات التي تصل من جهة العميل تحتاج تحققاً قبل بدء العملية.

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

أدوات المطورين

جهز بيئة اختبار منفصلة

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

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

دعم التكامل

صمّم محاولة الدفع لتتحمل إعادة الطلب

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

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

عالج الإشعار كرسالة تحتاج تحققاً

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

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

اختبر مسارات الفشل قبل الإطلاق

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

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

نفّذ إطلاقاً محدوداً مع خطة رجوع

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

في OrsunPay، راجع أدوات المطورين ودعم التكامل لتحديد ما يقدمه الاتصال الحالي. لا تفترض أن إضافة طبقة أوركسترا تعني توجيهاً تلقائياً بين جميع المزودين أو دعماً لكل بلد. طلب واضح، نتيجة موثوقة وإجراء للاستثناءات هي قاعدة جيدة قبل توسيع البنية.

المصادر

• Stripe Checkout
• Stripe Webhooks