How to Add Loyalty to an EPOS Without a Customer App: A Guide for EPOS Providers and ISVs

Why customers will not download another app to collect rewards

Most shoppers already pay by card, so the card is a better loyalty identifier than an app they have to find, download and open while they pay. Cards made up 64% of all UK payments in 2025, according to UK Finance, so the payment moment already carries an identifier for most visits.

The problem lands on the EPOS provider. Merchants ask for loyalty integrated with EPOS, then discover that an app-based scheme pushes the work onto staff and customers. A cashier has to prompt. The customer has to agree, download, register, verify an email and reopen the app before the card is even presented. Each of those steps loses people, and the queue behind them makes staff stop asking.

The result is a scheme that exists on paper and barely functions in store. Merchants blame the EPOS. The EPOS provider inherits support tickets for a feature nobody wanted to build.

There is a different starting point: identify the customer at the moment they pay, with no download. The comparison between loyalty apps and card-linked loyalty for enterprise retail sets out why the two models produce very different repeat-visit data.

What are the ways to add loyalty to an EPOS?

There are three patterns: a loyalty module built into the EPOS, an API connection to a third-party loyalty engine, and loyalty that runs on the payment terminal alongside the EPOS. Each puts the engineering burden in a different place and identifies the customer by a different method.

A built-in module gives you full control of the basket, the reward logic and the user interface. It suits EPOS providers with a dedicated product team and merchants who want a scheme shaped around their menu or range. You own every line of it, including the parts nobody enjoys maintaining.

An API connection to a third-party engine moves the rules, balances and campaign tooling outside your codebase. You still build the enrolment screen, the identification step and the redemption flow in your own software. This suits merchants who already have a CRM and want the EPOS to feed it.

Terminal-resident loyalty runs next to the payment application on the payment terminal. Identification happens at the tap, so the EPOS does not need an enrolment screen at all. This suits distributed estates where you cannot ship an EPOS release to every site at once.

Table 1. Three ways to add loyalty to an EPOS, compared.

Combine them where it helps. Terminal recognition handles identification, and the EPOS supplies basket lines for item-level offers.

How does loyalty on the payment terminal recognise customers without an app?

Software running next to the payment application receives an approved, non-payment reference for an eligible card and matches it to a loyalty profile. A returning customer is recognised when they tap, with no app download, no QR code and no plastic card.

The customer flow runs in this order:

1. The customer taps to pay as normal.
2. The card is recognised against an existing loyalty profile, or flagged as new.
3. A new customer opts in on the terminal screen in a couple of taps.
4. Rewards are earned and redeemed on the same screen at the same moment.
5. The profile builds across visits, so visit frequency and spend accumulate without anyone re-entering details.

Control of the payment itself does not move. The approved payment application keeps card reading, authorisation and payment security. The value-added services layer sits alongside it and does not process payments, which is what makes an app-free loyalty programme viable on a certified device.

This is the mechanic behind card-linked loyalty with EPOS: the card becomes the join key between visits, so identification is passive rather than something staff have to request. For the detail on why tokens work as an identifier across channels, see the explanation of the payment terminal as a join key for unified customer data.

For an ISV, this pattern keeps the identification problem outside your release cycle, which is why a loyalty SDK for ISVs that runs on the payment terminal needs so little EPOS work.

How do rewards reach the EPOS basket?

The simplest set-up applies the reward on the payment terminal at the moment of payment. A deeper set-up passes the customer reference and reward back to the EPOS so it can show item-level offers before the total is confirmed.

For the terminal-only route, the EPOS needs to expose nothing beyond the amount it already sends for payment. The reward adjusts what the customer pays at the terminal, and reconciliation runs against the payment record.

For the basket route, the EPOS needs three things: the basket total, the item lines, and a way to apply a discount to a named line or to the order. Agree the format and the timing before any build work starts, because the reward has to arrive while the order is still editable.

The trade-off is about what the data tells you. Payment data alone shows who came back, how often they came and how much they spent. Basket data adds what they bought, which is what enables product-level offers and brand-funded campaigns.

Start with payment data. Add basket lines when a merchant has a specific use for them.

What does each option cost an EPOS provider to build and run?

A built-in module costs the most engineering time and the most ongoing maintenance. An API integration costs less but still requires enrolment and identification work inside your software. Terminal-resident loyalty needs the least EPOS work, because identification happens on the payment terminal rather than in your application.

Build cost is the part most roadmaps estimate. The running costs are the part that surprises people:

• Customer support for balance queries, failed redemptions and merchant configuration changes
• Consent records, retention rules and subject access requests
• Reward liability reporting, so finance can see outstanding points across the estate
• Multi-site roll-out, where every new version has to reach every checkout

Commercial models fall into three broad shapes. A licence fee gives predictable cost and no upside from usage. A revenue share ties your income to merchant adoption and usually suits partner-led distribution. A wholesale model lets you buy the service and price it into your own merchant packages, which protects your margin and your merchant relationship.

Pick the model that matches who owns the merchant. If you invoice the merchant, wholesale usually fits. If the payment provider does, revenue share usually fits.

What data protection and PCI DSS rules apply?

A card reference used for loyalty can still be personal data. Tokenisation does not on its own take a system out of PCI DSS scope, so treat both questions separately rather than assuming one answer covers the other.

Start with the UK GDPR position. The ICO's pseudonymisation guidance explains that pseudonymised data remains personal data in the hands of anyone who holds the additional information needed to re-identify the individual. A loyalty profile keyed to a card reference sits squarely in that category, so the usual obligations apply: lawful basis, retention limits, and a record of processing.

On the card security side, the PCI SSC's tokenisation guidelines treat every component of a tokenisation system as part of the cardholder data environment. Scope reduction comes from how the architecture is assessed, not from the word token. Confirm the assessment position with your payment provider before you design around it.

For marketing, the ICO's legitimate interests guidance notes that legitimate interests can apply to direct marketing, but only where PECR does not require consent. Capture consent on the terminal screen when the customer joins, and store the timestamp with the profile.

How to choose: a checklist for EPOS providers and ISVs

Start from the payment terminals and acquirers your merchants already use, because that determines which patterns are available to you. Then decide how much basket data the proposition genuinely needs.

Work through it in this order:

1. Confirm which payment terminals and acquirers your merchants use across the estate. Supported models vary, so list them before you scope anything.
2. Decide whether payment data is enough, or whether item-level offers make basket data necessary.
3. Agree who owns the customer relationship and the resulting data: the merchant, the EPOS provider or the payment provider. Put it in the contract, not the kick-off deck.
4. Check consent capture and data processing terms, including where consent is recorded and how it is passed on.
5. Pilot on one site. Measure recognition and redemption on the payment terminal before touching the wider estate.
6. Roll out through the payment provider's terminal management system, so merchants install nothing and no EPOS release is required.

That last point is what makes an EPOS loyalty integration deliverable at estate scale. For the regulatory and commercial background, read the definitive guide to card-linked loyalty in the UK for PSPs and enterprise retailers.

What we have learned putting loyalty next to the EPOS since 2019

I co-founded Zeal with Belal Mohamed in 2019, and I have spent seven years building software that runs on payment terminals. We built the core technology in 2020 and 2021, tested it in the real world in 2022 and 2023 with Ingenico as a strategic partner, and have worked with Castles and other industry partners since 2024.

In my experience, three habits decide whether a deployment goes smoothly:

• We confirm the terminal first. Supported models vary, so we agree the exact payment terminal before anything is switched on.
• We deploy through the payment provider. Zeal reaches terminals through our partners' terminal management systems, so merchants install nothing and no engineer visits a site.
• We agree data requirements up front. Integration and customer-data requirements are settled before switch-on, not after the first merchant asks for a report.

Zeal is an award-winning value-added services provider for payment terminals. It runs next to the payment app, works alongside the existing EPOS and payment processing, and does not process payments.

More than 30,000 merchants have been activated on Zeal across payment providers. Our live UK payment partners are Adyen, DNA Payments, Elavon, Lloyds Cardnet, NMI, Viva Wallet and Worldpay, and our partners' signed activation pipeline covers 4 million payment terminals.

Frequently asked questions

Can I run loyalty with my EPOS without a customer app?

Yes. Loyalty without customer app downloads works by identifying the card at the moment of payment, so the customer joins on the terminal screen in a couple of taps with no app, QR code or plastic card.

Does loyalty on the payment terminal replace my EPOS?

No. It runs alongside the existing EPOS and payment processing. The EPOS keeps the order, the payment application keeps authorisation, and the value-added services layer handles identification and rewards.

Do I need basket data for loyalty to work?

No. Payment data alone shows who returned, how often and how much they spent, which supports visit-based rewards. Basket data is needed only for item-level offers and product-specific campaigns.

Is a card used for loyalty personal data under UK GDPR?

Usually, yes. The ICO's pseudonymisation guidance says pseudonymised data stays personal data for anyone holding the information needed to re-identify the person, so a loyalty profile keyed to a card reference falls in scope.

Which payment terminals support loyalty alongside the EPOS?

Supported terminal models vary and are confirmed before switch-on. Live UK payment partners include Adyen, DNA Payments, Elavon, Lloyds Cardnet, NMI, Viva Wallet and Worldpay.

Building loyalty for EPOS providers across a partner estate starts with the payment terminals your merchants already run. Talk to partnerships to confirm what your estate supports.

Sources

• UK Finance, UK Payment Markets 2026 (summary), August 2026.
• Information Commissioner's Office, Pseudonymisation and Legitimate interests.
• PCI Security Standards Council, PCI DSS and tokenisation guidelines (information supplement).

About the author

Omar Ebeid is Co-founder and CEO of Zeal, which he founded with Belal Mohamed in 2019. Zeal won Team of the Year at the UK FinTech Awards 2026 and Platinum in the Fintech category at the Juniper Research Future Digital Awards 2023, and has raised $14 million in total, including a $10 million pre-Series A round announced on 9 September 2026. Connect with Omar on LinkedIn.