Payment Gateway Fundamentals

A payment gateway connects the takeaway’s checkout to the organisations that authorise and settle a card or wallet payment. The customer sees one payment button, but the restaurant depends on several linked steps: the order system creates the payment request, the provider processes it, the customer’s bank approves or declines it, and a result returns to the order system.

The practical question is not simply whether the gateway can take money. It is whether the complete payment and order flow remains accurate during normal service, busy periods and failure.

The organisations in a card payment

Party	Operational role
Restaurant	Sells the order, sets the price, fulfils it and manages the customer outcome
Ordering system	Builds the basket, sends the payment request and creates the order record
Payment gateway or PSP	Provides the technical payment service and transaction reporting
Acquirer	Provides merchant acquiring and receives card transactions for the restaurant
Card scheme	Operates the network and scheme rules
Issuer	The customer’s bank or card provider, which authorises or declines the payment

A supplier may combine several of these roles or use partners. Ask who holds the merchant agreement, who provides support and which organisation appears on statements and bank deposits.

Authorisation, capture and settlement

These terms describe different stages:

Authorisation: the issuer approves the payment request or declines it.
Capture: the provider submits the authorised amount for processing under the configured flow.
Settlement: the net money is transferred to the restaurant’s bank account.
Refund: an amount is returned through the payment route.
Chargeback: a disputed card transaction is reversed through the card-scheme process.

Do not label all these states simply “paid”. Staff need to know whether the customer was charged, whether the order was accepted and whether the money was settled.

Hosted and embedded checkout

Approach	Operational benefit	What to verify
Redirect to a hosted payment page	Payment data is entered on the provider’s page	Mobile journey, return to the order confirmation, branding, failure handling and PCI scope
Hosted fields or iframe	Payment fields appear within the restaurant checkout but are provided by the payment service	Supported implementation, scripts, browser security, error handling and validation requirements
Direct integration	Greater control over the checkout experience	Substantially greater technical and security responsibility; suitable expertise is required

Do not assume that using a hosted component makes the restaurant automatically compliant. Confirm the applicable PCI DSS validation method with the acquirer or payment provider and maintain the restaurant website securely.

Order creation must depend on a reliable payment result

Define exactly what happens when:

the payment succeeds normally;
the customer closes the browser;
the provider response is delayed;
the payment succeeds but the order callback fails;
the customer taps the payment button twice;
the customer retries after an uncertain result;
the restaurant rejects an already authorised order.

Use a unique order and payment reference. Before charging again, staff should search the provider dashboard and order system. A duplicate payment created during a busy shift is not a minor technical issue; it creates immediate customer distrust and additional refund work.

Payment methods

A gateway may support:

debit and credit cards;
Apple Pay and Google Pay;
other wallets;
pay-by-bank or open-banking options;
stored payment tokens for returning customers;
card-present terminals through a connected provider.

Offer methods because customers use them and the operation can support them, not because the provider’s feature list is long. Each method needs clear reporting, refund handling and testing.

Fraud and authentication

The payment provider may apply authentication, fraud screening and risk rules. The restaurant should understand:

when the customer may be asked for additional verification;
how declined and challenged payments appear;
whether high-risk orders can be reviewed or are automatically rejected;
which evidence is available if a dispute occurs;
how delivery address, device or behavioural signals are used;
how fraud controls affect legitimate repeat customers.

Do not weaken security controls simply to reduce checkout friction. Instead, measure genuine payment failures and work with the provider on configuration.

Settlement and cash flow

Ask the provider to document:

settlement frequency;
cut-off times and weekends;
fees deducted before settlement;
minimum payout thresholds;
reserves or temporary holds;
negative balances after refunds or chargebacks;
the bank statement reference;
how settlement reports can be exported.

A fast payout is only useful if it can be reconciled. The provider should expose the gross transactions, fees, refunds, disputes and net amount behind each deposit.

Refund capability

Check whether the gateway supports:

full and partial refunds;
multiple partial refunds up to the available amount;
role-based staff permissions;
a reason and audit note;
refund status reporting;
webhooks or order-system updates;
clear treatment of the original processing fee;
refunds after the original transaction has settled.

The restaurant should not promise when the customer’s bank will display the credit unless the provider gives a reliable range. Confirm that the refund was submitted and give the customer a reference or written record where available.

Reporting and reconciliation

The minimum useful export includes:

restaurant order reference;
provider transaction reference;
created date and time;
authorised, captured, refunded and disputed amounts;
payment method;
fees;
settlement identifier;
net payout date;
status and reason codes.

Test that these references travel through the ordering system, payment dashboard and accounting process. If staff must match orders by customer name and rounded total, the integration is not operationally complete.

Support and incident response

Ask who supports the restaurant when:

all online payments fail;
one payment method stops working;
payments succeed but orders do not appear;
a refund remains pending;
a settlement is missing;
the account is placed under review;
a security incident is suspected.

Record the ordering supplier, payment provider and acquirer contact routes. During an incident, staff should not have to discover which company owns the problem.

Gateway acceptance checklist

Run successful and declined test payments on mobile and desktop.
Interrupt the checkout and confirm the recovery behaviour.
Attempt a duplicate submission.
Process a partial and full refund.
Verify the order and payment references in every report.
Reconcile a real settlement to the bank.
Confirm staff permissions and multi-factor authentication.
Document the fallback when the provider is unavailable.
Confirm PCI DSS responsibilities with the provider or acquirer.

Related guides

Payments — the main guide for the wider topic.
Choosing a Payment Gateway for Online Orders — a detailed next step for putting this guidance into practice.
Payment Methods for Takeaway Ordering — a detailed next step for putting this guidance into practice.
Marketplace Payments and Commission — a closely related operational control to review alongside this page.
Payment Security and Compliance — a closely related operational control to review alongside this page.

Official guidance checked

Guidance checked: 24 July 2026. Gateway features, authentication, fees and settlement terms must be verified in the current provider agreement and technical documentation.