Running a Restaurant POS in Egypt: Local Payments, EGP Pricing and What to Check

Most restaurant software is written for a card-and-cash till and treats everything else as an edge case. In Egypt, everything else is a large part of the business.

The till sees more than cash and card

A typical Egyptian restaurant collects payment through several rails on the same shift: cash, a card terminal, and one or more mobile wallets — Instapay, Vodafone Cash, Etisalat Cash, Orange Cash — plus Fawry for guests who prefer to settle at a kiosk or through their banking app. A POS that only has “cash” and “card” as options forces the cashier to lump a wallet payment into “cash,” which quietly breaks the end-of-day reconciliation the moment the bank statement and the drawer stop matching.

The fix is not complicated: the payment method on each order should be its own field, not a guess. GoSufra records Cash, Card, Instapay, Vodafone Cash, Etisalat Cash, Orange Cash and Fawry as distinct methods on the order itself, so the shift report breaks sales down by the rail that actually moved the money, and a manager can see which wallet a slow settlement came from instead of arguing about it later.

Two ways to actually take a payment

Recording a method is different from collecting one. For guests who pay online — a QR-menu order, a delivery order, or a subscription payment for the restaurant’s own account — GoSufra’s Egyptian plan settles through Paymob or Fawry, the two gateways built for the Egyptian market rather than routed through a foreign processor with a currency conversion in the middle.

EGP pricing, not a converted quote

A plan quoted in dollars and converted at whatever the card network’s rate is that day is not the same thing as a plan priced in Egyptian pounds. GoSufra keeps a separate Egyptian price list, billed in EGP through Paymob, rather than treating Egypt as one more country to convert a US price into. If you are comparing software, ask the vendor directly: is the number on the page what the bank statement shows, or does the actual charge move with the exchange rate every month?

The e-receipt system is not optional, and it is not static

Egypt’s Tax Authority runs a mandatory electronic invoice system for business-to-business transactions and a separate, phased electronic receipt system for point-of-sale retail transactions, including restaurants — each sale is meant to be reported with a signed, sequential record rather than only printed on paper. The phase-in has covered businesses in stages by size and sector, and the exact threshold and timeline for the current phase changes as the rollout continues.

This is worth saying plainly: nothing here is a substitute for confirming your restaurant’s current obligation with your accountant or through the Tax Authority’s own channels. What a POS can and should do regardless of the current phase is keep every sale numbered sequentially with no gaps, print the tax registration number on the receipt, break tax and service charge out as their own lines, and make the full sales and tax detail exportable rather than locked inside a monthly PDF. That is the groundwork any e-receipt connector needs; a system that cannot produce clean, gapless, itemized sales data cannot be made compliant by adding an integration on top of it.

A short checklist before you commit

• Does the POS let you tag a sale by the exact payment method the guest used, including the wallets your guests actually carry?
• Is the Egyptian price a real EGP price, or a converted one that moves with the exchange rate?
• Which gateway actually processes an online payment — one built for Egypt, or a foreign processor with an extra currency hop?
• Can you export sequential, itemized sales and tax data without gaps, for the month your accountant needs it?
• Who is responsible for the e-receipt integration itself — the POS vendor, a middleware provider, or you — and does that match what you were told when you bought it?

A restaurant in Cairo or Alexandria does not need software built for a different market and patched for this one. It needs software that already assumed Egypt when it was built.