Till integration: ZVT, O.P.I. or cloud — what really connects the till and the terminal

The short answer

There are three routes from the till to the card terminal: ZVT (the German classic, binary, serial or on the same IP network), O.P.I. (XML over TCP/IP, from international retail) and cloud integration, where the payment request runs via a terminal server and till and terminal no longer have to sit on the same network. Which route fits is decided not by the terminal but by the till — and by whether it runs locally on a computer in the shop or as a cloud application in the browser.

The three routes compared

	ZVT	O.P.I.	Cloud integration
Data format	binary, fixed data fields	XML	provider-specific, via terminal server
Connection	serial (RS232) or TCP/IP	TCP/IP, two channels	internet, terminal also via SIM
Requirement	till and terminal on the same network	till and terminal on the same network	no shared network environment needed
Origin	German retail standard, version ZVT 700	Open Payment Initiative, started 2003, later handed to the IFSF	a product of the respective payment network operator
Typical limitation	extensions only with effort	less widespread among German SMEs	dependence on a provider's server

Two points of context. The details on ZVT's protocol version and port assignment come from provider and integrator glossaries, not from a normative text — under the Deutsche Kreditwirtschaft's accreditation contract, the Technical Annex itself may not be passed on to third parties and is therefore not freely available to read. And the most widespread criticism of ZVT — wide scope for interpretation in implementation, new functions such as QR code payments only retrofittable with considerable effort — comes from a provider selling an alternative in the nexo Retailer Protocol. It holds true all the same if you ask three till manufacturers about the same ZVT function.

What counts in practice: Nexi carries ZVT and O.P.I. throughout on its own terminals, and on the SmartPOS A35 an API of its own in addition. REA Card names ZVT and O.P.I. for the flex series and places the third route alongside with ZVT Cloud — a terminal with no ZVT or OPI interface, payment requests via a cloud-based terminal server, operation via SIM even outside the till network. PAYONE, by contrast, named no till interface on its public product pages as at the review date of 1 August 2026. That is not a technical shortcoming but an information gap — and for a merchant with an existing till it is exactly the question they want answered before signing.

TA 7.2 is not a till interface

This is where the market gets most confused, and it costs money. The Technical Annex TA 7.x is Annex 2 to the Deutsche Kreditwirtschaft's accreditation contract: it governs security requirements, approved terminals and key injection. Version 7.2 is binding. Anyone describing TA 7 as a till interface is wrong — that is the terminal's approval level, not the connection to the till.

The two levels are connected all the same, and in this direction: a new TA version changes the binding technical requirements for the terminal, the terminal needs a software update for it — and because the till talks to that same terminal over ZVT or O.P.I., the till software has to follow afterwards. That is the real migration effort, and it lands with the merchant; it appears in no quotation. REA Card sets out four deadlines for the last migration wave — from 1 January 2022 only TA 7.2 / DK-POS 3.0-compliant devices could newly enter the market, from 30 September 2022 additional Mastercard charges applied to non-compliant devices, from 1 July 2023 TA 7.1 terminals lost the contactless function, and by 1 January 2025 all devices had to support TA 7.2. And the provider itself concedes that the update was technically not implementable on all of its own terminals, so a hardware swap became necessary. The next wave is coming either way. Anyone buying a till should therefore know who pays for maintaining the interface.

What the integration costs — and what re-keying costs

For setup, providers charge a flat fee, usually together with contract handling and shipping: CCV quotes up to 50 euros one-off, Nexi Austria names 25 to 100 euros for activation, and a comparison portal lists 29.99 euros (all figures as at 1 August 2026). If you use the cloud route via a SIM card, CCV puts around 5 euros a month on top.

These amounts are small in themselves. It gets interesting when you set them against the alternative — typing the amount into the terminal by hand. The following calculation is a model calculation with a disclosed assumption, not a measurement: eight seconds of extra effort per ticket for entry and checking.

Business	Ticket size	Card payments/month	Integration at €50 one-off, over 12 months per ticket	Cloud SIM €5/month per ticket	Re-keying at 8 s per ticket
Bakery	€6.50	900	0.5 cents	0.6 cents	2.0 hours/month
Restaurant	€48.00	400	1.0 cents	1.3 cents	53 minutes/month
Trades business	€320.00	45	9.3 cents	11.1 cents	6 minutes/month

The result turns the usual logic around. Fees scale with ticket size — which is why every tenth of a per cent of negotiation is worth it for the trades business. Till integration scales with ticket count — which is why the bakery needs it more urgently, even though its tickets are small. Two hours of till time a month is more than the integration costs in a whole year, and the transposed digits it avoids are not yet counted in.

The payment slip is not the till receipt

Because integration brings till and terminal closer together, the question of the TSE comes up regularly. The line is clearly drawn: a pure card terminal with no till function does not fall under section 1 KassenSichV and needs no certified technical security device. But as soon as a till app with product management and order entry runs on the device — the normal case on SmartPOS devices — it is a till system: TSE obligation, mandatory details on the receipt under section 6 KassenSichV and notification to the tax office within one month under section 146a(4) AO. The terminal's payment slip with terminal ID, trace and authorisation number is not the till receipt in this context. Two documents, two legal bases. What applies in an individual case is a matter for your tax adviser, not for this text.

What to do now

1. Ask the till first, not the terminal provider. Ask the till manufacturer or dealer about the supported interface: ZVT serial, ZVT over TCP/IP, O.P.I. — and whether the till runs locally or in the cloud.
2. With a cloud till, ask specifically about the cloud route. Anyone running a browser-based till will not get far with ZVT on the local network. Have this point confirmed in writing before signing the contract.
3. Request the interface specification. Several payment network operators only release it on request. Without that document the till dealer cannot give a binding answer.
4. Ask for the setup fee and the running costs separately. The one-off fee, SIM costs and any configuration charges belong in the quotation, not in the first invoice.
5. Establish who pays for the next rulebook change. Interface adjustment after a new TA version: included in the service contract or billed extra?
6. Calculate ticket count instead of ticket size. With many small tickets, integration is a decision about time, not about fees — and you make that one once, not monthly.