أخطاء Checkout: صمّم مسار تعافٍ لا طريقًا مسدودًا

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

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

يحلل هذا المقال نمطًا تصميميًا بالاعتماد على وثائق الوصول والدفع الحالية التي جرى التحقق منها في 29 سبتمبر 2026. أمثلة Checkout افتراضية بوضوح، وليست نتائج من متجر نور أو A/B Test أو حالة عميل.

صنّف الفشل قبل كتابة الرسالة

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

تحتاج الحالات إجراءات مختلفة. يمكن لخطأ Postal Code الإشارة إلى حقل واحد. ويحتاج المنتج النافد قرارًا في السلة. وتعيد البطاقة المنتهية العميل إلى الدفع مع حفظ الشحن. أما انتهاء مهلة الشبكة بعد إرسال الدفع فلا يجب أن يدعو لمحاولة مكررة؛ بل يحتاج فحص الحالة ورسالة واضحة بأن الدفع قيد التأكيد.

اكتب Error-State Contract قبل تصميم الشاشات. سجل لكل حالة: إشارة المصدر، والشرح الآمن للعميل، والخطوة المتأثرة، والبيانات التي بقيت صحيحة، وإجراء التعافي الأساسي، والبديل، ووجهة Focus، ورمز Analytics، والشرط الذي ينهي الحالة. يجب أن يراجع المصممون والمهندسون والدعم وفريق الدفع العقد نفسه.

احفظ العمل الذي ما زال صالحًا

يصبح التعافي مكلفًا عندما تمحو قيمة خاطئة واحدة عشر قيم صحيحة. احتفظ بالسلة والعنوان وخيار التوصيل وسياق الدفع غير الحساس إلا إذا أبطلها التغيير فعلًا. تقدم إرشادات WCAG 2.2 حول الإدخال المكرر Checkout مثالًا مباشرًا: بعد رقم بطاقة غير صحيح، لا ينبغي مسح المعلومات المرسلة من النموذج.

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

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

ضع الخطأ في مكانين مفيدين

عندما يكشف الإرسال أخطاء حقول، استخدم ملخصًا في بداية قسم النموذج ورسالة Inline بجانب كل حقل متأثر. يحتفظ نمط Validation في GOV.UK بالقيم كما أدخلها المستخدم، وينقل Keyboard Focus إلى ملخص الخطأ، ويربط كل بند بحقل. كما تطلب إرشادات Error Summary تطابق صياغة الملخص مع الرسالة بجانب المدخل.

يجيب الملخص عن «ما الذي أوقف Checkout؟» ويوفر التنقل. وتجيب الرسالة القريبة عن «ما الذي يجب تغييره هنا؟». اربطها برمجيًا بالحقل، وعبّر عن Invalid State دلاليًا لا باللون فقط، ولا تعتمد على أيقونة أو حد أحمر وحده. حتى الخطأ الواحد قد يحتاج ملخصًا لمستخدم Screen Reader أو Zoom لا يرى الحقل وأعلى الصفحة معًا.

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

اكتب تعليمات تعافٍ لا رمز تشخيص

تجيب الرسالة المفيدة عن أربعة أسئلة: ماذا حدث، وأين، وماذا يستطيع العميل فعله الآن، وماذا حفظ النظام. تجيب «فشل الدفع» عن واحد فقط. أما «انتهت صلاحية البطاقة. استخدم بطاقة أخرى أو حدّث تاريخ الانتهاء؛ حُفظ عنوانك وخيار التوصيل» فتجعل المسار ظاهرًا.

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

احتفظ بطبقة تشخيص مستقلة للدعم والهندسة: فئة خطأ ثابتة، ورمز المزود، ومعرف محاولة الدفع، وCorrelation ID، والتوقيتات. رسالة العميل قرار منتج، أما سجل التشخيص فدليل تشغيلي. يمكن ربطهما دون عرض تفاصيل حساسة أو مربكة.

تعامل مع نتائج الدفع كآلة حالات

أخطاء الدفع ليست فئة واحدة. تميز وثائق الرفض في Stripe بين رفض البنك، والدفع المحظور، وAPI Call غير الصحيحة، وتوضح أن بعض النتائج تحمل أسبابًا محددة مثل رمز أمان غير صحيح أو بطاقة منتهية، بينما لا ينبغي إعادة بعضها دون تغيير. يجب أن تحول Checkout الدليل إلى إجراءات مسموحة، لا أن تعرض رد الـGateway الخام.

مثّل حالات: جاهز، جارٍ الإرسال، يحتاج إجراء العميل، رفض قابل للإصلاح، استخدم وسيلة أخرى، نتيجة مجهولة، مؤكد، وفشل نهائي. امنع الإرسال المكرر فقط أثناء نشاط المحاولة نفسها، وأبقِ Status Message قابلة للوصول تشرح ما يحدث. وإذا كانت النتيجة مجهولة، فاستعلم عن محاولة الدفع الحالية بهويتها الثابتة؛ لا تنشئ Financial Intent ثانية لأن المتصفح انتهت مهلته.

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

أعلن التقدم من دون سرقة الانتباه

تغير Checkout حالتها كثيرًا دون إعادة تحميل: يعاد حساب التوصيل، أو تُقبل قسيمة، أو تفتح المصادقة، أو يستمر تأكيد الدفع. تطلب إرشادات Status Messages في WCAG أن تكون التغييرات المهمة التي لا تنقل Focus متاحة برمجيًا للتقنيات المساعدة.

استخدم Status Region هادئة للتقدم والنجاح، واحجز Alert الفورية لما يحتاج انتباهًا عاجلًا. لا تعلن كل ضغطة، ولا تكرر الرسالة في أكثر من Live Region. Spinner بلا نص ليست حالة مكتملة؛ أرفق بها «جارٍ تأكيد الدفع—لا تغلق الصفحة».

إذا تغير الزر من «إتمام الطلب» إلى «جارٍ التنفيذ»، فامنع تفعيله مرة ثانية، واعرض Busy State، ولا توفر إلغاءً إلا عندما يكون آمنًا. قد يبدو Control معطل بلا تفسير كأنه معطوب، خصوصًا أثناء مصادقة بطيئة أو تعافٍ من الشبكة.

أضف المراجعة حيث تصبح العواقب مكلفة

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

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

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

مثال افتراضي: خطآن ومسار تعافٍ واحد

تخيل Checkout على الهاتف يرسل فيها العميل العنوان والدفع معًا. Postal Code ملتبس، وموعد التوصيل لم يعد متاحًا أثناء بقاء النموذج مفتوحًا. هذا مثال تصميمي افتراضي.

تعود الصفحة مع حفظ كل القيم. ينتقل Focus إلى ملخص فيه رابطان: «أدخل Postal Code كاملًا» و«اختر موعد توصيل آخر». ينقل كل رابط إلى Control المطابقة حيث تظهر رسالة Inline بالنص نفسه. يبقى الموعد القديم ظاهرًا لكنه غير متاح، وتعرض البدائل أسعارها، ويؤدي تغيير الموعد إلى تحديث الإجمالي عبر Status Message معلنة.

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

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

قس هل تعافى العملاء فعلًا

انخفاض عدد الأخطاء الخام ليس نجاحًا بالضرورة؛ فقد تكون Validation غائبة، أو قد يغادر العملاء قبل تسجيل الخطأ. قس التعرض للخطأ حسب الفئة، ونجاح التصحيح، والزمن حتى Submit صحيح، وتكرار الخطأ نفسه، وعدد Error Loops، والمغادرة بعد الخطأ، واختيار وسيلة بديلة، وعمر نتائج الدفع المجهولة. احتفظ بحوادث الخصم والطلب المكررين Guardrails صلبة.

قسّم النتائج حسب الجهاز واللغة واتجاه النص والمتصفح، ومجموعة أبحاث التقنيات المساعدة حيث يسمح Consent وحجم العينة. تحتاج RTL العربية إلى ترتيب Focus وروابط الملخص وربط الحقول وقراءة سلاسل الدفع مختلطة الاتجاه بالجودة نفسها. لا تضع العناوين أو أجزاء البطاقة أو نص العميل الحر في Analytics Labels.

ادمج Telemetry مع Usability Testing قائم على المهام. اختبر لوحة المفاتيح وScreen Reader، وZoom بنسبة 200%، وAutofill، والقيم المنسوخة مع مسافات، وشبكة بطيئة، وزر Back، وRefresh أثناء الإرسال، وتغير المخزون، ودفعًا ينجح في الخادم بعد انتهاء مهلة العميل. اسأل المشاركين ماذا يعتقدون أنه حدث وما الذي سيفعلونه. إذا لم يكن الإجراء التالي متوقعًا، فحالة الخطأ غير مكتملة.

القاعدة بسيطة: احفظ ما بقي صحيحًا، وحدد المشكلة، واقترح الإجراء الآمن، وأعلن التقدم بصورة قابلة للوصول، واجعل نتيجة المعاملة غير ملتبسة. لا ينجح خطأ Checkout إلا عندما يستطيع العميل التعافي دون فقد الثقة أو إنشاء خطر مالي ثانٍ.

إعداد: Noor Yasser