Beyond the Buy Button: ما يتطلبه تشغيل منظومة المدفوعات الرقمية وPPOB

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

قضيتُ مسيرتي في الجانب الآخر من تلك الشاشة. بدأتُ في خدمة العملاء في Metro Reload عام 2019، ثم انتقلتُ إلى تطوير الأعمال، ثم إلى المنتج، حيث أقود اليوم المنتج في Metro Reload وCashplus. وما تعلمته أن زر الشراء هو أقل أجزاء المنتج إثارة للاهتمام. فكل ما يقرر ما إذا كانت التجربة موثوقة يحدث حيث لا يراه المستخدم.

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

يمر منتج PPOB عادةً عبر عدة أيدٍ قبل أن يصل إلى من يدفع ثمنه. يبدأ من المزوّد الذي يملك المنتج، كمشغّل اتصالات أو مرفق أو جهة إصدار. ثم يمر بشركات الربط والتجميع (التي أسميها المستوى 1)، فموزّع من المستوى الثاني (Lv.2)، فموزّعين من المستوى الثالث فما بعده (Lv.3+)، فالتجار، قبل أن يصل إلى المستخدم النهائي.

تقع Metro Reload وCashplus في نقطتين مختلفتين من هذه السلسلة. تعمل Metro Reload موزّعاً بين الشركات (B2B) في المستوى الثاني (Lv.2): عملاؤها شركات لا مستهلكون. وتعمل Cashplus في المستوى الثالث فما بعده (Lv.3+)، فتخدم المستهلكين مباشرة (B2C) كما تخدم شركات تخدم المستهلكين بدورها (B2B2C). وهي تشتري من Metro Reload ومن موردين آخرين، مما يُبقي توافر المنتجات وأسعارها تنافسية، ويمنحها مخرجاً حين تتعثر جهة واحدة.

ولا تُنفَّذ كل العمليات الموصوفة أدناه بالطريقة نفسها تماماً في الشركتين. ومعظمها هو الطريقة التي يعمل بها هذا القطاع عموماً، مصفّاة عبر ما رأيته.

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

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

والمنتج الذي يسيء الغرباء فهمه أكثر من غيره، بحسب خبرتي، هو الشحن. فالناس يميلون إلى معاملة شحن المحافظ الرقمية وشحن النقود الإلكترونية على أنهما شيء واحد. المحفظة الرقمية مثل GoPay رصيد حساب لدى مزوّد. أما بطاقات النقود الإلكترونية مثل Mandiri e-Money وBNI TapCash وBRI BRIZZI وBCA Flazz فهي منتجات قيمة مخزّنة، وقد تتضمن بحسب الجهة المصدرة خطوات إضافية مثل تحديث الرصيد على البطاقة نفسها. وهي متشابهة في نظر المستخدم. لكنها ليست متشابهة لمن يبني المسار أو التكامل أو إجراءات الدعم أو معالجة الأخطاء.

لا يوجد مسار معاملة واحد شامل، بل عدة مسارات، ومعاملتها كمسار واحد هي الطريقة التي تتراكم بها المشكلات على المنصات.

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

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

ولتوضيح الاقتصاديات، إليك مثالاً افتراضياً. وهو للتوضيح فقط وليس تسعيراً حقيقياً لأي شركة. تخيّل منتج رصيد مدفوع مسبقاً بقيمة اسمية 10,000 روبية، يُشترى بـ 9,700 ويُباع بـ 9,850. الفارق الإجمالي 150 روبية. وهذا ليس ربحاً. فتكاليف المعاملات والعمليات والدعم والمعاملات الفاشلة وكل ما يتحمله العمل من تكاليف أخرى تُخصم منه. وحين تكون الهوامش بهذا الضيق لا تستطيع المنصة أن تفوز بالسعر وحده. فالمورّد الأرخص قليلاً الذي يفشل أكثر ليس أرخص في الحقيقة. وكل معاملة فاشلة أو متأخرة تعني عملية بيع ضائعة وحالة دعم وعميلاً قد لا يعود، وقد تتجاوز هذه التكاليف سريعاً خصماً صغيراً. ولذلك فالسؤال ليس أبداً «من يقدّم أقل سعر؟» وحده، بل «من يقدّم لي أقل سعر بنسبة نجاح أستطيع الاعتماد عليها؟». والموازنة بين الاثنين قرار منتج بقدر ما هو قرار تجاري.

من أقل أجزاء النظام ظهوراً التمويل. فكثير من منظومة PPOB يعمل بودائع مدفوعة مسبقاً، أي أرصدة ممولة مسبقاً. وفي السلسلة التي أعرفها، يحتفظ الموزّعون بوديعة لدى Metro Reload، وتحتفظ Metro Reload بودائع لدى مورّديها في المنبع، وتحتفظ Cashplus بترتيبات تمويل مسبق مع مورّديها بموجب اتفاقياتهم التجارية. وفي كل مرة تُعالَج معاملة يُخصم الرصيد المعني. وتتوقف ترتيبات التسوية والمطابقة الدقيقة على العلاقة والتكامل.

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

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

وخلف تلك الخطوات اعتبارات عملية يجب أن يهتم بها أهل المنتج: كيف يُدار مرجع المعاملة، ومتى يُخصم الرصيد، وكيف تُعالَج الاستجابات (callbacks) وتحديثات الحالة، وكيف تُسوّى المعاملة بعد ذلك كله. وحين تتصل المنصة بأكثر من مورّد، يوجد كذلك توجيه المزوّدين (provider routing)، وهو آلية توجيه المعاملة إلى مورّد مناسب. وقد يعكس الاختيار السعر والموثوقية والتوافر والعلاقة التجارية، والهدف الموازنة بين الموثوقية والتوافر والأداء التجاري. والقواعد المحددة وراء هذه القرارات داخلية، ولن أصفها هنا.

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

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

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

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

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

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

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

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

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

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