طبقة دفع واحدة، بوابات متعددة: WeChat Pay وAlipay في نقطة بيع Odoo
إذا كنت تدير تجارة تجزئة في الصين، فسؤال الدفع ليس سؤالًا حقًا. يدفع العملاء عبر WeChat Pay وAlipay، عند الكاونتر، بالتطبيق. الجزء المثير للاهتمام هو ما يقف خلف تلك اللمسة، وما إذا كانت طريقة ربطها بـ Odoo ستظل قائمة بعد متجرك الثالث، ومزوّد الدفع الثاني، وترقية Odoo التالية.
معظم المحاولات الأولى لا تصمد إلى ذلك الحد. إليك السبب، وكيف تبدو فعليًا نسخة تدوم.
الحل الفردي الذي لا يتوسع
المحاولة الأولى الشائعة هي سير عمل بأدوات منخفضة الكود يوقّع الطلب ويستدعي البوابة. يعمل جيدًا في العرض التوضيحي. كما يميل إلى التآكل لأسباب لا علاقة لها بالدفعات وكل العلاقة بانضباط الهندسة. ينتهي سر توقيع التاجر بالإقامة داخل سير العمل مباشرة. يُحدّث بيئة التشغيل نفسها دون أي تثبيت، بحيث يمكن لتغيير لم تجرِه أن يكسر الإنتاج. تُعالَج اللحظة المحرجة التي لا يزال فيها العميل يكتب رمز PIN بمجموعة متشابكة من خطوات فرعية دون سجل دائم لما حدث. يصعب التعبير عن إعادة المحاولة والتسوية بشكل موثوق. وكل عميل جديد يعني إعادة بناء سير العمل بالكامل يدويًا، دون أي اختبارات وحدة ودون أي حالة يمكن حملها للأمام.
لا شيء من ذلك مشكلة دفعات. إنها مشكلة "بنينا منتجًا من نموذج أولي"، وهي بالضبط الفخ الذي سعت Majorbird إلى إزالته.
عقد واحد، بوابات متعددة
مبدأ التصميم بسيط: يجب أن تتحدث نقطة بيع Odoo لغة محايدة واحدة، مهما كان المزوّد على الطرف الآخر. لذا يتحدث جانب نقطة البيع مع عقد HTTP واحد بمفردات صغيرة وثابتة: دفع (مرجع الطلب، المبلغ، الرمز الممسوح، البوابة المستهدفة)، استعلام أو استقصاء، استرداد، إلغاء، بالإضافة إلى وكيل خام كمخرج طوارئ للحالة غير المعتادة.
تُوحَّد حالة الدفع في مجموعة واحدة من الحالات تُطابقها كل بوابة: أُنشئ، قيد الدفع، مدفوع أو فاشل أو ملغى، ثم قيد الاسترداد، مسترد أو مسترد جزئيًا. التفاصيل الفوضوية الخاصة بكل مزوّد، خوارزمية التوقيع، أسماء الحقول، كيفية تنسيق المبالغ، أي نقطة نهاية يجب استدعاؤها، تُعزَل داخل وحدة خاصة بكل بوابة وتُبقى خلف سجل.
هذا ما يجعل "إضافة واحدة، بوابات متعددة" أمرًا حقيقيًا لا مجرد شعار. تُخزّن طريقة الدفع في Odoo نقطة نهاية فقط وأي بوابة تُستخدم. إضافة مزوّد جديد تعني وحدة جديدة واحدة وسطرًا واحدًا في السجل. إضافة نقطة البيع نفسها لا تتغير. لا إعادة عمل للوحدات، ولا نسخ متفرعة، ولا بناء خاص لكل عميل.
لماذا تُعد مدفوعات نقاط البيع الصينية مشكلة قائمة بذاتها
من الصادق القول إن هذا أصعب فعليًا من ربط بوابة بطاقة غربية، ولأسباب تفاجئ الناس.
التدفق معكوس. فبدلًا من أن يمسح العميل رمز QR الخاص بالتاجر، يمسح أمين الصندوق الرمز الظاهر في تطبيق العميل. هذا هو تدفق الباركود الذي يعرضه العميل، أو الدفع المصغّر (micropay).
الإجابة غالبًا ليست فورية. قد تُسوّى عملية الدفع فورًا، أو قد تنتظر بينما يكتب العميل رمز PIN، مُبلَّغة بحالة من نوع "المستخدم يدفع". لا يوجد نعم أو لا متزامن. عليك الاستقصاء حتى تُحل. بالقدر نفسه من الأهمية، الردود الغامضة مثل "النظام مشغول" أو "المستخدم لا يزال يدفع" يجب ألا تُعامَل أبدًا كفشل، لأن إعادة محاولة عملية دفع نجحت بالفعل هي الطريقة التي يُخصم بها من العميل مرتين. يجب عكس أي دفعة تظل عالقة في "قيد الدفع" بعد انتهاء مهلة زمنية تلقائيًا حتى لا تبقى الأموال معلّقة أبدًا.
تحتاج التسوية إلى دفتر أستاذ خاص بك. تجيب البوابات عن معاملة واحدة في كل مرة؛ لا يوجد "قائمة مبيعات اليوم" يمكن الاعتماد عليها، لذا يحتفظ النظام بسجله الدائم الخاص ويُسوّي مقابله. وخلف العقد الواحد، يمثّل المزوّدان عالمين مختلفين: يستخدم WeChat Pay v2 صيغة XML مع توقيع MD5 وشهادة TLS للعميل من أجل عمليات الاسترداد، بينما يستخدم Alipay صيغة JSON مع RSA2. كل هدف العقد المحايد هو ألا يحتاج أمين الصندوق، ولا نقطة بيع Odoo، إلى معرفة أي من ذلك أبدًا.
من حل مؤقت إلى خدمة
تحويل ذلك إلى شيء يمكن تشغيله لتجار كثيرين هو في معظمه انضباط برمجي عادي مطبّق بشكل صحيح. تعمل البوابة كخدمة واحدة ذات إصدار محدد بعلامات صور ثابتة، بحيث يكون ما اختبرته هو ما يُنشر فعليًا. الإعداد يتفوق على الكود: تأتي بيانات الاعتماد والبوابات من البيئة، لا شيء حساس مُرمَّز يدويًا، وتُسحَب الأسرار من خزنة عند بدء التشغيل بدلًا من تضمينها في الحزمة. منطق التوقيع مُختبَر بوحدات اختبار. هناك دفتر أستاذ دائم، وشبكة أمان للتسوية في الخلفية لحالة الدفعة العالقة، ولوحة تشغيل، ونسخ احتياطية تتحقق من نفسها ذاتيًا. يصبح إدخال عميل جديد قائمة تحقق، لا إعادة بناء.
ماذا يعني هذا عند الكاونتر
بالنسبة لتاجر تجزئة، النتيجة هادئة، وهذا هو الهدف. تقبل WeChat Pay وAlipay مباشرة في نقطة بيع Odoo، مع تأكيد واسترداد فوريين، وتُسوّى المدفوعات في Odoo تلقائيًا بدلًا من أن يُطابق أحدهم إجماليات تطبيق الدفع مع المبيعات يدويًا في نهاية اليوم. إضافة مزوّد جديد لا تعني إعادة بناء مخصصة. أصبح الطرح متعدد المتاجر ومتعدد العملاء أسرع، والصيانة أقل، وسجل المدفوعات قابل للتدقيق من البداية إلى النهاية.
اليوم تستهدف إضافة نقطة البيع نظام Odoo 18 Enterprise POS، بينما خدمة البوابة نفسها مستقلة عن إصدار Odoo. من المخطط نقلها إلى Odoo 19.
رأينا
مسارات الدفع الصينية ليست الجزء الصعب؛ يستطيع أي شخص تقريبًا إنجاح عملية دفع واحدة مرة واحدة. الجزء الصعب هو فعل ذلك بالطريقة نفسها لكل متجر، وكل مزوّد، وكل ترقية، دون إعادة بناء في كل مرة ودون خصم مزدوج ينتظر أن يحدث. هذا هو الفرق بين تكامل يعمل في عرض توضيحي وآخر يعمل في الإنتاج، وهو نفس انضباط التشخيص قبل البناء الذي تجلبه Majorbird إلى بقية تنفيذ Odoo.
إذا كنت تُقيّم كيفية قبول WeChat Pay وAlipay في نقطة بيع Odoo لديك، أو كنت بالفعل ترعى تكاملًا فرديًا بدأ يكلفك، فهذا حديث جيد يستحق أن يُجرى قبل أن ينهار في أسوأ لحظة ممكنة. تحدث في الأمر مع فريق Majorbird عبر odoo@majorbird.com أو www.majorbird.com.