mada, MEEZA, and KNET: The MENA Payment QR Guideمدى، ميزا، وكي-نت: دليل مدفوعات QR في الشرق الأوسط

If you accept payments in MENA, the most consequential thing your QR code is doing is not generating a payment — it's choosing a rail. The same scanned QR can settle a SAR 50 transaction in Riyadh through the mada network at one fee structure, an EGP 200 transaction in Cairo through MEEZA at another, a KWD 5 transaction in Kuwait City through KNET at a third — or it can route the same cards through Visa/Mastercard international rails at meaningfully higher cost. The customer doesn't see the difference; you and your processor absolutely do. This is the part of MENA payment QR that almost no English-language guide explains.

This piece is for MENA merchants, e-commerce operators, marketplace builders, payment-gateway integrators, and finance teams trying to understand why payment QR in this region is structurally different from accepting payments in Europe or North America. It is not legal or financial advice — settlement-rule nuances change with regulation, and your acquiring bank and payment processor are the authoritative source for your specific contract terms. But the structural picture is durable, and it's the picture every QR-payment decision in MENA gets made against.

The five MENA payment schemes you should know

mada — Saudi Arabia (SAMA)

mada is the Saudi national payment scheme operated under the Saudi Central Bank (SAMA). It is the default scheme on virtually every Saudi-issued debit card and the cheapest rail for domestic transactions — interchange fees, scheme fees, and settlement costs are all materially lower than running the same card through Visa or Mastercard rails (mada-branded cards typically also carry Visa or Mastercard co-badging for international use, but domestic transactions route through mada by default and by regulation in many cases). Vision 2030's cashless-economy push has made mada-routed QR payments a strategic government priority — mada QR specs are now an official SAMA-published standard, and accepting mada is increasingly table-stakes for any KSA merchant taking digital payments.

MEEZA — Egypt (CBE)

MEEZA is Egypt's national payment card scheme, operated under the Central Bank of Egypt as part of a long-running financial-inclusion strategy. It has been a tool of state-driven account opening — government salaries and pensions are routinely issued on MEEZA cards, expanding the cardholder base from a previously bank-account-light population. MEEZA QR sits atop this infrastructure. For merchants in Egypt accepting QR, MEEZA acceptance is now a meaningful share of card volume — substantially higher than it was three or four years ago — and the per-transaction economics differ from Visa/Mastercard rails on Egyptian-issued cards.

KNET — Kuwait

KNET is Kuwait's national payment switch, operated by the Kuwait Automated Settlement System and predating most modern QR schemes by decades — KNET has been the spine of Kuwaiti domestic card payments since the early 1990s. KNET is the default scheme on Kuwaiti debit cards and is overwhelmingly the rail customers expect at point of sale. KNET QR exists in modern form and is the de facto domestic QR rail for any Kuwaiti merchant — international cards work, but Kuwaiti customers generally prefer paying with their KNET debit card directly, often via NBK Pay or similar mobile wallets that QR-scan into a KNET transaction.

AAID — UAE

The UAE's domestic scheme picture is structurally a little different — historically more Visa/Mastercard-routed than KSA or Egypt — but the Central Bank of the UAE has been building the local infrastructure (instant payment rail, AAID — Aani — instant payment system launched by Al Etihad Payments). UAE QR payment via Aani and via the major banks' QR wallets routes through this domestic infrastructure for instant settlement, often substantially faster and cheaper than card-rail equivalents. For UAE merchants accepting QR, Aani acceptance is increasingly the strategic anchor.

Benefit — Bahrain

Benefit Pay is the Bahraini national payment scheme, operated by BENEFIT Company. Benefit QR is well-established in Bahrain (more so than equivalents in some larger neighbouring markets) — Bahrain's small geographic and population scale let domestic-scheme QR adoption move faster than in larger markets. For any Bahraini merchant, Benefit acceptance is functionally mandatory for serious POS volume.

Other schemes worth mentioning briefly: Jordan's JoMoPay (driven by Central Bank of Jordan), Qatar's QPAY (NAPS-operated), and Morocco's nascent national card-scheme work led by Bank Al-Maghrib. The pattern is consistent — every MENA market is building or has built domestic-scheme rails that route differently from international card networks, and QR payment is increasingly the surface where these rails meet the customer.

Why this matters operationally

Five practical implications that change how MENA merchants should think about QR payment.

1. Settlement cost varies by 100-300 basis points depending on which rail your QR routes

The exact numbers depend on your acquirer contract, your monthly volume, your merchant category code, and your card mix — and they shift over time. But as a structural fact: a mada-routed domestic transaction in KSA, a MEEZA-routed transaction in Egypt, a KNET-routed transaction in Kuwait will typically cost the merchant materially less to settle than the same card running through Visa or Mastercard international rails. If your processor lets you preference domestic-scheme routing where the card supports it, doing so over a year on a few thousand daily transactions adds up. If your processor doesn't expose that control to you, ask your account manager — the answer is sometimes a config flag away.

2. Cardholder experience differs by scheme

On a mada-issued card scanned at a Saudi merchant's QR, the customer's bank may prompt for a different authentication flow (mada SecureCode versus the international 3DS variants), may show the receipt in a slightly different format, and may settle in a different number of business days. Customers know which scheme they're on — most Saudi consumers will explicitly check that a merchant accepts mada before scanning. The same applies in Egypt for MEEZA, Kuwait for KNET, etc. The 'we accept all cards' signage that works in Europe doesn't carry the same trust signal in MENA — 'we accept mada' is the trust-anchor phrase a Saudi consumer is looking for.

3. Recurring/MIT and subscription QR payments have scheme-specific gotchas

If your QR initiates a subscription or a tokenised recurring charge (the customer scans once, future months charge automatically without re-scanning), the scheme matters enormously. Domestic schemes have their own merchant-initiated-transaction (MIT) standards, often more conservative than international card schemes — some require explicit per-charge customer authorisation, some have lower velocity limits, some don't yet support MIT at all for certain card categories. If you're building a subscription product on QR payment, your acquirer needs to confirm which schemes will support tokenised recurring on which card types, in which markets. This is the single largest source of integration friction we see MENA merchants hit when moving from international-scheme-only payments into domestic-scheme acceptance.

4. Refund, chargeback, and dispute flows are scheme-specific

Each domestic scheme runs its own dispute resolution process. mada disputes follow SAMA-aligned timelines and evidence requirements; MEEZA disputes follow CBE-aligned ones; KNET has its own. International-scheme dispute experience does not transfer directly. Your support team handling chargebacks needs to know which scheme each transaction routed through and what that scheme's specific evidence package looks like. The processor usually handles the heavy lifting, but the merchant-side data needs (transaction logs, customer IPs, delivery proofs, signed receipts) varies by scheme.

5. The QR itself doesn't pick the scheme — the card does

An important conceptual clarification: when a customer scans your QR and pays, the QR itself is largely scheme-agnostic. It's a payment-request envelope. The actual scheme is determined by which card the customer's wallet or app presents to settle the transaction. So a single QR can route through mada when scanned by a Saudi consumer with a mada-issued card, through Visa rails when scanned by a Lebanese tourist with a Visa-issued international card, and through MEEZA when scanned by an Egyptian customer with a MEEZA card. Your role as the merchant is to make sure your processor and gateway support all the schemes your customer base actually carries — the QR will adapt.

How a QR-payment flow actually executes in MENA

The full sequence, simplified:

1. Customer scans your QR with their banking app (mada app for Saudis with mada-only cards, the same banking-app QR for those with co-badged cards, similar pattern for other markets) or with their general payment wallet (STC Pay, Apple Pay, Google Pay, urpay, NBK Pay, etc.).
2. The wallet/app extracts the payment-request envelope from the QR (which encodes your merchant ID, the amount, the currency, an idempotency token, etc.).
3. The wallet/app presents the customer's selected payment instrument (a specific card, a wallet balance, or a bank account) to your gateway.
4. Your gateway determines the appropriate rail based on the card's scheme — domestic-scheme if available and preferenced, international-scheme otherwise.
5. Authorisation goes through that rail; settlement follows the rail's specific timing rules.
6. Customer sees a confirmation in their app; your gateway sends a webhook to your backend; your merchant of record reflects the transaction with the rail clearly tagged for reconciliation.

The rail choice happens at step 4 and is largely invisible to both the customer and the merchant. But the cost difference, dispute path, and reconciliation tagging at step 6 are all real and accountable. Your finance team's monthly close should reconcile by rail.

What MENA merchants should ask their payment processor

If you're evaluating a payment processor for QR acceptance in MENA, the questions that actually matter beyond the standard '%-per-transaction' rate:

• Which domestic schemes do you support natively as a default rail (not just as a fallback)? Per market.
• What is the settlement rate (interchange + scheme + acquirer markup) for each domestic scheme vs Visa/Mastercard on the same card type? Get a table by market and card category.
• Do you support tokenised recurring payments on mada? On MEEZA? On KNET? With what limits and on which card categories?
• When a customer scans a co-badged card, which scheme do you preference by default, and is that configurable per merchant?
• Which dispute portals do you front for me? Do I see one unified UI, or does each scheme require a separate workflow?
• What's your typical settlement timing per scheme — T+1, T+2, T+3? Domestic schemes are often faster than international, but this varies.
• Do you generate the QR for me, or do I need to comply with each scheme's QR-format spec (EMV QR Code Specification compatible, mada-aligned, etc.) myself?

Static vs dynamic QR at the payment layer

Payment QRs in MENA — whether mada, MEEZA, KNET, or international-scheme — come in both static and dynamic flavours, but they mean something specific in payments.

Static payment QR: encodes your merchant ID and possibly an account-routing identifier, but no amount. The customer scans, then types the amount manually in their wallet app. Used for small shops, taxis, market stalls. Cheap to deploy (one sticker per shop), but the customer-types-the-amount UX is friction-heavy and error-prone. Best for low-value, customer-initiated transfers.

Dynamic payment QR: encodes the merchant ID AND the specific amount AND a transaction-unique idempotency token, generated by the merchant's POS or app each transaction. The customer scans and confirms a pre-filled amount. This is the cleaner UX and the standard for any serious retail or e-commerce payment QR. Requires either a screen at the POS that can render the QR per transaction, or a printed QR that links to a transaction-specific dynamic URL.

QRA-style dynamic-URL QRs are a separate concept from dynamic-payment QRs and shouldn't be confused: a QRA dynamic QR encodes a redirect URL that the operator can edit anytime (changing where the QR sends the visitor), whereas a dynamic payment QR encodes a per-transaction amount + token generated at sale time. The two layer cleanly — you might use a QRA dynamic QR to point to a payment-checkout page, which then generates a dynamic payment QR for the specific transaction.

Where this fits with QRA + PayTabs

QRA's payment-related QR types are designed to layer on top of MENA-native payment processors — most commonly PayTabs in our customer base, which natively routes mada, MEEZA, KNET, and several international schemes through KSA-resident infrastructure. The QR carries a stable URL to your payment checkout; the checkout displays the per-transaction dynamic payment QR that the customer's wallet actually scans; the wallet routes through the appropriate domestic scheme based on the card presented. You get the routing optimisation, your customer gets the familiar wallet experience, and you keep the option to update the underlying payment URL or routing anytime without reprinting the QR.

The short answer

MENA payment QR is not just international cards on a different surface. mada, MEEZA, KNET, AAID/Aani, Benefit, and the parallel schemes in other markets route domestic transactions through national-scheme infrastructure with different cost, different settlement, different dispute flow, and different recurring-payment behaviour from Visa/Mastercard international rails. The customer scanning your QR is choosing a rail when they choose a card. Your processor should let you preference the domestic-scheme rail where it's available; your finance team should reconcile by rail; your dispute team should be ready for scheme-specific evidence requirements. Treat domestic-scheme support as table-stakes for MENA, not as a nice-to-have.