ربط API للدفع

دليل ربط API

خطط للمصادقة ومرجع العملية واستعلام الحالة وأمان الإشعارات عند ربط API للدفع. انطلق بعد التحقق من المواصفات التقنية المحدثة.

أبرز المزايا

منهج يناسب احتياجك

قيّم مسار العمل والنطاق التقني والمتطلبات التشغيلية معاً.

01

المواصفات

تحقق من معاني الحقول والحالات في الوثائق التقنية المحدثة.

02

الإشعارات

اختبر التحقق والسلوك عند تكرار الأحداث.

03

التأكيد

افصل الرد التقني عن النتيجة المالية.

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

وضح نموذج الطلب

يجب الرجوع إلى مواصفات API المحدثة لمعرفة وحدة المبلغ ودقة العملة وتفرّد المرجع التجاري للعملية. لا تُرسل طلبات فعلية بناءً على افتراض تنسيق للمبلغ أو اسم للحقل.

  • أكد طريقة المصادقة ومسار تجديد المفاتيح.
  • تحقق من نطاق منع تكرار التنفيذ لدى العميل والمزود.
  • حدد قواعد انتهاء المهلة وإعادة المحاولة بشكل منفصل.

عالج الإشعارات بأمان

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

النتيجة والتأكيد المالي

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

حلول وموارد ذات صلة

الأسئلة الشائعة

الأسئلة الأكثر شيوعاً

إجابات موجزة قد تحتاجها عند تقييم النطاق.

هل تحتوي الصفحة على نقطة نهاية قابلة للاستخدام؟ +

لا. لم تُنشر أمثلة لنقاط النهاية قبل التحقق من عنوان البيئة ومواصفات API المحدثة.

هل يعني HTTP 200 نجاح الدفع؟ +

ليس دائماً. يجب تقييم حالة العملية في الرد وأي تأكيد لازم من المزود بشكل مستقل.

هل أعيد إرسال الطلب نفسه عند انتهاء المهلة؟ +

يجب أولاً التحقق من الحالة وسلوك منع تكرار التنفيذ. فقد تؤدي الإعادة غير المنضبطة إلى تحصيل مكرر.