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

Egypt runs on a multi-rail payment stack. The Central Bank of Egypt (CBE) reports that 79% of citizens aged 15 and over held an active transactional account by June 2026. That measure includes bank and Egypt Post accounts, mobile wallets and prepaid cards; it does not mean 79% held bank accounts. The operator takeaway is that Egypt has several payment routes in parallel, each with its own acceptance path, settlement source and recourse model. A single provider's coverage needs checking before launch.

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. Depending on the providers you contract with, you may touch international cards, the Meeza domestic scheme, InstaPay-based transfers, Fawry's acceptance and bill-payment network, mobile wallets, and cash-on-delivery. Confirm how each product reports payments and pays you before deciding how to reconcile them.

Egypt's payment stack from an operator's view

Think in layers, and think about how you route across them. International card schemes support cross-border card acceptance, while Meeza is Egypt's domestic card scheme. InstaPay is the app on the instant account-to-account network between onboarded banks. Fawry has an acceptance and bill-payment network. Mobile wallets and cash-on-delivery are further routes to assess for the customers and providers you actually serve. These are different products, not proof of a common merchant checkout or settlement process.

No single one of these is "the" Egyptian rail. The operator job is to establish which routes your customers and providers can actually use, then confirm payment status and reconcile the proceeds. The table below is an orientation map: product terms, including refunds and disputes, still need checking against the contracted provider.

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 2.08 billion transactions in FY2025 (up 7.7% year-on-year) with total throughput value of about EGP 943.6 billion (up 56.8% year-on-year), across a retail acceptance footprint it reported at roughly 377,000 POS terminals, of which about 354,000 are acceptance-enabled. 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 a domestic card scheme. International card acceptance alone does not establish Meeza acceptance. Ask the prospective provider whether its merchant product supports Meeza, how it routes those payments and what its contracted fees and reconciliation data are. Do not assume Meeza 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.

The EBC describes instant transfers between onboarded banks. That description does not establish that your PSP offers an IPN merchant collection product, when it pays out to you, what it charges, or how errors and refunds are handled. Before offering this route, ask the provider for its transaction-confirmation event, merchant payout and reconciliation file, plus its written refund and dispute process. Do not equate instant transfer execution with your own settlement or a legal-finality rule.

Cards & international acceptance

International card acceptance — Visa and Mastercard — can serve foreign-issued cardholders, subject to your provider's coverage and contract. Ask how the acquiring route handles authentication, FX, settlement and domestic Meeza acceptance. A cross-border card setup alone does not establish Meeza support or its commercial terms.

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. Wallet acceptance and its refund and dispute processes vary by provider and product. Confirm the supported wallet routes, payment-status events and reconciliation fields before treating wallet checkout as covered.

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 providers and products. Ask when each product confirms payment, pays out, and makes reports available. Match the resulting records back to orders — see the reconciliation runbook for the triage discipline, and the settlement-file reference for examples of 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. Ask how each provider returns funds, which payment states permit a refund, and which confirmations and references you receive. If a particular product requires a separate payout, the payout and disbursement failure runbook covers its operational risks.
• Disputes. Card transactions have scheme and acquirer dispute rules. Obtain the actual error and dispute terms for any IPN-based, wallet or cash-adjacent collection product; an instant-transfer description alone is not a substitute.
• 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, errors and disputes handled by each product — what is the provider's written process and what data links the original payment to its resolution?
• 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 contracted acquiring or PSP route that demonstrably covers the domestic products 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-product refund and dispute playbook — grounded in each provider's terms and its actual payment and payout events.
• 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 a contracted refund process requires a separate outbound payout.
• 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.