The store is built. Launch is in two weeks. Somebody asks which payment methods it will accept, and the answer sounds like a one-line decision: cards, obviously, and cash on delivery because everyone does that.
It is not a one-line decision. Every method you switch on lands somewhere in your operation and stays there. Cards bring you disputes, refunds and a settlement report to reconcile. Cash on delivery brings you a courier holding your money, a return rate and a working-capital gap. Instalments bring you a second contract and a second set of statuses. Wallets bring you a flow that happens on the customer's phone, outside your control. The checkout button is the smallest part of any of it.
What follows is the practical shape of those decisions for a store selling in Egypt, what changes when the Gulf is added, and what a payment integration actually involves once you get past the demo.
The methods, and what each one drags behind it
Cards. Visa and Mastercard, and in Egypt also the national scheme, Meeza, which a substantial number of people hold and which you should not assume is covered by "we accept cards". Card payments settle to you in a batch, not per order, so you get a settlement report and a reconciliation job. They also bring chargebacks: a customer disputes a charge through their bank, you are asked for evidence, and somebody in your business has to be the person who assembles it.
Mobile wallets. In Egypt the telecom wallets are a second rail with real volume. The flow is not a card flow: the customer gives a mobile number, and the confirmation happens on their phone with a wallet PIN and a one-time code. That matters practically, because the customer leaves your checkout, and a percentage of them do not come back to it — which is a user-experience problem and a reporting problem at once.
Cash collected at an outlet. A reference code issued at checkout and paid in cash at an agent, kiosk or shop, valid for a period rather than indefinitely. It converts an online order into a deferred payment with an expiry, so your order system needs a pending state, a timer, and a rule for what happens to reserved stock when the code lapses.
Instalments and buy-now-pay-later. A real and now mainstream category in Egypt, offered through several providers, and separately through instalment plans on the customer's own bank card. Each provider is a separate integration, a separate approval decision made about your customer by someone other than you, and a separate settlement stream. The order can be approved by you and declined by them.
Cash on delivery. Treated below, because it is not really a payment method.
I am not going to give you a percentage split between these. The published figures for Egypt disagree with each other badly — different sources measure share of orders against share of value, and arrive at numbers that cannot all be true. What is safe to say is the direction: cash on delivery has historically dominated online purchases in Egypt, and its share has been falling as cards, wallets and instant transfers spread. Plan for a mix that shifts, not for a fixed ratio.
Instant bank transfer deserves a specific caution. Egypt's instant payment network is real and growing fast, and plenty of stores accept a transfer to a published handle. But accepting a transfer that way is a manual reconciliation method, not an integrated payment: nothing tells your system that the order is paid. Automated integration exists in places and is expanding, so ask your provider directly whether they offer it as a confirmed, notified payment method rather than as an instruction printed at checkout.
Cash on delivery is a credit product
COD is the method most stores treat as free and most stores are wrong about.
The customer takes delivery before paying. Between the order and the money you have: stock committed, a delivery paid for, a courier holding cash, and a customer who can decline at the door. Orders placed with no money down are refused more often than prepaid ones — the industry agrees on the direction even though the published rates vary too much to quote — and every refusal is a round trip you paid for twice.
Then the money comes back to you in a courier's remittance cycle, per merchant, in a batch, days after the deliveries. Which means a reconciliation that nobody scopes: for each remittance, which orders it covers, which orders were collected but not yet remitted, which were returned, and which have a discrepancy between the amount on the waybill and the amount handed over.
Architecturally, this is why a COD order cannot share a state machine with a prepaid one. A prepaid order is paid, then fulfilled. A COD order is confirmed, dispatched, attempted, collected, remitted, reconciled — or returned at any point along that line. Systems that force COD into the prepaid states end up with orders marked paid that nobody has been paid for. If you are also running your own deliveries, that reconciliation and the courier's own view of it have to agree; a delivery system that tracks status but not collections solves half the problem.
Cash on delivery is not a way of taking payment. It is a way of extending credit to a stranger and paying someone to go and collect it.
The Gulf is several markets
If you plan to sell into the Gulf, the first thing to absorb is that "the Gulf" is not a payment market. Each country has its own domestic scheme that carries most local debit traffic: mada in Saudi Arabia, KNET in Kuwait, Benefit in Bahrain, OmanNet in Oman, NAPS in Qatar alongside its newer Himyan debit card, and in the United Arab Emirates the newly launched national scheme, Jaywan, which is being rolled out to banks and merchants and whose acceptance is still widening. These schemes are interlinked regionally, which matters for cross-border acceptance, but they are not interchangeable with international card acceptance and they are not all reachable through any one provider.
Wallets and instalments differ by country too. Apple Pay and Google Pay are established payment habits in Saudi Arabia, alongside local wallets; the instalment providers that dominate in Saudi Arabia and the Emirates are not the ones you integrated in Egypt.
The second thing to absorb is structural and more expensive than the technical work. Accepting local payment methods in Saudi Arabia or the Emirates normally requires a local legal presence: a commercial registration or trade licence, corporate documents, and a corporate bank account in that entity's name for the provider to settle into. A store registered only in Egypt generally cannot simply switch on a Saudi gateway and accept mada. Some multi-country providers market cross-border acceptance, and it is worth asking about, but treat local incorporation as the default requirement rather than the exception, and get the answer in writing before you plan a launch date around it.
This is also where regulation sits. Payment providers are licensed by the central bank in each of these countries, and Egypt's framework for licensing payment service providers was tightened recently with a transition period for existing operators. The practical consequence for you is narrow but real: ask a provider what licence it currently holds and in which market, rather than assuming the company you used two years ago stands in the same position today.
What you are actually contracting with
There are two shapes of relationship and they are easy to confuse.
In the first, the provider aggregates you under its own arrangements. You sign up quickly, the provider receives the money and passes it on to you on a cycle. This is how most small and mid-sized stores in the region operate, and it is the pragmatic choice. The consequence is that the provider sits between you and your money, and its terms, its settlement timetable and its risk decisions become yours.
In the second, you hold your own merchant account with an acquiring bank and the gateway is only the technical route to it. More work to obtain, more accountable, and generally only worth pursuing at volume.
Either way, ask the questions that determine how the arrangement behaves when something goes wrong, not when it goes right: how long between a sale and the money arriving; what happens to a disputed transaction while it is disputed; under what circumstances a payout can be held, and who decides; what the refund mechanism costs you in time; and what the exit looks like if you change provider — specifically, whether saved card tokens can be migrated, because if they cannot, every returning customer has to enter a card again.
What the integration actually involves
The demo is a redirect and a success page. The work is everything around it.
Where the card data is typed decides your compliance scope. Three shapes, and the difference is not cosmetic:
| Shape | What it is | Your compliance burden | Trade-off |
|---|---|---|---|
| Hosted payment page | The customer leaves your site for the provider's page and comes back | Smallest; card data never touches your systems | Least control over the experience, and a visible jump out of your brand |
| Embedded frame or provider SDK | A field on your page, served by the provider, that you never read from | Small, but easy to enlarge accidentally with scripts on the same page | Good balance for most stores |
| Your own form, card data through your servers | You collect the card and pass it on | Largest by a wide margin, with the full self-assessment and the controls behind it | Only worth it at scale, with people who own that responsibility |
Most stores should be in the first two rows, and most stores that think they need the third do not.
Authentication happens, and sometimes visibly. Card payments are authenticated to the issuing bank, which may approve silently on the strength of the data sent with the transaction, or may challenge the customer for a code or an approval in their banking app. Both outcomes are normal. Your checkout has to handle a challenge appearing mid-payment, and your support team has to know why some customers see one and others do not.
Saved cards are tokens. For repeat purchases the provider gives you a token that stands in for the card; you store the token and never the number. Useful, and one of the places where changing provider later becomes painful, as above.
The webhook is the truth. The customer's browser returning to your success page is a user-experience event, and it can fail for reasons unrelated to the payment: the connection drops, the phone locks, the customer closes the tab after paying. The authoritative record is the server-to-server notification the provider sends you. Orders should be confirmed from that notification, and the notification must be verified, handled more than once safely, and reconciled if it never arrives.
Do not charge twice. Requests time out with the outcome unknown. Retrying without an idempotency key is how a customer is charged twice for one order, and the fix is always harder than the prevention.
Refund, void and partial capture are three different things. Cancelling before the money has moved is not the same operation as returning money that has moved, and shipping half an order is a partial capture rather than a refund. A system that only implements "refund" will do the wrong thing in two of those three cases.
Sandbox is not production. Every provider gives you test credentials and test cards. Nothing about the sandbox tells you how the live system behaves at eleven at night during a sale, and the first week live is when you find out.
The reconciliation nobody scopes
By the end of the first month you have at least three sets of numbers that must agree: what your store says was ordered and paid, what each provider's settlement report says was captured and paid out, and what your bank statement says arrived. Add couriers' COD remittances, each instalment provider's own stream, and refunds that cross a settlement boundary, and the month-end becomes a real job.
Build the reconciliation with the store, not a year later. It is a small amount of work while the data model is being decided and an unpleasant amount afterwards, and it is the only thing that tells you whether you have actually been paid. This is also where payments meet the accounting system: every one of these events is an entry, and in Egypt every sale is a document the tax authority expects to see — what a compliant accounting system has to do covers that side.
When to use more than one provider
Two reasons, both legitimate. Coverage: no single provider gives you Egyptian wallets, Egyptian instalments, Saudi and Emirati local schemes and international cards on one contract, so selling across markets usually means more than one. And resilience: a single provider having a bad hour is a bad hour for your revenue.
The cost is that each provider is another integration, another reconciliation, another set of statuses and another support relationship. Orchestration — a layer that routes between providers behind one integration of your own — exists for exactly this and is worth it once you genuinely have several. Adopting it before you do is buying a solution to a problem you do not yet have.
Which is the general shape of the advice here. If you sell a modest number of orders a week in one country, a hosted checkout from one local provider plus cash on delivery is the entire correct answer, and anyone proposing a payments architecture to you is overselling. The work described above starts to matter when you have volume, more than one market, or money moving between parties — a marketplace paying sellers, a platform holding a deposit — which is a different kind of system altogether.
Questions worth asking before you commit
- Which methods do you support for my market specifically — cards, the local scheme, wallets, instalments, cash at outlets — and can I see each one working?
- Am I contracting as an aggregated merchant, or do I need my own merchant account with a bank?
- What licence do you hold, in which market, and does it cover the settlement you are describing?
- How many days between a captured sale and money in my account, and what delays that?
- Under what circumstances is a payout held, and who inside your company decides?
- What does the dispute process require from me, and in what time?
- Can saved card tokens be exported if I move to another provider?
- What does the settlement report contain, in what format, and can it be retrieved automatically?
- What do I need in order to accept payments in each Gulf market I am targeting — entity, registration, bank account?
- Show me the sandbox, the test cards, and the webhook payloads before I sign anything.
Question seven is the one most often skipped and the one most expensive to discover late. For the rest of what to check in a supplier who will build this, how to choose a software company applies here too.
Before you switch anything on
Decide the methods first, then the order states they imply, then the reconciliation, and only then the integration. Softwiro builds commerce platforms where payment, orders, delivery and the ledger are one system rather than four that are kept in step by hand — contact us if you want that mapped for your store before anyone writes code.