What it costs to add payments to equipment you already own

First question: does the equipment have an interface

Everything starts with the controller. If it has a documented interface — Modbus RTU over RS-485, Modbus TCP over Ethernet, a pulse input with described logic — we can connect to it without changing the machine itself. We read the state, write the command “dispense time” or “dispense product”, and the rest is software.

If the interface is closed or absent, there are three ways out, and all of them cost more than the first option. Replace the controller with one that has an interface. Take the signals physically — pulses into an input, a current sensor on the pump, a relay in place of a button. Or obtain the protocol description from the manufacturer, which sometimes takes longer than everything else combined.

This single answer — documented interface or not — moves the cost of a project more than any other line in the specification. It can be established in a day, and it should be known before anything else is discussed.

Second: what language the acceptors speak

Coin and note acceptors speak MDB or ccTalk. Both are standard buses with described behaviour, and if the acceptor supports one of them the connection is known work: match the levels, poll the device, handle the events “accepted”, “returned”, “jammed”.

It becomes expensive when the acceptor is old and speaks a manufacturer’s own protocol, or gives out nothing but pulses. Pulses are enough to count money, but not enough to know why the acceptor rejected a note.

A separate case is an acceptor wired through the controller, where the controller does not expose its events. Then cash is visible only as “time dispensed”, and reconciling cash against cashless is done from assumptions rather than from a log.

Third: how many payment routes

Every payment route is a separate integration, a separate log and a separate reconciliation. Card at the bay means an acquirer, a terminal and its protocol. QR means a server, a payment service and connectivity. Apple Pay and Google Pay usually go through the same acquiring integration as the card, but need their own testing.

Two routes do not cost twice as much as one, but they do not cost the same either. The largest share of the work is not the integration itself but the alignment: every route must write to one log, with one timestamp and one bay number, so that at the end of the day they can be matched.

A practical suggestion: start with one cashless route on top of the cash that already exists. A second cashless route is cheaper to add once the first one works and the log is already built.

Fourth and fifth: fiscal receipts and offline operation

A fiscal receipt with no cashier is a topic of its own and we have written about it in detail. In short: if a receipt is required, it adds an integration with the fiscal service, error handling for registration, and a queue of receipts that failed on the first attempt. It is not the most expensive part, but it cannot be postponed, because it shapes how the log is built.

Offline operation is not an option but a baseline requirement if the equipment stands outdoors or on an industrial site. Mobile coverage drops, and the terminal has to take the payment, start the equipment and accumulate events locally, then send them on when the link returns. In the car wash network we support, the terminals work exactly this way, and 14 million payment transactions have passed through them.

What affects cost here: which payment routes must work offline (cash always; card depends on the terminal and the acquirer; QR never), how long the event queue may grow, and who needs to see that it is growing.

What is cheap and what is expensive

Cheap: connecting to a controller with documented Modbus; acceptors on MDB or ccTalk; one cashless route; a site with stable wired internet; a customer who has access to the current acquiring contract.

Expensive: a closed controller with no documentation; an acceptor with a proprietary protocol; three payment routes at once; fiscal receipts from day one plus offline operation; a site several hours away when one cable needs checking. None of these is a disaster on its own. Together they turn a project of a few weeks into a project of a few months.

The most expensive thing of all is rework. If the log is designed for one payment route and a second is added six months later, the thing that reports already rely on has to change. That is why even a minimal project gets a log designed for every route that might appear, not only the one that exists today.

What a typical project looks like, and what to check before buying

If the five answers above are favourable, a project on one site takes four to eight weeks. The first week is the survey, reading the controller documentation, testing the acceptors on the bench. Then the equipment integration and a first start on one bay. Then the cashless route, the log, the reconciliation. At the end, a week or two of watching real operation, looking at mismatches in the log and fixing what came up.

What stretches the schedule is not the technical work but the waiting: the manufacturer’s reply, the acquirer’s contract, access to the site. Those should be started in parallel with the first week, not after it.

Before buying a terminal, an acceptor or a controller, it is worth having answers to four questions: is the controller interface documented and do you have that document in hand; which protocol do the acceptors speak; does your acquirer allow unattended operation and on what terms; is there connectivity on site that can be relied on. Each can be checked without a contractor, and each changes the estimate.

There are no prices in this article on purpose: they are given after a conversation and a survey, not by email. The order of magnitude for ready-made solutions is on the products page, and it gives a sense of scale before we meet.

Frequently asked