Card payments for vending machines without a cashier

Three ways to accept payment on a machine

First, a reader with an MDB interface. The machine and the payment module speak the standard vending protocol: the machine states the price of a product or a session, the module confirms the payment, the machine dispenses. This is the cleanest option for classic vending because nothing in the machine logic has to change.

Second, a bank POS terminal connected to the equipment controller. Most self-service car washes work this way: the customer taps a card, the controller receives the confirmation and starts the bay for the paid time. The point is that the terminal and the controller are linked in software, not standing next to each other as two unrelated boxes.

Third, a QR code with no terminal at all. The customer points a camera, pays in a browser or a banking app, and the equipment gets its command from the server. This is the cheapest option per site and the only one that needs no hardware on each bay. The downside is that it depends on the internet, both on the customer’s phone and at the site.

A receipt without a cashier is an obligation, not an option

A machine that takes cashless payment is selling a product or a service, and in most jurisdictions that sale needs a fiscal receipt. There is no cashier, so the software has to produce it: a software fiscal register bound to that specific machine reports the sale to the tax authority and gives the customer a link or a QR code to the receipt.

In practice this means three things. Every machine is its own register or its own shift in the owner’s dashboard. The receipt must be produced even when the site’s internet is down: the system stores the transaction locally and fiscalises it as soon as the link returns. And at the end of the day the receipts must match what the acquirer settled, otherwise the discrepancy will be looked for on your side.

Per-machine reconciliation: where the shortfall hides

With ten machines and a terminal that reports one total per day, you cannot see which machine brought in less. Reconciliation has to happen at device level: how many transactions the controller accepted, how many the acquirer confirmed, how many receipts went to the tax authority. Three numbers that have to agree every day.

This is the level where fraud and faults become visible: a machine with fewer confirmed payments than starts; a bay that dispenses sessions without payment; a bill acceptor that swallows money and does not count it. In the car-wash network we built the payment layer for, more than 14,000,000 transactions have gone through this reconciliation, and it is the reconciliation, not the terminal, that lets the owner sleep.

What happens when the internet drops

The most common operator complaint: “the customer paid and the machine did nothing”, or the other way round. The cause is almost always the same: the exchange between payment and equipment is built so that any pause in connectivity loses an event.

The correct scheme: the on-site controller decides on its own and stores every event locally with a unique identifier. Payment confirmed means the session starts immediately; the report goes to the server when a channel is available. When the server receives the same event twice, it recognises the identifier and does not double the revenue. The machine keeps working offline, and reconciliation after recovery matches to the cent.

What to ask a vendor before you sign

Is payment integrated with the equipment controller, or are these two independent devices? Is a fiscal receipt produced for every transaction, and who is responsible for the fiscal register? Is there per-machine reconciliation, or one daily total? What happens to a payment when the link drops? Who owns the data, and can it be exported?

If two of these five questions get a “we will clarify later”, the solution is not ready for unattended operation. A machine that takes cards but cannot do receipts and reconciliation moves the problem from the till to the owner.

Frequently asked