All posts

MDB Protocols Payment

What is the MDB protocol?

MDB (Multi-Drop Bus) is the serial standard that lets a vending machine talk to coin changers, bill validators and cashless terminals. Here is how it actually works.

If you operate vending machines, you have relied on MDB for years without ever seeing it. It is the quiet wiring standard that lets a coffee machine, a snack machine or a bottle cooler accept a coin, a note or a card without the machine and the payment device having to know anything about each other's internals. Understanding it is the difference between treating a machine as a sealed box and treating it as a platform you can extend.

MDB in one sentence

MDB — Multi-Drop Bus — is a serial protocol that connects one master (the vending machine controller) to many payment and peripheral devices on a single shared bus. It was standardised by the vending industry (NAMA in the US, the EVA in Europe) so that any compliant coin changer, bill validator or cashless reader could be plugged into any compliant machine. That interoperability is the whole point: the machine does not care who made the coin changer, and the coin changer does not care what it is dispensing.

The physical picture

MDB is a two-wire serial bus running at 9600 baud, opto-isolated so a fault in a peripheral cannot damage the machine controller. One device — the VMC, the Vending Machine Controller — is always the master. Everything else is a peripheral that only speaks when spoken to.

The vending machine controller acts as bus master and polls each peripheral in turn along a single shared two-wire bus. VMC master Coin changer addr 0x08 Bill validator addr 0x30 Cashless · Hero Nexus addr 0x10 poll → ← reply
One master, many peripherals, one shared bus. A payment terminal joins as a cashless device.

Master, peripherals and addresses

Every peripheral type has a reserved address. A coin changer answers at 0x08, a bill validator at 0x30, the first cashless device (a card reader or mobile-payment terminal) at 0x10, a second cashless device at 0x60. Because the bus is shared, MDB uses a 9-bit serial format: the ninth bit — the mode bit — marks whether a byte is an address (the master selecting who should listen) or plain data. Only the addressed peripheral replies. Every message ends with a checksum so a corrupted frame is detected and retried rather than acted on.

The master runs the conversation on a loop. It polls each peripheral, asks "anything to report?", and the peripheral answers or stays silent. Nothing on an MDB bus happens without the VMC asking for it first. That single rule is what keeps a bus with several independent devices deterministic.

What a payment actually looks like

The interesting part for an operator is the cashless device class, because that is where a modern terminal — a card reader, a QR scanner, a meal-card acceptor — lives. A cashless transaction is a short state machine:

  1. Enable. The VMC tells the cashless device it is allowed to take payment.
  2. Session start. The customer presents a card or phone. The device tells the VMC a payment method is ready and, if needed, how much credit is available.
  3. Vend request. The customer selects a product; the VMC asks the cashless device to approve a specific price for a specific item.
  4. Vend approved / denied. The device authorises (or declines) the amount.
  5. Vend success. The machine dispenses, and only then is the sale finalised and the money captured.

That ordering matters. The money is committed after the product drops, not before — so a jammed spiral or an empty slot does not charge the customer. MDB encodes that guarantee into the protocol itself.

Why this is the foundation, not a footnote

MDB is thirty years old, deliberately simple, and still on nearly every machine in the field. That is exactly why it is powerful: if a device can speak MDB, it can join a machine that was built decades before it. A terminal that registers as a cashless peripheral does not need the machine to be redesigned, rewired or replaced. It needs to speak the bus.

This is the hinge our whole platform turns on. Hero Nexus, the Android software that runs inside the payment terminal, registers on the MDB bus as a cashless device — so a machine engineered for coins in 1998 can take a contactless card, a meal card or a QR payment today, with no change to the machine's own controller. Everything above that — telemetry, cloud reporting, fleet management — rides on top of a clean MDB integration underneath.

If you want the full picture of what the terminal accepts once it is on the bus, our payment platform page walks through card, contactless, meal cards, İstanbulkart and QR as one capability rather than a pile of separate readers.

MDB is not glamorous. It is a 9600-baud serial loop with a checksum. But it is the reason a self-service machine can be upgraded instead of thrown away — and that is worth understanding before you buy your next fleet.

Let's bring your machines onto the platform.

Tell us how many machines you run and which protocols they speak — our engineering team will map the path.