Data Protection for Payment Information

A payment transaction can involve more personal data than a card number. Names, delivery addresses, phone numbers, email addresses, order history, device information, fraud signals, masked card references and refund records may all identify or relate to a person.

The restaurant should minimise what it receives, explain what it uses and protect the records throughout their life. This is separate from, but connected to, PCI DSS.

Identify the personal data in the payment process

Data	Typical purpose	Risk to control
Name, address and contact details	Delivery, collection updates, support and receipt delivery	Unauthorised marketing or excessive retention
Order history	Fulfilment, complaints, repeat-order features	Profiling without transparency or inappropriate staff access
Payment token or masked reference	Identify the transaction and support refunds	Treating a provider reference as harmless when it can still link to a person
Fraud indicators	Prevent payment abuse	Unfair automated decisions or opaque blacklisting
Refund and dispute evidence	Resolve a complaint or chargeback	Keeping excessive delivery, communication or device data

Financial information is not automatically special category data

Payment and financial information can be sensitive and damaging if misused, but it is not automatically “special category data” under UK GDPR. Do not use the wrong legal label. Instead, assess the real risk and apply appropriate security and retention controls.

Choose a lawful purpose for each use

Examples may include:

• processing necessary to take payment and fulfil the order;
• legal obligations for tax and accounting records;
• legitimate interests for proportionate fraud prevention or dispute handling, after an appropriate assessment;
• consent or the relevant soft-opt-in conditions for electronic marketing where applicable.

Do not rely on a single vague “consent to our privacy policy” statement for every purpose.

Minimise card data

• Use hosted or tokenised payment methods.
• Do not store full card numbers unless the approved payment design genuinely requires it and all obligations are met.
• Never retain card security codes after authorisation.
• Do not copy payment details into staff chats, email or spreadsheets.
• Use provider references for refunds and support.

Keep service messages separate from marketing

An email address used to send an order receipt or payment update is being used for a service purpose. It should not be added automatically to a promotional mailing list.

Where the takeaway wants to market to customers, provide a separate, clear preference and apply PECR as well as UK GDPR. Keep evidence of the choice and honour opt-outs across connected systems.

Retention by purpose

Different records can have different retention periods:

• transaction and tax records;
• customer account details;
• fraud evidence;
• chargeback evidence;
• support conversations;
• marketing preferences.

Document the reason for each period. Do not keep all payment-related data indefinitely merely because storage is cheap. Conversely, do not delete records needed for tax, legal claims or active disputes.

Access controls

• Limit payment reports to staff who need them.
• Give refund access separately from ordinary order access.
• Use individual accounts and multi-factor authentication.
• Hide unnecessary customer details from kitchen and driver screens.
• Review exports and downloads.
• Disable access promptly when staff leave.

Processors and other organisations

The ordering platform, gateway, marketplace, delivery provider and analytics service may each process customer information. Document:

• what each provider receives;
• its role under data-protection law;
• where data is stored;
• sub-processors;
• security commitments;
• retention and deletion;
• international transfers where relevant;
• incident notification;
• data export on termination.

Do not assume every marketplace is simply the restaurant’s processor. The legal roles depend on the actual purposes and contract.

Data-subject requests and corrections

Staff need a route to:

• locate customer records across systems;
• verify the requester’s identity proportionately;
• correct inaccurate contact or account information;
• apply deletion where appropriate while preserving records that must lawfully remain;
• record objections to marketing;
• avoid exposing another person’s order during support.

Personal-data breach response

1. Contain the incident and secure affected accounts.
2. Record what happened and when it was discovered.
3. Identify the data and people affected.
4. Assess the risk to individuals.
5. Contact relevant processors and payment providers.
6. Report to the ICO within 72 hours where the breach is notifiable.
7. Inform affected people where the legal threshold is met.
8. Document the decision even where no report is made.

Privacy notice checklist

• Restaurant identity and contact details.
• Payment and order data collected.
• Purposes and lawful bases.
• Recipients and provider categories.
• Retention information.
• Customer rights.
• Complaint route to the ICO.
• Marketing choice explained separately.
• Fraud and automated-decision information where relevant.

Related guides

• Payments — the main guide for the wider topic.
• Payment Security and Compliance — the broader guide that frames this implementation.
• PCI DSS Compliance for Restaurants — a closely related operational control to review alongside this page.
• Fraud Prevention for Online Orders — a closely related operational control to review alongside this page.

Official guidance checked

• ICO: special category data
• ICO: privacy notices for small organisations
• ICO: 72-hour breach response
• ICO: service receipts and direct marketing

Guidance checked: 24 July 2026. The restaurant should document provider roles and obtain professional advice for complex data-sharing or fraud decisions.