MDB vs DEX vs API: Which Interface Does Your Vending Project Need?

01   /   BUYER NOTES

Start with the job, not the abbreviation

An operator planning its own mobile app may ask for MDB, DEX and an API in the same email. That is a reasonable starting point, but these labels do not describe interchangeable options. Connecting a payment reader, downloading audit records and allowing an external application to request a vend are different jobs. A machine may support one without supporting the others in the way your project needs.

The practical first step is to draw the journey: customer selects an item, a service authorises the purchase, the controller attempts delivery, and the result reaches the customer and the operator. Write down which organisation owns each step. This exposes missing links sooner than a long list of interface acronyms.

02   /   BUYER NOTES

MDB: the machine and its payment peripherals

MDB, or multi-drop bus, concerns communication between the vending machine controller and compatible peripherals such as payment devices. It is not the name of a universal cloud service. A statement that equipment is MDB-compatible therefore does not establish that your mobile application can directly control every function.

For procurement, record the controller model, reader model, firmware versions and supported operating modes. Then request evidence for the actual combination. A successful purchase matters, but so do a declined authorisation, a cancelled selection and a failed vend. The integration must handle the outcome of the physical transaction, not merely accept a payment request.

Avoid treating a matching connector as sufficient evidence. Electrical, protocol and software requirements belong in the interface review. Installation and electrical checks should follow the documented equipment instructions and be handled by qualified personnel; this article is not a wiring guide.

03   /   BUYER NOTES

DEX: audit information rather than an app command channel

DEX is associated with transferring vending audit information. Depending on the implementation, that information may include sales totals, selection data and other machine records. The presence of DEX does not, by itself, mean that an app can reserve a product, change a price or release an item on demand.

Ask for a representative file from the proposed configuration with an explanation of each field. Establish whether a counter is cumulative or covers a reporting interval, how selections map to products, and what happens when a controller or product layout changes. Without those definitions, a technically successful import can still produce misleading reports.

A useful acceptance exercise is to perform a documented set of test transactions, collect the audit output and reconcile the changes. Record the starting values first. Do not interpret a cumulative counter as sales for the current day simply because the file was retrieved today.

04   /   BUYER NOTES

API: inspect the actual contract

API means application programming interface. It describes a way for software to interact, but says little about the operations a specific vendor makes available. One API might expose sales reports; another might support selected machine commands. Neither scope should be inferred from the word API on a brochure.

Read the documentation before allocating development work. Identify the supported actions, authentication method, permissions, response fields, error states and version policy. Check whether delivery results are pushed as events or must be requested, and whether a test environment is available. Confirm commercial access and support responsibilities separately from technical feasibility.

For an app-led project, agree what happens if a request times out after the machine has already acted. Repeating a command without checking its status can create a second action in some systems. The integration design should define unique transaction references, duplicate handling and recovery explicitly; these are requirements to validate, not claims about a particular machine.

05   /   BUYER NOTES

An interface worksheet for a real purchasing conversation

Use four columns: business action, sending system, receiving system and evidence required. For example, a hypothetical office project could contain three separate rows: authorise a purchase through the chosen payment service; request one item through a documented control interface; reconcile completed sales through an agreed reporting feed. This example is a planning model, not a statement that every product offers those interfaces.

Add failure cases beneath each row. If the reporting feed is delayed, can the customer still receive the product? If authorisation succeeds but dispensing fails, which system creates the exception record? If the app is unavailable, does the machine offer another approved purchasing route or display an unavailable message? Each answer needs an owner.

Finally, attach the exact evidence: protocol documentation, sample messages, sample audit files and a recorded end-to-end demonstration on the proposed configuration. A checklist marked “supported” is less useful than a test showing which fields arrive and which physical outcome they represent.

06   /   BUYER NOTES

Source and limits

The functional distinction between MDB and DEX is explained in Vending Market Watch’s DEX and MDB primer. That article was published in 2008; it provides background, not current compatibility evidence for a machine or reader.

Use current manufacturer documentation and project-specific testing for purchasing decisions. This guide does not assert that all WEIMI configurations include MDB, DEX or a command API. Share your architecture and required operations so the relevant configuration and integration scope can be reviewed.