Today, almost all vending machines are equipped with cashless payment terminals. Vendotek POS terminals are one of the most popular solutions, successfully used in machines from various manufacturers.

 

You encounter vending machines every day — coffee and snack machines in office buildings, train stations, subways, and shopping centers, as well as equipment at self-service car washes and entertainment areas.

 

The MDB (Multi-Drop Bus) protocol is typically used to communicate with coffee and snack machines. This is one of the main protocols for connecting payment devices to vending equipment. MDB facilitates data exchange between the vending machine controller (VMC), the cashless payment terminal, the coin changer, the bill acceptor, and other equipment.

 

In this article, we'll cover in detail:

• How interactions using the MDB protocol work
• How initialization occurs and what nuances need to be considered

This material is useful for integrators, technical specialists, and VM owners. Understanding the principles described helps customers configure the equipment without errors and quickly resolve device interaction issues.

MDB (Multi Drop Bus) is the most popular and widely used in modern European and Chinese vending machines, as well as in car washes, gaming machines, etc.

 

 

Executive (Protocol A) — a simpler protocol, where the control device is usually a coin changer.

 

Much less common protocols are:

• BDV — for German vending machines;
• VCCS — for Japanese machines.

 

How to determine if a vending machine supports the MDB protocol

1. Check the user manual, manufacturer specifications, or online documentation—they usually contain information about supported protocols.
2. If the vending machine has a coin changer and bill acceptor, check for MDB markings on the devices themselves or near the connectors.
3. Check for stickers on the equipment casing. Machines often have stickers indicating MDB compatibility on the outside of the casing or near the coin changer/bill acceptors.
4. Pay attention to the connectors. MDB-compatible machines have distinctive multi-pin connectors. Examples and diagrams can be found, for example, here.
5. Consult a vending machine technician or integrator — they are able to accurately determine the machine's compatibility with MDB.
6. Contact the manufacturer. Providing the machine's model and serial number will provide you with precise information about the protocols implemented on the machine.

MDB uses a serial data bus, which has specific technical requirements. Key features include:

• Baud rate: A fixed rate is 9600—relatively low by modern standards, but sufficient for stable operation of vending equipment.
• Data format: A 9-bit data frame is used, with the ninth bit used to separate address and data bytes.
• Electrical characteristics: Operates from a 24 V DC network, providing reliable power to peripheral devices.
• Connector type: Standard 2-row, 6-pin Molex Mini-Fit Jr 6-Way interface for connection to the MDB, including power, ground, and data lines.
• Polling mechanism: The VMC continuously polls slave devices, requesting data and sending commands for synchronous operation.

All devices are connected to a common data bus — that is, they are connected by a single wire. The Master device controls the bus, while all other devices operate in Slave mode.

 

Usually, the VMC acts as the MDB Master. In some configurations, it may be a coin changer (using the Executive protocol) or a telemetry modem.

 

Typical Slave devices include: a cashless payment terminal, a bill acceptor, a coin changer, a telemetry modem, and other peripherals.

1. Via MDB

2. Via Executive using coin changer

3. Via Executive using telemetry modem

4. It is also possible to connect via special RS232-MDB converters

It's important to note that due to the specifics of the physical interface, the MDB protocol is sensitive to current fluctuations. Design changes to the MDB Master hardware on the VMC side (for example, changing resistor values ​​in the circuit) can lead to desynchronization during data exchange with other devices on the bus. This is especially critical for devices sensitive to such fluctuations due to their own slave implementation.

The connection diagram depends on the protocol the machine operates in.

 

VMC connected via MDB:

• The VMC is the master device on the bus.
• The Vendotek terminal acts as a slave device and is connected between the machine and other peripheral devices (bill acceptor, coin changer, etc.) via a common bus.
• Product prices are set in the VMC.

VMC connected via Executive:

• The master device is the coin changer, which communicates with the VMC via the Executive protocol.
• The Vendotek terminal also acts as a slave device and connects to the coin changer via the MDB interface.
• Prices can be set either in the coin changer (Price Holding mode) or in the VMC (Executive Standard mode).

It's worth noting that some VM developers may misinterpret the MDB protocol specification, which may result in some devices not functioning properly. For example, bill acceptors may become blocked, requests may not be received by the cashless payment terminal, etc. Also, some VM models may not support MDB cashless devices as such.

In the MDB protocol, the Vendotek cashless payment terminal is a cashless slave device. Key configuration parameters include:

• cashless device address;
• decimal point;
• peripheral functionality level;
• «virtual» credit.

Let's look at each of these parameters in more detail.

 

Cashless device address

 

From 0 to 2 cashless devices can be connected to a MDB bus simultaneously.

Each is assigned its own address, which the Master Device (VMC) uses to communicate with them:

• Cashless #1: 00010xxxB (10H), requests start with 1, for example 1305xxxx
• Cashless #2: 11000xxxB (60H), requests start with 6, for example 6305xxxx

Typically, a Vendotek terminal is configured as Cashless #2 if:

• A key reader system is used (small portable devices that can be used for discounts or making purchases, such as the Caiman Lite MDB);
• The terminal connects to the MEI 8500 coin changer;
• The Cashless #1 address is already occupied by the telemetry modem.

 

Decimal point

 

When a purchase request is made from the Master device, the purchase amount is transmitted without cents. The cashless payment terminal interprets this amount according to the set decimal point.

 

A common issue is a mismatch between the decimal point on the VMC and the cashless device. For example, if the MDB Master device is set to a price of 100 with a decimal point of «0,» and the cashless device is set to «2,» the cashless device will interpret the amount as 1. Therefore, to avoid errors, the decimal point on the terminal and the machine must match.

 

 

Peripheral functionality level

 

The functionality level determines which additional features the device supports. Vendotek terminals support the basic features of Level 3 functionality. The levels can be roughly divided as follows:

• Level 1 — basic
• Level 2 — Level 1 + card recharge option (Revalue operation)
• Level 3 — Level 2 + Always Idle mode (sale without touching the terminal screen) and other functionalities

 

«Virtual» credit

 

When selling for cash, the customer immediately deposits an amount that becomes the actual credit, which can be used to make a purchase.

 

In the case of cashless payments, the terminal «tricks» the machine or simulates the availability of funds by sending a fictitious amount, called a «virtual» credit, to the VMC. This is necessary to begin the purchase session, especially when using Level 1 or Level 2. The terminal notifies the machine that funds are available before the card is actually debited.

After transferring the «virtual» credit, the customer can select an item, the price of which must not exceed this amount. The «virtual» credit value in the machine settings must be higher than the one displayed on the terminal.

 

 

Polling devices on the bus

 

The MDB-Master device regularly sends POLL commands via the MDB protocol to all connected Slave devices.

 

 

Poll frequency

 

The frequency of sending POLL commands can vary from 25 to 200 ms. It's important to note that polling too frequently can interfere with the slave device's ability to process POLL commands, as responses will be delayed. Conversely, polling too infrequently can slow down the equipment, for example, by reducing the speed of accepting coins or bills. The optimal recommended polling frequency for all devices is 125–200 ms.

 

 

After command behavior

 

Once the MDB-Master (VMC) has issued a command, it must wait for a complete response from the cashless device before sending the next one.

 

In response, the Slave device can transmit:

1. simple ACK (acknowledgement) (ex., to READER ENABLE)
2. an informed response with data (for example, to the READER CONFIGURATION DATA command), which the device can transmit in two ways:
   1. immediately after the command
   2. first acknowledge receipt of the command with ACK, and then transmit the data.

After receiving an ACK from a device, the VMC must continue sending POLL requests until the cashless device responds with data or until the maximum application response time (specified in READER CONFIGURATION) has expired.

 

By default, the maximum response time from a cashless device is 5 milliseconds. During this time, the device must send an ACK, transmit data, or send a NAK. (negative acknowledgement).

 

 

No response behavior

 

If a slave device remains unresponsive for a long time, the VMC should terminate all internal processes and then reset the bus connection using the RESET command. Before doing so, it is recommended to wait at least 10 times longer than the maximum response time.

 

If the VMC cannot communicate with a device within the «maximum application response time», it should attempt to reset that device once every 10 seconds and continue with another available Slave device that is still responding to requests.

 

If a command requires data to be returned, the VMC must wait at least 30 seconds for a response, unless otherwise specified. While the cancellation is in progress, the terminal does not respond to VMC requests. Once the machine receives a response to the next POLL, it can conclude that the cancellation is complete.

 

 

Initialization on the bus

 

After polling devices, the MDB Master initializes the connected slave devices on the bus. While executing initialization commands, the VMC determines which additional functions are supported by the peripheral devices and enables only those that will be used.

 

Until a specific function is activated, a peripheral device must ignore commands related to that function and not respond to them. For example, a Level 3 peripheral functionality command can only be sent to a slave device that supports that level. It should not be transmitted to devices operating at Level 1 or Level 2.

 

The peripheral device is also required to send only responses supported by the VMC: a Level 3 response must only be transmitted to a VMC that supports this level or higher. The exchange level is the lower of the two values—the machine level and the peripheral device level.

1. POLL — VMC starts polling

Since the VM can start up faster than the terminal, the terminal doesn't have time to respond to the first POLL commands and doesn't send a JUST RESET request. Therefore, the protocol specification recommends sending a RESET after the first received POLL response.

2. RESET — VMC resets the connection on the bus and puts the terminal into its initial state.

JUST RESET — the terminal confirms the reset with a JUST RESET command.

3. SETUP — CONFIG DATA — VMC informs the terminal of the supported level of peripheral functionality and additional information.

READER — CONFIG DATA — the terminal transmits data about its functionality level, decimal point, country code, currency and the maximum time without a response from the cashless device (Application Maximum Response Time).

 

4. SETUP - MAX/MIN PRICE — VMC reports the maximum and minimum possible product price.

5. EXPANSION REQUEST ID — VMC transmits additional information: manufacturer, firmware version, etc.

PERIPHERAL ID — The terminal provides information about itself: manufacturer, device model, etc., and when working in Level 3, information about activated functions.

6. EXPANSION ENABLE OPTIONS — VMC transmits information to the cashless device about the activation of functions in Level 3.

7. READER ENABLE — VMC switches the terminal to active mode.

 

Once initialization is complete, the device is ready to accept cashless payments.

Sometimes there are machines/coin changers that do not always send the Reader enable command.

VMs have two modes of product dispensing: multiple and single vend.

• Multiple vend — Allows the customer to select and pay for multiple items in a single transaction. This is typically implemented through a shopping cart interface, which improves convenience and speed of service but requires more complex machine logic and payment system operation.
• Single vend — The customer pays for only one item at a time. This is easier to implement and is suitable for VMs with a simple interface or for selling individual items.

 

In practice, single vends are more often used, since the implementation and support of multiple vends is technically more complex.

 

Sale process

 

The cashless sales process involves a sequential exchange of requests between the VM and the payment device.

 

The primary request is the Vend Request (13 00H). Once sent, the terminal enters payment mode (card or QR code). The request only transmits two parameters:

• product price
• cell/spiral ID

Depending on the VM settings, the following may be used:

• a single price list for cash and cashless sales
• separate price lists

If a separate price list is used for cashless transactions, it's important to ensure that the prices are correct. For example, the default price for an item can be set to 0, in which case the VM will allow a zero-dollar sale. This will result in a free purchase, as the terminal doesn't need to debit any funds.

basic payment scenario, vend session starts by touching terminal screen

1. The customer touches the terminal screen
2. The terminal opens a session and sends a corresponding request to the VMC.

In the Begin Session request, the terminal reports the maximum «virtual credit» within which payment can be made upon command from the device.

3. The customer selects a product on VM
4. The VMC (if the VMC is running in MDB) or the coin changer (if the VMC is running in Executive) sends a request to the terminal to debit funds.

After this, the VMC «remembers» the customer's choice for a specified period of time and waits for the transaction result from the terminal. This period of time is called the «hold timeout» for the selected item. In the VMC settings, it may be called: Reservation time / Booking time / SET TIMEOUT / Cashless sales time.

 

If the sale does not occur within this timeout, the machine reports the sale as unsuccessful at the dispense stage.

5. The customer pays for the products and the transaction is carried out with the bank.
6. VMC is awaiting the transaction result:
   1. If the operation is unsuccessful, the terminal reports this with VEND DENIED — VMC terminates the session (step 8).

2. If the transaction is successful, the terminal responds with VEND APPROVED with information about the amount to be debited, and the VMC proceeds to dispense the product.

7. Product dispense.
   1. If the product cannot be dispensed (or the timeout for holding the selected product selection has expired), the VMC sends a command to Vendotek to cancel the transaction, and the terminal initiates the cancellation of the previously performed operation.

2. If the dispense was successful, the VMC notifies the terminal in a VEND SUCCESS request with information about the ID of the product that was issued.

8. Session ends.

with Always Idle mode, without touching the terminal screen

If Always Idle mode is enabled, the payment session (transition to payment) begins immediately upon selecting a product. The sequence of steps is identical to Level 1, except for sending the Begin session button.

1. The customer selects a product on VM.
2. The VMC (when the VMC is running in MDB) or the coin changer (when the VMC is running in Executive) sends a request to the Vendotek terminal to write off funds, indicating the amount and the cell/spiral number of the product.
3. The customer pays for the goods by tapping or inserting a bank card, and the transaction is completed.
4. The VMC waits for the transaction result:
   • if the operation is unsuccessful, the VMC terminates the session
   • if the transaction is successful, the VMC proceeds to product issuance

5. If the product cannot be dispensed (or the timeout for holding the selected product expires), the VMC sends a command to Vendotek to cancel the transaction, and the terminal initiates a refund.

   If the issuance was successful, the VMC notifies the terminal about it.

6. Session ends.

This is accomplished using the Vend Cancel command from the machine. For example, the machine sends such a request during a payment session if the cancel or reset button is pressed.