شرح الدفع بالطلب: دفع STK بالطريقة الصحيحة

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

إليك ما يحدث فعلاً خلف النافذة، وما يلزم لجعلها فورية وآمنة ويستحيل معها الخصم مرتين.

طريقتان لوصول الطلب

هناك آليتان خلف عبارة "تظهر نافذة"، وهما مهمتان لأن لكل منهما مدى مختلفاً وأنماط فشل مختلفة.

الآلية الكلاسيكية هي أدوات تطبيقات شريحة SIM (STK): شيفرة تعمل على شريحة SIM نفسها، ولهذا تستطيع إظهار نافذة آمنة لإدخال الرمز السري على هاتف بسيط دون أي تطبيق مثبّت. بهذه الآلية وصلت أنظمة الأموال عبر الهاتف المحمول الأولى إلى الجميع: القائمة وإدخال الرمز السري يُداران من الشريحة، عبر الشبكة، على جهاز لا يحمل شيئاً آخر. أما الآلية الحديثة فهي إشعار التطبيق: إشعار يصل إلى تطبيق على الهاتف الذكي فيفتح شاشة تأكيد. وتنتهي الاثنتان عند النقطة نفسها: يأذن العميل، وتمضي عملية الخصم في دورة حياتها. والمنصة الجديرة بالبناء تدعم الاثنتين، لأن قاعدة العملاء تشمل الاثنتين.

عملية الخصم آلة حالات

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

• معلّقة: طلب التاجر الخصم؛ وأُرسلت النافذة؛ والنظام ينتظر العميل.
• مأذونة: أدخل العميل رمزه السري وأكّد؛ وتحقق النظام من الرصيد والحدود وهو يقيّد الحركة.
• مكتملة: قيّد دفتر الأستاذ قيوداً متوازنة؛ وتحرك المال؛ ويستطيع التاجر التسليم.
• مرفوضة / منتهية / فاشلة: رفض العميل، أو انتهت مهلة النافذة، أو فشل أحد الفحوص؛ لم يتحرك أي مال، وأُغلقت عملية الخصم بنظافة.

كل عملية خصم تكون في حالة واحدة بالضبط من هذه الحالات في أي لحظة، ولا تنتقل إلا عبر انتقالات محددة. هذه ليست بيروقراطية، بل هي ما يجعل المسار قابلاً للفهم والاستعادة. حين يحدث خطأ، يكون السؤال دائماً: "في أي حالة هذه العملية، وأي انتقال توقف؟"، وهو سؤال له جواب، بدلاً من هزّ الكتفين.

كيف يعرف التاجر النتيجة

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

1. الاستعلام المتكرر (polling). يسأل التاجر نقطة الحالة مراراً: "هل انتهى؟". ينجح ذلك، لكنه مُهدِر وبطيء: إن استعلمت كثيراً أثقلت الواجهة البرمجية، وإن استعلمت قليلاً بقي العميل واقفاً عند الصندوق ينتظر.
2. الإشعارات الراجعة (Webhooks). ترسل المنصة إلى التاجر استدعاءً راجعاً موقّعاً لحظة تغيّر حالة الخصم. يعرف التاجر خلال لحظات، دون استدعاءات مهدرة، ويحصل على حدث واضح يتصرف بناءً عليه. هذه هي اللبنة الصحيحة، والمنصة المبنية جيداً تجعلها الخيار الافتراضي مع الاستعلام كبديل احتياطي.

ما الذي يجعله جديراً بالثقة

ثلاث خصائص تحوّل عرضاً يعمل إلى نظام يستطيع التاجر بناء عمله عليه.

عدم التكرار: قاتل الخصم المزدوج

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

إشعارات راجعة موقّعة

الإشعار الراجع استدعاء HTTP غير مطلوب يصل إلى خادم التاجر مدّعياً أن دفعة قد اكتملت. لماذا يصدّقه؟ لأن كل استدعاء راجع موقّع: توقيع HMAC-SHA256 يُحسب على المحتوى بسرّ مشترك لا تعرفه إلا المنصة والتاجر. يعيد التاجر حساب التوقيع ويرفض كل ما لا يطابق، مما يجعل الاستدعاءات المزيفة "تم الدفع لك" عديمة الفائدة للمهاجم. ولأن الشبكات تتعطل، يُعاد إرسال الإشعارات الراجعة بفواصل متزايدة حتى يُقرّ باستلامها، فلا يضيع الحدث بسبب انقطاع لحظي لدى التاجر، بل يُعاد تسليمه حتى يرد خادمه بالنجاح.

انتهاء الصلاحية

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

الحالات الحدّية التي تفصل الأنظمة الحقيقية عن العروض

المسار السعيد (إرسال، تأكيد، اكتمال) هو الربع السهل من العمل. أما الإخفاقات المثيرة فتعيش في الفجوات:

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

تسلسل زمني تطبيقي

إليك ما يحدث، ثانية بثانية، حين يخصم تاجر 1,250 من عميل مقابل مشتريات بقالة. التوقيتات نموذجية لا مضمونة.

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

بناء جانب التاجر بشكل صحيح

نصف التكامل الموثوق للدفع بالطلب يعيش في نظام التاجر. معالج الإشعارات الراجعة الجيد:

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

اختيار نافذة انتهاء الصلاحية

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

تفاصيل يلاحظها العملاء

اختيارات صغيرة في شاشة النافذة تحدد ما إذا كان العملاء يثقون بها:

• أظهر الاسم المسجل للتاجر، لا رمزاً داخلياً، حتى يعرف العميل من يطلب.
• أظهر المبلغ والمرجع بوضوح قبل حقل الرمز السري.
• قدّم خيار رفض واضحاً، حتى يستطيع العميل الذي لم يتوقع النافذة رفضها بدلاً من تجاهلها.
• أكّد بالكلمات وبرسالة: إيصال يتضمن التاجر والمبلغ والمرجع، على الشاشة وبرسالة قصيرة.
• حذّر من النوافذ غير المتوقعة. يرسل المحتالون نوافذ أملاً في أن يوافق العميل بشكل لا إرادي؛ وسطر قصير مثل "وافق فقط إذا كنت تدفع لهذا التاجر" يقلل هذا الخطر.

دورة حياة واحدة لكل القنوات

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

الدفع بالطلب أم رمز QR أم رقم الصندوق؟

الدفع بالطلب واحد من ثلاث طرق شائعة للتحصيل من العميل. وكل منها يناسب موقفاً مختلفاً:

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

الاحتيال حول النوافذ

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

قياس الدفع بالطلب

أبعد من المنضدة: الطلبات عن بُعد

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

اختبار تكامل الدفع بالطلب

قبل أن يبدأ التاجر التشغيل الفعلي، نفّذ هذه الحالات في بيئة الاختبار:

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

التكامل الذي يجتاز هذه الاختبارات سيتصرف جيداً في أكثر أيامه ازدحاماً.

الأسئلة الشائعة

ماذا لو لم يكن لدى العميل اتصال بيانات؟

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

هل يستطيع التاجر الخصم من العميل دون موافقته؟

لا. لا يكتمل الخصم إلا حين يأذن به العميل برمزه السري. التاجر يستطيع أن يطلب؛ والعميل وحده يستطيع أن يوافق.

كيف تُعالَج المبالغ المستردة؟

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

ماذا يفعل أمين الصندوق إذا قال العميل إنه وافق لكن الصندوق لا يُظهر شيئاً؟

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

هل الدفع بالطلب آمن للمبالغ الكبيرة؟

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

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