لو سبق لك الدفع ببطاقتك البنكية عبر الإنترنت، فغالبًا قابلت خطوة بيظهر فيها طلب إدخال رمز OTP المرسل من البنك لتأكيد العملية. هذه الخطوة تُعرف باسم 3DS Challenge، وهي واحدة من أهم الإجراءات الأمنية في عمليات الدفع الإلكتروني.
أهمية 3DS Challenge
الغرض الأساسي من هذه الخطوة:
- تقليل عمليات الاحتيال: عبر التحقق الإضافي من هوية حامل البطاقة.
- نقل مسؤولية المخاطرة: من التاجر (Acquirer) إلى البنك مصدر البطاقة (Issuer) في حالة حدوث نزاع على العملية. وهذه النقطة تُعرف باسم Liability Shift.
ما معني Liability Shift؟
ببساطة: إذا اعترض العميل على عملية دفع وادعى أنها احتيالية، وتم التحقق منها بنجاح عبر 3DS Challenge، فإن البنك مصدر البطاقة هو من يتحمل المسؤولية، وليس التاجر.
لماذا يُسمى 3DS؟
كلمة 3DS اختصار لـ 3 Domain Secure، وهو يشير إلى ثلاث جهات رئيسية تشارك في العملية:
- بنك التاجر (Acquirer Domain)
- شبكة البطاقة (Card Network Domain)
- البنك مصدر البطاقة (Issuer Domain)
خطوات عمل 3DS Challenge
العملية تمر بعدة مراحل، وغالبًا تحدث قبل خطوة الدفع الفعلية:
- 3DS Lookup
- بوابة الدفع تتواصل مع Directory Server (DS) الخاص بشبكة البطاقة (Visa / Mastercard) للتحقق من دعم البطاقة لخدمة 3DS .
- إذا كانت البطاقة مدعومة، يحدد الخادم ACS (Access Control Server) الخاص بالبنك، وهو الخادم الذي يعرض صفحة إدخال رمز OTP، ويكون تحت إدارة البنك مباشرة.
- إرسال طلب التحقق (AReq)
- إذا كانت البطاقة تدعم 3DS، تقوم بوابة الدفع بإرسال Authentication Request (AReq) إلى خادم التحقق (ACS).
- يحتوي هذا الطلب على بيانات مهمة مثل: رقم البطاقة، عنوان IP، بيانات المتصفح، والمبلغ.
- التحقق من العميل
هنا يقرر البنك كيفية متابعة العملية:
- Frictionless Flow: إذا اعتبر البنك العملية آمنة، يتم إتمام التحقق دون عرض أي صفحة للعميل.
- Challenge Flow: إذا كانت هناك حاجة للتحقق الإضافي، يعرض البنك صفحة OTP ليدخل العميل الرمز.
- استلام النتيجة (ARes)
- يرسل البنك نتيجة التحقق عبر Authentication Response (ARes)، والتي تحتوي على:
- قيمة اسمها CAVV = Cardholder Authentication Verification Value ودي بينشأها البنك مصدر البطاقة بعد التحقق من العملية.
- ال ID الخاص بعملية التحقق في ال ACS Server الخاص بالبنك
- حالة التحقق (transactionStatus) وبيكون حرف بيمثل نتيجة العملية: Y ناجح، N: فشل، U: غير متاح
- ECI (Electronic Commerce Indicator):رقم يحدد نوع العملية وهل حصل فيها تحقق 3DS ام لا. القيم 02 او 05 تعبر ان التحقق تم بشكل سليم.كمان انه يستخدم من قبل شركات البطاقات لتحديد مسؤولية العملية في حالة حدوث Chargeback.
من النقاط المهمة جدا والتي يعتمد عليها تطبيقات كثيرة هي ان البيانات الخاصة بعملية التحقق تكون ناتجة من بنك مصدر البطاقة، فبغض النظر عن بوابة الدفع التي تقوم بارسال البيانات للبنك، سيتمكن البنك من التعرف عليها. ومن ضمن العمليات المعتمدة علي هذه النقطة:
- التحقق مع بوابة دفع واستخدم البيانات مع بوابة دفع اخري لاستكمال عملية الدفع.
- تكرار المحاولة لو العملية فشلت العملية بسبب خطأ أو رفض من بوابة الدفع، سواء من نفس البوابة أو باستخدام بوابة اخري.
نصيحة للمبرمجين
عرض صفحة 3DS Challenge بشكل يحافظ على تجربة المستخدم؟
هنا بيكون قدامك اختيارين:
1️⃣ تحويل العميل بالكامل لصفحة التحقق (Redirection)
- العميل بيتحول من الموقع الخاص بيك وبيتم تحويله لصفحة اخري لبوابة الدفع لاستكمال ال 3DS Challenge.
- بالرغم إن الطريقة بسيطة، إلا إنها بتأثر على تجربة المستخدم بسبب الخروج من الموقع وتعدد التحويلات.
2️⃣ عرض صفحة التحقق داخل iframe في صفحة الدفع.
حاليا، معظم بوابات الدفع بتدعم عرض الـ 3DS Challenge داخل iframe على شكل modal بيتعرض فوق صفحة الدفع:
الطريقة دي ليها فائدتين:
- تحسين تجربة المستخدم: من خلال تقليل عدد ال redirection. العميل بيكمل عملية الدفع داخل الموقع الخاص بيك بدون تحويل لصفحات خارجية.
- تقليل احتمالية حدوث عدم تطابق في حالة عمليات الدفع بين النظام الخاص بك وبوابة الدفع.
للتوضيح:
- الاعتماد على تحويل العميل لصفحة خارجية، بيتطلب بالتبعية انتظار اعدة تحويل العميل لموقعك بعد إتمام التحقق.
- لو العميل اغلق الصفحة، أو حصل عنده مشكلة في الاتصال بعد اكتمال ال 3DS وقبل التحويل لموقعك، فبوابة الدفع بتتم العملية، لكن العميل لا يتم تحويله لموقعك، فالنظام الخاص بك لا يتك تحديثه بحالة الدفع.
- الحل الأول للمشكلة بيكون من خلال استخدام ال webhook. لو مستخدم الخاصية مع بوابة الدفع، بتستقبل request/notification من بوابة الدفع لل back-end الخاص بك ان حصل تحديث علي عملية الدفع.
- لو ال webhook فشل (سواء لتأخير عند بوابة الدفع او ال back-end الخاص بيك) لو عملية الدفع كانت ناجحة، فهي هتكون عملية مدفوعة لكن النظام عندك غير محدث بان الدفع تم.
العميل هيتخصم منه المبلغ من غير استكمال الطلب. ودا بيكون من أكبر أسباب نقص ثقة العملاء في الموقع.
بالرغم أن حدوث مشكلة في ال redirection وال webhook سويا احتمال ضعيف، لكن يظل عرض ال 3DS في iframe أفضل، لأنه بيلغي التحويل للصفحات الخارجية وبيقلل الاعتمادية علي ال webhook. بالاضافة ان رحلة الدفع بتتم في موقعك بشكل كامل وهذا يحسن تجربة المستخدم.
قد يكون تعديلا بسيط، لكن كل ما كانت تجربة المستخدم أبسط وأسرع، كل ما زادت معدلات إتمام عمليات الدفع.