الدفع الإلكتروني في المطاعم: كيف تختار بوابة وتربطها دون أن تخسر طلباً

2026-09-22 · 12 دقائق قراءة

الدفع الإلكتروني للمطاعم ليس زر دفع فقط — بل سلسلة من الرسوم والتسويات والاستردادات. إليك كيف تختار البوابة وتربطها دون أن تخسر طلباً واحداً.

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

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

لماذا لم يعد الدفع عند الاستلام كافياً

الدفع عند الاستلام يبدو مجانياً، وهو أبعد ما يكون عن ذلك. تكلفته الحقيقية موزّعة على بنود لا تظهر في أي فاتورة:

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

اختيار بوابة الدفع الإلكتروني للمطاعم

قرار الدفع الإلكتروني للمطاعم في السوق السعودي والخليجي يبدأ من سؤال واحد: ما وسائل الدفع التي يستخدمها عملاؤك فعلاً؟ بطاقة مدى هي الأكثر انتشاراً محلياً، وApple Pay يقفز بمعدل إتمام الطلب على الجوال، والبطاقات العالمية تلزمك إن كان لديك عملاء زائرون.

لا تربط أربع بوابات. اربط واحدة تغطي عملاءك اليوم، وتأكد أن نظامك يسمح بإضافة ثانية لاحقاً دون إعادة بناء عملية الدفع — التوسع إلى سوق ثانٍ هو السبب الأشيع لتغيير البوابة، كما يظهر عند إدارة الفروع المتعددة عبر أكثر من دولة.

الرسوم التي تُذكر والرسوم التي لا تُذكر

النسبة المعلنة على الصفحة الرئيسية للبوابة نادراً ما تكون ما ستدفعه. احسب التكلفة الفعلية على أساس متوسط طلبك، لا على أساس النسبة وحدها.

1. النسبة + الرسم الثابت: الرسم الثابت لكل عملية هو ما يؤلم في الطلبات الصغيرة — طلب بـ 25 ريالاً يدفع نسبة فعلية أعلى بكثير من طلب بـ 150.
2. فرق بطاقات مدى والبطاقات الائتمانية: غالباً سعران مختلفان، والخلط بينهما يجعل تقديرك للتكلفة خاطئاً منذ اليوم الأول.
3. رسوم الاسترداد: بعض البوابات لا تعيد رسم العملية الأصلية عند الاسترداد، فتدفع مرتين على طلب لم تربح منه شيئاً.
4. رسوم النزاع (chargeback): قليلة التكرار وباهظة الوحدة، وتستحق أن تعرف قيمتها قبل التوقيع لا بعده.
5. مدة التسوية: المال الذي يصل بعد خمسة أيام بدل يومين هو تكلفة سيولة حقيقية إن كنت تدفع للموردين أسبوعياً.

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

الربط الصحيح: ما الذي يجب أن يفعله النظام نيابةً عنك

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

1. مطابقة المبلغ مع الطلبيجب أن يُرفض أي مبلغ لا يطابق إجمالي الطلب المحفوظ على الخادم، لا المبلغ الذي أرسله المتصفح.
2. منع الخصم المزدوجالضغط مرتين على "ادفع" يجب أن يعيد استخدام نفس عملية الدفع المعلّقة، لا أن ينشئ عمليتين تظهران في كشف العميل.
3. احترام خانات العملةالريال والدرهم بخانتين عشريتين، بينما الدينار الكويتي والبحريني والريال العُماني بثلاث. الخلط هنا يعني خطأً بعشرة أضعاف في المبلغ المحصّل.
4. التحقق من توقيع الـwebhookإشعار التأكيد القادم من البوابة يجب أن يُتحقق من توقيعه قبل اعتماده، وإلا فأي جهة تستطيع الادعاء بأن طلباً قد دُفع.
5. الربط بالفاتورة الضريبيةعند اكتمال السداد تُصدر الفاتورة الضريبية بمعطياتها الصحيحة — وهو ما يربط الدفع مباشرة بـالفوترة الإلكترونية ZATCA بدل خطوة يدوية لاحقة.

التسوية والاسترداد: حيث تُكتشف الأخطاء

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

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

خطة تفعيل في أسبوع واحد

لا تبدأ بيوم الخميس. التفعيل الهادئ يكشف المشاكل وأنت قادر على التعامل معها:

1. اليوم الأول: أنشئ الحساب لدى البوابة وأكمل التحقق التجاري — عادةً هو أطول خطوة وليست تقنية.
2. اليوم الثاني: اربط المفاتيح في وضع الاختبار ونفّذ عملية كاملة ثم استرداداً كاملاً.
3. اليوم الثالث: فعّل الدفع على قناة واحدة فقط — الطلب الأونلاين مثلاً — وليس على كل القنوات دفعة واحدة، كما في الطلب الأونلاين والتوصيل.
4. اليوم الرابع: طابق يوماً كاملاً: مبيعات النظام مقابل عمليات البوابة مقابل الإيداع البنكي.
5. اليوم الخامس: درّب الكاشيرين على حالتين فقط: الدفع لم يكتمل، والعميل يطلب استرداداً.

بعد أسبوع ستعرف رقمك الحقيقي: نسبة العمليات الناجحة، ومتوسط التكلفة لكل طلب، ومدة وصول المال. إن أردت تفعيل الدفع الإلكتروني للمطاعم مربوطاً بنقطة البيع والفاتورة الضريبية والتقارير في مكان واحد، ابدأ تجربة مجانية وجرّب عملية واحدة من البداية إلى الإيداع.

Restaurant Payment Gateways: Choosing One and Connecting It Without Losing an Order

A restaurant payment gateway is not just a pay button — it is fees, settlement and refunds. Here is how to choose one and connect it without losing an order.

The easiest decision in any restaurant payment gateway project is switching the pay button on. Everything hard comes afterwards: why SAR 96.70 landed in your account for a SAR 100 order, when the money actually arrives, and what to do when a guest is charged twice on a Thursday night.

This guide covers choosing, connecting and running one: how the providers available in Saudi and the GCC differ, which fees get quoted and which do not, how to read a settlement, and how to handle refunds and double charges without turning your accounting into an investigation.

Why cash on delivery stopped being enough

Cash on delivery looks free and is anything but. Its real cost is spread across lines that never appear on an invoice:

• Refused orders at the door: a guest without the right cash, or one who changed their mind — a full trip with no revenue.
• Change floating with drivers: cash circulating outside the till all evening, hard to tie back to any one order.
• Delivery time: counting cash and returning change adds two minutes per drop, which is one fewer order per driver per hour.
• Cash-up variances: every end-of-shift gap becomes a conversation, and often a deduction from somebody.

Choosing a restaurant payment gateway

The restaurant payment gateway decision in Saudi and the wider Gulf starts with one question: what do your guests actually pay with? mada is the most widely held card locally, Apple Pay lifts completion rates on mobile, and international card schemes matter if you serve visitors.

Do not connect four gateways. Connect the one that covers today's guests, and make sure your system can add a second later without rebuilding checkout — expansion into a second country is the most common reason restaurants switch, as anyone running multi-branch operations across borders discovers.

The fees that get quoted, and the ones that do not

The percentage on a gateway's home page is rarely what you end up paying. Work out the real cost against your own average order value, not against the headline rate.

1. Percentage plus fixed fee: the per-transaction fixed fee is what hurts on small tickets — an SAR 25 order pays a far higher effective rate than an SAR 150 one.
2. Local debit versus credit card rates: usually two different prices, and conflating them makes your cost estimate wrong from day one.
3. Refund fees: some gateways do not return the original transaction fee on a refund, so you pay twice on an order you earned nothing from.
4. Chargeback fees: rare per occurrence and expensive per unit, worth knowing before you sign rather than after.
5. Settlement period: money arriving in five days instead of two is a genuine working-capital cost if you pay suppliers weekly.

Ask every provider to price one hundred transactions at your average order value. Rates alone hide the fixed fee, and the fixed fee is what decides whether small orders are profitable.

Connecting it properly: what the system should do for you

A sound integration is more than rendering a checkout page; it is a set of guardrails that prevent expensive mistakes before they happen. Five of them are worth asking any vendor about explicitly:

1. Match the amount to the orderAny amount that does not match the order total held on the server must be rejected — never trust the figure the browser sends.
2. Prevent double chargesPressing "pay" twice should reuse the same pending transaction rather than creating two that both show on the guest's statement.
3. Respect currency decimalsSAR and AED use two decimal places; Kuwaiti and Bahraini dinars and Omani rials use three. Getting this wrong is a tenfold error in what you collect.
4. Verify the webhook signatureThe confirmation callback from the gateway must have its signature verified before it is trusted, otherwise anyone can claim an order was paid.
5. Tie it to the tax invoiceWhen payment completes, the tax invoice should be issued with the correct details — connecting payment directly to ZATCA e-invoicing instead of a manual step afterwards.

Settlement and refunds: where errors surface

A gateway does not transfer each transaction separately. It batches the day and pays out once, net of its fees. So the sales figure in your system will never equal the deposit in your bank — which is fine, as long as you can name and explain the difference.

Refunds should always run through one path inside the system, never straight from the gateway dashboard. The reason is practical: a single path is what guarantees that total refunds never exceed what was actually captured, and that a retry does not refund twice. A refund issued outside the system disappears from your reporting and shows up only in the bank, which is the worst possible place to discover it.

A one-week rollout plan

Do not go live on a Thursday. A quiet rollout surfaces problems while you still have the capacity to deal with them:

1. Day one: open the account and complete commercial verification — usually the longest step, and not a technical one.
2. Day two: connect the keys in test mode and run a full transaction followed by a full refund.
3. Day three: enable payment on one channel only — online ordering, say — rather than everywhere at once, as covered in online ordering and delivery.
4. Day four: reconcile a complete day: system sales against gateway transactions against the bank deposit.
5. Day five: train cashiers on exactly two situations — the payment did not complete, and the guest wants a refund.

After a week you will know your real numbers: success rate, average cost per order, and how long the money takes to arrive. If you want a restaurant payment gateway wired to your POS, your tax invoices and your reports in one place, start a free trial and run a single transaction end to end, from checkout to deposit.