QR-Authorised Dispensing: Separate Scanning, Permission and Vend Confirmation
WEIMI INSIGHTS / SYSTEM INTEGRATION • AUTHORISED ISSUE
Reading a code is not the same as granting permission to dispense. Keep identity, authorisation and physical completion as separate events in the integration.
Design a non-payment issue workflow in which your application approves the request and the machine reports what happened.
SCAN
Pass the required input through a supported interface.
AUTHORISE
Let the approved application decide the permitted action.
CONFIRM
Record the machine’s actual supported outcome signals.
Agree the complete state flow before integration. A scanner connection and a dispense command do not by themselves provide duplicate prevention, permission checks or reliable completion records.
01 / BUYER NOTES
1. Define the role of the scanned code
State whether the code identifies a person, an order or a one-time entitlement. These uses have different data and access requirements. Keep the code’s purpose limited to the approved workflow rather than placing unnecessary personal information in it.
Ask how the proposed scanner delivers data to the application. Confirm the supported interface, input format and handling of incomplete or unreadable scans. A scanner that works on a desktop test does not automatically establish integration with the machine’s control flow.
Provide clear instructions for the user. They should know where to scan and what to expect next. The interface should not imply that a successful scan has already authorised or completed a dispense when those decisions happen in later stages.
02 / BUYER NOTES
2. Keep the permission decision in the agreed system
Identify which application decides whether the request is allowed and what it may release. For internal equipment or supply issue, this may be the organisation’s own system. Ask the equipment supplier to confirm whether the proposed configuration can operate under that external authorisation model.
Define the approved response when permission is denied or unavailable. A network timeout should not silently become permission to dispense unless a specifically reviewed offline policy provides for that behaviour. Keep the decision with the organisation responsible for the service rules.
Limit the requested action to the authorised item and quantity. The integration should not rely on the customer choosing any product after a general identity check if the entitlement is narrower. Test the actual relationship between approval, selection and controller command.
03 / BUYER NOTES
3. Prevent a repeated scan from becoming an unintended repeat issue
Decide how the workflow identifies one request and recognises a retry. Users may scan again when the screen is slow or unclear. The application and controller integration need an agreed method that avoids treating every repeated input as a new authorised issue.
Test the case where the application loses contact after sending a command. It needs a supported way to determine the result before deciding what to do next. Blindly resending the command can create a different problem from the original interruption.
Ask the supplier what request references and status information are available. Keep any implementation within the documented interface and supported controller behaviour. A general claim of API access is not enough evidence that the required duplicate and recovery controls exist.
04 / BUYER NOTES
4. Distinguish command acceptance from physical completion
Request a definition of every result reported by the machine. A controller accepting a command, a mechanism completing movement and a product being detected are not necessarily the same event. The application should display and record only the outcome supported by the available evidence.
Define uncertain outcomes explicitly. If the system cannot determine whether the item was delivered, the operator needs a review process rather than an automatic success or immediate repeat. Agree what information is retained and how the user is directed to support.
Keep any high-impact decision outside an unsupported machine inference. The vending equipment can execute and report a defined task, but the responsible business or professional workflow must determine whether an item may be issued. Do not expand the equipment’s role through ambiguous status wording.
05 / BUYER NOTES
5. Test the complete authorised-issue journey
Run normal and exception cases using a suitable test environment and approved sample data. Include unreadable input, denied permission, repeated scans, delayed responses and a controlled dispensing failure. Compare the application record with the machine’s supported status information.
Confirm the user-facing fallback and staff recovery procedure. A non-payment workflow still needs support when a person cannot obtain an authorised item. Keep the process clear without exposing sensitive identifiers on a public screen or in an unnecessary shared log.
Send WEIMI a state-flow description and the required interfaces. Ask for configuration-specific feasibility confirmation and English documentation if your team needs it. Approve the integration only when the system owners can explain each transition from scan to final recorded outcome.
Three events to keep separate
Code read
Means: The input was captured in a supported format.
Does not mean: The request has been approved.
Request authorised
Means: The responsible application permitted a defined action.
Does not mean: The physical item has been delivered.
Dispense outcome
Means: The machine reported its supported result.
Needs: Clear interpretation and an uncertain-outcome process.
PRACTICAL ANSWERS
Questions about QR-authorised dispensing
Can scanning a QR code directly authorise any vend?
Only under an explicitly designed and approved workflow. Scanning, permission and dispensing should be treated as separate steps.
What should happen after an uncertain dispense result?
Use the agreed status-review and recovery process. Do not automatically repeat a command without establishing how duplicates are prevented.
Does no-payment mode remove the need for transaction records?
No. The operator still needs appropriate issue and outcome records, with data limited to the legitimate service requirements.
YOUR NEXT STEP
Specify the authorisation flow before the hardware command
Share your application workflow and required scanner inputs with WEIMI. Request a supported interface review covering permissions, retries and dispense outcomes.
Explore equipment →Discuss your requirements →