Card-Linked Loyalty in the UK: A Guide for PSPs and Retailers

Card-linked loyalty connects an enrolled payment credential to a loyalty account or offer so an eligible payment can trigger points, cashback or another reward without a separate scan at checkout. In the UK, the design must distinguish payment references from people, control PCI DSS exposure, establish a UK GDPR lawful basis and assess PECR separately for electronic marketing.

What is card-linked loyalty in the UK?

Card-linked loyalty associates an enrolled debit card, credit card or supported wallet presentation with a loyalty account or offer. An authorised participant in the payment or programme stack matches a qualifying transaction against the programme rules and records or delivers the reward.

It solves the forgotten-loyalty-card problem because the enrolled payment credential can perform the recognition step. However, card-linked does not always mean app-free, automatic or consent-free. A bank app or portal may still be needed to discover and activate an offer. American Express UK, for example, requires an Amex Offer to be saved to a specific eligible card before purchase.

Card-linking is a lower-friction recognition method, not a guarantee of more repeat visits. Programme economics, customer adoption, reward relevance and merchant context still determine the outcome. The defensible promise is that an enrolled payment reference can recognise a returning payment credential without a separate scan. It does not identify the person holding the card.

Which card-linked loyalty terms must teams define first?

Card-linked offer (CLO)

An offer attached to an enrolled payment credential. A qualifying purchase can trigger cashback, points or another benefit under the programme terms.

Payment-linked loyalty

A broader category in which payment events contribute to recognition, earning or redemption, sometimes alongside a merchant customer reference.

Terminal-resident SDK

Software deployed within or alongside the payment application on a payment terminal. It can support approved enrolment, progress and reward interactions during checkout.

Primary account number (PAN)

The card number associated with a payment account. PCI DSS treats PAN as cardholder data.

Payment token

An alternative value that replaces PAN within a defined token domain. EMVCo explains payment tokenisation, but a token is not necessarily portable across providers, merchants, devices or channels.

Payment Account Reference (PAR)

An EMVCo reference that can link PAN and payment-token transactions in supported implementations. EMVCo includes merchant loyalty among its PAR use cases, subject to availability and permitted use.

Provider-specific alias

A reference created by an acquirer, PSP, gateway, processor or merchant vault. Its stability is limited to the provider's domain and contract.

Pseudonymisation

Separating identifiers from additional information. The ICO confirms that pseudonymised data can remain personal data.

A token is not anonymous, globally stable or equivalent to a customer identity by default.

How do card-linked offers work from enrolment to redemption?

1. Present the programme and notice. Explain the benefit, eligibility, purposes, data use, terms and relevant rights.
2. Enrol or activate. The customer links an eligible payment credential to an account, or saves an offer to an enrolled card. Record programme choices separately from marketing preferences.
3. Accept payment normally. The customer presents a physical card or supported mobile wallet at the payment terminal.
4. Receive an approved reference. An authorised party may supply a token, PAR or provider alias with permitted transaction context. Available data is implementation-specific.
5. Match programme rules. Check the reference, merchant, spend, time and offer conditions in an authorised issuer, scheme, acquirer, processor, merchant or programme environment.
6. Record earning. Post points, cashback, progress or a statement credit immediately or later, according to the programme terms.
7. Show the outcome. Use a terminal screen, receipt, account or permitted service message. Electronic marketing needs a separate PECR assessment.
8. Support redemption. Allow automatic or customer-selected redemption and define balances, expiry, partial use, returns and disputes.

A terminal-resident SDK can support checkout interactions and connect them to a dashboard or loyalty service. It does not create a universal right to payment data, and its role depends on the approved architecture.

How should refunds, reversals and chargebacks affect rewards?

Refund logic should mirror the event that created the reward. A full refund will usually reverse associated earning, while a partial refund may require proportional adjustment. The exact outcome must follow the programme terms and available processor or merchant data.

1. Authorisation reversal: keep rewards pending until the chosen qualifying event, such as capture or settlement.
2. Full refund: link the refund to the original transaction and reverse the reward without relying on visible card digits.
3. Partial refund: recalculate earning against net eligible spend and define rounding.
4. Chargeback: state when rewards are frozen, reversed or restored after resolution.
5. Negative balance: define the result when reversed rewards have already been spent.

Use approved transaction and programme references, audit trails and customer-visible rules. Test split tenders, gratuities, offline approvals, delayed capture and cross-outlet returns.

Do mobile wallets behave like the physical card?

Not necessarily. A wallet can present a device-specific token instead of the physical card's PAN. Apple says Apple Pay uses a device-specific Device Account Number and a transaction-specific security code. A card provisioned to a phone and watch should not be assumed to expose the same merchant-facing reference.

This creates false splits, where one person appears as several references, and false merges, where several people share a payment account. Reissues and acquirer migrations can create further breaks. PAR may bridge some PAN and token presentations, but it remains an account reference, not human identity or consent.

Test each wallet, device, acquirer, MID, outlet and reissue scenario. Do not claim universal wallet support until the live partner implementation has been validated.

What are the main UK implementation models?

A terminal-resident model can reduce separate scanning and use existing hardware, but it must pass Payment App Vendor integration, certification, TMS deployment, security and support gates. Hardware-agnostic and acquirer-agnostic design can reduce dependency risk, but every supported combination still needs validation.

How should PSPs and retailers choose a model?

For PSPs and acquirers, card-linked services can differentiate an acquiring proposition and create value-added-service revenue. Any fee or revenue-share model must cover integration, certification, support, rewards and channel costs. No churn or revenue result should be promised without evidence.

Retailers can increase coverage of eligible enrolled transactions and shorten feedback loops between checkout and campaign management. They cannot identify every transaction because cash, unsupported credentials, shared accounts and customer choice leave unavoidable gaps.

What do PCI DSS, UK GDPR and PECR require?

PCI DSS controls account-data exposure

PCI DSS v4.0.1 defines account data as cardholder data and/or sensitive authentication data. PAN is cardholder data. Full track data or chip equivalents, card verification codes and PIN data must not be stored after authorisation, subject to narrow issuer exceptions.

Tokenisation can reduce exposure but does not automatically remove connected systems from PCI scope. Token vaults, detokenisation paths and systems that can affect security still require architecture review and, where appropriate, QSA assessment. Tokens alone do not prove compliance.

UK GDPR governs purposes, fairness and rights

A token, PAR or provider alias is likely personal data when it singles out a returning customer or links to a loyalty profile. Define controllers and processors, select a lawful basis for each purpose, provide transparent information, minimise data, set retention periods and enable rights.

The ICO requires a lawful basis to be chosen and documented before processing. Contract may support administration objectively necessary for enrolled membership. Legitimate interests may support proportionate recognition or analytics after a documented assessment. Consent must be freely given, specific, informed, unambiguous and evidenced.

A DPIA may be mandatory for high-risk designs such as large-scale profiling, matching multiple sources, invisible processing or systematic behavioural tracking. Payment completion alone does not tell a customer that a credential will build a visit profile.

PECR governs electronic marketing

Loyalty enrolment does not automatically authorise email, text or similar marketing. The ICO says marketing to individuals generally requires consent unless every soft opt-in condition applies. Those conditions include obtaining details during a sale or negotiation, marketing the sender's own similar products or services, and offering an opt-out at collection and in every message.

Do not add promotions to service messages or digital receipts without assessment. Identify the sender, honour objections and retain sufficient suppression data to prevent re-enrolment.

How should the merchant dashboard use terminal data?

A dashboard should convert approved programme data into decisions rather than expose raw credentials. Useful functions include campaign configuration, reward-liability monitoring, earning and redemption reporting, refund reconciliation, visit-frequency analysis, consent status, suppression controls and customer-rights workflows.

Reporting must distinguish transactions, enrolled accounts, recognised references and inferred profiles because a payment credential is not a unique customer. PSP and acquirer views can also show TID and MID deployment state, software version, terminal health and merchant adoption. This estate telemetry has a different purpose and retention basis from loyalty data.

Can open banking complement card-linked loyalty?

Yes, but it is a separate consented service, not a universal card-present identifier. Open Banking Limited explains that customers choose whether to share account information or make payments through regulated providers and can revoke access.

Future programmes may combine card, wallet and account-to-account events within a customer-controlled account. Apps can provide persistent engagement, terminals can reduce checkout friction, and open banking can add authorised account data or payment journeys. Combining them increases purpose-limitation, minimisation and role-mapping work.

How does Zeal fit into this architecture?

Zeal is the #1 value-added services provider for payment terminals. It helps PSPs, acquirers, Payment App Vendors and enterprise retailers place value-added experiences within supported terminal estates while preserving existing payment and merchant-system responsibilities.

Evaluate a Zeal deployment against the same controls: approved references, TMS compatibility, enrolment, redemption, wallet lifecycle, refunds, PCI DSS scope, UK GDPR roles and PECR permissions. Zeal should be positioned as the VAS layer, not as the party that identifies a person from a card.

Frequently asked questions

Is card-linked loyalty the same as cashback?

No. Cashback is one reward type. Programmes may instead award points, progress, discounts, merchant credit or statement credit. Card-linking describes the use of an enrolled payment credential and a qualifying transaction to trigger programme rules; it does not prescribe the reward type, funding model or timing.

Does card-linked loyalty work without an app?

It can remove an app scan at checkout, but an app or portal may still handle enrolment, activation, progress or account controls. A fully app-free journey depends on the programme, available payment references, permitted partner interfaces and terminal experience, so “no app required” must be verified for the specific implementation.

Does a payment token identify the customer?

No. A token identifies a payment reference within a defined domain. One person may have several tokens, while several people may share an account or corporate card. Say “returning payment credential” unless the customer has explicitly linked the reference to an authenticated loyalty account with appropriate notice and controls.

Is tokenised loyalty data anonymous under UK GDPR?

Usually not if an organisation can link the token to an account or use it to single out a returning customer. Tokenisation reduces PAN exposure, but the identifier may remain personal data and still requires a lawful basis, transparency, minimisation, retention, security and workable data-subject rights.

Can loyalty enrolment be used as consent for marketing?

Not automatically. Membership administration and electronic marketing are separate purposes. Email and text marketing generally require PECR consent unless every soft-opt-in condition applies. The sender must identify itself, provide an easy opt-out when details are collected and in every message, and honour objections and suppression records.

What should a PSP test before rollout?

Test token and PAR availability, MID and TID scope, wallet and card-reissue behaviour, refunds, split tenders, terminal models, payment-application versions, TMS targeting, rollback, consent, deletion, suppression and reporting. Legal, Product, Security and the relevant PSP or acquirer should approve the actual data flow and permitted use before rollout.

Source note

This article reflects public and authoritative information available as at 8 August 2026. Regulatory guidance and implementations change. Confirm PCI DSS scope, UK GDPR roles, PECR permissions, scheme rules and partner data availability against the live architecture before deployment. This is operational guidance, not legal advice.

Discuss a UK card-linked loyalty or payment-terminal VAS deployment with Zeal.