افصل عملية الدفع عن قرار التسليم
عملية الدفع تعالج اختيار العميل ونتيجة المعاملة. أما التسليم فهو قرار شركتك بشحن منتج أو تأكيد حجز أو إتاحة خدمة. وجود صفحة دفع احترافية لا يجعل رسالة في متصفح العميل أمرا موثوقا للتسليم. يجب أن تعرف من يملك كل خطوة وأين تحفظ نتيجة القرار.
توضح وثائق Gammal Tech دعم روابط الدفع المستضافة بالبطاقات وApple Pay. يمكن أن يساعد ذلك موقعا مناسبا على تجنب بناء نموذج خاص به لإدخال بيانات البطاقة. ولخطوات التنفيذ، راجع دليل إنشاء رابط دفع. لكنه لا يثبت وحده امتثال الشركة لمتطلبات معينة ولا يستبدل مراجعة رحلة الشراء كاملة.
رتب رحلة الشراء على مراحل واضحة
- عرّف الطلب: حدد المنتج والمبلغ والعملة وعلاقة الطلب بالعميل أو بالحجز في سجل موثوق مناسب للعمل.
- اعرض الرابط المقصود: احم الصفحة والحساب الذي يستطيع تغيير رابط الدفع.
- اعتبر العودة بداية للمراجعة: اعرض حالة انتظار مفهومة إلى أن تتأكد النتيجة.
- تحقق من المعاملة: استخدم وسيلة موثوقة يدعمها المزود وطابق النتيجة بالطلب.
- نفذ التسليم مرة واحدة: سجل القرار حتى لا يؤدي تحديث الصفحة أو تكرار الإشعار إلى تكراره.
- تابع الاستثناءات: حدد مسؤولا للمبالغ غير المتطابقة والنتائج المعلقة والاسترداد.
للتسليم الآلي، كلف المطور بتأكيد طريقة التحقق المدعومة للتكامل ثم تنفيذها واختبارها وفقا لتوثيق المزود. وفي الخدمة التي يديرها الموظفون يدويا، عين شخصا لمراجعة سجل التاجر المعتمد وتوثيق القرار قبل تأكيد الطلب. اختر المسار بوضوح حتى يحصل العملاء على إجراء ثابت ويمكن متابعته.
ما الدليل الذي تعتمد عليه قبل التسليم؟
| المعلومة | ما الذي تدل عليه؟ | التصرف |
|---|---|---|
| صورة أرسلها العميل | ادعاء يحتاج مراجعة | البحث عن المعاملة الفعلية |
| صفحة نجاح في المتصفح | وصول المتصفح إلى صفحة | التحقق من حالة الدفع الموثوقة |
| حقل paid يستطيع المستخدم تعديله | قيمة قد يؤثر فيها المستخدم | عدم استخدامها كمرجع للدفع |
| تأكيد موثوق مطابق للطلب | دليل على المعاملة | تطبيق قواعد التسليم ومنع التكرار |
تؤكد إرشادات OWASP لتكامل الدفع أهمية التحقق الموثوق ومطابقة تفاصيل الطلب. أما الآلية الدقيقة فتؤخذ من توثيق المزود الذي تستخدمه.
مثال توضيحي: حجز مكان في ورشة بالإسكندرية
شركة تقدم ورشة بعدد محدود من الأماكن. يفتح العميل رابط الدفع ثم يرسل صورة للمحادثة مع خدمة العملاء. قبل تأكيد الحجز، يبحث الموظف عن الطلب ويطابق المبلغ والعملة ومرجع المعاملة من المصدر المعتمد. مطابقة اسم ظاهر في صورة فقط لا تكفي لمعرفة أن المعاملة تخص هذا الطلب.
إذا فتح العميل صفحة العودة عدة مرات، يجب أن يبقى الحجز لمكان واحد. يحتاج النظام مرجعا ثابتا للطلب وحالة واضحة توضح أن التسليم تم. رمز جلسة تسجيل الدخول المتغير لا يصلح ليكون رقم الحجز الدائم أو المرجع الوحيد لمتابعته لاحقا.
وإذا ظلت النتيجة معلقة، اعرض رسالة صريحة وطريقة للتواصل. لا تجعل أول نصيحة للعميل أن يعيد الدفع فوراً. يحتاج فريق الدعم إجراء للتحقق من المحاولة السابقة قبل اقتراح محاولة جديدة، حتى لا تتحول مشكلة في عرض النتيجة إلى التباس مالي وخدمة عملاء صعبة.
احم الطريق الذي يصل بالعميل إلى الدفع
الصفحة التي تحتوي زر الدفع تظل هدفا مهما. من يستطيع تغيير الرابط قد يرسل العميل إلى مكان آخر، وقد يضيف رسالة مزيفة تطلب بيانات لم تكن تريد جمعها أصلا. راجع وجهة الروابط عند النشر وقلل عدد الحسابات التي تستطيع تغيير صفحة الشراء.
راجع أيضا الأدوات الخارجية التي تعمل في هذه الصفحة. تشرح OWASP مخاطر JavaScript الخارجي داخل صفحات الموقع. عمليا، يجب أن يعرف الفريق سبب وجود كل أداة تسويق أو محادثة في خطوة الدفع. تقليل الأدوات غير الضرورية يجعل فحص المسار أسهل ويقلل الأجزاء التي تحتاج متابعة.
أسئلة شائعة
هل صفحة الدفع المستضافة تؤمن موقعي بالكامل؟
لا. قد تقلل التعامل المباشر مع بيانات البطاقة، لكن الموقع وروابط الدفع وسجلات الطلبات وقرارات التسليم تحتاج حماية مناسبة.
هل أفتح الخدمة المدفوعة عند ظهور صفحة النجاح؟
اعتمد على تحقق موثوق مطابق للطلب. صفحة المتصفح أو حقل يستطيع المستخدم تعديله لا يكفيان كمرجع لصلاحية مدفوعة.