الموارد · 47
المدفوعات غير المؤكدة: استعادة عملية الدفع دون تكرار الطلبات
مطابقة تأخيرات الشبكة، وإرجاع المتصفح، والإشعارات، وحالة العمل بدلاً من اعتبار أي إشارة واحدة كافية.
مُحدَّث · 3 min
ما يُساعد هذا الدليل على تحقيقه
- فصل المحاولة والدفع والطلب
- معالجة عمليات الإرجاع المتأخرة أو المفقودة
- إزالة الإشعارات والطلبات المكررة
- شرح حالة عدم اليقين دون مطالبة المستخدمين بالدفع مرة أخرى
فحص سريع
- ما هو مصدر تأكيد الدفع؟
- هل يؤدي إغلاق المتصفح إلى تغيير حالة العمل؟
- هل يؤدي حدث متكرر إلى إعداد طلبين؟
- هل يتم التحقق من توقيعات الأحداث؟
- كيف يكتشف فريق الدعم عملية غير مؤكدة؟
طريقة خطوة بخطوة
- 1
تحديد الحالات
فصل سلة التسوق، ومحاولة الشراء، والتفويض، والدفع المؤكد، والطلب، والاسترداد. كتابة مسارات الانتقال، والمصدر الموثوق، والإجراءات المسموح بها. اتباع مزود الخدمة وطرق الدفع الفعلية؛ لا يتم تأكيد كل طريقة فورًا.
المُخرَج: مخطط الحالة وعقد العمل.
- 2
تحديد العملية.
ربط محاولة الشراء بالطلب ومعرّفات مزود الخدمة. استخدام قاعدة التكرار الموثقة لتكرار نفس العملية. يتطلب الغرض الجديد أو المعلمات المتغيرة قرارًا صريحًا بدلًا من إعادة استخدام المفتاح بشكل أعمى.
المُخرَج: قواعد هوية واسترداد مستقرة.
- 3
معالجة عودة المتصفح.
عرض الحالة من فحص جانب الخادم المناسب لمزود الخدمة. إعادة التوجيه إلى صفحة النجاح وحدها لا تُعد دليلًا على الدفع. تغطية حالات إغلاق المتصفح، وعدم وجود عودة، وانقطاع المصادقة، وبطء الشبكة.
المُخرَج: مسار العودة والرسائل حسب الحالة.
- 4
التحقق من الإشعارات
التحقق من صحة الإشعارات وفقًا لوثائق المزوّد، وتسجيل هوية الحدث، ومعالجة التكرارات دون حدوث آثار مكررة. قد تتأخر الأحداث أو تكون خارج الترتيب. عند الحاجة، استرجع الكائن المرجعي قبل حدوث انتقال غير قابل للعكس.
المُخرَج: معالج مُختَبَر وآثار بدون بيانات بنكية.
- 5
تسوية التناقضات
مقارنة عمليات المزوّد، والطلبات، والتنفيذ. عزل حالات الدفع بدون طلب، والطلب بدون تأكيد، والمعالجة المزدوجة، والمبالغ المستردة غير المُعمَّمة. تحديد مسؤول وإجراء لكل تناقض؛ وعدم تكرار الرسوم غير المؤكدة تلقائيًا.
المُخرَج: قائمة انتظار التسوية والقرارات.
- 6
اختبار الاسترداد الكامل
في وضع اختبار المزوّد، إعادة تشغيل المهلة، والتكرار، والحدث المتأخر، والطلب المعكوس، والمبلغ المسترد المفقود. التحقق من انتقال تجاري واحد، ومعلومات العميل الصحيحة، ودعم الرؤية. تختلف تفاصيل التكرار بين المزوّدين. المخرجات
المخرج: أدلة عدم الازدواجية ومعايير النشر.
مثال عملي افتراضي
حالة توضيحية
مثال توضيحي: تتم عملية الدفع بنجاح، لكن يفقد العميل الاتصال قبل التأكيد، ويصل إشعاران لاحقًا.
القرار والأدلة المتوقعة
تم تأكيد طلب واحد. يعرض قسم الاسترداد حالة "تم التحقق"، ويمكن للدعم مطابقة المرجع دون طلب تفاصيل البنك.
تمييز الآليات
| الآلية | الغرض | التحقق أو التقييد |
|---|---|---|
| عودة المتصفح | إعلام الواجهة واستئنافها | قد يكون مفقودًا أو متقطعًا |
| تم التحقق من رابط الويب | استلام تغيير حالة الموفر | قد يتكرر أو يتأخر أو يكون خارج الترتيب |
| مطابقة الخادم | مقارنة حالة الدفع وحالة الطلب | يحتاج إلى قاعدة لحل التناقضات |
مؤشرات الإدارة
| المؤشر | ما يقيسه | الإجراء الأول |
|---|---|---|
| حالات غير مؤكدة | عمليات لم تُحل خلال التأخير المقصود | التحقق من الحالة المرجعية |
| تأثيرات مكررة | تم تنفيذ الطلبات أو المعالجة مرتين | إصلاح إزالة التكرار في الأعمال |
| سد الثغرات | حالات مطابقة مع القرار والأدلة | معالجة أقدم الحالات وأكثرها أهمية |
الأخطاء الشائعة
- التأكيد من عنوان URL للنجاح فقط
- اعتبار انتهاء المهلة فشلًا في الدفع
- افتراض تصل الأحداث بالترتيب
- تكرار عملية الدفع قبل التحقق
الأسئلة المتكررة
هل يعني انتهاء المهلة فشل العملية؟
لا، هذا يعني عدم استلام الرد خلال فترة التأخير. تحقق من حالة العملية قبل إنشاء عملية أخرى.
هل خاصية التكرار لدى المزوّد كافية؟
لا، يجب أن تتحمل عمليات إنشاء الطلبات وتنفيذها والإشعارات المعالجة المتكررة دون حدوث آثار تجارية مكررة.
ما الذي يجب إبلاغ المستخدم به؟
اشرح أن عملية التحقق جارية، وقدّم مرجعًا آمنًا وطريقة لاستعادة الحالة. تجنّب طلب دفعة أخرى بينما الدفعة السابقة غير مؤكدة.
المراجع الرسمية
تدعم المراجع الطريقة. قم بتكييف عمليات التحقق مع سياقك؛ فهي ليست شهادة. قد تكون عناوين المراجع الأصلية والوثائق المصدرية بلغة أخرى.
