رحلة الدفع خطوة بخطوة: عبدالله عبدالرحيم سنكر يشرح ربط مدى و Apple Pay

تبي متجرك أو تطبيقك يستقبل مدى و Apple Pay، والمطوّر يقول «نربط بوابة دفع ويخلص». بعد الإطلاق تبدأ الأسئلة: عميل انخصم منه وما وصله تأكيد، وطلب انحسب مرتين، واسترداد ما يدري أحد وين وصل. عبدالله عبدالرحيم سنكر يشرح هنا وش يصير فعلاً من لحظة ضغط «ادفع» إلى لحظة وصول الفلوس لحسابك، عشان تعرف وش تطلب من المطوّر ووش تسأله. وبدون ترشيح لبوابة معيّنة، لأن الاختيار يعتمد على نشاطك وعقدك.

اللاعبون قبل الخطوات

مدى هي الشبكة الوطنية لبطاقات الخصم في السعودية، وشريحة كبيرة من الناس هنا يدفعون ببطاقة مدى مربوطة بحساباتهم البنكية مباشرة. و Apple Pay محفظة أكثر منه وسيلة دفع مستقلة: البطاقة نفسها، مدى أو ائتمانية، محفوظة في الجوال، والدفع يتم برمز مشفّر بدل رقم البطاقة الحقيقي. وبوابة الدفع هي الوسيط اللي يستقبل هذا كله من موقعك أو تطبيقك ويكلّم الشبكات والبنوك. وأنت كصاحب متجر تحتاج حساب تاجر عند البوابة، وغالباً يُطلب سجل تجاري ووثائق للتحقق، فابدأ فيه بدري لأن الموافقة تاخذ وقتاً.

الرحلة من الضغطة إلى الحساب البنكي

• الخادم ينشئ الطلب أولاً: المبلغ يُحسب في خادمك من الأسعار المخزنة عنده، مو من التطبيق. لو التطبيق هو اللي يرسل المبلغ، أي أحد يقدر يعدّله ويدفع ريالاً على منتج بألف.
• بيانات البطاقة تنجمع عند البوابة، مو عندك: عبر صفحة الدفع المستضافة أو حقول ومكتبات البوابة المضمّنة. رقم البطاقة ما يمر على خادمك أبداً، وهذا يريحك من أغلب متطلبات معيار PCI DSS الثقيلة.
• التحقق الإضافي 3-D Secure: البنك يطلب من العميل رمزاً يوصله أو تأكيداً من تطبيق البنك. هنا تفشل عمليات كثيرة لأن الشاشة ما ظهرت صح داخل التطبيق، فاختبرها على الجوال بالذات.
• التفويض ثم التحصيل: البنك يحجز المبلغ أولاً، ثم يتحصّل. أغلب المتاجر تسوي الاثنين مرة وحدة، لكن أنشطة مثل الحجوزات ممكن تحجز الآن وتحصّل لاحقاً.
• التأكيد من خادم لخادم: البوابة ترسل لخادمك إشعاراً (webhook) بنتيجة العملية. هذا هو مصدر الحقيقة، مو صفحة «تم الدفع» اللي شافها العميل.
• التسوية: الفلوس ما توصل حسابك البنكي لحظياً، تتجمع وتتحوّل على دورات يحددها عقدك مع البوابة.

Apple Pay له متطلبات خاصة

تفعيل Apple Pay مو مجرد زر. تحتاج معرّف تاجر (Merchant ID) في حساب Apple Developer، وشهادة معالجة دفع تُنشأ بالتنسيق مع البوابة عشان تقدر تفك الرمز المشفّر. وعلى الويب لازم توثّق نطاق موقعك عند آبل بملف تضعه في مسار محدد على النطاق، وإلا ما يظهر الزر أصلاً. والزر نفسه له إرشادات شكل من آبل، فلا تصمم زراً من عندك بشعار مقلّد. ويظهر الزر بس للي أجهزتهم ومتصفحاتهم تدعمه، فخلّ خيار البطاقة العادي دائماً موجوداً جنبه لمستخدمي أندرويد والكمبيوتر.

وفيه حد فاصل داخل التطبيقات لازم تعرفه من البداية: Apple Pay وبوابات الدفع للسلع والخدمات الحقيقية، مثل منتج يُشحن أو خدمة تُقدَّم خارج التطبيق. أما المحتوى الرقمي اللي يُستهلك داخل التطبيق، مثل اشتراك يفتح ميزات أو عملة افتراضية، فغالباً تفرض آبل وجوجل أنظمة الشراء داخل التطبيق الخاصة بهم. والخلط بين الحالتين سبب معروف لرفض التطبيقات.

أخطاء تكلّف فلوساً حقيقية

• الاعتماد على صفحة العودة: العميل دفع، وانقطعت الشبكة قبل ما يرجع لتطبيقك. لو كنت تعتمد على العودة، يبقى الطلب «غير مدفوع» والفلوس انخصمت. الـ webhook يحل هذا.
• عدم التحقق من توقيع الـ webhook: أي أحد يعرف الرابط يقدر يرسل «تم الدفع» مزيّفاً. تحقّق من التوقيع، وطابق المبلغ والعملة ورقم الطلب مع اللي عندك.
• معالجة نفس الإشعار مرتين: البوابات تعيد إرسال الـ webhook لو ما رديت بسرعة. لو كل إشعار ينشئ شحنة، بيوصل للعميل طردان. سجّل معرّف العملية وتجاهل المكرر.
• زر «ادفع» يقبل ضغطتين: عطّله بعد أول ضغطة، واستخدم مفتاح منع التكرار مع البوابة لو تدعمه.
• تخزين ما لا يجوز تخزينه: رمز التحقق CVV خلف البطاقة ما يُخزَّن أبداً، ورقم البطاقة كامل ما مكانه قاعدة بياناتك. ولو تبي الدفع المتكرر، استخدم رموز حفظ البطاقة اللي توفرها البوابة.
• مبالغ بكسور عشرية: خزّن المبالغ بالهللة كأعداد صحيحة، وحوّلها للعرض فقط.
• رسالة رفض غامضة: «فشلت العملية» بس تخلّي العميل يجرّب نفس البطاقة خمس مرات. البوابة غالباً ترجع سبباً عاماً مثل رصيد غير كافٍ أو تحقق لم يكتمل، فاعرضه بلغة بسيطة، واقترح وسيلة ثانية.

بعد الدفع: الاسترداد والفاتورة والمطابقة

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

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

في منصة أزهل الرقمية يُعامَل الدفع كأخطر جزء في المشروع، لأنه المكان الوحيد اللي الخطأ فيه يعني فلوس ناس حقيقيين. وعبدالله عبدالرحيم بن سنكر الكندي ينصح إنه يُختبر بسيناريوهات الفشل قبل النجاح: بطاقة مرفوضة، وشبكة تنقطع في النص، وإشعار يوصل مرتين، واسترداد جزئي. لو مرّت كلها بسلام، تقدر تطلق وأنت مطمّن، لأن مسار النجاح عادةً يشتغل من أول تجربة، والمشاكل كلها تسكن في المسارات الثانية.