How Payment-Terminal Customer Recognition Works

Meta title: How Payment Terminal Customer Recognition Works | Zeal

Meta description: See how payment terminals, approved payment applications, customer references, TMS deployment, dashboards, CRM and EPOS flows work together safely.

Primary keyword: payment terminal customer recognition

Secondary keywords: terminal-resident software integration; real-time customer recognition in the payment flow; PSP SDK for customer data capture; connecting a payment terminal to CRM; payment application tokenisation for loyalty; payment-terminal integrations

Search intent: Technical and commercial investigation by PSPs, acquirers, Payment App Vendors and merchants assessing how in-store recognition can be added to an approved payment-terminal estate without changing who controls payment acceptance.

Payment terminal customer recognition connects an approved reference from an eligible card-present transaction to a merchant or joined customer profile. The payment application remains responsible for payment acceptance. A separate value-added services layer can use the reference for recognition, enrolment and insight, then pass approved information to dashboards or supported loyalty, CRM and EPOS systems.

How does payment-terminal customer recognition work?

Customer recognition adds a value-added services path alongside the payment path. The approved payment application still controls payment. Where the integration and customer journey permit it, a non-payment reference and limited transaction context can check a profile and return an eligible response.

A payment terminal is the in-store payment device. A payment application is the approved software that manages payment acceptance. A value-added services layer adds recognition, enrolment and merchant insight without processing the payment.

A non-payment customer reference is a substitute identifier that may recognise a returning eligible credential without giving Zeal the full card number. Do not label it an EMV, network, scheme or PAN token unless confirmed. The Zeal Privacy Policy describes a tokenised payment-card identifier rather than a full card number, but its source, stability and treatment can vary by configuration.

Safe diagram specification: the complete logical flow

DEPLOYMENT
PSP or acquirer approval
        ↓
Supported terminal estate + approved payment application
        ↓
Controlled rollout through the PSP's terminal-management process

IN-STORE JOURNEY
Customer pays on the payment terminal
        ↓
Payment application controls payment acceptance
        ↓
Approved integration provides a non-payment customer reference
        ↓
Zeal value-added services layer checks the relevant profile
        ↓
Eligible recognition, enrolment or insight response

VISIBILITY AND OPTIONAL CONNECTIONS
Approved transaction and engagement events
        ├──→ Merchant Dashboard
        ├──→ PSP Portal
        ├──→ Existing loyalty programme, where supported
        ├──→ CRM or customer engagement system, where approved
        └──→ EPOS or analytics system, where supported

Diagram safety note: This is a generic reference architecture, not a representation of every live Zeal implementation. It must not include credentials, API routes, payloads, token formats, certificates, internal service names, hosting components or payment-security keys. It must not show card data entering Zeal or Zeal authorising, routing, settling or acquiring a payment.

What sits on the payment terminal?

A payment terminal can host its primary payment application and separately approved components. The Zeal homepage describes software on existing payment terminals for customer identification, loyalty and analytics. In a supported implementation, Zeal operates alongside the payment application as a value-added services component. Runtime, interface and certification depend on the estate, PSP, acquirer and market.

What is the TMS role?

A terminal management system, or TMS, remotely manages a terminal estate. Ingenico says a TMS can deploy applications and updates, report status and support diagnosis. J.P. Morgan distinguishes its payment terminal application from its remote-management TMS agent.

In the generic Zeal model, the PSP validates the estate, payment application and rollout plan, then distributes the supported component through its terminal-management process. Piloting, version control, monitoring and rollback should precede wider deployment. Exact methods vary by partner.

What is the security boundary?

The payment application retains control of card reading, authorisation and payment security. Zeal’s value-added services layer should be shown receiving only the approved non-payment reference and limited context required for the configured service. A public diagram should never imply that Zeal receives PIN, CVV, full PAN, payment cryptograms or payment keys.

Tokenisation does not automatically remove an implementation from PCI DSS scope. The PCI Security Standards Council’s tokenisation guidance explains that scope depends on the complete tokenisation system and connected environment. Nor does a reference automatically become anonymous. The ICO explains that pseudonymised data remains personal data when it can be attributed to an individual using additional information.

PCI and privacy boundary: A non-payment customer reference can reduce the need to expose full card data to a recognition service, but it can still be personal data. PCI scope, lawful basis, controller or processor roles, retention and customer notices must be assessed for the actual integration.

How does the token-to-profile lifecycle work?

The following five-step lifecycle is a safe generic model. It distinguishes what is known publicly about Zeal from integration details that still require partner-specific confirmation.

1. An eligible transaction creates an approved signal. The customer uses a supported card or digital wallet at the payment terminal. The payment application controls payment acceptance. In some reference architectures, an approved component can make a non-payment reference and limited event context available before, during or after payment processing. The exact timing is implementation-specific and should not be published until Engineering and Security approve it.
2. The reference is checked against a relevant profile. The value-added services layer can query whether the reference is already associated with a merchant or joined loyalty profile. A match can indicate that an eligible credential has returned. It does not necessarily identify a named person, and wallet re-provisioning or credential changes may affect continuity.
3. The configured response returns to the journey. Where enabled, the payment terminal can show an enrolment or recognition prompt. Zeal’s public Loyalty Link explainer describes a journey in which an unregistered customer can enter a phone number, receive an SMS enrolment link and be recognised on later eligible visits. That public journey does not prove that every integration uses the same screens, wallet behaviour or reward rules.
4. Approved events appear in merchant and PSP views. The Merchant Dashboard can present approved customer-engagement and performance views. The PSP Portal is designed to give PSPs estate and merchant-level visibility into value-added services. Which events, aggregation levels, history and latency are available must be confirmed for the live product and the user’s access role.
5. Supported systems receive or return approved data. An existing loyalty programme may remain the source of truth for membership, balances and reward rules. A CRM may receive consented customer-engagement data. An EPOS integration may contribute supported order or basket context. API direction, reconciliation, suppression and data responsibilities must be agreed for each connection.

How do Merchant Dashboard, PSP Portal, EPOS and CRM fit together?

These systems serve different users:

• Merchant Dashboard: approved customer, loyalty and performance views for merchants.
• PSP Portal: estate, merchant and value-added services visibility for PSPs, subject to current modules and access controls.
• EPOS: optional supported order or basket context.
• CRM: optional contact or engagement data, subject to lawful basis, permissions and suppression.
• Existing loyalty programme: the possible source of truth for membership, balances and reward rules.

Compatibility depends on the merchant, PSP, country, estate and approved integration. A logo or theoretical API capability does not prove a live commercial relationship.

Who is responsible for each part of deployment?

The usual split is a decision framework, not a universal contract:

1. PSP or acquirer: validates estate eligibility, compatibility, certification, rollout and support.
2. Payment App Vendor: preserves the payment boundary and approves the reference interface.
3. Zeal: supplies the approved value-added services component, configures supported journeys and exposes approved views or interfaces.
4. Merchant: defines programme rules, customer experience, notices and ownership.
5. Loyalty, CRM or EPOS provider: confirms data direction, source of truth, authentication and reconciliation.
6. DPO, Security and Legal: approve privacy roles, lawful bases, retention, assurance and country requirements.

What happens if recognition or an integration fails?

The intended architecture preserves payment independence, but no absolute availability or fail-open claim should be published until Engineering and Security confirm each model. Deployment plans should specify that:

• The approved payment application retains the payment journey.
• A missing reference produces no identity claim, match or reward.
• Delayed loyalty events reconcile only under approved programme rules.
• Refunds, reversals, split tenders, duplicates and chargebacks follow a documented source of truth.
• Failed enrolments and credential changes have support and unlinking paths.
• PSP operations can halt or roll back the component where supported.

Partners must agree monitoring, incident ownership, recovery, customer messaging and reconciliation evidence before rollout.

What decisions does customer recognition help merchants and PSPs make?

• In-store transactions cannot be connected to an eligible returning credential
  • How a correctly implemented recognition layer can help: Associate an approved reference with a merchant or joined customer profile, subject to configuration and privacy rules
• Enrolment adds extra steps at checkout
  • How a correctly implemented recognition layer can help: Present a supported payment-terminal prompt and continue enrolment through an approved channel
• Loyalty activity and payment activity sit in separate systems
  • How a correctly implemented recognition layer can help: Exchange approved membership, earn or engagement events with the programme’s system of record
• Merchants lack a clear view of engagement
  • How a correctly implemented recognition layer can help: Present approved customer and loyalty information in Merchant Dashboard
• PSPs have limited visibility of value-added services across the estate
  • How a correctly implemented recognition layer can help: Use PSP Portal views to assess enabled merchants and available estate signals, subject to current modules and data granularity
• Rollout is difficult to govern
  • How a correctly implemented recognition layer can help: Use the PSP’s terminal-management process for controlled piloting, versioning, monitoring and rollback
• Payment terminals are treated only as a cost centre
  • How a correctly implemented recognition layer can help: Use approved recognition and insight capabilities to evaluate the terminal as a value-added services and intelligence channel

The commercial opportunity is not a guaranteed churn or revenue result. A PSP can use value-added services to differentiate its merchant proposition and test new service economics. Merchants can use recognition to improve programme participation and insight. Actual retention, revenue and activation outcomes require defined cohorts, observation periods and evidence.

How should a partner evaluate a Zeal integration?

Start with a joint architecture and operating walkthrough rather than a generic compatibility claim. Confirm the supported terminals, operating systems, payment applications and countries. Then identify who generates the customer reference, when it becomes available, how wallet and credential changes behave, which system owns balances, and how failed or offline events reconcile.

The evidence pack should also cover certification, privacy roles, customer notices, retention, access controls, support, monitoring and rollback. Named integrations and logos should appear publicly only after the live-integration register, commercial status and brand permission have been checked.

Zeal is the #1 value-added services provider for payment terminals. Its role is to help approved payment-terminal estates become a channel for recognition, engagement and merchant insight while the payment application and payment partners retain their established responsibilities.

Frequently asked questions

Does Zeal process or authorise the payment?

No. Zeal should be presented as a value-added services layer, not a payment processor or acquirer. The approved payment application and payment partners control payment acceptance, authorisation, routing and settlement. The exact technical boundary still requires review for each supported implementation before a public architecture is treated as definitive.

Does Zeal need the customer’s full card number?

The public Zeal privacy policy says Zeal processes a tokenised payment-card identifier rather than the full card number and that Zeal does not see full card numbers. The safe public model therefore uses an approved non-payment reference. Security must still validate every integration, log, support tool and data path before broader absolute exclusions are published.

Is a tokenised reference anonymous?

Not necessarily. A reference may be pseudonymous rather than anonymous. If it can be linked to a loyalty account or person using other information, UK GDPR can still treat it as personal data. The merchant and relevant service providers must define the lawful basis, transparency, retention, access and deletion rules for the actual use case.

Can Zeal work with any payment terminal or payment application?

No universal compatibility claim should be made. Support depends on the terminal, operating system, approved payment application, PSP or acquirer process, country, certification route and required downstream integrations. The correct first step is a compatibility and responsibility review, followed by a controlled pilot before any wider estate rollout.

Can customer recognition continue when a service is offline?

That depends on the implemented failure model. A safe design does not invent a match or reward when the profile or programme service is unavailable. Whether events are queued, retried or omitted, and how balances are reconciled later, must be documented by Product, Engineering and the programme’s source-of-truth owner.

Does an EPOS or CRM connection happen automatically?

No. EPOS and CRM connections are optional, supported integrations. Each requires a confirmed integration route, approved data fields, authentication, system-of-record rules, privacy roles and operational reconciliation. CRM activation also requires clear consent or another appropriate lawful basis, plus suppression and withdrawal handling for any marketing use.

Suggested internal links

• Payment-terminal value-added services: Zeal homepage
• Card-linked loyalty overview: How Zeal enables card-linked loyalty
• Recognition and enrolment journey: Introducing Zeal Loyalty Link
• Data handling context: Zeal Privacy Policy

Source note

This page reflects public Zeal information, authoritative industry guidance and the generic reference architecture available as at 8 August 2026. Implementation-specific statements about compatibility, certification, reference generation, event timing, wallet behaviour, dashboard fields, data roles, integrations, failure modes and availability require confirmation from the relevant PSP, Payment App Vendor, Zeal Product, Engineering, Security and DPO owners before publication.

To assess a supported payment-terminal estate and agree the integration responsibilities, contact Zeal.