Choose QR role
Decide whether QR is only for collecting payment or also for identifying a machine action.
QR payment guide
Static QR vs dynamic QR for self-service machine payment.
Use this guide when a machine operator is deciding whether a printed static QR code is enough, or whether the machine needs a dynamic QR workflow connected to a controller board and payment callback.
Static QR comparisonDynamic QR workflowPayment callbackMachine result upload
Project fit
When QR design changes machine control
Buyer signals
- A machine must start automatically after payment, not after manual checking.
- The project needs device ID, price, product, relay channel, or session encoded in the payment flow.
- Your backend needs payment reference, result upload, and fault handling.
- You need to choose between low-cost sticker flow and integrated machine control.
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
Static QR can collect money; dynamic QR can drive machine workflow
For unattended machines, the important question is not only how the customer pays. It is how payment approval reaches the machine and how the machine reports the result.
- Static QR
- Simple printed merchant QR, usually low-cost, but often requires manual validation or loose reconciliation
- Dynamic QR
- Device/product/session-specific code, exact payment reference, server callback, and automated machine action
- Machine output
- relay, pulse, MDB vend, unlock, serial command, timed session
- Returned events
- payment reference, command accepted, machine started, session completed, vend.result, fault
Workflow
From machine interface to API-controlled result.
Map machine action
Define product, relay channel, session duration, unlock, or vend command.
Connect callback
Payment approval from QuLink QR or your checkout triggers the controller board.
Report result
The board uploads success, failure, timeout, telemetry, or session result.
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/SELF-18/commands
{
"command": "start_session",
"source": "dynamic_qr_payment",
"reference_id": "QR-SESSION-18",
"machine_action": {
"type": "relay",
"duration_ms": 900000
}
}
Project RFQ
Send a machine photo. We help identify the board, interface, and next test step.
Send the machine type, payment country, price/session rule, and whether the machine should start automatically after payment.
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.
Can a static QR start a machine automatically?
Usually not by itself. Automatic start normally needs a payment callback and a controller board connected to the machine.
When is dynamic QR worth it?
Dynamic QR is worth it when device identity, exact amount, product, session, or result tracking matters.
Can QuLink support either model?
QuLink can help with QR payment workflows or with receiving your payment callback and triggering the machine-side action.
Related use cases