Payment Security and Compliance

Payment security is not achieved by adding a padlock icon or choosing a familiar provider. It depends on the full route from the customer’s browser or terminal to the payment service, the staff accounts that can issue refunds, the devices used in the restaurant and the records retained afterwards.

This hub explains the controls an independent UK takeaway should understand. It does not replace the payment provider’s PCI DSS validation instructions, the acquirer’s requirements or professional data-protection advice.

Map every way the restaurant accepts payment

Payment route	Main security questions
Hosted online checkout	Who hosts the payment page, what scripts run on the restaurant website, and which SAQ route applies?
Embedded payment fields	How is the third-party form integrated and protected from unauthorised script changes?
Card terminal	Is the device approved, physically inspected, supported and linked to the correct merchant account?
Telephone payment	Can staff use a provider-approved method without writing down card data?
Marketplace	Which payment and customer-data responsibilities sit with the platform and which remain with the restaurant?
Cash	How are till access, driver cash and end-of-shift reconciliation controlled?

Reduce the payment-data footprint

The safest card data is data the restaurant does not receive or store. Prefer provider-hosted or tokenised methods that keep sensitive account data out of the restaurant’s ordinary systems.

Never request full card details by email, SMS or social media.
Do not write card numbers or security codes on paper.
Do not store card verification codes after authorisation.
Do not place full account data in POS notes, support tickets or spreadsheets.
Use tokens or provider references for repeat payments where supported.

PCI DSS responsibilities remain

Outsourcing card processing can reduce the restaurant’s scope, but it does not automatically remove PCI DSS obligations. The applicable validation route depends on how payments are accepted and integrated. Confirm it with the acquirer or payment provider rather than choosing a Self-Assessment Questionnaire from a blog post.

For e-commerce, current PCI guidance also places attention on payment-page scripts and protection against unauthorised changes. Even a restaurant that outsources account-data functions needs to understand whether its own website can affect the security of the payment page.

Control staff access

Give each employee an individual account.
Use role-based permissions for refunds, reports and configuration.
Enable multi-factor authentication where available.
Remove access promptly when a person leaves or changes role.
Review high-value refunds and manual payment changes.
Keep an audit history showing who did what and when.

Shared manager PINs make investigation difficult and allow former staff to retain access.

Protect devices and networks

Keep POS terminals, tablets, printers, routers and payment devices supported and updated. Separate guest Wi-Fi from operational systems, restrict remote access and document who maintains each device.

Staff should check terminals for unexpected damage, replacement labels, loose parts or unfamiliar cabling. Any suspected tampering should trigger the provider’s incident process rather than continued use.

Prevent common online-payment failures

Use duplicate-submission controls.
Do not create a confirmed order from an unknown payment outcome.
Search by transaction reference before asking the customer to pay again.
Protect API keys and webhook secrets.
Verify that refund notifications cannot be forged.
Monitor changes to checkout scripts and integrations.
Test provider outages and delayed callbacks.

Fraud controls must fit the operation

Strong fraud controls should reduce loss without rejecting legitimate customers unnecessarily. Review:

address and postcode mismatches;
unusual order value or frequency;
repeated failed attempts;
high-risk delivery instructions;
account takeover indicators;
chargeback patterns by channel and reason.

Do not publish the restaurant’s internal fraud thresholds. Escalate suspicious orders through a defined process rather than asking front-line staff to improvise.

Personal data and payment data

Names, addresses, contact details, order history, device information and masked payment references can be personal data. Financial information may be sensitive in the ordinary sense, but it is not automatically “special category data” under UK GDPR.

Use a clear privacy notice, retain only what is needed, restrict access and keep service receipts separate from marketing preferences.

Incident response

Contain the affected account, device or integration.
Preserve logs and evidence.
Contact the payment provider, acquirer or platform through its incident route.
Assess whether personal data was affected.
Record the decision on notification.
Report a notifiable personal-data breach to the ICO without undue delay and within the applicable 72-hour period.
Communicate with affected people where required.
Fix the root cause before restoring normal access.

Not every security event is reportable, but every suspected incident should be assessed and documented.

Supplier questions

Which PCI DSS validation route applies to this setup?
Who hosts and controls the payment page?
What evidence of PCI DSS compliance is available?
How are payment-page scripts monitored?
How are terminals replaced and inspected?
What fraud controls are configurable?
How are refunds authorised and logged?
What is the security-incident contact route?
How can data and audit logs be exported?

Related guides

Payments — the main guide for the wider topic.
Data Protection for Payment Information — a detailed next step for putting this guidance into practice.
Fraud Prevention for Online Orders — a detailed next step for putting this guidance into practice.
Payment Gateway Fundamentals — a closely related operational control to review alongside this page.
Receipts and Reconciliation — a closely related operational control to review alongside this page.

Official guidance checked

Guidance checked: 24 July 2026. PCI DSS scope and incident obligations depend on the restaurant’s actual systems and provider relationships.