شرح 3-D Secure 2 للتجار: المسار السلس والتحدي ونقل المسؤولية
فريق Visatk · · 9 دقائق قراءة · Read in English
شرح 3-D Secure 2 للتجار: كيف يعمل EMV 3DS، والفرق بين المسار السلس ومسار التحدي، وقيم ECI ورموز الحالة، واستثناءات SCA، وكيف تنتقل مسؤولية الاحتيال.

إذا كنت تبيع عبر الإنترنت وتقبل البطاقات، فغالبًا ما يكون 3-D Secure جزءًا من صفحة الدفع لديك بالفعل، سواء فعّلته بنفسك أو فعّله مزوّد الدفع نيابةً عنك. فهو البروتوكول الذي تقوم عليه برامج العلامات التجارية مثل Visa Secure وMastercard Identity Check وAmerican Express SafeKey، وهو الأداة الرئيسية التي تستخدمها البنوك المُصدِرة للتأكد من أن من يدفع هو حامل البطاقة الحقيقي. أما جيله الحالي، EMV 3-D Secure (المعروف عادةً باسم 3DS2)، فيختلف كثيرًا عن نوافذ كلمات المرور المزعجة التي لا يزال كثير من المتسوقين يتذكرونها.
يشرح هذا الدليل كيف يعمل 3DS2 خلف الكواليس، والفرق بين المسار السلس (Frictionless) ومسار التحدي (Challenge)، وكيف تقرأ النتائج التي تُرجعها بوابة الدفع، وما الذي تغطيه فعلًا آلية نقل مسؤولية الاحتيال، وكيف تستخدم 3DS بذكاء لتقليل الاحتيال دون أن تخسر عملاءك الحقيقيين في صفحة الدفع.
ما هو 3-D Secure وما الذي غيّره 3DS2 #
3-D Secure هو بروتوكول لمصادقة حامل البطاقة في المدفوعات التي لا تكون فيها البطاقة حاضرة فعليًا. و"النطاقات الثلاثة" هي نطاق البنك المستحوذ (التاجر وبنكه المستحوذ)، ونطاق الجهة المُصدِرة (بنك حامل البطاقة)، ونطاق التشغيل البيني (شبكات البطاقات التي تربط بينهما). وتتم المصادقة قبل التفويض؛ إذ تحصل الجهة المُصدِرة على فرصة للتحقق من هوية المتسوق، ثم تُرفق النتيجة بطلب التفويض.
اعتمد الإصدار الأول (3DS1) على كلمات مرور ثابتة، وكان يحوّل المتسوقين إلى صفحات الجهة المُصدِرة التي بدت غالبًا غير موثوقة ولا تعمل جيدًا على الهاتف. وكانت نسبة التخلي عن الشراء مرتفعة، فتجنّبه كثير من التجار. وقد أوقفت الشبكات العمل بـ 3DS1 في عام 2022، وتتولى EMVCo اليوم إدارة مواصفة EMV 3DS، مع إصدارات 2.1 و2.2 وما بعدها التي أضافت المزايا تدريجيًا.
| الجانب | 3DS1 (متوقف) | 3DS2 / EMV 3DS |
|---|---|---|
| البيانات المرسلة للجهة المُصدِرة | قليلة جدًا | غنية: بيانات الجهاز والمتصفح والطلب والحساب |
| التجربة المعتادة | كلمة مرور ثابتة في كل معاملة | معظم المعاملات سلسة؛ والتحدي فقط عند ارتفاع المخاطر |
| تطبيقات الهاتف | دعم ضعيف وتحويلات للمتصفح | دعم أصلي عبر SDK داخل التطبيق |
| طرق المصادقة | كلمة مرور | رمز OTP، أو موافقة عبر تطبيق البنك، أو القياسات الحيوية، أو المصادقة المنفصلة |
| الاستخدام دون دفع | لا | نعم، مثل التحقق من البطاقة دون خصم مبلغ |
| دعم المعاملات التي يبدأها التاجر | لا | نعم، عبر 3RI في الإصدار 2.2 وما بعده |
الأطراف المشاركة في معاملة 3DS2 #
معرفة دور كل طرف تجعل فهم رسائل الأخطاء وأدلة النزاعات أسهل بكثير.
- طالب 3DS (3DS Requestor) – أنت، التاجر، الذي يبدأ المصادقة من موقعه أو تطبيقه.
- خادم 3DS (3DS Server) – برنامج تشغّله عادةً بوابة الدفع أو مزوّد متخصص، يجمع بياناتك في طلب مصادقة ويتواصل مع الشبكات.
- خادم الدليل (Directory Server) – تشغّله كل شبكة بطاقات، ويوجّه الطلب إلى الجهة المُصدِرة الصحيحة بناءً على نطاق رقم البطاقة.
- خادم التحكم في الوصول (ACS) – تشغّله الجهة المُصدِرة أو جهة نيابةً عنها، ويقيّم المخاطر ويقرر الموافقة بصمت أو مطالبة حامل البطاقة بالتحدي.
- حزمة 3DS SDK – مكوّن مدمج في تطبيقات الهاتف لعرض التحدي بشكل أصلي داخل التطبيق بدلًا من نافذة متصفح.
كيف يعمل مسار 3DS2 خطوة بخطوة #
- جمع البيانات. في صفحة الدفع، يجمع خادم 3DS لديك معلومات المتصفح أو الجهاز، ومبلغ الطلب وعملته، وعنواني الفوترة والشحن، والبريد الإلكتروني، والهاتف، وسجل الحساب. وتُجري بعض الجهات المُصدِرة أيضًا استدعاءً قصيرًا يُسمى "3DS Method" لأخذ بصمة المتصفح في الخلفية.
- إرسال طلب المصادقة. يرسل خادم 3DS طلب مصادقة (AReq) عبر خادم الدليل التابع للشبكة إلى خادم ACS لدى الجهة المُصدِرة.
- قرار المخاطر لدى الجهة المُصدِرة. يقارن خادم ACS بياناتك بما تعرفه الجهة المُصدِرة عن حامل البطاقة: أجهزته المعتادة، ونمط إنفاقه، وموقعه، وسلوكه السابق.
- الرد. إما أن يُكمل رد المصادقة (ARes) العملية فورًا (المسار السلس)، أو يطلب تحديًا، أو يُبلغ بفشل المصادقة أو تعذّرها.
- التحدي عند الحاجة. يُكمل حامل البطاقة الخطوة التي تطلبها الجهة المُصدِرة، مثل الموافقة عبر تطبيق البنك أو إدخال رمز لمرة واحدة، ثم يرسل خادم ACS النتيجة النهائية.
- التفويض. ترسل بوابة الدفع طلب التفويض مرفقًا بقيمة المصادقة (CAVV لدى Visa وAAV لدى Mastercard) وقيمة ECI ومعرّف معاملة خادم الدليل، وتتحقق الجهة المُصدِرة من مطابقتها لما أصدرته.
المصادقة والتفويض قراران منفصلان؛ فقد تُرفض معاملة اجتازت المصادقة بنجاح بسبب عدم كفاية الرصيد، وقد تُقبل معاملة دون مصادقة.
المسار السلس مقابل مسار التحدي #
المسار السلس (Frictionless) #
في المسار السلس تكتفي الجهة المُصدِرة بالبيانات وحدها، فتصادق على المتسوق دون أي تفاعل منه. لا يرى العميل أي خطوة إضافية، ومع ذلك تحصل عادةً على نتيجة المصادقة نفسها وعلى الحماية نفسها من المسؤولية كما لو أنه أكمل تحديًا. وهذا هو السبب الرئيسي في أن 3DS2 أقل إضرارًا بمعدلات التحويل بكثير من الإصدار السابق.
مسار التحدي (Challenge) #
عندما ترى الجهة المُصدِرة مخاطر أعلى، أو عندما تفرض اللوائح المصادقة القوية للعميل، تطلب من حامل البطاقة إثبات هويته. والتحديات الحديثة تكون عادةً إشعارًا إلى تطبيق البنك مع موافقة بالبصمة أو الوجه، أو رمز مرور لمرة واحدة يُرسل عبر رسالة نصية. ويضيف التحدي بضع ثوانٍ وبعض حالات التخلي عن الشراء، لذا فالهدف هو تزويد الجهات المُصدِرة ببيانات جيدة كافية بحيث لا تطلب التحدي إلا عند الحاجة الحقيقية.
المصادقة المنفصلة (Decoupled) #
قدّم الإصدار 2.2 المصادقة المنفصلة، حيث يصادق حامل البطاقة خارج جلسة الدفع، كأن يفعل ذلك في تطبيق البنك بعد دقائق. وهي مفيدة لمراكز الاتصال وبعض السيناريوهات المؤجلة، لكن دعمها يختلف حسب الجهة المُصدِرة ومزوّد الدفع لديك.
قراءة النتائج: قيم transStatus وECI #
تعرض بوابة الدفع عادةً حقلين أساسيين: حالة المعاملة الصادرة من خادم ACS، ومؤشر التجارة الإلكترونية (ECI) الذي يُرسل مع طلب التفويض. وتختلف التسميات الدقيقة بين المزوّدين، لذا تأكد منها في وثائق بوابتك.
| transStatus | المعنى | قيمة ECI المعتادة (Visa / Mastercard) | ما الذي تفعله |
|---|---|---|---|
| Y | تمت المصادقة (سلسة أو بعد التحدي) | 05 / 02 | تابع إلى التفويض |
| A | محاولة؛ الجهة المُصدِرة أو ACS لا تشارك بالكامل | 06 / 01 | تابع عادةً؛ والحماية تتوقف على قواعد الشبكة |
| C | يلزم التحدي | – | اعرض التحدي |
| D | تأكيد التحدي المنفصل | – | انتظر النتيجة النهائية |
| N | لم تتم المصادقة أو رُفضت | 07 / 00 | لا تتابع دون مراجعة |
| R | مرفوضة من الجهة المُصدِرة | – | لا ترسلها للتفويض |
| U | تعذّرت المصادقة (مشكلة تقنية) | 07 / 00 | طبّق قواعد المخاطر الخاصة بك |
| I | للعلم فقط (مشاركة بيانات دون مصادقة) | 07 / 06 حسب الحالة | لا تتوقع نقل المسؤولية |
خزّن قيمة transStatus وقيمة ECI وقيمة المصادقة ومعرّف معاملة خادم الدليل مع كل طلب. فإذا تلقيت لاحقًا نزاع احتيال، فهذه بالضبط الحقول التي يحتاجها البنك المستحوذ لإثبات أن المعاملة تمت مصادقتها. ويمكنك مقارنتها بنتائج تحقق أخرى مثل رموز استجابة AVS وCVV في سجل الطلب.
نقل المسؤولية: ما الذي يغطيه وما لا يغطيه #
أشهر فوائد 3-D Secure هي نقل المسؤولية (Liability Shift). فعندما تتم مصادقة المعاملة بنجاح ثم يدّعي حامل البطاقة لاحقًا أنه لم يُجرِها، تنقل قواعد الشبكات عمومًا خسارة الاحتيال من التاجر إلى الجهة المُصدِرة. وعمليًا يعني ذلك أنه يمكن الدفاع ضد النزاعات المصنفة كاحتيال، مثل رموز الاحتيال لدى Visa أو رموز "عدم تفويض حامل البطاقة" لدى Mastercard، باستخدام بيانات المصادقة.
كما أن 3DS لا يعالج الاحتيال الودي، حيث يُجري حامل البطاقة الحقيقي عملية الشراء ثم يعترض عليها لاحقًا لسبب لا يتعلق بالاحتيال. لذلك تظل أوصاف الفواتير الواضحة والسياسات الصريحة وأدلة التسليم القوية أمورًا أساسية.
3DS2 واستثناءات المصادقة القوية للعميل #
في المنطقة الاقتصادية الأوروبية والمملكة المتحدة، تفرض قواعد PSD2 المصادقة القوية للعميل (SCA) على معظم مدفوعات البطاقات الإلكترونية التي يبدأها العميل، ويُعد 3DS2 الطريقة المعيارية لتطبيقها. ولدى أسواق أخرى، منها الهند وأجزاء من الشرق الأوسط وآسيا، متطلبات مصادقة خاصة بها. وحيث تنطبق SCA يمكنك طلب استثناء لتتجاوز الجهة المُصدِرة التحدي، لكن القرار النهائي يظل دائمًا بيد الجهة المُصدِرة.
| الاستثناء أو الإعفاء | متى ينطبق | ملاحظة حول المسؤولية |
|---|---|---|
| القيمة المنخفضة | المدفوعات الصغيرة تحت الحد التنظيمي مع حدود تراكمية | تبقى عادةً على التاجر |
| تحليل مخاطر المعاملة (TRA) | عندما تكون معدلات الاحتيال لدى البنك المستحوذ أو الجهة المُصدِرة دون مستويات محددة | تبقى على الطرف الذي طبّقه |
| المستفيد الموثوق | أضاف حامل البطاقة التاجر إلى قائمة موثوقة لدى بنكه | تتوقف على الجهة المُصدِرة والشبكة |
| المعاملات التي يبدأها التاجر | الاشتراكات والأقساط بعد إعداد تمت مصادقته | خارج نطاق SCA؛ أشر إلى المصادقة الأصلية |
| طلبات البريد والهاتف والمعاملات الخارجية | الطلبات عبر البريد أو الهاتف، أو وجود الجهة المُصدِرة أو البنك المستحوذ خارج المنطقة | خارج النطاق؛ وتنطبق قواعد المخاطر العادية |
تحدد الجهات التنظيمية والشبكات هذه الحدود والشروط، وهي تتغير بمرور الوقت، لذا اعتبر هذا الجدول للاسترشاد فقط وتأكد من القيم الحالية مع البنك المستحوذ.
متى تُفعّل 3-D Secure: استراتيجية قائمة على المخاطر #
خارج المناطق التي تفرض المصادقة، أنت من يقرر متى تستدعي 3DS. فتشغيله على كل طلب يحقق أقصى حماية من المسؤولية، لكنه قد يضيف خطوات على العملاء المتكررين منخفضي المخاطر، وعدم تشغيله إطلاقًا يتركك مكشوفًا. ويتبع معظم التجار المتمرسين حلًا وسطًا قائمًا على القواعد:
- صادِق دائمًا على أول عملية شراء من الحسابات الجديدة، خاصة للسلع مرتفعة القيمة أو سهلة إعادة البيع مثل الإلكترونيات وبطاقات الهدايا والتذاكر.
- صادِق عندما تتعارض المؤشرات: كأن تختلف دولة البطاقة المستخرجة من البحث عن BIN عن دولة عنوان IP، أو يكون عنوان الشحن جديدًا.
- صادِق بعد التغييرات الأخيرة في الحساب، مثل بريد إلكتروني جديد أو إعادة تعيين كلمة المرور أو إضافة بطاقة محفوظة جديدة.
- استخدم 3DS عند حفظ بطاقة لعمليات خصم مستقبلية يبدأها التاجر، حتى تستند المدفوعات المتكررة اللاحقة إلى إعداد تمت مصادقته.
- فكّر في التخطي أو طلب الاستثناءات فقط للعملاء الراسخين ذوي السجل النظيف، وحيث يدعم مزوّد الدفع ذلك.
- توقف وشدّد القواعد عند ظهور علامات هجوم اختبار البطاقات.
اعرف الجهة المُصدِرة ودولة البطاقة عبر أداة فحص BIN
كيف ترفع نسبة المعاملات السلسة #
لا تستطيع الجهات المُصدِرة الموافقة بصمت إلا عندما تثق بالبيانات. والتجار الذين يرسلون حقولًا كاملة ودقيقة باستمرار يواجهون تحديات أقل. ركّز على الممارسات التالية:
- أرسل الحقول الاختيارية. البريد الإلكتروني والهاتف وعنوان الشحن وعمر الحساب ومدى تطابق عنوان الشحن مع الفوترة، كلها تساعد الجهة المُصدِرة.
- شغّل 3DS Method. السماح للجهة المُصدِرة بأخذ بصمة المتصفح يمنح محرك المخاطر لديها دليلًا قويًا من الجهاز.
- نظّف بياناتك. تجنب القيم الوهمية مثل "test@test.com" أو "000"؛ فقد تعتبر الجهات المُصدِرة البيانات العشوائية مؤشر خطر.
- استخدم أحدث إصدار مدعوم. تضيف إصدارات البروتوكول الأحدث عناصر بيانات ومسارات جديدة مثل 3RI والمصادقة المنفصلة.
- اضبط مؤشر التحدي بعناية. اطلب "بلا تفضيل" أو "دون تحدٍّ" عندما يكون ذلك مناسبًا، و"طلب تحدٍّ" فقط عندما تريده فعلًا.
- راقب حسب الجهة المُصدِرة وBIN. تتبّع معدلات التحدي والنجاح والتخلي مجمّعة حسب الجهة المُصدِرة ونوع البطاقة والدولة لتعرف أين تتركز العوائق.
أخطاء شائعة في تطبيق 3DS #
- تفويض مبلغ أعلى من المبلغ الذي تمت مصادقته، كأن يُضاف الشحن بعد المصادقة، ما قد يُسقط نقل المسؤولية.
- معاملة النتيجتين "U" أو "A" تمامًا مثل "Y" دون فهم كيفية تعامل قواعد الشبكة معهما.
- عدم تخزين بيانات المصادقة، ثم العجز عن الدفاع ضد نزاعات الاحتيال بعد أشهر.
- نوافذ تحدٍّ لا تناسب الشاشات الصغيرة أو تحجبها إعدادات منع النوافذ المنبثقة.
- الإيقاف الكامل عند تعذّر 3DS بدلًا من الرجوع إلى قواعد المخاطر الخاصة بك.
- افتراض أن 3DS يغني عن الفحوص الأخرى؛ فهو يعمل بأفضل صورة إلى جانب فحوص AVS وCVV وحدود السرعة ومؤشرات الجهاز.
وأخيرًا، اختبر بشكل صحيح. ينشر مزوّد الدفع لديك بطاقات اختبار تُنتج نتائج المسار السلس والتحدي والفشل في بيئة الاختبار. استخدمها بدلًا من البطاقات الحقيقية، وتأكد من أن كل نتيجة تؤدي إلى حالة الطلب الصحيحة ورسالة العميل المناسبة والبيانات المخزنة الصحيحة.
الأسئلة الشائعة #
هل 3-D Secure 2 إلزامي؟
هل تمنحني المصادقة السلسة نقل المسؤولية؟
لماذا لا يزال بعض العملاء يواجهون التحدي؟
هل يحمي 3-D Secure من جميع النزاعات؟
ما الفرق بين ECI وCAVV؟
متخصصون في المدفوعات ومكافحة الاحتيال وأدوات المطورين.


