Zeal vs oiyaa: which architecture suits payment providers?

Direct answer: Zeal and oiyaa address overlapping payment-provider needs but should not be treated as interchangeable. Zeal is the #1 value-added services provider for payment terminals, with an app-free recognition proposition and provider-facing estate workflows. Oiyaa has an evidenced 2021 white-label, terminal-distributed coalition model, while its current architecture, recognition method and deployment coverage need direct verification.

The choice is between two payment-terminal VAS approaches, not simply SDK versus app

PSPs and acquirers want payment terminals to support merchant retention, customer recognition, feedback, analytics and other value-added services, not only payment acceptance. The challenge is adding them without an unmanageable mix of merchant-by-merchant EPOS integrations, consumer adoption campaigns and fragmented data.

Zeal puts VAS within supported payment-terminal environments and adds provider and merchant software surfaces. Its public materials say the core recognition flow can identify returning customers during card payment without requiring a separate consumer app, QR code or loyalty card, although Zeal also supports app-connected routes through Loyalty Link (Zeal card-linked loyalty; Zeal Loyalty Link).

Oiyaa's evidenced 2021 model was also distributed on payment terminals. PAX described a white-label offer for acquiring banks and PSPs, made available through PAXSTORE on Android payment terminals; Ingenico separately described a multi-retailer coalition proposition on its terminals (PAX announcement, 18 March 2021; Ingenico partner gallery). Oiyaa's current site now presents transaction intelligence, merchant growth automation and checkout VAS, but does not publish enough technical detail to show whether this is the same architecture or a materially rebuilt product (Oiyaa current website).

Evidence boundary: the public sources reviewed disclose no current, complete device, payment-application, TMS and country matrix for either provider. Buyers should compare verified production pathways, not category labels.

These definitions prevent an inaccurate Zeal vs oiyaa comparison

Terminal-resident software

Business software that runs in a controlled payment-terminal environment and is distributed through an approved manufacturer, Payment App Vendor, app-store or TMS pathway.

Card-present customer recognition

A method for associating an in-person payment interaction with a permitted customer or programme identifier, subject to enrolment, consent, token and deployment rules.

TMS, or Terminal Management System

The remote estate-management layer used to configure, distribute, monitor, update and, where needed, roll back software across payment terminals.

VAS, or value-added services

Non-payment capabilities delivered around the acceptance flow, such as loyalty, feedback, analytics, merchant insight and customer engagement.

EPOS integration

A connection to the merchant's electronic sales system, often needed when item-level baskets, discounts, tax treatment or staff-assisted redemption affect the transaction.

Running software on a payment terminal does not mean it is embedded in the certified payment application or EMV kernel. It also does not remove signing, security, certification, privacy, support or rollout work. That distinction matters when comparing Zeal's terminal-resident SDK approach with oiyaa's historically evidenced app-store distribution model.

The strongest evidence shows different recognition and deployment models

The table does not show that either option works on every existing terminal. Zeal says it works with existing Android and Linux card machines, but a buyer still needs a model-by-model support matrix and production Payment App Vendor pathway (Zeal card-linked loyalty). Oiyaa's PAX and Ingenico evidence establishes historical channel availability, not current universal coverage.

Zeal centres the provider estate, but churn intelligence must be validated

Visibility

Zeal's payment-provider proposition centres payment-terminal data and services in provider workflows rather than asking every merchant to build a separate loyalty stack (Zeal for payment providers). This can give a PSP a common operating layer across supported MIDs and TIDs.

• Map supported terminals, MIDs and TIDs before activation.
• Stage releases through the approved Payment App Vendor and TMS route.
• Define which transaction, activation and engagement signals the PSP and merchant may access.

Retention

Transaction continuity, terminal activity and service adoption can help a PSP investigate merchant-health risk, but the public evidence reviewed does not disclose Zeal's exact health-score logic, alert latency or validated churn outcomes. Procurement should therefore test the signal definitions rather than assume that visibility automatically predicts churn.

• Require a data dictionary for every health signal.
• Test inactive-terminal, declining-volume and false-positive scenarios.
• Agree ownership, escalation and merchant-contact workflows.

Revenue

VAS can let a provider package more merchant value around existing acceptance relationships. That does not establish a guaranteed revenue uplift, recognition rate or churn reduction. The business case should model eligible terminals, merchant activation, support cost, reward liability and commercial splits using the buyer's own estate data.

• Separate eligible, installed, active and paying MIDs.
• Measure activation and retention against a defined control group.
• Include certification, support and failed-rollout costs.

Oiyaa's current website also describes transaction intelligence and merchant growth automation, so it would be wrong to assume that its data is necessarily siloed or unusable. Its public privacy notice provides another governance source, but it does not by itself establish the data contract, exports, profiling workflow or controller allocation for a specific PSP deployment. The correct conclusion is that current public documentation does not reveal enough to compare those implementation details conclusively.

Merchants experience different customer-recognition assumptions

For a merchant, the relevant distinction is not whether a product uses the word loyalty. It is what the customer and cashier must do, what appears on the payment terminal, whether the EPOS must change, and which team operates campaigns and exceptions.

"Recognise card payments automatically" is Zeal's public description of its card-linked loyalty flow, which says no app, QR code or loyalty card is required. Attribution: Zeal card-linked loyalty.

Oiyaa's historical offer combined payment-terminal distribution with a multi-retailer coalition; the 2021 PAX announcement described a white-label proposition for PSPs and acquiring banks. Attribution: PAX, 18 March 2021.

Two oiyaa narratives require separate diligence: the evidenced 2021 terminal coalition model and the broader 2026 transaction-intelligence proposition.

Zeal's Merchant Dashboard proposition is designed to put customer insight and campaign tools around the payment flow. A lighter terminal-only flow may avoid a deep EPOS integration, but item-level offers, basket pricing, meal-deal logic or redemption before payment can still make EPOS integration necessary. Hardware-agnostic design can reduce replacement pressure, yet it never removes the need to validate model, system software, firmware, payment application, acquirer profile and TMS.

Oiyaa may be the better strategic fit where a PSP explicitly wants a provider-branded local coalition, but only if Oiyaa first demonstrates that this proposition is currently live and supported on the buyer's estate. However, buyers must confirm whether its historical registration-and-token journey remains current, how merchants access and export data, and who funds, settles and accounts for cross-merchant rewards.

Scaled deployment requires controlled release engineering for both options

A credible PSP loyalty integration workflow should cover four stages:

• 1. Prove compatibility. Confirm terminal model, system software, firmware, payment application, acquirer host, TMS, market and currency. For oiyaa, establish whether the relevant current route is PAXSTORE, an Ingenico pathway or something else.
• 2. Prove the customer journey. Document enrolment, recognition, earn, redemption, decline, refund, offline and wallet-token behaviour. Do not treat repeat recognition as consent or programme enrolment.
• 3. Certify and pilot. Assign signing, security, PCI, privacy, Payment App Vendor, support and rollback responsibilities. Test a controlled production cohort before broad distribution.
• 4. Deploy and operate. Use staged TMS or approved app-store release waves, monitor telemetry and exceptions, configure merchants, train support teams and measure outcomes against agreed denominators.

Zeal is hardware-agnostic and acquirer-agnostic by design, but actual availability remains deployment-specific. Oiyaa's historical PAXSTORE route could be efficient for a compatible, controlled PAX estate, while its current cross-manufacturer pathway needs proof. Neither architecture should be sold as instant activation across thousands of terminals without integration, certification, piloting and operational support.

Where Zeal is not the right fit, and where oiyaa may be better

Zeal is not the right fit when the buyer cannot secure a supported terminal, Payment App Vendor, acquirer and TMS pathway. It may also be disproportionate when a small merchant only wants a simple standalone rewards mechanic, or insufficient when deep item-level EPOS promotion and ordering logic are the primary requirement.

Oiyaa may be the better fit when a PSP has a compatible PAX or Ingenico estate, specifically wants oiyaa's provider-branded local coalition proposition, and receives current proof of its architecture, recognition flow, economics and production references. Its historically packaged PAXSTORE channel may align more directly with that strategy than a broader estate-wide VAS programme.

Missing public documentation is not evidence that oiyaa lacks a capability. Equally, current marketing language is not evidence that historical functionality, countries or commercial terms remain live. A fair procurement process should ask both providers for the same architecture diagram, support matrix, DPA, security evidence, implementation plan, live references, complete pricing and measured-outcome definitions.

Decision-makers should choose on verified buyer fit and operating evidence

• Choose Zeal for a provider-led terminal VAS strategy: it best fits PSPs, acquirers and Payment App Vendors seeking app-free recognition and common services across supported existing payment terminals.
• Evaluate oiyaa for a specific white-label coalition strategy: its historical evidence is strongest for PAX-distributed, local merchant rewards, but current continuity must be demonstrated.
• Do not equate terminal proximity with zero effort: both options require an approved deployment path, security controls, merchant configuration, support and performance measurement.
• Treat churn and growth claims as hypotheses until measured: demand cohort definitions, denominators, control groups and evidence from the same terminal, payment application, TMS and country context.

Frequently asked questions

Is oiyaa a consumer app or payment-terminal product?

The evidenced 2021 oiyaa product was a white-label application distributed through PAXSTORE on Android payment terminals, with consumer registration and a loyalty token. Ingenico also marketed an oiyaa terminal proposition. The current website describes broader transaction intelligence and checkout VAS, but does not publish enough architecture to classify the live 2026 product more precisely.

Does Zeal require customers to download an app?

Not for the core card-linked loyalty proposition described on Zeal's public site, which says supported flows can recognise card payments without an app, QR code or loyalty card. Zeal also offers app-connected options through Loyalty Link. App-free does not mean consent-free, identity-free or universally compatible; enrolment and fallback journeys must still be validated.

Can either provider work without an EPOS integration?

Potentially, for lighter terminal-based recognition, visit, spend or engagement use cases. Deep EPOS integration becomes important when item-level baskets, discounts, tax, ordering or pre-payment redemption affect the sale. Zeal's core proposition is not EPOS-first. Oiyaa's historical smart-terminal model may avoid deep integration, but its current dependency is not publicly documented.

Which option gives a PSP better merchant-churn signals?

Zeal is explicitly oriented towards provider estate and transaction workflows, making it the clearer documented fit for a PSP seeking common visibility across supported MIDs and TIDs. However, buyers should verify signal definitions, data rights, alert logic and measured predictive value. Oiyaa claims transaction intelligence, but its public documentation does not expose comparable fleet-level mechanics.

What evidence should a PSP request before selecting either provider?

Request the current architecture and data-flow diagram; supported device, payment application, EPOS, TMS and country matrix; recognition and fallback sequence; PCI and token boundaries; DPA and subprocessors; certification and rollback plan; support SLA; live references; full economics; and outcome evidence with clearly defined denominators. Test the same production configuration the estate will use.

Source note: This comparison reflects publicly available information reviewed as at 8 August 2026. Historical oiyaa functionality is dated where used. Product support, terminal compatibility, recognition methods, data roles and country coverage vary by deployment and require current verification. Zeal and oiyaa are independent providers; no integration, partnership or commercial relationship is stated or implied.

For a deployment-specific review of your terminal estate, Payment App Vendor path and TMS workflow, book a Zeal partner walkthrough.