Payment approval
A card reader, QR checkout, wallet, or payment provider confirms the payment outside the vending controller.
Guides
MDB cashless flow
How does an MDB cashless transaction work?
An MDB cashless transaction starts with payment approval from a reader, QR checkout, wallet, or payment provider. The machine-side cashless device or gateway then sends the authorization over MDB, the vending controller dispenses, and the available result is reported for reconciliation. The exact sequence depends on the controller and is confirmed on a sample.
MDB cashlessVend authorizationResult callbackSample validation
Part of MDB Vending Machine API Gateway
Transaction flow
Four stages from payment to vend result.
Payment approval, MDB authorization, dispense, and reconciliation are separate steps. Keeping them separate makes failure handling clearer.
Vend authorization
The cashless device or gateway sends the authorization over the MDB cashless path; the controller decides whether to accept the vend.
Dispense
The vending controller runs the motor or product release. The available result depends on the controller.
Result and reconciliation
The machine-side board or reader reports success, failure, timeout, or fault; your backend matches it to the payment reference.
What to verify
Check these four points on a real machine.
MDB version and cashless path
Confirm the controller version and whether the cashless path accepts the project's authorization model. MDB 4.2/4.3 is the target profile; older versions need review.
Vend mapping
Confirm product/slot, price, authorization amount, timeout, and whether the controller requires a selection before authorization.
Result behavior
Determine whether the controller reports vend success, failure, or fault events. If it does not, define a safe timeout and reconciliation rule.
Failure and retry rules
Define what happens when payment succeeds but the vend fails, times out, or the machine goes offline.
Sample flow
From payment callback to a reconciled test.
Approve a test payment
Use a test reader, QR flow, or server callback with a known payment reference.
Send the MDB authorization
Trigger the machine-side authorization and observe the controller response.
Verify dispense and result
Confirm the product release and capture the available vend result or timeout.
Reconcile the record
Match payment reference, device ID, slot, result, and timestamp in your backend.
Where QuLink fits
Machine-side authorization, not payment acquiring.
What QuLink can do
- Map a payment callback or server command to the MDB cashless path.
- Return vend result, payment reference, timeout, and fault events when available.
- Keep the existing controller and reader for a pilot.
- Support an optional QuLink QR payment workflow or your own provider.
What it does not replace
- Payment acquiring, settlement, or wallet balance.
- A repair service for a card reader or vending controller.
- A guaranteed result on every MDB controller or firmware version.
- Certified electrical installation or machine safety.
Not the right fit if
- You need payment acquiring rather than a machine-side action.
- The controller has no usable MDB cashless path and cannot be evaluated.
- There is no machine, controller, or payment module information for a sample.
Interface and data
What the cashless path needs to return.
- Machine interface
- MDB cashless path, vending controller, optional auxiliary relay/serial
- Trigger source
- QuLink QR payment, card reader, wallet callback, PSP, or server approval
- Data returned
- payment reference, vend.result, timeout, fault, online status
- Project mode
- MDB cashless pilot, payment app integration, retrofit rollout
FAQ
MDB cashless questions.
Does MDB process the payment itself?
No. Payment approval normally comes from a card reader, QR checkout, wallet, or payment provider. MDB carries the cashless authorization into the vending controller.
Who authorizes the vend?
The cashless device or gateway sends the authorization over the MDB path, and the vending controller decides whether to accept it. The exact sequence depends on the controller.
What happens if the vend fails after payment?
That must be defined in the project. A safe flow uses a timeout, a result event where available, and a reconciliation rule for refunds or retries.
Can we keep our own payment provider?
Yes. Your provider can confirm payment first, then call the machine-side command or callback that authorizes the vend.
What should we test first?
Test one machine with a known payment reference: authorization, dispense, result or timeout, and reconciliation.
Project RFQ
Send a machine photo. We help identify the board, interface, and next test step.
Send the vending machine model, controller and MDB photos, current reader or payment provider, target vend action, and failure rules so we can scope the sample.
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