Payment gateways in Saudi Arabia: the options, which one fits you, and what integration actually involves

"We want to accept payments online" sounds like one step. In practice it is three decisions: which payment methods you want, which gateway connects you to them, and how it goes into your website or app without breaking the customer's experience.

This post walks through all three, without fee numbers, because they change and depend on your volume, and any number we write today will be wrong in two months. Ask the gateway about fees; ask us about the rest.

First: the payment methods a Saudi customer expects

• mada. Most cards in Saudi Arabia are mada cards, and if your gateway does not support mada directly, you lose a large share of customers from day one.
• Apple Pay. On mobile it has become the fastest method, and the difference in checkout completion between it and typing a card by hand is visible.
• Visa and Mastercard. Essential, and they cover foreign cards if you have customers outside the Kingdom.
• Instalments (buy now, pay later). Tabby, Tamara and others. For mid-priced products and above, their presence lifts checkout completion, but their fees are higher and you need to work out whether they pay off on your products.
• STC Pay and wallets. Depending on your audience.
• Cash on delivery. Not an online payment, but do not remove it at the start if your customers are used to it.

The rule: start with mada, Apple Pay and cards. Add instalments when the basket size justifies it.

Second: the types of gateway

There are roughly three categories, and each has its place.

Local gateways built for the Saudi market

Native mada support, familiarity with central bank requirements, and Arabic support in the same time zone. They suit most local stores and apps. Moyasar, HyperPay, Tap and PayFort are among the names we work with.

Global gateways

Excellent APIs and strong documentation, but local mada and Apple Pay support and registration requirements differ. They suit you when you have international customers or a digital product sold worldwide.

Gateways bundled into store platforms

Salla, Zid and similar platforms come with a built-in gateway or a fixed set of options. If your store is on a platform, the choice is limited to what the platform offers, which is acceptable at the start.

Third: how to choose

Ask each gateway these questions:

1. Are mada and Apple Pay supported directly? No workarounds.
2. What are the registration requirements? A commercial registration, a bank account in the company's name, and often a published website with a privacy policy and a refund policy. The last one is forgotten so often that it delays launches by weeks. (We published a refund policy on our own site for exactly this reason.)
3. When does the money reach your account? The settlement period matters for cash flow.
4. Fees: a percentage per transaction, a fixed fee, a monthly fee, refund fees. Ask for the full sheet.
5. Refunds and disputes: how do you return money to a customer? From the dashboard or by request? And what happens when a customer disputes with their bank?
6. The API and documentation: a question for whoever builds for you, but the answer decides how long integration takes.
7. A test environment: can you run complete transactions before the live account is enabled?

Fourth: what "integration" technically means

This is where the misunderstanding lives. Integration is not a "Pay" button. It is four parts:

1. The payment page or form. Either you redirect the customer to the gateway's page (simpler and safer, slightly less smooth), or you embed the payment form inside your site or app (better experience, higher security requirements). In apps, Apple Pay needs a specific setup in the Apple developer account with a merchant certificate.

2. Server-side confirmation. The most important part and the most neglected. When the customer pays, the gateway sends a notification to your server (a webhook) saying "the transaction succeeded". Your system must rely on that notification, not on what the browser says, or you end up with orders marked "paid" with no money, or money with no order.

3. The non-success states. Failure, cancellation, timeout, an accidental double payment. Each state needs a defined behaviour in your system, or the customer calls to say "I was charged and got nothing".

4. Reconciliation. At the end of the day or the month, what the gateway dashboard shows must match what your system shows. If you run Odoo or an accounting system, integration reaches here too: every successful transaction is recorded, fees are recorded, and settlement reconciles.

The mistakes that delay launch

• Starting gateway registration late. Registration and verification take days to weeks. Start it on day one of the project, not the last week.
• A website without policies. Most gateways require a published privacy and refund policy before activation.
• Testing on the live account. Test in the sandbox, then one real transaction for a small amount, then open up.
• Relying on the browser response. Point two above. It causes most of the payment problems we see.
• Forgetting Apple Pay on the web. It needs domain verification with Apple, not only the app setup.

A payment gateway with Odoo or a booking system

If you run Odoo or a custom system, payment does not stop at "succeeded". The invoice is issued e-invoicing compliant, the stock decreases, and the payment is recorded in accounting. That part of the integration is what turns monthly reconciliation from a day into minutes. We covered invoicing in ZATCA e-invoicing on Odoo.

The short version

Choose the payment methods your customer expects (mada, Apple Pay and cards first), pick a gateway that supports them directly with a clear registration path, and start registering on day one. Technically, rely on server confirmation rather than the browser, handle the failure states, and reconcile at month end. Do those four and you will not have payment problems.

If you would like help choosing the gateway and connecting it to your store, app or Odoo, book a free consultation.