Egypt Payments Operator Guide: Fawry, Meeza, InstaPay, Cards, and Wallets

Egypt is a large, fast-digitizing market that is still meaningfully cash-heavy, and it runs on a distinctive multi-rail payment stack. The headline numbers are real — the Central Bank of Egypt (CBE) reports financial inclusion reaching 76.3% of adults in June 2025, up from 27.4% in 2016 — but the operator takeaway is not "Egypt is now easy to accept payments in." It is that Egypt has several payment rails operating in parallel, each with its own acceptance path, settlement source, and recourse model. Accepting payments here is not "plug in one PSP and switch it on."

This guide is the operator how-to. For the broad country overview — inclusion stats, fintech ecosystem, BNPL, licensing landscape — see the Egypt market page. What follows is the operational layer beneath that summary: how an operator routes across Egypt's rails, where the money actually settles, how refunds and disputes differ from rail to rail, and the questions to put to a provider before launching.

The single most important mental model: in Egypt, accepting payments is a routing and reconciliation problem, not a single integration. You will likely touch international cards, the Meeza domestic scheme, instant bank transfers via InstaPay, Fawry's acceptance and bill-payment network, mobile wallets, and cash-on-delivery — and you will reconcile money arriving from several different sources on several different clocks. Plan for that shape up front, and Egypt is tractable; assume one rail covers it, and reconciliation will surprise you.

Egypt's payment stack from an operator's view

Think in layers, and think about how you route across them. International cards (Visa/Mastercard) cover foreign-issued cards and cross-border buyers but are a minority of domestic volume. The Meeza domestic scheme covers a large base of locally-issued cards. InstaPay — the instant account-to-account (A2A) rail — covers bank-to-bank transfers in seconds. Fawry covers acceptance and bill-payment, including cash-adjacent collection through a wide physical network. Mobile wallets cover a large, partly-unbanked segment. And cash-on-delivery still covers a material slice of e-commerce.

No single one of these is "the" Egyptian rail. The operator job is to support the mix your customers actually use, route each transaction to the rail that completes it, and then reconcile the proceeds back together. The table below is the orientation map — what each rail is, how an operator uses it, and the recourse you get when something goes wrong. (Recourse, in particular, is where Egypt's rails diverge most sharply, so read that column carefully.)

Fawry — what it is and where it fits

Fawry is one of Egypt's longest-established electronic-payment companies, built around a bill-payment and acceptance network spanning both retail (physical points and agents) and digital channels. For an operator, Fawry's distinctive value is reach into cash-adjacent collection: a customer can be issued a payment reference and settle it through Fawry's network, which is how a lot of bill-pay, top-up, and voucher-style flows work in Egypt. That makes Fawry a useful rail for collecting from customers who do not want to — or cannot — pay by card or bank transfer online.

On scale, attribute the numbers to Fawry's own reporting. Fawry reports processing roughly 1.93 billion transactions in 2024 with total throughput value of about EGP 601.7 billion, across a retail acceptance footprint it reported at roughly 372,400 POS terminals. Treat these as company-stated, point-in-time figures — network counts grow over time, and the throughput spans Fawry's several business lines (acceptance, banking, financial services), not bill-pay alone. The operator takeaway is not a precise number; it is that Fawry is large enough to be a serious collection channel, and that its strength is the cash-adjacent and bill-pay use case that cards and InstaPay don't naturally serve.

The operational catch with Fawry-style collection is confirmation timing: because payment can be completed away from your checkout (at an agent, later, in cash), your system needs to handle the gap between "reference issued" and "payment confirmed," and reconcile the confirmation back to the order. That is a different state machine than a card auth, and it is worth designing for explicitly.

Meeza — the domestic card scheme

Meeza is Egypt's national domestic card scheme, operated under the Egyptian Banks Company (EBC) and the CBE. It was built to widen access — including for previously-unbanked Egyptians — and it now sits on a large base of locally-issued cards (more than 43.5 million Meeza cards reported issued by June 2025, per CBE/industry figures). Meeza Digital extends the brand into mobile wallets, connecting tens of millions of wallets for transfers, QR, request-to-pay, and online purchase.

For an operator, Meeza matters because it is where a large share of domestic card acceptance lives. International card acceptance alone leaves Meeza-only cardholders unable to pay you. The operator angle is twofold: coverage (you need domestic acceptance to reach the local card base, not just foreign cards) and economics (domestic-scheme acceptance and international-scheme acceptance are priced and routed differently, so cross-border buyers and domestic buyers are commercially distinct). Be careful not to over-claim specifics here: exact interchange, MDR, and routing defaults vary by acquirer, merchant category, and contract — confirm Meeza acceptance and its commercials explicitly with whichever provider you onboard with, rather than assuming it comes bundled with international-card acceptance.

InstaPay & instant bank transfers

InstaPay is the consumer-facing mobile app on Egypt's Instant Payment Network (IPN), the instant A2A rail operated by the Egyptian Banks Company. Per EBC, the IPN enables instant, secure transfers 24/7 and supports sending to accounts, digital wallets, and electronic cards; InstaPay lets users transfer by mobile number. The IPN was launched following a 2020 CBE mandate requiring banks operating in Egypt to support it — so it is national infrastructure, not a single bank's product.

For operators, InstaPay (and IPN-based pay-by-bank more broadly) is attractive as a collection rail: settlement is fast, and the cost structure of A2A is typically favourable versus cards. But the recourse model is the thing to internalise. A2A transfers on the IPN are designed to be final once completed — there is no card-style chargeback mechanism to pull funds back after the fact. That cuts both ways: you face less fraud-driven chargeback exposure, but a customer who pays the wrong amount, or whom you need to refund, gets handled as a fresh outbound payment (a payout back to them), not a reversal. Reconciliation is also distinct: InstaPay proceeds arrive on their own clock and in their own report, separate from your card settlement, so they are one more source to fold into your books.

Cards & international acceptance

International card acceptance — Visa and Mastercard — is what lets you take foreign-issued cards and serve cross-border buyers, and it is generally where 3D Secure, FX, and dynamic currency conversion (DCC) considerations live. The operational reality in Egypt is that you typically need a local acquirer or PSP to acquire card transactions into the Egyptian banking system; pure cross-border card acceptance does not by itself give you good domestic-card economics or Meeza coverage.

The card lifecycle itself — how an authorization becomes a capture becomes settled money, and where the gaps are — is the same shape everywhere, and it is worth being fluent in before you reason about Egyptian card settlement. The mechanics are covered in authorization, capture, settlement; the Egypt-specific overlay is that card proceeds are just one of several settlement sources you are reconciling, and that FX/DCC and local-versus-international routing add a commercial dimension on top of the lifecycle.

Mobile wallets & cash-adjacent flows

Egypt has a large mobile-wallet base — Meeza Digital plus telco- and bank-issued wallets — reaching tens of millions of users, including a substantial partly-unbanked segment. Wallet checkout is therefore a real acceptance channel, not a niche. The catch, again, is recourse and reconciliation: wallet dispute handling varies by provider and is generally more limited than card chargebacks, and each wallet flow is another settlement source to reconcile.

Cash-adjacent flows deserve their own line. Cash-on-delivery remains material in Egyptian e-commerce, and cash-adjacent collection (via networks like Fawry) reaches customers who won't pay online at all. The operational cost of cash is not the fee — it is collection certainty and reconciliation: cash introduces leakage, handling risk, delayed confirmation, and a manual-ish matching step between "order placed" and "cash actually collected." Operators serving Egypt should size the cash segment honestly and build the reconciliation muscle for it rather than treating it as an afterthought.

Common operational issues

This is where the multi-rail stack turns into day-to-day work. The recurring issues:

• Payment-confirmation timing. Card auths are near-instant, but Fawry-style and cash-adjacent collection complete away from checkout, so you must model the gap between "reference issued" and "confirmed paid" and avoid fulfilling on an unconfirmed payment.
• Reconciliation across multiple settlement sources. Cards, Meeza, InstaPay, Fawry, wallets, and cash each settle on their own clock and in their own report. Matching all of them back to orders is the core operational load — see the reconciliation runbook for the triage discipline, and the settlement-file reference for how to read provider settlement files.
• Settlement visibility and currency. Know which rail settles when, in what currency, and net of what fees — and confirm whether you can get USD settlement or only EGP, because that drives FX exposure.
• Refunds. Card refunds are routine; A2A (InstaPay) and cash-adjacent refunds are hard, because there is no reversal — a refund is a fresh outbound payment, which is its own failure-prone flow. The payout and disbursement failure runbook covers what breaks when you push money back out.
• Chargebacks and disputes. Cards carry chargeback rights and a dispute framework; InstaPay/A2A and most wallet flows do not, so your loss-and-dispute model has to be rail-specific rather than one-size-fits-all.
• Routing between rails. Deciding which rail to offer or prefer per transaction — cards vs wallet vs local A2A — is a routing decision; multi-acquirer routing covers the orchestration discipline even though Egypt's mix is broader than just acquirers.
• Failed and ambiguous payment states. Across cash-adjacent and async rails you will get "did it complete?" states; build deterministic handling for pending, failed, and timed-out payments so they don't silently become fulfilled-but-unpaid orders.

What to ask your PSP / acquirer before launching Egypt

Before you launch, get explicit answers — in writing, per rail — to this checklist. The whole point is to surface coverage gaps and reconciliation surprises before they hit production. (For the underlying who-does-what of acquirers, gateways, and PSPs that these questions probe, see the payment-stack actors guide.)

• Which rails do you actually support — international cards, Meeza, InstaPay/IPN, Fawry, mobile wallets, cash-on-delivery — and which are live versus roadmap?
• Do you provide local card acquiring into the Egyptian banking system, or only cross-border card acceptance?
• Is Meeza acceptance included, and on what commercials (routing, fees) versus international cards?
• Do you support InstaPay / IPN collection, and how are confirmations and reconciliation delivered?
• Do you support Fawry integration for cash-adjacent and bill-pay collection, and how is confirmation timing handled?
• What settlement currency and timing apply per rail — EGP only, or USD available — and what is the payout schedule and any reserve?
• What reconciliation files do you provide per rail, in what format, and how do they tie back to orders?
• How are refunds and disputes handled per rail — card chargebacks, A2A refunds-as-payouts, wallet and cash-adjacent recourse?
• How is FX / DCC handled, and who bears the FX risk on cross-border and EGP settlement?
• What KYC / onboarding is required, and what is the realistic timeline to go live?

Operator readiness checklist

Before launch, confirm you have:

• A rail map for your customers — which of cards, Meeza, InstaPay, Fawry, wallets, and cash your actual buyers use, and which you'll support at launch.
• A local acquiring or PSP relationship that demonstrably covers the domestic rails you need (not just cross-border cards), confirmed in writing.
• A reconciliation plan across every settlement source — one matching process that folds card, Meeza, InstaPay, Fawry, wallet, and cash proceeds back to orders.
• A per-rail refund and dispute playbook — card chargebacks handled one way, A2A and cash-adjacent refunds (as outbound payouts) handled another.
• Deterministic handling of pending/failed/timed-out states, so async and cash-adjacent payments never silently become unpaid-but-fulfilled orders.
• Settlement-currency and FX clarity — you know what settles in EGP vs USD, when, and who carries the FX risk.

Scope note

Availability and mechanics vary by PSP, acquirer, bank, merchant category (MCC), and contract — what one provider offers in Egypt, another may not, and the specifics change over time. This guide is operator framing, not legal or regulatory advice, and it makes no licensing claims about any specific provider — whether a given company is or isn't licensed for a given activity is something to verify directly, not infer from here. Company-stated and regulator-stated metrics (Fawry's volumes, the CBE's inclusion and InstaPay/Meeza figures) are attributed to their sources and are point-in-time; they are not independently audited here. Where sourcing for a precise claim was thin — exact MDR/interchange, routing defaults, individual providers' rail coverage — this guide deliberately narrows or omits the claim and tells you to confirm with your provider. For the broad country overview, see the Egypt market page linked above; verify current specifics with your providers and the Central Bank of Egypt before you launch.

Related references

• Issuer, Acquirer, Gateway, PSP — who you actually contract with, who holds your money, and who you call when a payment breaks; the actor map behind the PSP/acquirer checklist above.
• Authorization, Capture, Settlement — the card lifecycle that underlies Egyptian card settlement and the reconciliation gaps.
• PSP Reconciliation Failure Runbook — triage discipline for when proceeds across your several Egyptian settlement sources don't reconcile.
• Stripe / Adyen Settlement File Reference — how to read provider settlement files so multi-rail reconciliation is tractable.
• Payout and Disbursement Failure Runbook — what breaks when refunds and A2A reversals have to go out as fresh payments.
• Multi-Acquirer Routing — the orchestration discipline for choosing between rails per transaction.
• US–Mexico Remittance Corridor — a contrasting cross-border, multi-rail corridor with its own settlement and recourse shape.