Getting paid in MENA — checkout is a systems decision, not a payment plugin

Checkout is the one screen where intent turns into money — and in MENA it is also the most fragmented screen you run. A single customer might reach for cash on delivery, a Meeza card, an InstaPay transfer, or a Tabby instalment plan, and each of those settles on a different clock, charges a different fee, and fails in a different way. Most businesses respond by dropping a hosted checkout widget on the front of the page and calling payment "done." It is not done. It is just deferred — into a spreadsheet someone reconciles by hand at the end of every month.

The market makes this unavoidable. MENA digital payments are projected to grow from roughly 251 billion dollars in 2025 to 422 billion by 2030 [1], yet cash has not left: cash on delivery and bank transfer still made up about a third of payment value in Egypt in 2025, and nearly 45% of online shoppers across the region still reach for COD [2]. At the same time the digital rails are scaling fast — Egypt's InstaPay went from 11.5 million users in its first year to 53 billion dollars in annual transaction value by 2024 [3] — and instalments are a market of their own, with Middle East buy-now-pay-later forecast to climb from 2.7 billion dollars in 2025 toward 8.8 billion by 2031 [4]. You do not get to pick one method. You have to take all of them, at once.

So the real decision is not Paymob versus Fawry versus Kashier. It is architectural: is payment a plugin glued to the front of a checkout page, or a capability wired into the system that already owns your orders, your inventory, your refunds, and your books? This piece maps the four methods and their settlement clocks, the reconciliation tax that COD quietly charges, and the two ways businesses actually build — one fragile, one structural.

Start with the method mix, because it is wider here than almost anywhere else. Cash on delivery still rules the floor — about 45% of MENA online shoppers reach for it, and in Egypt cash and bank transfer were still roughly a third of payment value in 2025 ^[2]. But the digital side is not creeping, it is sprinting: cards and the Central Bank of Egypt's Meeza national scheme run through gateways like Paymob, Fawry, and Kashier ^[5], mobile wallets and InstaPay have scaled into tens of billions of dollars a year ^[3], and instalments have become a category of their own ^[4]. The customer expects all of them on the same checkout. That is the constraint you are designing against.

The trap is treating those methods as interchangeable, because every one of them settles on a different clock. A card payment clears in near-real time but can be reversed weeks later by a chargeback, and a meaningful share never completes because the 3-D Secure step drops on a flaky connection. A wallet or InstaPay transfer is instant and final. Cash on delivery is not really a payment method at all — it is a logistics event: a courier collects cash days or weeks after the order, hands it back in a batch, and someone on your side has to match every note to every order by hand ^[6]. Bolt these onto the front of a page and you have not unified anything; you have created four separate reconciliation jobs and assigned them all to a human.

Cash on delivery deserves its own paragraph because it is the method that quietly eats the margin. Return and rejection rates in MENA run between 10% and 30% depending on category and season ^[7], and a failed delivery is not free — once you add the reship, the support time, the return handling, and the lost customer, the industry puts the cost of a single failed order somewhere around 15 to 40 dollars ^[8]. Then there is the refund: when the money arrived as physical cash through a courier, sending it back is a manual operation, not a click. COD looks like the cheap, friction-free option to the customer. To the operator it is an operations problem wearing a payment-method costume — and if your system does not track the order through delivery, collection, and settlement, you carry that problem in a spreadsheet forever.

This is why the gateway choice matters less than where the integration lands. Paymob, Fawry, Kashier, Geidea, and PayTabs will all take a card and a wallet payment competently ^[5]; the instalment providers — Tabby, Tamara, valU — will embed a plan at checkout and pay you the full amount up front while they carry the customer credit risk ^[4][9]. Any of them works. What separates a clean operation from a messy one is whether the payment result flows back into the system that created the order, or whether it lands in a separate dashboard you have to log into, export, and re-key. A hosted redirect that leaves the customer on the gateway's page is the fastest thing to ship and the slowest thing to reconcile.

So here is the decision that actually matters: bolt-on versus wired-through. In the wired model, the order is created once inside the system you own; every method — card, COD, wallet, instalment — posts its status back against that same order record; reconciliation to the ledger is automatic; and a refund is a state change with a defined path, not a hunt through three dashboards and a courier manifest. The same structured payment data that satisfies your accountant is the data that drives your cash-flow view, your settlement timing, and any forecasting or AI you put on top — because it finally lives in one place and is finally true. For a shop doing a handful of orders a month, that is overkill. For an operating business taking real volume across four payment methods, it is the difference between owning your numbers and renting a monthly headache.