Taking payment online: what happens between the guest tapping pay and the money being yours

A guest taps Pay on your ordering page and sees a green tick. Somewhere behind that tick, four or five things had to go right, and one of them decides whether you actually have the money or merely have the guest’s permission to take it. Most arguments with a payment provider start because a restaurant assumed those were the same thing.

The gateway takes consent first, money second

Every card rail splits a payment into two moments:

1. Authorisation — the card issuer agrees the money exists and sets it aside.
2. Capture — the merchant says “take it now”, and it moves.

Some gateways collapse those into one step for you. Others do not, and hand you an order that is approved, funded, and entirely uncollected until you ask for it. PayPal works the second way: a guest who approves on PayPal’s page has consented to pay you, and nothing has left their account until the capture happens. Stripe Checkout, configured the ordinary way, does both for you.

This matters for one practical reason. If your system marks an order paid the moment the guest is redirected back, you will eventually serve food against approvals that were never captured — and you will find out at the end of the month, from your bank, not from your POS.

So the rule is simple and worth insisting on with any vendor: a sale is paid when the money moved, not when the guest came back.

Four rails, and what each is honestly for

Fawry is the odd one and the useful one: it does not take a card at all. It issues a code, the guest pays it at a kiosk or a pharmacy, and the confirmation comes back to you afterwards. For a market where a large share of people hold no card, that is not a fallback — it is the main road.

Cash and the card terminal on your counter are still the other two rails, and they do not involve a gateway at all. They are recorded at the till and reconciled against the drawer at the end of the shift.

Your currency picks the gateway, not your preference

This is the part that surprises people, so it is worth stating plainly: a payment provider settles in a fixed list of currencies, and if yours is not on the list, no amount of configuration helps.

Paymob and Fawry settle in Egyptian pounds. They are the right answer in Cairo and irrelevant in Madrid. Stripe reaches almost everywhere. PayPal reaches a great deal of the world but does not take Egyptian pounds at all, nor riyals, nor dirhams — so an Egyptian restaurant pricing its menu in EGP cannot put PayPal behind its checkout, however much it might want to.

A good system tells you this at setup rather than at the first failed order. A restaurant pricing in euros should simply not be offered the Egyptian rails; one pricing in pounds should not be quietly allowed to configure a provider that will refuse its first transaction.

If you operate in more than one country, price each branch in its own currency and let each branch carry its own provider. Which leads to the next thing people get wrong.

Branch keys are not head office keys

A payment provider’s credentials belong to a merchant account, and a merchant account settles into one bank account in one currency.

So when a group has a branch in another country, that branch cannot inherit the head office’s gateway credentials — not as a policy decision, but as an arithmetic one. The keys would point its guests at a processor that cannot take its money.

The sane arrangement: a branch pricing in the same currency as the restaurant inherits its settings and needs no separate setup. A branch pricing in a different one keeps its own credentials, its own callback address, and its own settlement. Ask any vendor how they handle this before you open the second country, not after.

The webhook is the confirmation

When a guest finishes paying, two things happen independently:

• their browser is redirected back to your page, and
• the provider sends your server a signed notification saying what happened.

Only the second one is trustworthy. A browser redirect can be interrupted by a dropped connection, a closed tab, a dead battery, or a guest who simply pressed back — and in every one of those cases the money may well have moved anyway. Worse, a redirect is a URL, and a URL can be typed.

The signed notification — the webhook — is the provider telling your server, server to server, with a signature you verify, that the payment settled. That is the event that should mark the order paid, release the ticket to the kitchen, and appear in the day’s takings.

Two practical consequences:

• Your callback address must be reachable from the internet. A webhook is an inbound request. It does not work against a laptop on a café WiFi, which is why a test that passes on a developer’s machine can fail in production.
• The provider will send the same event twice. Networks lose acknowledgements, and every serious provider retries. Paying attention to this is what stops a single order being recorded as two payments.

Refunds run backwards down the same rail

A refund is not a transfer back — it is an instruction to the original rail to reverse a specific charge. That means you can only refund through the provider that took the money, and you generally need the reference of the exact capture rather than the order.

Two things follow. First, cash refunds and gateway refunds are different operations and should look different in your reports, because one empties a drawer and the other adjusts a bank settlement. Second, a partial refund has to be attached to the charge it reverses, or your reconciliation will never close.

What actually loses the order

In practice, online payment fails for dull reasons rather than exotic ones:

• The amount is right but the currency is not. The provider refuses, and the guest sees an unexplained error.
• The redirect URL is an app link rather than a web address. Some providers accept only ordinary https addresses and reject the rest outright — the order is never even created.
• Nobody set the webhook up. Payments succeed, guests are charged, and nothing in the restaurant knows. This is the single most common failure, and it is silent.
• The test keys were never swapped for live ones. Everything works beautifully and no money ever arrives.

None of these are clever problems. They are checklist problems, which is exactly why they should be on a checklist — and why a connection test that actually calls the provider, rather than just saving your keys, earns its place on the settings screen.

The short version

Offer the rails your guests actually use, price each branch in the currency it settles in, let the webhook — not the redirect — decide when an order is paid, and test with live keys before you tell anyone the page is open. The rest is configuration.