في مزود دفع حقيقي لا يوجد رقم سحري واحد يقبل دائما. فما يحكم النتيجة في مزود مثل Stripe test cards هو جدول داخلي في بيئة الاختبار: تلتقط البيئة الأرقام التي تعرفها، وتقرأ صفا في جدول السيناريوهات، وتعيد الاستجابة التي يقترن بها ذلك الصف. فالبطاقة هنا مفتاح تشغيل لا وسيلة دفع، والرقم يحدد الحالة التي تريد اختبارها، من النجاح البسيط إلى الرفض المعقد الذي يتطلب مصادقة إضافية.
توضح هذه المقالة كيف تعمل القائمة، ولماذا لا تكون الأرقام مشتركة بين البيئات، وكيف تختار القيم بحيث تغطي مسارا كاملا لا لقطة واحدة.
كيف يقرر المزود نتيجة الاختبار؟
البيئة التجريبية لمزود الدفع تتصرف كأنها شبكة بطاقات مصغرة. فعندما يصل طلب دفع، يقرأ دفتر عناوين ثابتا مربوطا داخل المزود نفسه، ولا يخرج إلى أي شبكة خارجية، ولا يستشير أي جهة مصدرة.
ولكل صف في ذلك الدفتر قيمة محددة ونتيجة محددة: بطاقة تقبل، وبطاقة ترفض بسبب عام، وبطاقة ترفض لسبب يخص حساب الجهة المصدرة، وبطاقة تطلب خطوة تحقق إضافية. ولأن الجدول ثابت، فالسلوك قابل للتكرار تماما، وهذا سبب وجوده أصلا: فريق يختبر على جهازين مختلفين يجب أن يحصل على النتيجة نفسها.
وهذه الخاصية تعني أيضا شيئا مهما: القيمة لا تحمل معنى خارج بيئة ذلك المزود. ورقم ناجح عند مزود ما قد لا يعني شيئا عند غيره، أو قد يعني شيئا مختلفا تماما.
لماذا تنشر مزودات الدفع قوائم أرقام الاختبار؟
يبدو نشر أرقام تجريبية سلوكا غريبا لمن ينظر إليه من خارج المجال. لكن الفائدة واضحة من الطرفين.
فمن جهة التاجر، لا يستطيع أحد اختبار مسار الطلب من طرفه إلى طرفه دون قيم مقبولة من المزود. والبنية التحتية الحقيقية للشبكات لا يمكن استخدامها لهذا الغرض، لأن ذلك يعني معاملات حقيقية على حسابات حقيقية. فالقائمة هي الطريقة الوحيدة لتمرين مسارات النجاح والفشل دون لمس أي مال.
ومن جهة المزود، القائمة المنشورة وثيقة. فالتاجر الذي يخالف سلوكا موثقا يمكن أن يوجه إليها، والتاجر الذي يختبر بشكل غير صحيح ينتج عنه دعم فني مكلف للطرفين. ولهذا ينشئ المزود الصفحة ويحدثها بدل أن يترك كل فريق يختلق قيمه.
البطاقة العامة للنجاح
هناك قيمة واحدة موجودة في كل دليل تقريبا وتحفظها الفرق عن ظهر قلب، وهي 4242 4242 4242 4242. وتملك الطول المعتاد، ولها بادئة تنتمي إلى شبكة Visa، ورقم ختامي يجعل مجموع التحقق صحيحا. وبقية الحقول تملأ بقيم مقبولة، أي تاريخ انتهاء في المستقبل ورمز أمان من ثلاثة أرقام.
هذه القيمة هي نقطة البداية المعقولة، ونقطة النهاية السيئة. فالاختبار الذي يتوقف عندها يثبت أن المسار الأساسي موصول، ولا يثبت أي شيء عن التصرف عندما لا تسير الأمور على ما يرام، وهو ما يقضي فيه النموذج معظم عمره الإنتاجي.
نصيحة: هذه القيم تعمل في بيئة الاختبار وحدها
القيمة نفسها عند إرسالها إلى قناة حقيقية لا يقبلها أحد من الجانبين. فبيئة الإنتاج عند مزود الدفع لا تحتوي على الدفتر الداخلي نفسه، فتمرر الطلب إلى الشبكة الحقيقية، حيث لا يعرف أحد هذا الرقم، فتعود النتيجة بالرفض.
ولهذا لا يجوز أن تنتقل بيانات الاختبار إلى أي بيئة تفويض حقيقية، ولا أن تستنسخ بيانات الاختبار من بيئة إلى أخرى بغير قصد، ولا أن يبقى أي منفذ في نظامك قابلا للكتابة عليه من بيئة الاختبار. والتقاسم الصحيح هو أن تحتفظ البيئتان بمفاتيح منفصلة تماما، وأن يستخدم كل مسار في الكود المفتاح الذي يخص بيئته.
عائلات الرفض التي تستحق التغطية
الرفض ليس حالة واحدة، وأهم ما تعلمه قائمة المزود هو أن هناك عائلات مختلفة تحتاج معالجة مختلفة. والنسخ الشائعة تغطي:
- رفض عام. يصل النموذج ولا يبلغ عن سبب محدد. هو الحالة الافتراضية التي يجب أن يتعامل معها كل مسار.
- تعذر الوصول إلى الجهة المصدرة. يبدو كفشل مؤقت في الاتصال لا كقرار سلبي من البنك.
- رصيد غير كاف. رفض نهائي لسبب خاص بالحساب، وإعادة المحاولة لن تغيره.
- بطاقة منتهية. فشل يتطلب مسار استبدال البطاقة لا مسار إعادة المحاولة.
- خطأ في المعالجة. مشكلة عابرة على مستوى النظام، وقد تنجح المعاملة نفسها عند إرسالها مرة أخرى.
- حجب مشتبه به للاحتيال. الرفض الذي يحتاج وضوحا في الرسالة ومسار دعم واضحا للمستخدم.
الفرق العملي بين هذه العائلات ليس نص الرسالة وحده، بل القرار الذي يتخذ بعدها: هل تعيد المحاولة، ومتى، وهل تبلغ المستخدم أن يجرب بطاقة أخرى، وهل يجب أن يصبح الطلب حالة خاصة يراجعها أحد.
محاكاة المصادقة الإضافية
بعض مسارات الدفع تمر بخطوة تحقق إضافية يقودها بنك الجهة المصدرة، وفي البيئة التجريبية يحاكي المزود هذه الخطوة بطريقتين: حالة تنجح التحقق، وحالة تفشل فيه أو تترك بلا جواب.
وتغطية هذه الحالات ليست تفصيلا ثانويا، لأن نظام المعاملات يحتاج أن يقبل حالات وسيطة: طلب لم يحسم بعد، وطلب يحتاج تدخل العميل، وطلب انتهت صلاحية جلسته قبل أن يكمل. وإذا لم يمر النظام بهذه الحالات في بيئة الاختبار، فسيقابلها أول مرة في الإنتاج مع مستخدم حقيقي ينتظر النتيجة.
قائمة السيناريوهات أقوى من رقم واحد
من الخطأ الشائع تخزين رقم واحد في ملف إعدادات واستخدامه في كل مكان. فالقيمة الواحدة لا تصف سيناريو، والاختبار الحقيقي يحتاج تسمية النية لا الرقم.
والأفضل أن تدار المجموعة كوثيقة صغيرة من الحالات: اسم الحالة، والبعد الذي تفحصه، والنتيجة المتوقعة. فحالة تفحص رفضا باستخدام بطاقة الرصيد غير الكاف يجب أن تقول صراحة إنها تتوقع رفضا دائما، وإن النظام يجب أن يمنع إعادة المحاولة عليها، وإن الشاشة يجب أن تظهر مسار البطاقة البديلة. وهكذا تصير المجموعة مطابقة لقواعد عملك لا مجرد أرقام مجمعة.
وتستكمل هذه القائمة بأرقام مقترنة بحالات أخرى: بطاقة ببادئة شبكة مختلفة لاختبار الكشف، وبطاقة بتاريخ انتهاء في الماضي لاختبار تحقق الحدود، وبطاقة عادية لتمرين المسار السعيد. وأرقام البطاقات للاختبار تعرض الخصائص التي تفصل بين هذه الأنواع، ومقارنة الشبكات تساعدك في اختيار البادئات التي تريد أن يتعرف عليها كاشفك.
للمطورين: ضبط بيانات الاعتماد والبيئات
الانفصال الحقيقي بين البيئات ليس مفاتيح منفصلة فقط، بل تصميم يمنع الخلط من أصله.
ابدأ بمراجعة ما يفعله كل مسار في الكود. فإذا كان مفتاح البيئة يقرأ من ملف واحد وينتشر إلى كل الخدمات، فسيأتي يوم يستخدم فيه مسار واحد مفتاحا لم يقصد. واجعل المفتاح مرفقا بيئته في وقت التشغيل، وليكن إرسال طلب دفع إلى بيئة إنتاج من مفتاح اختبار خطأ صريحا لا حالة صامتة.
ثم راجع السجلات. فحقول الاختبار لا يجوز أن تتسرب إلى أي مكان يحتفظ بأثر طويل، ولا أن تخلط مع بيانات إنتاجية في جدول واحد، لأن جدولا واحدا يعني أن التفريق بين الاثنين لاحقا سيصير تخمينا. وإذا كان اختبارك يمر عبر واجهتك نفسها، فتأكد أن الواجهة تعرف أنها في وضع الاختبار ولا تظهر أي إشارة خاطئة عن حصول دفع حقيقي.
وأخيرا افحص ماذا تفعل بحمولة الاختبار بعد استخدامها. فالقيم التي ترسل في سياق اختبار لا يجب أن تظهر في تقرير أو في تصدير أو في نسخة احتياطية تستخدم لاستعادة بيئة حقيقية. وتغطي ملاحظات PCI DSS القواعد الأوسع لبيانات الاختبار، ويضع دليل التحقق في الكود الفحوص قبل بلوغ هذه الحالة.
متى تكون البيانات المنشأة أفضل من قائمة المزود؟
مناسب أن تستخدم قائمة المزود إن كان مزودك هو موضوع الاختبار نفسه. أما إذا كنت تختبر منطقك أنت، ككشف الشبكة أو تحقق المجموع أو حفظ نماذج كثيرة، فالقائمة قصيرة ولا تتنوع.
هنا تظهر فائدة البيانات المنشأة: أعداد كبيرة من البطاقات الصحيحة بنيويا، مقسمة على الشبكات التي تريدها، وتاريخ انتهاء متسق في الدفعة نفسها، ودون أي قيمة محفوظة عن ظهر قلب. وأداة إنشاء رقم البطاقة تنتج هذه المجموعات وتتيح لك اختيار الشبكة.
الخطوات التالية
حول مجموعة الحالات من ملاحظات إلى جدول له أعمدة: الحالة، القيمة المستخدمة، النتيجة المتوقعة، والقرار التالي المطلوب من الكود. ثم شغل الجدول في اختباراتك الآلية، وأضف حالة تحقق إضافية وحالة رفض نهائي، فهما الحالتان الأكثر إهمالا في أنظمة الدفع.