نقاط التكامل في معاملة البطاقة

في المقالات السابقة شرحنا دور معالجي الاستحواذ ومعالجي الإصدار وبوابات الدفع (Payment Gateways) وجهات التيسير (Facilitators). في هذا المقال سنتعمق في نقاط التكامل الفعلية بين هذه المكونات، ونُحدد من يتصل بمن وكيف.

لنبدأ أولاً بمخطط التكامل الكامل ثم نشرح كل نقطة:

يُوضّح المخطط السابق كلاً من الطرفية والجهة الميسِّرة ومعالج الاستحواذ وشبكة البطاقة ومعالج الإصدار والبنك المُصدِر، مع جميع نقاط التكامل التي تحمل حروفًا من A إلى G.

تكامل الطرفية مع الجهة الميسِّرة (A, B)

كما ذكرنا في مقال سابق، تُبنى الطرفيات (Terminals) وفق معيار ISO 8583 للتواصل مع مفتاح الدفع (Payment Switch). في الحالة التي نناقشها في هذا المخطط، تتواصل الطرفية مع مفتاح دفع جهة التيسير أو بوابة الدفع.

وفقًا للمخطط، نقطة التكامل (A) هي بين الطرفية وبوابة دفع جهة التيسير، إذ يستخدمان ISO 8583. أما نقطة التكامل (B) فهي تكامل الطرفية مع تطبيق نقطة البيع (POS Application) الخاص بالتاجر. يعتمد نوع هذا التكامل على تكامل محلي (Local Integration) يُنفَّذ عبر شبكة محلية LAN. سنتناول هذا الأمر بمزيد من التفصيل في مقال لاحق عن الأجهزة الطرفية.

أما إذا كان التاجر يعمل عبر الإنترنت (بطاقة غير حاضرة/CNP)، يتواصل تطبيق التجارة الإلكترونية مع بوابة الدفع أو الجهة الميسِّرة مباشرةً عبر REST/HTTPS.

تكامل الجهة الميسِّرة مع معالج الاستحواذ - Chase كمثال (C)

كما أشرنا في مقال سابق، تمتلك جهة التيسير (Facilitator) حسابات تاجر فرعية (Sub-Merchant Accounts) لدى البنك المستحوذ. تُرسَل جميع المعاملات من خلال هذه الحسابات.

بالنسبة لـ Chase كمعالج استحواذ، تُقدَّم واجهتا برمجة التطبيقات (APIs) WePay Core وWePay Clear لجهات التيسير (Facilitators) وإلا يُطلق عليها شركاء الشبكة (Network Partners). WePay Core لإدارة جهات التيسير وتسجيل التجار الفرعيين (Sub-Merchants) وWePay Clear لمعالجة المعاملات. ثمة أيضًا MATCH API لفحص التاجر مقابل قائمة التجار المتعثرين.

يُعدّ التكامل عبر REST/HTTPS في معظم معالجي الاستحواذ الجدد. الأقدم منهم يستخدم تنسيقات ملكية خاصة.

ملاحظة مهمة: شهادة PCI DSS مطلوبة لجهة التيسير. إذ إنها تتعامل مع بيانات حامل البطاقة الحساسة.

معالج الاستحواذ - شبكة البطاقة - معالج الإصدار (C, D)

كما تناولنا ذلك في مقال سابق، تتضمن نقطتا التكامل (C) و(D) واجهة شبكة البطاقة (Card Network Interface) لدى كل من معالج الاستحواذ ومعالج الإصدار. تتولى شبكة البطاقة (Visa أو Mastercard) إدارة هذه الاتصالات وتشغيل الأجهزة المرخّصة لدى كلا المعالجَين.

معالج الإصدار مع البنك المُصدِر (F, G)

هاتان النقطتان الأكثر إثارةً للاهتمام. لنتخذ من Marqeta مثالاً. تُقدّم Marqeta مفهوم بوابة تمويل Just-in-Time أو JIT Funding Gateway.

في النموذج الاعتيادي، يملك البنك المُصدِر GPAs أي حسابات ذات غرض عام (General Purpose Accounts) لحاملي البطاقات. تحتفظ Marqeta بأرصدة المحافظ المُسبَقة الدفع.

في نموذج JIT Funding، تُمكَّن الجهة الميسِّرة من التحكم الكامل في قرارات التفويض عبر نقطة نهاية POST لـ webhook. حين تصل Marqeta بطلب تفويض، تستدعي الـ webhook على الفور، وتُعيد الجهة الميسِّرة موافقة أو رفضًا في الوقت الفعلي مع مبلغ التمويل.

نقطة النهاية المستخدمة لتسجيل هذا الـ webhook هي: /fundingsources/programgateway

عند وصول طلب تمويل JIT كاستدعاء POST على عنوان URL لـ webhook الخاص بالجهة الميسِّرة، يتضمن الحقل jit_funding تفاصيل طلب التمويل.

بعد ذلك، تُرسل Marqeta أحداث المعاملات (Transaction Events) عبر نقاط نهاية الـ webhook لدى الجهة الميسِّرة لمعالجة أحداث الحسابات. تشمل هذه الأحداث التفويض وإلغاء التفويض والتسوية والاسترداد وغيرها. يُمكّن هذا الجهة الميسِّرة من تحديث دفاتر أستاذ حسابات حاملي البطاقات في أنظمتها الخلفية بشكل فوري.

أما نقطة التكامل (G) فهي استدعاءات Marqeta لهذه الـ webhooks على عنوان URL جهة التيسير. أحداث المعاملات مُدرجة هنا.

نقاش حول تصميم بوابة الدفع

بوابة الدفع أو API Gateway هي خدمة قابلة للتطوير عديمة الحالة (Stateless Scalable Service). وهي المرشح الأمثل لأن تكون على Lambda أو Azure Functions. على سبيل المثال، في حال طلبات JIT في Marqeta، يُمكّن نموذج الاستدعاء بالـ webhook لكل معاملة من توسيع البوابة بسهولة عبر Lambda أو Azure Functions.

يُعدّ تجميد المبلغ في حساب حامل البطاقة بناءً على طلب التفويض خطوةً مهمةً. إذ لا يُسترجَع المبلغ فعليًا إلا عند اكتمال التسوية.

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