Keep the controller, add an API gateway
Your server needs vend commands, MDB events, and machine status without replacing the vending controller.
Guides
MDB gateway selection
How do you choose an MDB gateway for a vending machine?
Choose an MDB gateway by the controller path, payment ownership, data needs, and backend ownership, not by board price alone. Confirm MDB 4.2/4.3 or the actual controller version, define the vend action and result, and validate one machine before rollout. QuLink is machine-side hardware, not a payment acquirer, and compatibility is confirmed on a sample.
MDB 4.2/4.3 targetAPI + telemetrySample validationOwn backend
Part of MDB Vending Machine API Gateway
Key facts
What to decide before comparing MDB gateways.
Controller first
MDB 4.2/4.3 is the target cashless path; older or custom behavior needs review.
Payment ownership
Decide whether QuLink QR payment or your own reader, PSP, or wallet authorizes the vend.
Data scope
Heartbeat, vend result, faults, and telemetry are possible when exposed; inventory is not guaranteed.
Rollout proof
Validate one machine before a fleet; do not choose a gateway from a model name alone.
Pending sample: exact MDB timing, vend mapping, timeout, and result behavior are confirmed on the actual machine.
Starting points
Four common MDB gateway projects.
Start with what the machine already has: a controller, a reader, a backend, or a data requirement.
Keep the reader, add a gateway
The existing reader or PSP stays; QuLink adds an independent machine-side control or data path where supported.
Add data visibility only
You need heartbeat, vend result, faults, or usage without changing the payment authorization path.
Evaluate OEM or custom MDB
Older MDB versions, custom firmware, or unusual controllers need a firmware review and real-machine sample.
Gateway vs board vs reader
What are you actually selecting?
The label matters less than the job. A gateway, cashless board, reader, and data bridge solve different problems.
| Option | Best for | What it does | What to confirm |
|---|---|---|---|
| MDB gateway | API or server control plus MDB events. | Maps commands and events between your backend and the vending controller. | MDB version, cashless path, event schema, and result mapping. |
| MDB cashless board | Payment authorization inside an existing machine. | Sends the cashless authorization; the controller decides whether to dispense. | Reader or PSP, authorization flow, and vend result. |
| Card reader replacement | A reader or network problem only. | Approval happens at the reader; may not add independent machine data. | Reader support, payment host, and contract. |
| Data bridge only | Telemetry without changing payment. | Reads status, faults, or usage without authorizing a vend. | Available interface, poll rate, and fields. |
One project may combine roles. Select by the job you need, then confirm the exact profile on a sample.
Selection checks
Check these four points before choosing.
MDB version and cashless path
Confirm the controller's MDB version and whether the cashless path is available. MDB 4.2/4.3 is the target profile; older versions need review.
Who authorizes payment
Decide whether QuLink QR payment, an existing reader, your PSP, or a wallet callback authorizes the vend.
Command and result mapping
Define product or slot, amount, payment reference, timeout, vend result, and what happens after a failure.
Data and operations
Confirm heartbeat, fault, telemetry, dashboard, retention, and who owns the backend and alerts.
Sample path
From machine photos to a gateway decision.
Capture the machine
Machine front, controller label, MDB harness, connector, reader, and model plate.
Define the job
Write one sentence: what should the gateway authorize, trigger, or report?
Map the interface
Confirm MDB version, cashless path, command shape, result fields, and failure behavior.
Test one machine
Validate authorization, dispense, result or timeout, reconnect, and data delivery before rollout.
Where QuLink fits
Machine-side MDB integration, not payment acquiring.
What QuLink can do
- Map server commands or payment approval to MDB cashless behavior.
- Return vend result, payment reference, fault, and device status when exposed.
- Add an independent status or telemetry path while the existing reader stays in place.
- Support a pilot on one machine before a repeatable fleet profile.
What it does not replace
- Payment acquiring, settlement, or wallet balance.
- The controller manufacturer's MDB documentation or wiring diagram.
- A guarantee that every MDB version or controller behaves the same.
- Certified electrical installation or machine safety.
Not the right fit if
- You only need a payment acquiring account and no machine-side action.
- The controller has no usable MDB path and cannot be evaluated from photos.
- There is no machine, controller, reader, or wiring information for a sample.
Interface and data
What the gateway selection needs to define.
- Machine interface
- MDB cashless path, vending controller, optional relay or serial auxiliaries
- Server side
- API command, webhook event, payment callback, telemetry
- Data returned
- payment reference, vend.result, fault, timeout, online status when exposed
- Project mode
- gateway selection, API integration, telemetry pilot, OEM controller
FAQ
MDB gateway questions.
Is an MDB gateway the same as a card reader?
No. A reader approves payment; an MDB gateway maps server commands or payment approval to the controller's MDB cashless path and can return machine events.
Do we need a gateway if we already have a card reader?
Not always. A gateway is useful when you need API control, an independent data path, telemetry, or a result callback that the current reader does not provide.
Can we keep our own payment provider?
Yes. Your PSP, wallet, or app can confirm payment first, then call the machine-side command or callback. QuLink is not the acquirer.
What data can the gateway return?
Heartbeat, vend result, timeout, fault, device status, and telemetry when the controller exposes them. Product-level inventory is not guaranteed.
What should we send first?
Machine model, controller and MDB photos, reader or PSP details, target action, required data, and expected quantity.
Project RFQ
Send a machine photo. We help identify the board, interface, and next test step.
Send the machine model, controller and MDB harness photos, current reader or PSP, target action, data requirement, and expected quantity.
A good first message
If you are unsure about the exact interface, send what you have. Photos often answer more than a long spec.
- Machine type and target country
- Machine photo, board photo, or wiring photo
- Action after payment or API command
- Need data upload? expected quantity?
Fastest first step
- Send a machine photo
- Describe the action after API or payment
- Tell us if data upload is needed
Related use cases