The MDB protocol is how a vending machine talks to the things that take money. Dating from the 1980s, it connects bill acceptors, coin dispensers and card terminals to a machine’s controller. It endures because it solved the problem properly the first time. If you are building any unattended machine that charges people, including a photo booth, this is the layer your payment hardware expects to speak.
Master and slave, and why it matters
MDB has exactly one master, called the Vending Machine Controller. The controller runs the bus and starts every exchange. Everything else is a slave that answers when spoken to.
Card readers, coin mechs and bill validators are all slaves. They never volunteer information. The controller asks, they reply, and the whole conversation is driven from one end.
For a photo booth that means your PC takes the controller role, or something between the PC and the reader takes it on the PC’s behalf. That choice is the single biggest architectural decision in the payment side of your machine.
Why you cannot just plug it into a USB port
Here is the part that surprises people who assume MDB is ordinary serial with a different plug.
MDB uses a different electrical interface and carries nine bit data rather than the eight bits a standard serial port handles. It also demands very quick replies, on a timing budget a general purpose computer running Windows cannot reliably meet. Miss the window and the bus treats the device as absent.
That is why a bridge board exists. It handles the electrical translation and the tight timing in dedicated hardware. What reaches the PC is something it can actually cope with: a serial port, normal eight bit bytes, no hard deadlines.
What the bridge is actually doing
Picture a translator with a stopwatch. On one side it speaks MDB at MDB’s pace. On the other it speaks plain serial at yours.
A capable bridge can sit on either side of the relationship. Configured as a slave it pretends to be a payment peripheral, which is how people build custom readers. Configured as a master it drives the bus, which is what a photo booth needs. Your machine is the thing asking for money, not the thing collecting it.
The cashless device role
A card terminal on MDB is a cashless device, and the exchange is simpler than people expect.
The controller says it wants a specific amount. That reader then deals with the card, the network and the bank, before coming back with approved or declined. There is no ambiguity, and no polling a web service to learn what happened. That is the entire reason this beats a QR checkout on an unattended machine.
Because the answer is definitive, your software can branch cleanly. Approved starts the session. Declined shows a message and offers another attempt. Nothing is left hanging in a state where you do not know whether money moved.
What this means for a photo booth
Photo booths inherited the vending world’s problem without inheriting its solutions, and most booth software still reflects that.
Products built for mobile event work assume a person is present, so they either skip payment entirely or bolt on a phone checkout. Neither approach needs the machine to know anything. Once the booth is alone in a lobby, that gap becomes the whole problem, and MDB is the mature answer to it.
The trade is real, though. You take on a bridge board, a wiring loom, and a class of grounding fault that simply does not exist with a laptop and a tripod. Anyone telling you the unattended route is simply better has not spent an evening chasing intermittent resets.
When a bus device disappears
Because everything on MDB is polled by the controller, a peripheral that stops answering simply looks absent rather than broken. That is useful, since the machine keeps running instead of hanging. However it also means the symptom you see is silence, which tells you very little on its own.
So work outwards rather than inwards. First confirm the bridge still enumerates as a serial port, because if Windows has lost the device nothing above it can work. Then check power on the MDB side, since the bus needs supplying and a marginal supply produces exactly this behaviour. After that, look at grounding, which is where our own intermittent resets turned out to live.
Only once all three check out is it worth suspecting the reader. In practice the terminal is almost never the fault, though it is invariably the first thing people replace.
Getting started without buying anything
You can build and test the entire payment path before a board or a terminal arrives. A stand-in reader runs approved and declined through your real screens on an ordinary laptop.
Do that first. Design the flow, decide what a decline looks like, and only then order hardware. The protocol is the easy part to add once the experience around it is settled.
Frequently asked questions
Is MDB the same as serial?
No. It uses a different electrical interface and nine bit data, and it enforces reply timings a normal PC serial port does not.
Can I write MDB support myself?
You can, and people do, usually against a bridge that handles the timing. Writing it against raw MDB from a Windows application is a fight you will lose.
Does MDB handle refunds?
The reader and your processor handle the money. What the protocol gives you is a definite result at the moment of the transaction. That is what lets you avoid needing a refund at all.
Do coin mechs and card readers coexist on one bus?
Yes. That is what a multi drop bus is for. Several peripherals share the wiring and the controller addresses each in turn.
VertexBooth is a Windows booth that takes the controller role over a bridge, so MDB payment works without you writing any of it. One time early access licence, and a stand-in reader for testing. Download it.
Practical wiring and the faults that follow are in Nayax MDB on a photo booth. Protocol background above draws on Qibixx’s MDB documentation.
