العميل يتصل أو يرسل صورة: «انسحب المبلغ من بطاقتي، والطلب عندكم مكتوب قيد الانتظار». تفتح لوحة Moyasar أو Tap وتلقى العملية مدفوعة فعلًا، لكن منتجك ما يعرف. هذي من أكثر مشاكل الدفع اللي نشوفها، وسببها غالبًا واحد: المنتج يعتمد على رجوع العميل للموقع عشان يعرف إنه دفع.
كيف يمشي الدفع فعلًا
- منتجك ينشئ عملية دفع ويرسل العميل لصفحة البوابة أو نموذجها.
- العميل يدخل بطاقته، وغالبًا يمر بخطوة تحقق من البنك (رمز OTP لمدى والبطاقات)، وأحيانًا يفتح تطبيق البنك.
- البوابة ترجّع العميل لرابط في موقعك (callback أو redirect)، ومعه رقم العملية.
- وبشكل منفصل، البوابة تقدر ترسل إشعار مباشر من سيرفرها لسيرفرك (webhook) إن العملية نجحت.
الخطوة 3 تمر عن طريق متصفح العميل. والخطوة 4 من سيرفر لسيرفر، ما لها علاقة بالعميل ولا بمتصفحه.
ليش يظل الطلب معلّق
- المنتج ينتظر الخطوة 3 فقط. العميل سكّر الصفحة بعد ما دفع، أو انقطع النت، أو الجوال انتقل لتطبيق البنك وما رجع لنفس المتصفح. المبلغ انسحب، والرجوع ما صار، فالطلب يبقى معلّق.
- الـ webhook ما انضبط، أو انضبط للتجربة فقط. في Moyasar ينسجّل في اللوحة، وفي Tap ينرسل مع كل عملية في
post.url. يشتغل وأنت تجرّب، وفي الوضع الحقيقي ما يوصل شي. - الـ webhook يوصل وسيرفرك يرفضه. الرابط يطلب تسجيل دخول، أو يرجّع خطأ، أو الكود ما يلقى الطلب لأنه ما ربط عملية الدفع برقم الطلب من البداية.
- المبلغ ما يطابق. الكود يقارن المبلغ المدفوع بسعر الطلب ويغلط في الهللات، فيرفض عملية صحيحة. شوف فقرة الهللات في قبل لا تفعّل الدفع في منتجك.
- حالة ما يعرفها الكود. الكود يتوقع حالة «مدفوع» فقط، والعملية رجعت بحالة ثانية، مثل حجز المبلغ بدون سحبه (authorized)، فما يسوي شي.
كيف تتأكد بنفسك
- خذ رقم العملية من لوحة البوابة، ودوّر على الطلب في منتجك: هل الرقم مسجّل عنده أصلًا؟
- في Moyasar، تأكد من إعدادات Webhooks في اللوحة إن فيه رابط مسجّل للوضع الحقيقي (Live) ويأشّر على دومينك الحقيقي. وفي Tap، الرابط ينرسل مع كل عملية دفع في
post.url، فتأكد إن الكود يرسله وإنه دومينك الحقيقي، موlocalhostولا رابط التجربة. - إذا اللوحة تعرض سجل الإشعارات المرسلة، شوف إيش رد سيرفرك عليها.
- جرّب عملية حقيقية بمبلغ صغير، وسكّر الصفحة أول ما تنجح، قبل ما ترجع للموقع. إذا الطلب ظل معلّق، هذا هو السبب.
الحل الصح
- السيرفر هو اللي يقرر إن الطلب مدفوع، مو صفحة الرجوع. لما يوصل رقم العملية، سواء من رجوع العميل أو من الـ webhook، السيرفر يسأل البوابة عن العملية نفسها بالمفتاح السري، ويتأكد من ثلاثة: الحالة مدفوعة، والمبلغ والعملة يطابقون الطلب، والعملية تخص هذا الطلب بالذات.
- الطريقين مع بعض. رجوع العميل يعطيه صفحة نجاح سريعة، والـ webhook يضمن إن الطلب يتسجّل حتى لو العميل ما رجع.
- التسجيل مرة وحدة. نفس العملية ممكن توصل من الطريقين، أو يوصل الإشعار أكثر من مرة. أول مرة تتسجّل، والباقي يتجاهل.
- فحص دوري للمعلّق. مهمة تشتغل كل كم دقيقة، تاخذ الطلبات المعلّقة من فترة وتسأل البوابة عن حالتها. شبكة أمان لو فات شي.
لو العميل دفع مرتين
لما الطلب يبقى معلّق، العميل الطبيعي يرجع ويدفع مرة ثانية. فتلقى عندك عمليتين ناجحتين لطلب واحد. أول ما تكتشف هذا: رجّع المبلغ المكرر من لوحة البوابة، وأرسل للعميل إيميل يوضّح إيش صار ومتى يوصله المبلغ. وبعد الإصلاح، الكود يمنع إنشاء دفع جديد لطلب انسجّل مدفوع، ويقول للعميل إن طلبه مدفوع بدل ما يعرض له زر الدفع مرة ثانية.
الحل اللي لا تسويه
- تقرأ الحالة من الرابط. رابط الرجوع ممكن يحمل كلمة مثل
status=paid، وأي أحد يقدر يكتبها بيده في المتصفح. الحالة تنقرأ من البوابة، مو من الرابط. - تعدّل الطلبات المعلّقة يدويًا كل يوم. تمشي اليوم، لكن مع زيادة الطلبات بتغلط، وبتأكّد طلب ما انسحب مبلغه، أو تنسى طلب انسحب.
تبي الدفع يمشي بدون متابعة يدوية؟
مسار الدفع مكان ما يتحمل التجربة على العملاء. الإصلاح المباشر يصلّح المسار كامل على نسخة منفصلة من منتجك ويختبره مع البوابة قبل ما يوصل لعملائك. وإذا تبي تفهم وين المشكلة أول، ابدأ بـ مكالمة استشارية.