Choosing a Payment Stack for MENA: Paymob, Fawry, and Stripe Together

A Cairo-based skincare brand with a good product and a clean website was converting at under 2% at checkout. The team had focused on the funnel — better product photos, faster page load, a simplified cart. The actual problem was on the payment page: the only option was international Visa/Mastercard via Stripe. A significant portion of their Egyptian customers either did not have international-enabled cards, preferred to pay through Fawry kiosks near their homes, or wanted cash on delivery. Every one of those customers saw one option and left.

Payment coverage in MENA is a market access decision, not a technical detail.

Why MENA payment stacks are multi-provider by necessity

No single payment provider covers the full range of preferred methods across MENA markets. The gap between what Stripe covers and what Egyptian, Saudi, or UAE customers actually use can be large:

Stripe handles international Visa and Mastercard reliably, powers subscription billing cleanly, and has excellent developer tooling. In Egypt it is available but covers mainly banked users with internationally-enabled cards — a meaningful segment, not the whole market.

Paymob is the most widely-used payment orchestration layer in Egypt. It routes through local card acquirers, supports mobile wallets (Vodafone Cash, Orange Money, Etisalat Cash), and integrates installment providers. It covers card-on-delivery orders, instalment plans, and bank transfer flows that Stripe does not.

Fawry reaches customers who pay in cash at Fawry-enabled kiosks, pharmacies, and convenience stores — a network of over 300,000 points across Egypt. The customer adds to cart, receives a reference code, and pays in cash within 24–48 hours. For lower-income segments and for customers who distrust card-on-file, Fawry is often the only method they will use.

A realistic payment mix for an Egyptian consumer e-commerce product at moderate scale: roughly 40–50% card (Paymob local acquiring), 20–30% mobile wallet, 10–20% Fawry, and 5–15% cash on delivery. Stripe-only covers the card segment and misses the rest.

Architect around a payment ledger, not scattered provider fields

The natural instinct when adding a second payment provider is to add a column. Order has stripePaymentIntentId, then add paymobOrderId, then add fawryReferenceCode. Six months later the finance team cannot reconcile because different providers settle differently, use different currencies in their reports, and have different refund windows.

Design around a payment ledger from the start:

model Payment {
  id            String        @id @default(cuid())
  orderId       String
  provider      PaymentProvider // STRIPE | PAYMOB | FAWRY | COD
  providerRef   String        // the provider's own reference ID
  method        String        // CARD | WALLET | CASH | FAWRY_CODE
  amount        Int           // in smallest currency unit (piastres or cents)
  currency      String        // EGP | USD | SAR
  status        PaymentStatus // PENDING | AUTHORIZED | CAPTURED | FAILED | REFUNDED
  settledAt     DateTime?
  providerFee   Int?          // provider's fee in smallest unit
  createdAt     DateTime      @default(now())
  updatedAt     DateTime      @updatedAt

  order         Order         @relation(fields: [orderId], references: [id])

  @@index([orderId])
  @@index([provider, providerRef])
  @@index([status, settledAt])
}

All providers write to the same table. Finance reports query one source. Refunds, disputes, and partial payments all have a consistent audit trail.

Build checkout around trust, not just method coverage

Adding Fawry support without surfacing it clearly is wasted integration work. Customers need to recognize the method, understand the flow, and feel confident they will receive what they paid for.

Practical trust signals at checkout:

• Show logos for each payment method — Fawry's green logo, Vodafone Cash's red, and the card network logos are immediately recognizable to MENA users.
• Explain the Fawry flow in Arabic: "ستحصل على رمز دفع تستخدمه في أقرب نقطة فوري خلال 48 ساعة." Customers who have not used it before need to understand the process before they commit.
• Currency in Arabic numerals vs Western numerals — decide and stay consistent. ١٢٠ج.م is fine; mixing it with EGP 120 in the same flow looks unpolished.
• Clear retry states: if a mobile wallet payment fails (common during peak traffic on Vodafone Cash), offer the next best method immediately rather than showing a generic error.

Handling payment confirmation webhooks reliably

Each provider sends payment status updates via webhook. Fawry in particular can notify hours after the transaction when the customer pays at a kiosk. Design your order state machine to handle delayed confirmation:

// Orders can be in PENDING_PAYMENT state for up to 48h for Fawry
// Do not cancel them prematurely
async function handleFawryWebhook(payload: FawryWebhookPayload) {
  if (!verifyFawrySignature(payload)) {
    throw new UnauthorizedException("Invalid Fawry signature");
  }

  if (payload.paymentStatus === "PAID") {
    await paymentService.capture({
      orderId: payload.merchantRefNumber,
      providerRef: payload.referenceNumber,
      paidAt: new Date(payload.paymentTime),
    });
  }
}

Never auto-cancel a Fawry order after 30 minutes. Set a cancellation window that matches the Fawry payment window — typically 48 hours.

Reconciliation: the finance team's reality

Stripe settles in USD or GBP and requires conversion to EGP on your books. Paymob settles in EGP with a 2–3 business day delay. Fawry settles weekly. Cash on delivery is collected by a logistics partner with their own payout schedule.

Reconciliation means matching each settlement batch to the individual payments it covers, accounting for provider fees, and flagging any transaction in your ledger that has no corresponding settlement line. This is tedious if the data is scattered; it is manageable if payments are in a single ledger with provider and settlement references.

Build a weekly reconciliation report early — even a CSV export is valuable. The finance team will run it manually until volume justifies automation. Starting with a coherent data model means automation is a query away when needed.

Payment strategy in MENA is market strategy. The providers you support directly determine which customers can buy from you. The data model you choose determines how painful operations and finance become as volume grows.

For how these payment flows fit into multi-vendor marketplace products, see Why We Build Multi-Vendor Marketplaces Differently in MENA.