How to Choose a Protocol and Clearing Solution for Vending Machines?
And the right way to choose - Executive Protocol vs. MDB
For most new machines — coffee, smart lockers, Smart Fridge, food and snacks — the recommended protocol is MDB, thanks to global support, flexibility, and compatibility with IoT, the cloud, and contactless payments. Executive Protocol remains relevant for older fleets that want to upgrade using a converter. Beyond the protocol, the payment provider determines the customer experience and the approval rates, and this is where PayPlus stands out thanks to clearing without holding a credit limit, an end-to-end solution from a single provider, and a European financial license (EMI).
Table of contents
What Is a Communication Protocol in a Vending Machine?
In a vending machine there are several components that need to 'speak' the same language: the machine controller (VMC – Vending Machine Controller), a coin reader, a bill reader, a credit terminal, an NFC reader, a cellular modem, a Telemetry system and sensors. The shared language is called the Communication Protocol, and it defines who starts the conversation, which commands exist, how a credit approval is transferred, how a sale is carried out, how errors are handled, and how prices are canceled or updated.
Without a unified protocol — you cannot connect new payment devices to the machine. Two standards dominate the market: MDB and Executive Protocol (EXE).
Components the protocol connects:
- Machine controller (VMC)
- Credit terminal (Cashless)
- Cellular modem
- Coin / bill reader
- NFC reader
- Telemetry system and sensors
Which Protocol Is Right for Your Machine?
If you develop coffee machines, Smart Fridge, smart lockers, food machines, snack machines, or self-service stations, the recommendation in most cases is MDB: more flexible, more widely accepted, and easily connects to future technologies.
Smart Fridge
Snack Machines
Parking Lots
Do You Have an Existing Fleet?
A fleet of hundreds of Executive machines? There's no reason to rush to replace it. In most cases you can add a credit terminal, Telemetry Cloud, and NFC using a suitable converter.
What is MDB and how does it work?
MDB (short for Multi Drop Bus) is the communication standard most widely used in the modern vending world. It enables a unified connection between the machine controller (VMC) and peripheral equipment — coin acceptors, bill validators, and cashless payment terminals.
In the MDB architecture there is only one Master: the VMC. All other components are Slaves. The VMC polls each component in turn and asks "Do you have any data?". This orderly management prevents collisions between components.
One Master (VMC) · Slaves:
- Coin Acceptor
- Bill Validator
- Cashless Reader
- Card Reader / NFC Reader
Global standard
Most machine manufacturers support it — easy to replace equipment, add components, find spare parts, and perform integration.
Excellent support for credit terminals
Contactless, EMV, Apple Pay, Google Pay, and NFC.
Compatibility with Telemetry and IoT
Cloud, Remote Monitoring, and full inventory management.
Simple expansion
You can add a reader, communication module, camera, or sensors without changing the machine logic.
A deeper look: physical layer, framing and timing in MDB
The next part dives into the technical layer of MDB. This section matters to anyone developing a terminal, converter, controller or Telemetry system that connects directly to the bus.
The physical and electrical layer
MDB is an asynchronous serial UART bus running at a fixed rate of 9600 bps with NRZ encoding. Each frame is made up of 11 bits:
start bit 1 — start bit
data bits 8 — in LSB-first order
mode bit 1 — the "ninth bit", distinguishes between address and data
stop bit 1 — stop bit
Electrically, the bus is a single-ended open-collector at voltage levels of about 9–11V, with opto-isolation. The VMC powers the peripheral devices through the same connector (18–42VDC unregulated), and the physical connection is made with a 5-pin Molex / 6-pin MTA connector in a daisy-chain topology (Y / piggyback). The VMC is also responsible for the power budget — and must enable/disable devices according to power availability.
Command block structure (Framing)
The mode bit is the heart of the logic: when the Master (VMC) transmits, mode=1 denotes an ADDRESS byte and mode=0 denotes a DATA byte. All devices read the address byte, but only the one whose address matches responds; only the addressed device reads the data bytes. When a device replies to the Master, it sets the mode bit on the last byte of the block to mark its end.
ADDRESS byte : [ 5 bits address | 3 bits command ] mode = 1 SUBCOMMAND : (optional) mode = 0 DATA[0..n] : (optional payload, MSB first) mode = 0 CHK : 8-bit sum (mod 256) of preceding bytes mode = 0
For example, the RESET command (command 2h) to the Cashless address (10h) is encoded as 1 00010 010b = 112h (the ninth bit = 1, the upper five bits = address, the lower three = command). The device simply replies ACK without a mode bit of its own; error checking is done via checksum only, and there are three reserved control bytes: ACK = 00h (acknowledge), NAK = FFh (reject), RET = AAh (retransmit request). Multi-byte values are sent MSB-first.
Peripheral addresses table
The upper five bits of the address byte define the device type. These are the main addresses in the spec:
Polling and timing (Bus Timing)
The VMC polls (POLL) each device cyclically — each device is polled once every 25–200 ms. The maximum response time (t-response) is 5 ms: silence beyond that is treated as a NAK, and the device must repeat the block (or append it) at the next opportunity. If a device does not respond for longer than the maximum response time — it is considered absent from the bus.
The Cashless transaction state machine
The Cashless interface is the most relevant part for a clearing provider, and it is defined as a clear State Machine. The spec defines three feature levels (Feature Levels 1/2/3), where higher levels support Revalue, extended files, and more. The main states:
The main command groups from the VMC to the terminal:
Terminal reset
Config Data (feature level, display rows/columns) and Max/Min Prices
Cyclic polling; through which the terminal reports events
Vend Request / Cancel / Success / Failure / Session Complete / Cash Sale
Reader Enable / Disable / Cancel
Value loading and expansions (manufacturer ID, serial number)
The main command groups from the VMC to the terminal:
Card presented -> BEGIN SESSION (funds available) User selects -> VMC sends VEND REQUEST (item price, item #) Terminal decides -> VEND APPROVED / VEND DENIED Machine vends -> VMC sends VEND SUCCESS Settle -> SESSION COMPLETE -> END SESSION
Note that Vend Approved is not the end of the transaction — only after VEND SUCCESS (confirmation that the product was actually dispensed) is it correct to close/charge. This is exactly the "cross-check" between payment approval and successful dispensing that prevents charging without product delivery — a critical point in a correct clearing implementation.
Improved contactless payments (Contactless)
As of version 4.2, an "option bit" was added that lets the terminal declare it can accept a Vend Request directly from the Enabled/Idle state, without a preceding Begin Session. This solves the "double tap" problem that was common on older NFC terminals, and enables a single clean tap experience.
How a Credit Transaction Is Carried Out in MDB (Step by Step)
1. The customer taps a card
2. The terminal performs verification
3. The terminal requests sale authorization
4. The VMC approves
5. The machine releases a product
6. A Vend Success message is received
7. Cross-check between approval and successful release
8. The transaction is closed (Session Complete)
What is Executive Protocol and how does it work?
Executive Protocol (EXE) is an older protocol, common mainly in European machines — especially in Italy, France, and Spain. It is still widely used in existing machine fleets, and is therefore relevant for upgrade (Retrofit) projects.
The main architectural difference: in MDB the machine controller manages the process, whereas in Executive the payment system manages a large part of the business logic — credit approval, sale authorization, pricing, and transaction cancellation. (Different implementations exist across different manufacturers.)
The disadvantage of Executive:
It is less flexible when you want Mobile Payments, Remote Vend, Basket, coupon management, advanced Telemetry, and IoT integrations. That's why new projects are usually based on MDB.
Existing machines
Machines from manufacturers like Necta, Bianchi, Fas, Saeco, or Zanussi mostly run on Executive. There's no need to replace the entire machine.
Simple installation
Sometimes you can connect a new reader directly, without changing the electrical system.
Low cost for a large fleet
For a fleet of hundreds of old machines, an Executive upgrade is significantly cheaper than replacing the whole controller.
Executive in depth — the inverted architecture
Executive, also known as "Protocol A", was developed by Mars Electronics International (MEI) in the early 1980s. The fundamental difference from MDB is the reversal of the Master/Slave roles: the coin mechanism (Coin Mechanism) is the Executive (Master), and the machine controller (VMC) is a peripheral node (Slave).
This is in fact the exact opposite of MDB, where the VMC is in control. Executive is essentially a "control protocol" that transfers very little data. The Executive polls (POLL) the peripheral node, it returns its status, and the Executive analyzes the status and decides the next action. Electrically, power is supplied separately — usually 24V AC.
Price Holding vs. Price Display
Executive has two main operating modes that determine where the pricing logic "sits":
Price Holding
Prices are stored at the Executive. The VMC returns the product line number (Product Line) in the range 1–250, and the Executive "translates" it into a price from its price database. This mode allows more detailed audit.
Price Display / Standard
Prices are stored in the controller itself, and the Executive acts mainly as a credit authorizer.
At the command level, CREDIT is sent followed by VEND. Important: a VEND command is not guaranteed after CREDIT — the decision to dispense a product may rely on more than just price coverage (e.g. change availability), so the implementation must manage the state carefully.
The German extension — BDV001
On top of Executive, the BDV branch (BDV001) was developed in Germany by the BDV association, to enable the transfer of larger data files — configuration and audit data — that the original protocol was not designed for. BDV is especially common in European machines and is effectively an extended "dialect" of Executive.
A credit transaction in Executive
At the user level the process is similar to an MDB transaction, but the division of responsibility differs: the payment system manages the credit, the machine receives authorization, performs the sale, and a success response is returned.
Summary of the architectural difference
| Aspect | MDB | Executive |
|---|---|---|
| Who is the Master | Machine controller (VMC) | Payment mechanism / coins |
| Who is the Slave | All peripheral devices | Machine controller (VMC) |
| Where the pricing logic sits | In the VMC | Usually in the Executive (Price Holding) |
| Amount of data | Rich, structured | Minimal (control protocol) |
| Power supply | On the bus (18–42VDC) | Separate (usually 24V AC) |
| Source / standard | NAMA / EVA | MEI (Protocol A) + BDV |
Modern hybrid architecture
The common solution today in markets that were formerly Executive-only is not to "pick a side" but to combine: a payment / change-giver system (cashless / changegiver) acts as an intermediate Master:
upstream - toward the machine it speaks Executive — so the older machine "feels" that it's connected to a familiar payment mechanism.
downstream - toward the peripherals it speaks MDB — and lets you connect a bill validator, EMV terminal, NFC and modern Telemetry.
This combines the data-management integrity of Executive with the modularity and cost of MDB. This is exactly the connection point where a good clearing platform (like PayPlus's) hides the protocol complexity behind a single abstraction layer.
Can you connect an MDB terminal to an Executive machine?
A fleet of hundreds of Executive machines? There's no reason to rush to replace it. In most cases you can add a credit terminal, Telemetry Cloud, and NFC using a suitable converter.
Developer integration guide - design principles
When building a terminal, converter, or system that connects to both protocols, a layered architecture is recommended that keeps things stable even when adding a new protocol or device in the future.
1. Layer separation (Layered Design)
Business Logic (pricing, sessions, settlement)
| unified interface
PaymentDevice { Vend(), Refund(), EnableDevice(),
DisableDevice(), GetMachineStatus() }
| |
MdbDriver ExecutiveDriver
(9600 9-N-1, POLL, (Protocol A master role,
ACK/NAK/RET, CHK) CREDIT/VEND, price holding)The Business Logic doesn't need to know whether MDB or Executive sits underneath — each protocol is a Driver that implements the same Interface.
2. State management (State Machine)
Manage the transaction lifecycle as an explicit state machine, with legal transitions only. This prevents edge cases like "approval received but the product wasn't dispensed".
3. Communication resilience (Resilience)
Idempotency Keys
Every charge request carries a unique identifier, so a mid-transaction disconnect won't cause a double charge on retransmission.
Timeout & Retry
Match the 5ms t-response and the POLL cycle; don't assume a device is "gone" after a single failure.
Full Event Log
Log every command/response (append-only) for accounting, debugging, and reconciliation with the clearing.
Vend Success cross-check
Charge only after confirmation that the product was dispensed, not at the moment of payment approval.
Developer tip
Separate the protocol layer from the business logic. Write a separate Driver for MDB and for Executive on top of a unified Interface (Vend, Refund, EnableDevice, DisableDevice, GetMachineStatus), manage a clear State Machine with Timeout and Retry, log every event in an Event Log, and use Idempotency to prevent double charges during communication disconnects.
How to choose a clearing provider? Why PayPlus leads
The protocol determines how the machine talks — but the clearing provider determines the customer experience, the approval rates, the settlement speed, and the ability to manage a fleet at scale. This is where PayPlus stands out as the complete and leading solution in Israel for the Unattended / Self-Service world.
Real clearing with no credit-line hold
In a vending machine the authorization request is sent the moment the card is tapped — before it's even known which product will be chosen. Many solutions handle this with a Pre-Authorization on a ceiling amount that temporarily holds money on the card: the customer sees a hold higher than the purchase, prepaid cards get drained and youth cards get declined, and the release takes days. PayPlus places no hold — an exact, real-time charge only for the amount actually purchased.
One end-to-end solution
In a vending machine the authorization request is sent the moment the card is tapped — before it's even known which product will be chosen. Many solutions handle this with a Pre-Authorization on a ceiling amount that temporarily holds money on the card: the customer sees a hold higher than the purchase, prepaid cards get drained and youth cards get declined, and the release takes days. PayPlus places no hold — an exact, real-time charge only for the amount actually purchased.
The trust of major brands
PayPlus serves some of the largest customers in Israel — among them Decathlon, SodaStream, the Fox Group and more. For a machine operator this is practical proof of the ability to handle high transaction volumes, regulatory requirements and the standards of large organizations.
Regulated activity abroad too
Beyond Israel, PayPlus has a regulated international presence with a European financial license (EMI), enabling regulated digital-banking activity under full regulatory supervision — including Multi-Currency support and cross-border expansion.
Full Israeli regulatory compliance
A machine fleet generates thousands of small transactions, each requiring documentation. PayPlus issues invoices automatically, including invoice-receipt documents per the Israeli Tax Authority's invoicing model, manages VAT, and integrates with ERP/accounting systems — all automatically.
Smart integration with the machine
In a vending machine the authorization request is sent the moment the card is tapped — before it's even known which product will be chosen. Many solutions handle this with a Pre-Authorization on a ceiling amount that temporarily holds money on the card: the customer sees a hold higher than the purchase, prepaid cards get drained and youth cards get declined, and the release takes days. PayPlus places no hold — an exact, real-time charge only for the amount actually purchased.
PayPlus vs. other solutions
| Feature | PayPlus | Other solutions |
|---|---|---|
| Credit hold | None - exact charge only | Usually Pre-Auth on a ceiling amount |
| End-to-end solution | Full - single provider | Usually split across several providers |
| Leading enterprise clients | Decathlon, SodaStream, Fox and more | Varies |
| Regulated international activity | European EMI license | Usually local only |
| Invoices + allocation numbers | Automatic, built-in | Depends on the solution |
| MDB / Telemetry support | Full | Partial |
| Real-time reporting | Central Dashboard | Limited |
Common mistakes to avoid
Choosing a protocol based only on the machine, without checking which clearing providers actually support it.
Switching to a provider that holds a credit line — hurts approval rates and generates customer complaints.
Replacing an entire fleet of Executive machines instead of upgrading with a converter.
A fragmented solution split across several providers with no single point of responsibility.
Skipping Idempotency — leads to double charges during communication dropouts.
Failing to cross-check payment approval with Vend Success — causes charges without product delivery.
FAQ
Summary
MDB and Executive are not competitors but two standards serving different generations of vending machines: MDB is the natural choice for new projects thanks to its flexibility and compatibility with IoT, the cloud, and contactless payments; Executive remains relevant for upgrading older fleets. In many cases the right solution is not to choose between the two, but to choose a payment platform that supports both.
PayPlus combines clearing without a credit-line hold, a full end-to-end solution, the trust of the largest brands in the market, and a European financial license — making it the leading choice for machine operators looking for a single, reliable, and advanced solution with the ability to grow in Israel and worldwide.
