اكتمل مسار الشراء والدفع ما زال معلقا: متى يسمح التطبيق بتنفيذ الطلب؟

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

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

عرّف فترة الانتظار قبل تصميم الصفحة

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

يوضح دليل Stripe لتنفيذ الطلبات أن بعض الوسائل لا تكتمل فورا. ويوثق للوسائل المتأخرة حدث checkout.session.async_payment_succeeded عند النجاح اللاحق، ويوصي أيضا بمعالجة checkout.session.async_payment_failed. لذلك حدد حالة انتظار ثم مساري النجاح والفشل، لا المسار الناجح وحده.

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

قدم نتيجة مفيدة أثناء الانتظار

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

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

لا تعتمد على عودة المشتري

يحذر Stripe صراحة من إمكان نجاح الدفع ثم انقطاع الاتصال قبل تحميل صفحة العودة. لذلك يشترط الدليل الإشعارات الخادمية لتحقيق تنفيذ آلي موثوق بدلا من الاعتماد على تلك الصفحة وحدها.

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

دفعة واحدة لا تعني عمليتي تسليم

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

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

اختبر الانتقال حتى نهايته

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

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

حدود المصدر

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