Payments

Payments are not a separate back-office topic. They connect the customer’s checkout, the order ticket, the kitchen, refunds, marketplace statements and the money that eventually reaches the bank. A reliable payment setup lets staff answer five basic questions for every order: was it authorised, was the order accepted, what amount should be received, what deductions apply, and has the money arrived?

This guide maps the main payment decisions for an independent UK takeaway. Provider features, fees and settlement rules change, so use current contracts and statements rather than assumed market averages.

Map the payment flow before choosing tools

The customer chooses delivery or collection and reviews the full price.
The ordering system sends the payment request to a payment service provider or marketplace.
The payment is authorised, declined or left in an uncertain state.
The ordering system decides whether a kitchen ticket should be created.
The provider captures or confirms the payment under its configured flow.
Fees, refunds, chargebacks and adjustments are recorded.
The provider or marketplace settles a net amount to the restaurant.
The restaurant reconciles orders, statements and bank deposits.

A payment marked successful in one dashboard is not enough. The restaurant must also know whether the order reached the kitchen, whether it was fulfilled, and whether the expected settlement arrived.

The main payment models

Model	Who takes the payment?	What the restaurant must control
Direct website or app	The restaurant’s chosen payment provider, through the ordering system	Gateway integration, checkout, refunds, settlement, fraud controls and reconciliation
Marketplace	The platform under its own commercial and payment arrangement	Partner terms, deductions, payout reports, complaint allocation and adjustments
Card-present collection	The restaurant’s terminal provider	Terminal availability, end-of-day totals, refunds and matching terminal batches to the till
Cash	The restaurant or driver	Change, till controls, driver handover, failed delivery exposure and end-of-shift reconciliation
Mixed payment operation	Several providers	A common order reference and channel-by-channel records

Payment status and order status are different

Define separate statuses for:

payment initiated;
payment authorised;
payment failed;
payment outcome unknown;
order received;
order accepted;
order rejected;
refund requested;
refund submitted;
refund confirmed;
chargeback or dispute opened.

This separation prevents two costly errors: preparing food for a payment that did not complete, and charging a customer without creating a visible order. The ordering supplier should explain how duplicate submissions, delayed callbacks and interrupted browser sessions are handled.

Choose a gateway around the whole operation

Do not choose on the headline transaction rate alone. Check:

compatibility with the ordering system, POS and accounting process;
support for the payment methods customers actually use;
how hosted checkout or embedded payment fields affect security responsibilities;
payment status handling when the internet connection or provider response is delayed;
refund permissions and audit history;
settlement frequency and reserve or hold conditions;
report exports and stable order references;
support hours during the restaurant’s trading periods;
contract, termination and data-export arrangements.

Show the customer the real price

Delivery charges, service fees, minimum-order effects and other unavoidable costs should not appear as a surprise at the final payment step. The customer should be able to understand the payable total before committing to the order. Optional extras should not be preselected without a valid reason and clear choice.

Price presentation is also an operational control. When fees and minimums are unclear, the restaurant receives more abandoned baskets, complaints and refund requests.

Understand the full cost of payment

Build a provider comparison from the following categories:

percentage charge;
fixed transaction charge;
monthly or platform fee;
terminal rental or hardware;
refund treatment;
chargeback or dispute fees;
currency or premium-card treatment where relevant;
integration and support costs;
reserve, hold or delayed-settlement impact;
staff time spent resolving mismatches.

Calculate the effect on real basket sizes. A fixed per-transaction fee has a larger proportional effect on a low-value order than on a large one. Label every example as illustrative and replace it with current provider figures before making a decision.

Marketplace money needs separate controls

A marketplace statement may combine:

completed orders;
commission or service charges;
delivery-related deductions;
restaurant-funded promotions;
refunds and customer adjustments;
previous-period corrections;
tax documentation;
the net payout.

Do not treat the bank deposit as sales revenue. Reconcile the gross order value, each deduction and the final payout. Where the provider’s role, tax treatment or refund allocation is unclear, use the current agreement and obtain professional accounting advice rather than inferring the answer from the dashboard label.

Refunds and chargebacks are not the same

A refund is normally initiated by the restaurant, marketplace or payment provider in response to a cancellation, service failure or agreed remedy. A chargeback is a card-scheme process initiated through the customer’s card issuer. It can remove funds from the merchant and may include a separate fee.

Keep evidence that explains:

what was ordered;
the price and terms shown;
payment authorisation;
order acceptance;
preparation and handover;
delivery or collection outcome;
customer contact;
any refund or replacement already provided.

Do not use a blanket “no refunds” statement. Prepared food may be treated differently from ordinary online retail goods, but customers still have rights where goods are faulty, not as described or the business has not supplied what was agreed. Escalate unclear legal cases rather than relying on a short website policy.

Payment security is a shared responsibility

Using a payment provider does not remove every responsibility from the restaurant. Confirm the applicable PCI DSS validation route with the acquirer or payment provider. Avoid storing full card details, restrict access to payment and refund functions, use individual staff accounts, enable multi-factor authentication where available, review third-party scripts on checkout pages and keep devices and software supported.

Staff should never ask a customer to send full card details by email, text or social media. Telephone payments, if accepted, need a provider-approved process rather than handwritten card information.

Daily and weekly reconciliation

Daily

Compare completed orders with payment totals by channel.
Check failed, duplicated and unknown-status payments.
Confirm refunds submitted during the shift.
Match cash and terminal totals to the till.
Log unexplained differences with an owner and deadline.

Weekly or by settlement period

Match provider and marketplace statements to bank deposits.
Review all fees and adjustments.
Confirm that refunds and chargebacks are recorded in the order system.
Investigate missing payouts and old unresolved items.
Export records required for bookkeeping and VAT.

Payment failure plan

Failure	Immediate control	Customer message
Payment declined	Do not create a confirmed kitchen order unless the system clearly supports another payment route	Explain that payment was not completed and offer a safe retry or alternative
Payment outcome unknown	Search by order reference before asking the customer to pay again	Say that the status is being checked; do not imply that no money was taken
Gateway unavailable	Pause affected online checkout or switch to an approved fallback	Show the unavailable method and any genuine alternative
Order paid but not received by kitchen	Create a controlled recovery ticket only after verifying the payment and avoiding duplication	Confirm the order manually and provide a realistic time
Refund cannot be submitted	Record the case, provider error and promised follow-up	Explain the next step without promising a bank-credit date you do not control

What to measure

payment acceptance and failure rate by method;
duplicate or unknown-status incidents;
refund value and root cause;
chargeback volume and reason;
payment cost by channel and basket size;
settlement delays;
unreconciled value and age;
support cases caused by payment or payout issues.

Related guides

Channel Profitability — a detailed next step for putting this guidance into practice.
Marketplace Payments and Commission — a detailed next step for putting this guidance into practice.
Online Ordering — a closely related operational control to review alongside this page.
POS and Kitchen Systems — a closely related operational control to review alongside this page.
Business Planning and Finance — a connected decision that can change the recommended approach.
Restaurant Marketing and Customer Retention — a connected decision that can change the recommended approach.

Official guidance checked

Guidance checked: 24 July 2026. Provider fees, card-scheme procedures, settlement timing and marketplace deductions are contract-specific and must be checked against current documentation.