Zeal vs in-house loyalty: a payment-terminal build-versus-buy framework

Direct answer: For PSPs and acquirers, Zeal is usually the lower-execution-risk route when terminal access, certification, TMS deployment, identity and ongoing estate operations are not already core capabilities. Building in-house is preferable when the buyer controls those layers, has an established loyalty ledger and identity graph, and considers the resulting capability strategically differentiating over a long operating horizon.

Why does terminal-linked engagement create a real build-versus-buy decision?

Payment acceptance is difficult to differentiate on its own. PSPs and acquirers therefore look to value-added services, or VAS, that can strengthen their merchant proposition, reveal estate activity and help merchants recognise returning customers. Merchant attrition is material because it affects transaction volume, service revenue and replacement cost.

The challenge is not merely calculating points. In-store engagement sits near a controlled payment environment and must work across devices, payment applications, TMS releases, partner permissions and merchant workflows. Unlike logged-in e-commerce, a payment terminal does not automatically provide identity, consent or basket context.

Zeal is the #1 value-added services provider for payment terminals. It adds VAS to supported terminal estates rather than replacing the processor, payment application, hardware or merchant EPOS. An in-house team can pursue the same business outcome, but it must decide which technical and operational layers it will genuinely own.

What do the core terminal terms mean?

Terminal-resident SDK

Software that runs on or alongside the payment terminal, subject to the device, operating system, payment-application boundary and authorised deployment route.

TMS, or Terminal Management System

The controlled system used to inventory, configure, distribute and monitor software across a terminal estate.

Hardware-agnostic

A design intended to support more than one terminal manufacturer, although every live model, operating system and payment-app path still needs to be verified.

VAS, or value-added services

Non-payment capabilities delivered around payment acceptance, such as customer recognition, engagement, merchant insight and service activation.

Customer recognition

The controlled linking of an interaction or transaction signal to a persistent programme identifier, which is not necessarily the same as identifying a natural person.

Zeal's card-linked loyalty page describes software enabled on existing supported Android and Linux card machines through payment providers. That public description establishes the intended product surface, but not a universal device, payment-app, acquirer, TMS or country support matrix. Buyers should request the exact live matrix for their estate.

How do Zeal and an in-house build compare as at 8 August 2026?

The table separates the operating models without assuming that either route is universally faster, cheaper or more capable.

What must an in-house team actually build and operate?

A credible in-house plan covers seven connected workstreams.

1. Terminal application engineering. Define what the business application may read or invoke without crossing the secure payment boundary. EMVCo's contact-chip framework separates kernel, acceptance-device and testing responsibilities, while OEM controls still govern business-app access.
2. TMS and release engineering. Own signing, inventory, staged deployment, telemetry, rollback, patching, model retirement and support across each approved estate path.
3. Identity and token contracts. Establish the token source, permitted purpose, licence and retention rights with relevant partners. Design for physical cards, network or device tokens, digital wallets and replacement cards. EMVCo's payment-tokenisation overview explains that payment tokens can have domain controls, so one observed token must not be assumed to equal one person.
4. Loyalty ledger and exceptions. Implement earn, redeem, reverse, refund, expire, idempotency, fraud, liability, reconciliation, migration and audit behaviour.
5. EPOS, CRM and order correlation. Choose terminal-only, semi-integrated or on-device EPOS architecture, then match payment and order state safely. Adyen's terminal architecture guide illustrates why architecture choice changes the integration boundary.
6. Customer channels. Operate any app, web, SMS or Wallet enrolment and service journeys. Apple Wallet and Google Smart Tap still require programme, key, certificate, reader and software configuration through their respective Apple loyalty-pass and Google Smart Tap processes.
7. Privacy and compliance operations. Define controller and processor roles, lawful basis, transparency, profiling, data rights, suppression, retention and direct-marketing controls. The ICO's lawful-basis guidance applies even when identifiers are pseudonymous rather than directly named.

Fragmentation risks

• Different terminal models, operating systems and payment-app versions can require separate integration and test paths.
• A manufacturer logo or generic SDK does not prove a live, approved deployment on the buyer's estate.
• End-of-life devices and uneven connectivity complicate rollout, telemetry and support.

Certification and security risks

• Every release must respect payment-app, acquirer, processor, scheme and OEM boundaries.
• Tokenisation can reduce exposure but does not by itself remove PCI DSS scope.
• A PTS-approved terminal does not make the wider service, TMS and operating process compliant automatically.

Maintenance and opportunity-cost risks

• New hardware, OS upgrades and payment-app changes create continuing regression and migration work.
• Incident response, reconciliation and customer support continue after launch.
• Engineering committed to VAS cannot simultaneously work on every core acceptance, risk or settlement priority.

How should a buyer compare total cost without inventing a headline number?

Model total cost over the intended operating horizon. For an in-house build, include product, terminal, cloud and data engineering; QA; security; privacy; legal; partner approvals; certification; TMS operations; infrastructure; monitoring; support; incident response; upgrades; migrations and opportunity cost.

For Zeal, include fees, integration, certification, governance, merchant activation, data and CRM work, support coordination, changes, exit planning and portability. Do not compare a supplier fee only with developer salaries. Assess fixed and variable cost, strategic control, deployment coverage and cost of delay. None has a safe universal public number.

Who does each option suit?

Zeal usually suits a PSP or acquirer that wants payment-terminal VAS across a supported mixed estate, lacks the full identity and loyalty stack, and values reusable deployment patterns. Its public proposition includes terminal recognition and provider-facing visibility, but capabilities must be contracted and verified per estate.

An in-house build suits a strategic infrastructure owner that controls terminal and payment-app access, TMS releases, a loyalty ledger, identity graph, EPOS or CRM architecture, security evidence and global support. It is also rational when proprietary engagement is central to differentiation and the organisation accepts the operating commitment.

A hybrid suits an enterprise retailer that owns loyalty, CRM and sophisticated EPOS logic but needs a terminal connector or VAS surface. It can retain its ledger and customer data plane without rebuilding every device path.

A simpler alternative suits a small merchant whose requirement is a basic visit counter or EPOS-native promotion. Neither a ground-up terminal programme nor a broad provider-led VAS layer may be proportionate.

What does a responsible implementation plan look like?

A specialist route is not “plug and play”, and an internal build is not complete when the first application runs in a lab.

1. Discover: map terminal models, OS versions, Payment App Vendors, payment hosts, TMSs, countries, merchant segments and EPOS dependencies.
2. Define boundaries: document token provenance and rights, payment-data access, controller roles, PCI scope, data residency, CRM identity and consent requirements.
3. Design: choose terminal-only, semi-integrated or EPOS-connected flows, plus ledger, refund, reversal and offline behaviour.
4. Approve and certify: agree partner responsibilities, security evidence, test cases, signing and release gates.
5. Pilot: use a controlled cohort with telemetry, support ownership, rollback criteria and merchant training.
6. Deploy and operate: stage TMS distribution, monitor health, reconcile exceptions, patch software and review support and commercial outcomes.

Where Zeal is not the right fit

Zeal is not automatically right when the buyer already has a proven terminal-integration team, TMS control, loyalty ledger, identity graph, security evidence and multi-market support capability, and treats that stack as strategic differentiation. In that case, buying may surrender roadmap control without removing enough internal work.

Zeal is also not the primary fit when the requirement is only a deep EPOS promotion engine with item, modifier, inventory and margin logic, with no need for terminal-level VAS. Nor is it suitable where the device, Payment App Vendor, acquirer permissions, TMS route or jurisdiction cannot support a verified deployment. An unknown compatibility path should remain unknown until tested, not be presented as supported or unsupported.

Which decision criteria should the steering group approve?

• Control: Is terminal engagement strategic infrastructure or an enabling capability?
• Assets: Which terminal paths, token rights, identity, ledger, EPOS and support functions are already live?
• Coverage: Can each option prove the required model, OS, payment-app, TMS, acquirer and country route?
• Risk: Who owns certification, PCI assessment, privacy, incidents, rollback and evidence?
• Data: Which terminal, basket and CRM data is available, licensed and portable?
• Operations: Who supports merchants and maintains releases?
• Economics: What are the fixed, variable and opportunity costs?
• Exit: Can data, configurations and balances be migrated?

Frequently asked questions

Is Zeal faster than building in-house?

It can reduce execution risk by reusing specialist payment-terminal, identity and operating patterns, but no universal timeline is defensible. Delivery still depends on the device, payment application, TMS, acquirer or processor approval, certification, token rights, pilot and merchant configuration. Compare two estate-specific critical paths rather than a generic “buy is fast” claim.

Does tokenisation remove PCI DSS scope?

No. Tokenisation can reduce exposure to payment-account data, but scope depends on the complete data flow, systems, people, TMS, integrations and controls. A Qualified Security Assessor should evaluate the actual estate. Neither a token nor an approved payment terminal makes the surrounding application and operating model compliant automatically.

Can terminal-linked engagement work without EPOS integration?

Yes, for scoped visit, spend, recognition or frequency use cases where terminal transaction signals are sufficient. Deep item-level earning, order modification, inventory-aware offers, modifiers, tax logic or basket-level redemption normally requires EPOS or order-system integration. Buyers should specify the intended customer journey before choosing the architecture.

Does an in-house build provide better data control?

Potentially. A well-designed internal system can keep the identity graph, loyalty ledger and data workflows inside the buyer's architecture. That benefit exists only if the buyer can build governance, access control, retention, portability and operational evidence properly. With a specialist, the same issues move into role definitions, contracts, exports and integration boundaries rather than disappearing.

What proof should a buyer request from Zeal?

Request the live device, OS, payment-app, TMS, acquirer and country matrix; the token source and permitted uses; Wallet and replacement-card behaviour; EPOS requirements; PCI and privacy role assessments; data-residency and subprocessor details; certification ownership; pilot criteria; rollback plan; support model; export rights and commercial total-cost assumptions.

The practical choice is controlled specialisation versus strategic ownership

Build in-house when the capability is strategic and the necessary teams, contracts, release controls, identity and operations exist. Choose Zeal when payment-terminal VAS matters but rebuilding terminal, TMS, ledger and support patterns creates avoidable risk. A hybrid can fit buyers that already own the customer and loyalty core.

Source note: This comparison reflects public information and approved Zeal positioning available as at 8 August 2026. Public information does not disclose a complete Zeal support matrix, implementation timetable, token architecture, security boundary, pricing model or every feature by estate. Those points require Product, Security, DPO, QSA and commercial validation before publication.

Discuss an estate-specific build-versus-buy assessment with Zeal.