Send photos first
Share machine, coin/payment module, MDB harness, and controller board photos.
Vending retrofit guide
MDB vs pulse for vending machine QR payment retrofit.
Use this guide when you need to choose whether a vending machine QR payment retrofit should connect through MDB, pulse simulation, relay output, serial, or a custom cabinet-controller profile.
MDB retrofitPulse simulationPayment callbackVend result upload
Project fit
When the interface choice affects the project
Buyer signals
- The vending machine may have MDB, coin pulse, relay, serial, or custom cabinet wiring.
- You need payment approval to trigger a vend action reliably.
- You want to avoid choosing a payment terminal before confirming the machine interface.
- Your backend needs vend result, fault, or online status after the action.
What to send first
- Machine photo or existing board photo
- Interface or wiring note if available
- Target action after API command or payment
- Whether telemetry or data upload is required
Not the right fit if
- You only need a pure payment acquiring account and no machine-side control.
- There is no physical machine action after payment, booking, or API approval.
- The project has no machine photo, board photo, wiring note, or interface clue yet.
Integration model
Start from machine wiring, then choose the payment trigger path
QuLink evaluates the existing machine interface first. MDB is usually cleaner for compatible vending machines, while pulse or relay can fit older machines when the start path is simpler.
- MDB path
- Best for MDB vending controllers, cashless retrofit, vend authorization, and richer machine events
- Pulse path
- Best for older coin-input machines where a pulse count can simulate credit or start
- Relay path
- Best for timed or simple trigger machines that start from dry contact or relay input
- Data returned
- vend.result, session.started, fault, timeout, online/offline, telemetry when supported
Workflow
From machine interface to API-controlled result.
Confirm interface
Identify MDB, pulse, relay, serial, or cabinet-controller behavior.
Map payment approval
Define whether QuLink QR, your wallet callback, or your backend approves the action.
Test one machine
Validate timing, vend result, timeout, and event upload before rollout.
API example
A clear server command or webhook for the machine-side action.
The exact command fields depend on machine interface, firmware profile, and whether payment or your own app triggers the action.
POST /v1/devices/VEND-42/commands
{
"command": "dispense",
"source": "qr_payment",
"machine_action": {
"interface": "mdb_or_pulse",
"slot": "A03",
"pulse_count": 3
}
}
Project RFQ
Send a machine photo. We help identify the board, interface, and next test step.
Send machine photos and the target QR payment flow. We will help decide whether MDB, pulse, relay, or OEM wiring is the right path.
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
FAQ
Questions buyers usually ask before a sample test.
Is MDB always better than pulse?
No. MDB can provide cleaner vending integration, but some older machines are easier to retrofit through pulse or relay after wiring is confirmed.
Can one board support both payment and telemetry?
Yes, depending on the interface and firmware profile.
Can QuLink work with my own payment provider?
Yes. Your provider can confirm payment first, then call QuLink to trigger the machine action.
Related use cases