فشل مصادقة 3D Secure لبطاقات الدفع بالعملات المشفرة: الأسباب الشائعة وطرق المعالجة

عند استخدام بطاقة دفع بالعملات المشفرة للتسوق عبر الإنترنت أو سداد رسوم الاشتراكات، قد تواجه موقفًا غير متوقع: يكون الرصيد المتاح في البطاقة كافيًا، وتكون بيانات البطاقة وتاريخ انتهاء صلاحيتها صحيحة، ومع ذلك تظهر على صفحة الدفع رسالة «3D Secure authentication failed» أو «Authentication unsuccessful». وفي بعض الحالات، يُكمل حامل البطاقة التحقق من هويته، لكن عملية الدفع تفشل رغم ذلك.

لا تشير هذه الرسائل بالضرورة إلى المشكلة نفسها. فقد تتوقف المعاملة خلال مرحلة المصادقة باستخدام 3D Secure، أو تنجح المصادقة ثم تُرفض المعاملة لاحقًا في مرحلة تفويض الدفع.

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

ماذا يعني فشل مصادقة 3D Secure فعليًا؟

3D Secure، المعروف اختصارًا باسم 3DS، هو بروتوكول للمصادقة يُستخدم في معاملات البطاقات المصرفية عبر الإنترنت، ويعتمد حاليًا بصورة أساسية على معيار EMV 3-D Secure. ويتيح للتجار ومزودي خدمات الدفع وشبكات البطاقات وجهات إصدارها تبادل معلومات المصادقة للمساعدة في التحقق من أن الشخص الذي يجري الدفع مخوّل باستخدام البطاقة.

تُعرف الخدمة المقابلة لدى Visa باسم Visa Secure، بينما تحمل خدمة Mastercard اسم Mastercard Identity Check.

تجري مصادقة 3DS عادةً عبر أحد مسارين:

• المصادقة دون تدخل إضافي (Frictionless Flow): تقيّم جهة إصدار البطاقة المعاملة استنادًا إلى مؤشرات المخاطر، مثل مبلغ المعاملة ومعلومات الجهاز وبيانات التاجر، دون الحاجة إلى اتخاذ حامل البطاقة أي إجراء إضافي.

• المصادقة بالتحدي (Challenge Flow): يُطلب من حامل البطاقة تأكيد هويته بخطوة إضافية، مثل إدخال رمز تحقق لمرة واحدة (OTP)، أو الموافقة على المعاملة عبر تطبيق جهة الإصدار، أو استخدام وسيلة مصادقة أخرى مدعومة.

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

للاطلاع على المبادئ التقنية لهذين المسارين، يمكن الرجوع إلى الورقة التقنية الصادرة عن EMVCo بشأن EMV 3-D Secure.

المصادقة وتفويض الدفع مرحلتان مختلفتان

تتولى تقنية 3DS المصادقة (Authentication)، بينما يحدد تفويض الدفع (Authorization) ما إذا كانت المعاملة ستحصل على الموافقة.

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

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

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

ابدأ بتحديد ما حدث أثناء محاولة الدفع

غالبًا ما تعبّر رسالة «Payment Failed» التي يعرضها التاجر عن النتيجة النهائية لعملية الدفع فقط، دون أن توضّح الخطأ الأساسي. وحتى عند ظهور رسالة «3DS Failed»، قد تكون هناك حاجة إلى مراجعة سجلات المصادقة والتفويض بصورة منفصلة.

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

عدم وصول رمز OTP: افحص حساب حامل البطاقة، لا بيانات التسجيل في المنصة فقط

تُعد رموز التحقق لمرة واحدة وسيلة شائعة في مصادقة 3DS بالتحدي، لكن قناة إرسالها تتحدد وفق خدمة إصدار البطاقة المعنية.

قد تختلف الشركة التي تدير العلامة التجارية لبطاقة الدفع بالعملات المشفرة عن المؤسسة التي تصدر البطاقة فعليًا. كما أن رقم الهاتف المستخدم للتسجيل في منصة الأصول المشفرة ليس بالضرورة الرقم المرتبط بحساب حامل البطاقة لاستقبال رموز مصادقة 3DS.

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

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

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

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

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

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

صفحة المصادقة لا تفتح، أو يتعذر الرجوع إلى التاجر بعد إتمامها

لا تعتمد مصادقة 3DS بالتحدي على جهة إصدار البطاقة وحدها، بل تتطلب أيضًا تكاملًا صحيحًا بين صفحة الدفع لدى التاجر ومزود خدمات الدفع.

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

إذا ظهرت نافذة فارغة، أو استمر تحميل الصفحة دون انتهاء، أو تعذر الرجوع إلى التاجر بعد المصادقة، فتحقق من الأمور التالية:

• هل فُتحت صفحة الدفع من خلال متصفح مدمج في تطبيق للتواصل الاجتماعي أو البريد الإلكتروني؟

• هل تتداخل إضافات المتصفح أو أدوات حظر النصوص البرمجية أو إعدادات الخصوصية مع صفحة المصادقة؟

• هل انقطع اتصال الشبكة أثناء إعادة التوجيه أو إجراء المصادقة؟

• هل ظلت صفحة الدفع الأصلية نشطة بعد الموافقة على الطلب داخل التطبيق؟

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

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

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

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

وفق البنية التقنية لمعيار EMV 3DS، يحتاج نظام 3DS لدى التاجر إلى التنسيق مع خادم التحكم في الوصول (Access Control Server، أو ACS) التابع لجهة إصدار البطاقة لإتمام المصادقة. وقد يتولى تشغيل هذا الخادم مزود خدمات مفوض من جهة الإصدار. ولا يستطيع حامل البطاقة العادي الاطلاع على هذه الاتصالات التقنية الداخلية، ولذلك تتطلب متابعة المشكلة عادةً تدخل التاجر أو مزود خدمات الدفع أو جهة إصدار البطاقة.

لماذا يطلب بعض التجار المصادقة بينما لا يطلبها آخرون؟

ليس من غير المعتاد أن تمر بطاقة الدفع بالعملات المشفرة نفسها بمسارات 3DS مختلفة عند استخدامها لدى تجار مختلفين.

يتأثر قرار بدء مصادقة 3DS، وكذلك قرار مطالبة حامل البطاقة بإجراء مصادقة إضافية، بعوامل منها إعدادات الدفع لدى التاجر، وتقييم المخاطر لدى جهة الإصدار، وقواعد شبكات البطاقات، والمتطلبات التنظيمية المعمول بها.

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

تستخدم Stripe الرمز authentication_required للإشارة إلى إحدى حالات رفض الدفع المرتبطة بمتطلبات المصادقة. ووفق وثائقها الرسمية الخاصة برموز رفض المدفوعات، ينبغي عادةً لتكاملات الدفع التعامل مع متطلبات المصادقة المعنية، وإعادة إشراك حامل البطاقة في مسار الدفع عند الضرورة.

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

في أسواق مثل المنطقة الاقتصادية الأوروبية، حيث تنطبق قواعد المصادقة القوية للعملاء (Strong Customer Authentication، أو SCA)، تخضع المدفوعات بالبطاقات عبر الإنترنت أيضًا لمتطلبات تنظيمية ذات صلة. ولا تعني هذه القواعد وجوب ظهور نافذة لإدخال رمز تحقق في كل معاملة؛ فقد تؤثر الإعفاءات المستوفية للشروط وترتيبات المصادقة المحددة في المسار الذي يراه المستخدم.

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

هل تعني رسالة Card not enrolled أن البطاقة لا تدعم 3DS؟

لا يمكن الجزم بذلك مباشرةً.

قد تتعلق رسالة «Card not enrolled» بعدم إكمال تسجيل حساب حامل البطاقة في خدمة 3DS، أو بإعدادات المصادقة الخاصة ببرنامج بطاقات معين، أو بعدم قدرة خدمة المصادقة المعنية على التعرف إلى البطاقة. ويتطلب تحديد السبب الفعلي مراجعة سجلات الأخطاء.

لا يكفي أن تكون البطاقة مفعلة، أو أن يكون المستخدم قد أكمل إجراءات اعرف عميلك (KYC)، أو أن تحمل البطاقة شعار Visa أو Mastercard، لإثبات أنها تدعم وسيلة مصادقة 3DS المطلوبة لدى التاجر الحالي.

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

إذا أعاد التاجر صراحةً رسالة «3D Secure not supported» أو «Card not enrolled»، فيمكن الاستفسار من مزود خدمة البطاقة عما يلي:

• هل جرى تفعيل البطاقة وتسجيلها في خدمة مصادقة 3DS المناسبة؟

• ما وسائل المصادقة التي يدعمها برنامج البطاقة، وهل توجد قيود إقليمية أو مرتبطة بالمنتج؟

• إذا كان استكمال التسجيل أو تحديث بيانات التحقق أو إعادة تفعيل الخدمة مطلوبًا، فما القناة والإجراءات المناسبة لذلك؟

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

نجحت المصادقة، فلماذا فشلت عملية الدفع؟

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

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

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

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

لمزيد من المعلومات حول مشكلات الرصيد وقيود التجار وأسباب رفض التفويض المعتادة، يمكن مراجعة دليل UCard Radar بشأن رفض معاملات بطاقات الدفع بالعملات المشفرة.

عند تكرار فشل المصادقة، لا تستمر في إعادة المحاولة

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

توضح Adyen في وثائق استكشاف أخطاء 3D Secure لخدمة إصدار البطاقات أنه بالنسبة إلى البطاقات الصادرة عبر خدمتها، تؤدي خمس محاولات مصادقة فاشلة متتالية إلى حظر مؤقت لمحاولات 3DS الإضافية. وعادةً ما يُرفع هذا القيد تلقائيًا بعد ساعة واحدة، ويمكن أيضًا التواصل مع فريق الدعم التابع لها لمعالجة المشكلة.

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

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

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

هل ينبغي التواصل مع التاجر أم جهة إصدار البطاقة؟ يعتمد الأمر على من يملك سجلات الخطأ

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

فقد تتولى منصة أصول مشفرة إدارة العلامة التجارية وخدمة العملاء، بينما تتحمل مؤسسة مرخصة مسؤولية إصدار البطاقة، ويتولى معالج مستقل معالجة طلبات التفويض، وتنفذ خدمة متخصصة لخوادم ACS مصادقة 3DS.

لذلك، قد لا يعرض التطبيق المرتبط بالعلامة التجارية سجلات المصادقة كاملةً.

تقدم خدمة Adyen Issuing مثالًا على ذلك. إذ توضح وثائقها الرسمية لاستكشاف الأخطاء أنه عندما تفشل مصادقة 3DS وتمنع المعاملة من الاستمرار بعد مرحلة المصادقة، لا يُرسل طلب التفويض إلى Adyen. ونتيجة لذلك، لا يُنشأ طلب تفويض مُمرر أو إشعار webhook مقابل له، كما لا تظهر المعاملة في قائمة Payments داخل Adyen Customer Area. وهذه حالة معالجة محددة ضمن خدمة Adyen Issuing، ولا تسمح بالاستنتاج أن جميع بطاقات الدفع بالعملات المشفرة أو جهات الإصدار الأخرى تستخدم آلية التسجيل نفسها.

لذلك، فإن عدم ظهور المعاملة في سجل معاملات البطاقة لا يعني أن التاجر لم يحاول بدء مصادقة 3DS.

يمكن تحديد الجهة التي ينبغي التواصل معها أولًا وفق طبيعة المشكلة:

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

عند التواصل مع التاجر، يمكن طرح السؤال التالي مباشرةً:

هل يمكنكم تأكيد ما إذا كانت مصادقة 3D Secure قد بدأت لهذه المعاملة، وما حالتها النهائية، وما إذا كانت عملية الدفع قد وصلت إلى مرحلة التفويض؟ وإذا فشلت المصادقة، فهل يمكن تزويدي برمز الخطأ المعني أو سبب الفشل؟

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

كيف يمكن تفسير رموز الحالة transStatus في 3DS؟

إذا استطاع فريق الدعم الفني لدى التاجر تقديم سجلات مصادقة أكثر تفصيلًا، فقد تتضمن الحقل transStatus الخاص بمعيار EMV 3DS.

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

لا ينبغي اعتبار الحالتين C وD فشلًا نهائيًا للمصادقة بصورة تلقائية. كذلك لا تعادل الحالتان A وI الحالة Y. ويتطلب تحديد ما إذا كانت المصادقة قد اكتملت نهائيًا النظر في مرحلة الرسالة والنتائج المرتبطة بها وطريقة معالجتها لدى مزود خدمات الدفع.

وفق مواصفات بروتوكول 3DS الصادرة عن EMVCo، يُعرَّف الرمز I بأنه Informational Only، ويشير إلى تأكيد استلام تفضيل التحدي الذي قدمه طالب مصادقة 3DS. ولا يعني ذلك أن حامل البطاقة قد أكمل المصادقة.

في المقابل، تصف وثائق مرجع واجهة 3D Secure 2 API لدى Adyen الرمز I بالعبارة «Authentication / exemption granted by Issuer»، أي أن جهة الإصدار وافقت على المصادقة أو منحت إعفاءً منها. وهذه صياغة محددة واردة في وثائق واجهة Adyen، ولا يجوز الخلط بينها مباشرةً وبين التعريف الوارد في بروتوكول EMV 3DS. كذلك لا ينبغي مساواة الإعفاء من المصادقة بنجاح التحقق من هوية حامل البطاقة الذي تعبّر عنه الحالة Y. وتورد الوثائق نفسها رموز الأسباب transStatusReason التي يستطيع الفريق الفني لدى التاجر الاستعانة بها في التحقيق الإضافي.

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

عند مشاركة لقطات الشاشة أو معلومات المعاملة، يجب تقديم البيانات الضرورية فقط بعد إخفاء المعلومات الحساسة. ولا يجوز مشاركة رقم البطاقة كاملًا، أو رمز CVV، أو كلمة مرور الحساب، أو رمز التحقق لمرة واحدة، أو عبارة استرداد المحفظة مع أي شخص.

بالنسبة إلى المستخدمين الذين يعتمدون بصورة متكررة على بطاقات الدفع بالعملات المشفرة لسداد الاشتراكات والتسوق عبر الحدود والخدمات الإلكترونية، من المفيد التأكد قبل طلب بطاقة جديدة من توفر خدمة 3DS، وقنوات المصادقة المدعومة، والجهة المسؤولة عن تقديم المساعدة عند فشل التحقق. فهذه المعلومات تعكس قدرة المنتج على توفير الدعم ومعالجة المشكلات أثناء الاستخدام الفعلي بصورة أوضح من مجرد الإعلان عن «دعم المدفوعات عبر الإنترنت عالميًا».