Payment Processing in the Middle East: Why Western Solutions Don't Work Here

Stripe doesn't operate in Jordan. Square doesn't exist in MENA. PayPal has severe limitations across the region. The payment stack that powers restaurants in New York and London simply does not function in Amman, Riyadh, or Cairo. But the MENA payment landscape is rich, growing, and far more interesting than Western fintech observers realize.

If you're building restaurant technology for Western markets, payments are a solved problem. You integrate Stripe. Maybe you add Square for in-person. You're done. The Stripe API is excellent, the documentation is world-class, and settlement happens reliably into a US or EU bank account. An engineer can ship a working payment integration in an afternoon.

Now try to do the same thing for a restaurant in Amman. Stripe has no Jordanian entity. You cannot create a Stripe account with a Jordanian business license. The same is true for large parts of the Middle East and North Africa. Stripe launched in the UAE in 2022 and Saudi Arabia in 2024, but that still leaves Jordan, Egypt, Iraq, Lebanon, Libya, and a dozen other markets without coverage. Square has zero presence in the entire region.

This is not a temporary gap that will close next quarter. It reflects fundamental structural differences in how payments work in MENA: different regulatory frameworks, different banking infrastructure, different consumer behavior, and a much larger role for cash, mobile wallets, and instant bank transfers than exists in the West.

The MENA Payment Landscape

The richness of payment methods in the Middle East is something that surprises engineers who've only worked with the Western stack. Each country has its own ecosystem, its own dominant methods, its own regulatory quirks. What works in Riyadh doesn't work in Amman. What works in Cairo doesn't work in Dubai.

Look at that table. A restaurant chain operating across Jordan and Saudi Arabia needs to support Cliq and eFawateer for Jordanian customers, Mada and STC Pay for Saudi customers, plus Visa/Mastercard everywhere, plus cash, plus potentially BNPL providers like Tabby. That's a minimum of eight distinct payment integrations across two countries.

The Engineering Challenge

Each of these payment methods is not just a different brand on the same underlying infrastructure. They are architecturally different systems with different integration patterns.

Cliq: Jordan's instant transfer rail

Cliq is Jordan's real-time gross settlement system for retail payments, operated by JoPACC (Jordan Payments and Clearing Company). It enables instant bank-to-bank transfers using an alias (phone number, national ID, or an IBAN). For a restaurant, Cliq works like this: the customer initiates a transfer to the restaurant's Cliq alias, the restaurant's system confirms receipt via webhook or API polling, and the order is marked as paid.

The technical challenge: Cliq doesn't have a unified merchant API the way Stripe does. Integration happens through the restaurant's bank, and each bank has its own API (or lack thereof). Some banks offer real-time webhooks. Others require polling. Some still rely on manual reconciliation. Nexara maintains adapters for multiple Jordanian banks' Cliq implementations.

Mada: Saudi Arabia's national debit network

Mada is not a payment gateway. It's the national payment network connecting all Saudi banks and point-of-sale terminals. Over 55% of card transactions in Saudi Arabia flow through Mada. For online payments, Mada works through certified payment gateways (HyperPay, Moyasar, PayTabs, and others). Each gateway has its own API, its own tokenization scheme, and its own settlement timeline.

The complication for multi-gateway systems: a Mada card tokenized through HyperPay cannot be used through Moyasar. Tokens are gateway-specific. If a restaurant switches gateways, all stored cards are invalidated. Nexara's abstraction layer handles this by maintaining gateway-specific token stores and transparently routing transactions.

eFawateer: bill payment as a payment method

eFawateer is Jordan's electronic bill presentment and payment system. It was designed for utility bills, but restaurants use it for catering orders, corporate accounts, and recurring deliveries. The customer receives a bill number, pays through their bank's eFawateer interface, and the restaurant receives confirmation. Settlement happens on a T+1 basis.

This is a fundamentally different payment flow from card processing. There's no real-time authorization. The restaurant presents a bill, waits for payment, and reconciles asynchronously. Nexara's payment engine handles this as a deferred payment flow with automatic reconciliation when eFawateer confirms settlement.

The Abstraction Layer

The core engineering problem Nexara solves is this: give the restaurant operator a single integration point, and handle the gateway-specific complexity behind a unified interface. The restaurant enables payment methods in their dashboard. The platform handles everything else.

Here is a simplified view of how the payment abstraction works at the API level:

// Unified payment initiation — gateway details abstracted away
const payment = await paymentService.initiate({
  orderId: 'ord_a8f2k9x',
  amount: 12.750,
  currency: 'JOD',
  method: 'cliq',        // or 'mada', 'card', 'stc_pay', 'efawateer'...
  branchId: 'br_amman_01',
  customer: {
    phone: '+962799001234',
    name: 'Ahmad Khalil',
  },
});

// Response is normalized regardless of underlying gateway
{
  id: 'pay_7j3mq9z',
  status: 'pending',         // | 'authorized' | 'captured' | 'failed'
  method: 'cliq',
  gateway: 'jordan_ahli',    // resolved internally based on branch config
  amount: 12.750,
  currency: 'JOD',
  redirectUrl: null,        // only for redirect-based flows (3DS, etc.)
  expiresAt: '2026-03-12T14:30:00Z',
  metadata: {
    cliqAlias: 'ALQUDS-GRILL',
    referenceNumber: 'CLQ-20260312-4821',
  }
}

The caller doesn't need to know whether this order will be processed through Jordan Ahli Bank's Cliq API, HyperPay's Mada integration, or a direct card acquirer. The method field determines the payment flow. The gateway is resolved based on the branch's country, enabled gateways, and routing rules (cost optimization, availability, fallback chains).

Gateway routing and fallback

In practice, payment gateways fail. APIs go down. Banks have maintenance windows. Settlement systems lag. A production payment system that depends on a single gateway will have outages that directly cost revenue — a customer who can't pay abandons their cart.

Nexara's payment router supports fallback chains. If a restaurant's primary card gateway (say, HyperPay) returns a 5xx error, the system automatically retries through a secondary gateway (say, PayTabs) without any customer-visible interruption. This requires maintaining active merchant accounts on multiple gateways per branch — operationally complex, but critical for reliability.

Currency Handling: Harder Than It Looks

MENA currencies have different decimal precision requirements. The Jordanian Dinar (JOD) uses three decimal places: 1.000 JOD, not 1.00 JOD. The Bahraini Dinar (BHD) also uses three. The Saudi Riyal (SAR), UAE Dirham (AED), and Egyptian Pound (EGP) use two. Getting this wrong means rounding errors on every transaction.

Nexara stores all monetary values as integers in the smallest currency unit (fils for JOD, halala for SAR) and converts to decimal representation only at the display and API boundary. This eliminates floating-point arithmetic errors entirely. A 12.500 JOD order is stored as 12500 fils internally. This pattern is well-known in fintech (Stripe does the same thing with cents), but it requires correct configuration per currency, and getting the decimal count wrong for JOD vs SAR silently corrupts every transaction.

Reconciliation: Where It Gets Really Hard

Payment processing has three phases: initiation, capture, and settlement. Western payment processors abstract away most of the settlement complexity — Stripe deposits funds into your bank account on a predictable schedule, and the Stripe dashboard shows you exactly which payments settled when.

In MENA, settlement varies wildly by gateway and method:

• Card payments via local acquirer: T+2 to T+7 depending on the bank
• Cliq: instant (but confirmation webhook timing varies by bank)
• eFawateer: T+1 after customer pays (which could be days after bill presentment)
• Mada: T+1 to T+3 depending on acquiring bank
• STC Pay: T+2 typically
• Cash on delivery: settled when the driver returns cash (tracked separately)

A restaurant that processed 200 orders today through four different payment methods will have settlement arriving across four different timelines, through four different banking channels, in potentially different formats. Without automated reconciliation, this is a full-time accounting job.

Nexara's reconciliation engine ingests settlement files and webhook confirmations from each gateway, matches them to internal payment records, flags discrepancies, and presents a unified view in the dashboard. The restaurant operator sees one screen: today's revenue, what has settled, what's pending, what's outstanding. They don't need to know that behind that screen, the system is reconciling across half a dozen different settlement protocols.

What a Restaurant Would Need Without This

To understand the value of a unified payment layer, consider what a restaurant chain with branches in Jordan and Saudi Arabia would need to build or buy independently:

1. Merchant accounts: Separate applications with a Jordanian acquiring bank (for card processing), JoPACC (for Cliq/eFawateer), a Saudi acquiring bank, and HyperPay or equivalent (for Mada/STC Pay). Each requires paperwork, compliance review, and a 2-8 week onboarding process.
2. Technical integrations: Separate API integrations for each gateway. Each has its own authentication scheme, its own request/response format, its own error codes, its own webhook structure. Budget 2-4 weeks of engineering per gateway.
3. PCI compliance: If you're handling card numbers (even to pass them to a gateway), you need PCI DSS compliance. Annual audits, network segmentation, encrypted storage. A Level 1 merchant assessment costs $50,000-$200,000. Nexara handles this at the platform level so individual restaurants don't need to.
4. Reconciliation infrastructure: Software to ingest settlement files from each gateway, match them to orders, handle partial payments, chargebacks, refunds, and currency conversion for cross-border scenarios.
5. Ongoing maintenance: Gateway APIs change. Banks update their systems. Regulatory requirements shift. Each integration needs ongoing maintenance. Saudi Arabia's SAMA (central bank) regularly updates its payment regulations, requiring gateway-level changes that cascade to every merchant.

A realistic estimate: building and maintaining this independently would cost a restaurant chain $150,000-$300,000 in the first year (engineering time, compliance, merchant account fees) and $50,000-$100,000 annually to maintain. For a single-location restaurant, it's simply not feasible. They're stuck with whatever their POS provider supports — usually just card payments and cash.

Regional Regulatory Complexity

Each MENA country has its own payment regulations, its own central bank requirements, and its own compliance frameworks. A few examples of the kind of regulatory variance Nexara handles:

• Jordan: Central Bank of Jordan (CBJ) requires all electronic payment processors to be licensed. Cliq transfers have a daily transaction limit per individual (currently 5,000 JOD). E-wallets (Zain Cash, Orange Money) have separate tiering based on KYC level.
• Saudi Arabia: SAMA mandates that all online payments support 3D Secure 2.0. Mada has specific technical certification requirements for online merchants. STC Pay requires separate merchant onboarding through STC's portal.
• UAE: The Central Bank of the UAE requires stored-value facilities to be licensed. Card-on-file transactions require explicit customer consent per the Consumer Protection Regulation of 2023.
• Egypt: The Central Bank of Egypt mandates that all electronic payment acceptors register with the Egyptian Banking Institute. InstaPay has transaction limits that vary by customer tier.

A platform operating across these markets needs to be aware of every one of these requirements and ensure compliance at the transaction level. Nexara's payment engine applies country-specific rules automatically: transaction limits, authentication requirements, data retention policies, and reporting formats.

Why This Matters for Restaurants Specifically

Restaurants have payment characteristics that make them particularly sensitive to gateway limitations. Average order values are low ($5-$25), which means per-transaction fees matter more than they do in e-commerce. Transaction volumes are high and time-concentrated (80% of daily transactions happen in a 4-hour window around lunch and dinner). Downtime during peak hours is disproportionately costly.

Restaurants also have delivery — which means cash handling, driver reconciliation, and the need to support different payment methods for dine-in, takeout, and delivery. A customer paying by Mada in the restaurant is a different flow than a customer paying by Cliq for a delivery order, which is a different flow than a customer paying cash to a Careem driver.

Nexara treats each of these as a distinct payment context with its own flow, its own reconciliation path, and its own reporting. The dashboard unifies all of them. The operator sees revenue by payment method, by channel (dine-in/delivery/pickup), by branch, by day — regardless of how many underlying gateways and settlement paths are involved.

The Road Ahead

The MENA payment landscape is evolving fast. Saudi Arabia's Vision 2030 has an explicit target of 70% non-cash transactions (up from about 62% today). Jordan's Cliq adoption doubled in 2025. Egypt's InstaPay processed more transactions in Q4 2025 than the entire previous year. Buy-now-pay-later providers like Tabby and Tamara are becoming standard for food orders above a certain threshold.

Each of these trends means new payment methods, new APIs, new regulatory requirements. A restaurant that built a direct integration with three gateways two years ago is already behind. A platform that maintains and updates those integrations centrally passes the benefit to every restaurant on the platform simultaneously.

That's the real argument for a payment abstraction layer. Not that it saves engineering time on the initial integration — though it does. It's that payments in MENA are a moving target, and the cost of keeping up with that target is too high for any individual restaurant to bear. The platform absorbs that complexity so the restaurant can focus on the food.

Nexara integrates 12+ payment gateways native to the MENA region, with unified reconciliation and automated compliance. Learn more at nexaratech.io.