Confirm payment event
Define what your system sends after approval: order ID, device ID, action, amount, or session.
Payment callback hardware
Turn a payment callback into a real machine action.
Use QuLink when your payment system already confirms orders, but you need hardware to start, unlock, dispense, pulse, or run a physical machine.
Own payment stackMachine actionResult callbackHardware bridge
Project fit
For payment platforms and apps that need machine execution
Buyer signals
- You own the checkout, wallet, or app approval flow.
- A successful payment should trigger a machine action.
- Your server needs a result callback for operations or support.
- You need hardware that can talk to relay, pulse, MDB, serial, or OEM wiring.
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
Payment stays in your stack; the board executes the machine-side command
QuLink receives your approved reference, translates it into the correct physical output, and returns status or result events.
- Trigger source
- wallet callback, payment provider webhook, app approval, operator backend
- Machine output
- relay, pulse, MDB vend, unlock, serial command, timed session
- Returned events
- command.accepted, machine.started, vend.result, session.completed, fault
- Project mode
- payment app integration, operator rollout, OEM hardware layer
Workflow
From machine interface to API-controlled result.
Map action profile
Map each approved event to a machine-side command.
Execute on device
The QuLink board triggers the machine and tracks the result.
Return callback
Your backend receives success, failure, timeout, or fault events.
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/{device_id}/commands
{
"command": "start_session",
"source": "payment_callback",
"reference_id": "PAY-APP-7781",
"machine_action": {
"type": "relay_or_mdb"
}
}
Start the project
Send the first machine details before writing a full spec.
Send your payment callback shape, machine type, action after approval, data fields needed, and target deployment count.
Useful first message
- Machine type and target country
- Machine photo, board photo, or wiring photo
- Action after API command or payment
- Data upload and estimated quantity
FAQ
Questions buyers usually ask before a sample test.
Does QuLink need to process payment?
No. QuLink can provide QR payment, but it can also simply receive your payment approval and execute the machine action.
Can one payment trigger different actions?
Yes, actions can map to device ID, product, relay channel, timed session, or firmware profile.
Can QuLink report failures?
Yes. Failure, timeout, fault, and result events can be included when the machine-side integration supports them.
Related use cases