MDB: why your machine does not see the payment

What MDB is and who is in charge

MDB (Multi-Drop Bus) is a serial bus inside the machine. It has exactly one master — the vending machine controller, the VMC — and several peripherals: coin mechanism, bill validator, cashless device, sometimes a bill recycler. A peripheral never starts a conversation. It stays silent until the VMC polls its address.

That single property explains most integration problems. If your terminal appears to work but the machine does not react, the fault is usually not in the terminal: the VMC is simply not polling the address the terminal sits on.

Technically the bus is slow and deliberately simple: 9600 bit/s, with a ninth bit separating an address from data. That simplicity is why machines built twenty years ago are still in service, and why new devices must speak just as unhurriedly.

Why a card terminal pretends to be a coin mechanism

The specification defines a peripheral type called the cashless device. That is exactly what a payment terminal becomes. It is not bolted on beside the machine — it takes a regular seat in the same system as coins and notes.

Then comes the single most important word in this topic: level. Cashless Level 1, Level 2 and Level 3 are different capability sets. The lower level does the minimum: deduct an amount, confirm, cancel. Higher levels allow showing a balance, serving several items in one session, and returning part of the amount.

The practical consequence: machine and terminal must meet at a level both support. A machine that only speaks the basic level will not improve because the terminal can do more. This is the first thing to establish before buying, not after.

Where integrations get stuck

Power. MDB provides a separate supply line for peripherals, and it is not unlimited. A terminal with a modem, a screen and a backlight draws more than the coin mechanism whose place it took. A machine that misbehaves precisely during payment is often just browning out at the moment the modem comes up.

Addressing. Every device type has its own bus address. Two devices on the same address and the bus goes quiet for both. This happens more often than you would expect on machines where several terminals have been tried in turn.

An old VMC. A machine can have the MDB connector physically present but firmware without cashless support. The socket is there, the line is there, the answer is not. The fix is a firmware update from the manufacturer, or an external controller that emulates the VMC — and that is a different conversation about cost.

What the connection gives you beyond the payment itself

The most underrated part is data. A terminal sitting on the bus sees not only that money was taken, but which item was selected and whether the machine actually dispensed it. That lets you match payments against dispenses on the same day instead of at month end.

Second, telemetry without extra hardware. The machine already reports its faults on the bus. A device listening there can forward them, and the operator learns about a breakdown before the customer does.

Third, pricing flexibility. Once payment goes through your side, a discount, a subscription or a corporate account becomes a rule in your system rather than a firmware change in the machine.

Where to start with a mixed fleet

Start with one machine, preferably the oldest. It will surface every limitation at once. A machine that works with everything tests nothing.

For each model record three facts: is MDB physically present, which cashless level the firmware supports, and how much power is left for peripherals. That three-column table saves more money than any comparison of terminal vendors.

And separately: agree on who keeps the data. If transactions are visible only in your terminal supplier’s portal and cannot be exported, you can neither reconcile revenue nor move to another supplier. Ask this at the first meeting, not in year three.

Frequently asked