غادر العميل التطبيق ليؤكد الدفع، ثم عاد فوجد السلة كما تركها. هل يضغط مرة أخرى؟ هذه اللحظة تستحق مكانًا في طلب عرض برمجة التطبيق، لأنها تربط مال العميل بحجزك الفعلي، بينما قد تعرض شاشة أنيقة رسالة غير كافية لاتخاذ القرار.
لشراء تنفيذ واضح، اطلب سيناريوهات للفشل والانتظار والعودة، لا تجربة نجاح واحدة. الهدف أن يعرف العميل والموظف ما ثبت وما يزال مجهولًا، وأن تظهر الحالة نفسها عند فتح الطلب من جهاز آخر، دون الاعتماد على ذاكرة الهاتف وحدها.
ابدأ بخط زمني لطلب واحد
نفترض تطبيقًا لحجز زيارة صيانة منزلية فعلية، وليس شراء محتوى رقمي. المثال توضيحي ولم ينفذ عليه تحصيل. اختار العميل موعدًا، وبدأ محاولة دفع، ثم خرج أثناء التحقق. نريد تتبع رقم الطلب ومرجع المحاولة والنتيجة لدى مزود الدفع وما عرفه الخادم وما رآه العميل.
اكتب بجوار كل نقطة مصدر المعلومة ووقتها. عبارة «ظهرت علامة النجاح» تصف واجهة، ولا تشرح وحدها لماذا ثبت الموعد. وفي المقابل، إغلاق الشاشة لا يثبت أن المال لم يتحرك. يجب أن يستطيع الدعم تفسير التسلسل دون مطالبة العميل بإعادة المحاولة فورًا.
بطاقة قبول للحالات المربكة
| الحالة التجريبية | ما تطلب رؤيته | سؤال الاستلام |
|---|---|---|
| خروج أثناء التحقق | طلب محفوظ وحالة مفهومة عند العودة | من أين جاءت الحالة المعروضة؟ |
| تأخر تأكيد المزود | انتظار ظاهر وخطوة متابعة محددة | من يراجع الطلب إذا طال الانتظار؟ |
| إغلاق نافذة الدفع | تمييز إغلاق الواجهة من إلغاء الدفع المثبت | هل فُحصت المحاولة القائمة؟ |
| ضغط جديد من العميل | صلة واضحة بالطلب والمحاولة السابقة | كيف يُمنع قرار تحصيل غير مقصود؟ |
| نجاح يصل بعد مغادرة العميل | تحديث الحجز وإتاحة نتيجة قابلة للاسترجاع | ماذا يرى الموظف والعميل لاحقًا؟ |
هذه بطاقة مقترحة للمشتري، وليست أسماء حالات موحدة لكل البوابات. اطلب من المنفذ ملأها وفق وسيلة الدفع المختارة وطريقة الحجز. لا تحوّل كل تأخير إلى رفض، ولا تعد العميل بموعد مؤكد قبل استيفاء سياسة التأكيد التي اعتمدتها.
افصل استعادة الشاشة عن إثبات الدفع
توضح وثائق Android أن النظام قد ينهي عملية التطبيق في الخلفية. حفظ ما كان المستخدم يراه يحسن العودة، لكنه لا يكفي ليقرر التطبيق أن دفعة تمت. اطلب عرضًا يغلق التطبيق ثم يستعيد الطلب من مرجعه، لا عرضًا يظل مفتوحًا طوال التجربة.
وتوصي إرشادات Stripe بإسناد تنفيذ الطلب بعد الدفع إلى متابعة الخادم، لأن العميل قد يغادر قبل اكتمال الخطوات. استخدم هذا المبدأ عند مناقشة التصميم، دون اعتباره إثباتًا لتوافر المزود لنشاطك أو بلدك. أهلية الحساب ووسائل الدفع وشروطها تحتاج تحققًا منفصلًا قبل التعاقد.
ماذا يفعل الموظف عندما لا تتفق الشاشات؟
في المثال، قد يتصل العميل بينما تظهر محاولة قيد المعالجة. اطلب شاشة دعم محدودة الصلاحية تعرض مرجع الطلب والحالة المعروفة وآخر تحقق والخطوة المسموحة، دون كشف بيانات دفع حساسة. لا تجعل الحل التشغيلي الوحيد طلب صورة من كشف حساب العميل.
حدد أيضًا من يملك تغيير الموعد أو تعليق الزيارة حتى تتضح النتيجة، وكيف يسجل السبب. وإذا ظهرت واقعة مالية لاحقة مثل استرداد أو نزاع، فلابد من سياسة متابعة مستقلة؛ نجاح محاولة الدفع ليس ضمانًا بأن الوضع المالي لن يتغير مستقبلًا.
ناقش احتمال انتهاء حجز الموعد المؤقت قبل وصول التأكيد. من يقترح البديل، وماذا يظهر للعميل إذا صار الموعد غير متاح؟ افصل معالجة سعة الفريق عن الحكم المالي، وسجل القرار حتى لا يتحول التأخير إلى وعد بخدمة لا يمكن تقديمها.
حوّل الاختبارات إلى بند قابل للتسليم
اطلب بيانات اختبار مناسبة بلا تحصيل حقيقي، ونتيجة متوقعة لكل حالة، وأثرًا يربط الواجهة بالخادم. أضف أجهزة وإصدارات متفقًا عليها ومسؤول إصلاح الاختلاف. لا يكفي تسجيل فيديو نجاح إذا تعذر بعده العثور على الطلب أو تفسير ما حدث.
يعرض دليل قبول إعادة المحاولة التفاصيل المشتركة لعدم اليقين والتكرار، بينما يضع دليل عرض تطبيق الهاتف حدود التطبيق والإدارة والخادم. أرفق البطاقة عند طلب تطوير تطبيق موبايل من نكست ويف لتقارن سلوك العودة والاستثناءات ضمن العرض.
المصادر وحدود المثال
فُتحت إرشادات Stripe حول قبول الدفع في Android ومتابعة الحالة، ووثائق Android عن حفظ حالة الواجهة في 4 نوفمبر 2026. البطاقة والمثال اقتراح تحريري بلا اختبار دفع فعلي، مع إعداد بمساعدة الذكاء الاصطناعي ومراجعة المعلومات والترجمة.