Our terminals can be connected to Vending Machines over the MDB bus. This article explains how the integration works, which behaviours are negotiated automatically, what you can configure during onboarding, and what is supported today.
How the integration works
The terminal runs in MDB Slave mode and connects to the Vending Machine Controller (VMC) using the MDB v4.3 protocol. The primary hardware is the IM30, which has a physical MDB Slave port. In this setup the vending machine is the master and the terminal acts as the cashless peripheral: the VMC requests a payment, Pay On Site processes it, and the result is returned to the VMC, which then delivers the product.
At each connection, the terminal and the VMC negotiate two things automatically: the highest command level both sides support, and the reader behaviour mode. You do not set these on the terminal.
Feature levels
MDB defines three cashless feature levels. The level is negotiated between the machine and the terminal at connection time — it is not something you fix in configuration. In testing, a terminal advertising Level 3 worked correctly with Level 1 and Level 2 machines, adopting the machine's level automatically.
| Level | Behaviour |
|---|---|
| Level 1 | Basic cashless payment — a single product, exact price known |
| Level 2 | Session-based vend — a maximum amount is shared, single product |
| Level 3 | Multi-vend — a maximum amount is shared, customer selects several products until the limit is reached |
Note
The level is auto-negotiated. The terminal adapts to whatever the vending machine presents.
Reader behaviour modes
Alongside the level, the terminal and VMC agree on when the contactless reader becomes active:
- Always Idle — the reader is always on. The customer taps first, then selects a product.
- Button First — the reader activates only after the customer has selected a product.
What you configure during onboarding
Most parameters are either negotiated automatically or inherited from the merchant record rather than set per terminal. The table below summarises what to expose.
| Parameter | Where it lives | Expose during onboarding? |
|---|---|---|
| Feature level (L1/L2/L3) | Auto-negotiated with the machine | No — not recommended to override |
| Multi-vend | Terminal / group configuration | No — better kept hidden (see limitations) |
| Country, currency, languages | Managed, linked to the merchant | No — inherited from the merchant |
| Schemes | Managed, linked to the merchant | No — inherited; drive the logos displayed |
| Payment mode (preselection) | Fixed behaviour | No — only preselection is supported today |
Country, currency, languages and schemes are managed centrally against the merchant, so they don't need per-terminal exposure. Schemes mainly drive which card scheme logos are displayed; it's worth managing them the same way in Pay On Site for consistency.
Payment mode: preselection only
Pay On Site currently supports preselection mode only — the exact price is known at the time of authorization. The customer selects a product (or products, up to the session limit), the VMC sends the final amount, the terminal authorizes that exact amount, and the VMC delivers.
There is no preauthorization mode, where the terminal would authorize a maximum and capture the actual amount afterwards. This is not exposed as a parameter because it isn't supported.
Reliability: negative vend
If a payment succeeds but the VMC fails to deliver the product, the flow triggers a negative vend — an automatic refund — so the customer is not charged for a product they didn't receive.