Payment gateways in Egypt: Paymob, Fawry and the rest

Any Egyptian online store needs to accept online payment, or lose the half of customers who do not want to deal in cash. But which one?

The options

• Paymob — the most widely used locally. Cards, wallets and Fawry.
• Fawry — strong for over-the-counter payment, good for customers without cards.
• Stripe / PayPal — if you sell mainly outside Egypt.
• Cash on delivery — still the most used, but it raises your return rate.

What you need to activate

• Commercial registration and tax card.
• A bank account in the business name.
• A working site with terms and a refund policy — gateways genuinely review these.

Start the gateway paperwork early. Activation takes one to three weeks; most people assume it takes a day.

Fees

Expect roughly 2–3% per transaction, sometimes with a fixed fee. The gap between providers is small, so the deciding factors are which one your customers trust and how cleanly it integrates with your store.

Turn the idea into a controlled launch

Start with the customer action the project must make easier: call, book, request a quote, buy or visit. That decision determines the page structure, content and tracking. A long feature list without a primary action usually produces an attractive project that nobody can measure.

Launch the smallest complete version, not a half-finished large version. Give one owner responsibility for content and approvals, test the full journey on a real phone, and record a baseline before launch. Improve from customer behaviour after launch rather than from internal opinions alone.

• Define one primary conversion and at most two supporting actions.
• Prepare final Arabic and English content before visual approval.
• Test forms, calls, maps, checkout and messages on real devices.
• Assign an owner and review performance every month.

A topic-specific field checklist

• Confirm that the provider operates through the regulated Egyptian payment ecosystem and supports your legal entity and business activity.
• Compare card, mobile-wallet and cash-channel coverage, settlement time, refund handling and chargeback evidence.
• Build a failed-payment and webhook-retry path; a successful screen alone is not proof that money settled.
• Display terms, privacy, shipping and refund pages before submitting the merchant application.

Details most proposals miss

Commerce is a chain of records: product, price, stock, customer, payment, shipment, return and refund. A polished storefront is not enough if those records disagree. The implementation should make exceptions visible and reconcile money and stock every day.

• One authoritative product and stock record with controlled updates.
• Order states that separate confirmation, payment, fulfilment, delivery, return and refund.
• Idempotent payment and shipping callbacks so retries do not duplicate work.
• Address, variant and total-cost confirmation before fulfilment.
• Daily exception queues for failed payments, delayed shipments and mismatched settlements.

The TechMate implementation layer

TechMate designs the storefront and the operational trail together. The customer gets clear status, while the team gets searchable orders, timestamps, responsibility and reports that can explain where margin or delivery performance was lost.

• Egyptian-pound totals shown consistently from product to receipt.
• Cash-on-delivery and electronic-payment journeys reported separately.
• Courier and gateway reference IDs stored against the order.
• Return and refund rules visible before checkout and enforceable in operations.
• Analytics connected to confirmed revenue, not button clicks alone.

Delivery phases that reduce risk

Release commerce in a controlled loop from product setup to settlement. Do not scale traffic until exceptions can be detected, owned and resolved without editing records by hand.

• Clean product, variant, price and stock masters.
• Test success, failure, cancellation, return and refund.
• Pilot payment and courier flows with real references.
• Reconcile order, money and stock totals daily.
• Automate only after exception patterns are understood.

Questions that reveal implementation quality

• Which system is authoritative for stock?
• What happens when a callback arrives twice?
• How is a partial return represented?
• Who owns a delayed shipment or settlement difference?
• Can margin be reported after delivery and returns?

A realistic scenario

Example: the customer is charged but closes the page before returning to the store. A mature integration trusts the verified server callback, records the provider reference and moves the order once—without creating a duplicate or waiting for a screenshot.

Sources directly related to this guide

• Central Bank of Egypt — e-commerce payment acceptance
• Central Bank of Egypt — payment systems and services
• Egypt Consumer Protection Agency — invoice, return and replacement FAQ