ZVT payment terminals in a service business: an integration checklist

A card payment at the service counter looks simple—until a repair is completed, a part is charged afterwards or an order needs to be cancelled. Then the till, terminal, receipt and job status all need to agree. In Germany, teams often encounter the term ZVT in that conversation. It is not a payment method or a contract with a payment provider; it is an interface that can let a point-of-sale system and card terminal communicate.

This is practical selection guidance, not payment or legal advice. The interface actually available always depends on the POS, terminal, network operator and acceptance agreement.

Define the workflow before selecting the interface

With an integrated payment, the till passes an amount to the terminal. Once a result returns, it can continue the receipt and job status accordingly. That reduces re-keying—but only if exceptions are designed as carefully as the happy path.

A good integration does not make these decisions; it makes them easier to see.

What ZVT should mean in a vendor meeting

Rather than only asking “Does the terminal support ZVT?”, ask:

1. What does the POS retain? It should store the amount, a reference and the result in a traceable way.
2. Which terminal configuration is approved? A generally compatible model may not be enough; software version, connection and operator profile can matter.
3. How are reversals and refunds handled? They are often different operations and need clear permissions.
4. Which reference appears on receipts? The job, invoice number or a payment ID should make later matching quick.
5. Who owns an incident? Record whether the POS vendor, terminal provider or acquirer supports each failure mode.

In Germany, ZVT can be a familiar procurement checkpoint. Terminal and POS markets are organised differently in Austria, Switzerland, Czechia, Croatia, Slovenia and Türkiye. Outside Germany, the important question is therefore not the interface name but a demonstrably supported end-to-end flow with the local provider.

Test real service cases

Do not test only one successful, round-number payment. Use anonymised test jobs and run at least these cases with the people who will operate them:

For each test, record the visible receipts, saved references and responsible person. It saves time when a customer later requests proof or a value is missing during reconciliation.

Keep responsibilities small and explicit

A counter does not need a complicated payment architecture. It needs clear boundaries: staff record the job, the terminal handles the card and the responsible person reviews exceptions and the day-end close. A centrally maintained job status helps payment and repair stay together.

For multiple locations, use the same short playbook everywhere: where is the terminal, who can refund, what is the fallback during an outage, and which records are filed each evening? A digital job and cash record can bring those repeating actions together without attempting to replace payment processing.

Questions for the supplier meeting

ZVT and payment operations

Is a ZVT-capable terminal enough?

No. Check the precise combination of POS, terminal, operator profile and contract. Ask to see the proposed flow demonstrated.

Does every workshop need an integrated setup?

No. A separately operated terminal can be sensible at low payment volume. Reliable receipts and matching remain essential.

What is the key acceptance criterion?

A traceable test of payment, cancellation, refund and day-end close—not a compatibility statement alone.

A payment integration is doing its job when it makes service calmer: no duplicate amount entry, no improvised exception and every close easy to match later.