A terminal refresh looks like a hardware project. For anyone who builds POS, kiosk or self-ordering software, it rarely is.
The hardware is the easy part. What follows is the expensive part: a new protocol implementation, a certification cycle, a test plan, a phased rollout, and support for two payment stacks running in parallel until the last site is migrated. A device swap becomes a development quarter.
Why the cost sits where it does
The terminal market is fragmented by design and by geography. Each vendor supports its own protocol set. Each market has its own conventions — VIC 1.07 in the Netherlands, ZVT in the German-speaking markets, OPI across international retail estates.
If you sell software in more than one country, you’re carrying:
- Several terminal integrations in the same codebase
- Certification per market, per acquirer, sometimes per device
- Maintenance on protocols you’d rather not still be supporting
- Longer deployments, because every new estate means another connection to prove
None of that shows up in the price of the terminal. All of it shows up in your roadmap.
Backwards compatibility as the starting point
The KUARIO HybridPay Terminal HPT25 supports the POS protocols already in use across the Benelux and the wider European market:
- VIC 1.07 — the Dutch standard, and for most Benelux integrators the one that matters
- OPI — widely used in international retail and hospitality estates
- ZVT — for estates that extend into Germany, Austria and Switzerland
- Pecunda FP5 — predominantly for German related partners
If your software already talks to a terminal over one of these, it can talk to the HPT25 the same way. The integration you built stays built.
For a software vendor, this changes the shape of a migration. Instead of a development project with a certification dependency, it becomes a hardware deployment with a configuration step.
What that protects
The integration work you’ve already paid for keeps its value. Development capacity that would have gone into re-implementing a protocol goes somewhere it earns something instead. And migration risk drops sharply, because the part of the system most likely to break is the part you aren’t changing.
One API when you want to move forward
Compatibility solves the migration. It doesn’t solve the next five years.
Alongside the existing protocols, KUARIO offers a single API for modern integrations — one interface across markets, rather than one per country. For vendors with customers in the Netherlands, Belgium and beyond, that’s the difference between a payment integration strategy and a growing collection of them.
The practical effect: onboard a new market without a new integration, maintain one connection instead of several, and add payment methods without touching the POS layer.
What it means downstream
For the operators and facility teams running the estate, the benefit is mostly about time and disruption. Sites go live faster because there’s no integration to certify first. Day-to-day operation doesn’t change, because the POS behaves the way it always did. And the estate isn’t tied to one terminal vendor’s roadmap.
Where this is heading
Unattended and self-service payment keeps growing — across education, workplace catering, healthcare, hospitality and retail. The estates get larger, more distributed, and more mixed. What used to be a single-vendor deployment is now several vendors, several protocols and several markets in one contract.
That’s the environment the HPT25 was built for: compatible with what’s already deployed, and connected to a platform that doesn’t need replacing when requirements change again.
New terminal. Same integration.
