مدفوعات البطاقات

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

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

لا. يحدد ISO 8583 هيكلا عاما، وينشر كل بنك محصل أو شبكة مواصفاته الخاصة للحقول وأنواع الرسائل والرموز. ولهذا نبني وفق مواصفات البنك المحصل ونجري اختبارات الاعتماد الخاصة به. وواجهة API لبوابة تقف أمام البنك المحصل تخفي هذه الفروق، وهو خيار أبسط غالبا لشركات التجزئة.

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

نعم. في مدفوعات البطاقات الإلكترونية ندمج EMV 3-D Secure عبر البوابة، ليتمكن البنك المصدر من التحقق من هوية حامل البطاقة حيث تتطلب الأنظمة أو المخاطر ذلك. ونعالج مسار التحقق الإضافي والمسار الذي لا يتطلبه في صفحة الدفع، ونختبرهما ببطاقات الاختبار التي يوفرها المزود.

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