MDB is the protocol that connects many vending machines, kiosks and unattended devices to their payment peripherals. MDB by Paying.co puts one API in front of the serial bus, so your application talks HTTPS while the connector handles polling, state machines, and vend control for supported equipment.
The path from evaluation to a pilot deployment. Licensing is ordered online at the existing license portal.
Confirm your equipment, MDB interface hardware, payment device, and processor environment below.
Order the Datacap or PAX connector for each device at the license portal.
Install the connector and configure it for your payment device and equipment.
Run a test vend with test data in an approved test environment, then a pilot, then roll out.
The software license covers the connector. A complete deployment also needs hardware, connectivity, and a processing relationship.
A per-device annual license for the Datacap or PAX connector, with MDB protocol support for supported equipment, the HTTPS API, webhooks, and audit logging. Documentation, updates, and support terms are confirmed at checkout.
We do not promise compatibility with every MDB machine. A deployment on one model, firmware, processor, or region does not establish support for others, so combinations are confirmed, and some require assessment.
| Connector and version | Device and OS | Interface or controller | Gateway or processor | Region and limits | Status |
|---|---|---|---|---|---|
| Confirmed per deployment | Confirmed per deployment | Confirmed per deployment | Confirmed per deployment | Confirmed per deployment | Supported, or requires assessment |
Not sure whether your equipment is supported? Check compatibility with our team. Include machine make and model, controller or interface, payment device, connector or environment, gateway or processor, country, deployment size, and any technical documentation.
MDB uses master-slave polling over a 9-bit serial bus, address mapping, level negotiation, and cashless device state machines. The connector handles that protocol work, and your application writes the business logic for taking a payment.
The connector speaks MDB to the machine and HTTPS to your code. Polling, acknowledgements, address mapping, and state transitions stay behind the API.
The connector coordinates communication with MDB peripherals within the limits of the MDB specification and your equipment.
Tap, chip, wallet, or QR payment is wired into the MDB cashless sequence so the machine is authorized to vend after the processor approves.
Reconnect and timeout handling, audit logs, and webhook events. Retry and recovery behavior depends on the equipment and provider.
| Component | What it controls |
|---|---|
| Your application | Business logic, price, and the call to start a payment |
| MDB connector | MDB protocol communication and the API and webhooks your application uses |
| Payment device and provider | Card acceptance, authorization, and approval or decline |
| Machine controller | Dispensing and the feedback it makes available |
A payment approval does not prove an item was delivered. Sending a vend command does not prove delivery either. What you can confirm depends on the feedback the machine provides.
The payment provider returns an approval or decline.
The connector sends the vend authorization to the machine.
The machine reports success or failure, where its interface supports it.
Ambiguous outcomes, duplicate protection, reversals and refunds, and reconciliation depend on the actual implementation, provider, and equipment. Learn how to design recovery when payment is approved but the machine did not start.Understand MDB levels and how they shape vending payments.
Charge, refund, status, and webhooks are the things a typical application needs. The bus details stay inside the connector. The example is illustrative and uses test data; API details are confirmed in the documentation you receive with your license.
One call starts the payment flow, covering authorization and vend release.
Approved, declined, vend complete, device reset, and processor timeout events as JSON.
Query connected devices for address, level, state, and last transaction.
Bus traffic and API calls are logged to help with troubleshooting.
Same protocol underneath, same install pattern. Choose the connector that matches the payment device and processor environment in your fleet. PAX refers to the device environment, not a processing relationship.
MDB bridge for Datacap-powered terminals using NETePay and dsiEMVUS, with webhook callbacks, configurable timeouts, and audit logging.
MDB bridge for PAX terminals running BroadPOS, with support for A-series and Aries hardware. Processor support depends on your configuration and is confirmed during setup.
MDB applies where the equipment exposes an MDB interface. Pulse-based equipment is different: see Pulse Pay Connect and which interface your machine needs.
Snack, beverage, coffee, and combo vending with cashless payment integration.
Ordering, ticketing, and check-in where payment triggers an action.
Equipment where payment authorization triggers a physical action, if it exposes an MDB interface.
Purpose-built machines that need a modern payment API over an existing MDB controller.
Need custom engineering beyond the product, such as an application, backend, or controller adapter? See Unattended Payment Systems.
License the connector matching your payment environment. Pricing is per device per year. Review the licensed unit, activation, renewal, replacement, and support terms at checkout.
Pick your payment environment, license the connector for each device, then test and deploy. Not sure your equipment is supported? Talk to us first.
License a connector →