Dynamic UPI QR Codes for Vending Machines: Transaction Flow and Integration Checklist

A dynamic UPI QR code can make a vending purchase straightforward: choose an item, scan, pay, and collect. Building that experience requires more than generating a different image for every order. You need to know which purchase the payment belongs to, whether the item is still available, what the machine is allowed to do, and how the transaction ends if the connection drops.

Use this article as an integration checklist. The broader payment guide explains the system context, while payment recovery addresses the difficult exception after money arrives. Here the focus is the contract from selection to a verified fulfilment decision.

1. Define one purchase session before creating the QR

Create an application order that records machine identity, selected item or compartment, price snapshot, currency, reservation state, and session identity. Prices and stock can change, so the purchase must refer to the accepted version. Decide how long the product remains reserved and whether the machine permits one or several simultaneous customer sessions.

Keep application identity distinct from provider identity. A provider may expose a QR identifier, payment identifier, and other resource references with different lifetimes. Store their mapping rather than assuming one string means the same thing everywhere. A clear mapping makes support, reconciliation, and later provider changes substantially less exciting, which is a desirable quality in a payment system.

2. Create the provider resource on a trusted backend

Select the payment product supported by your provider and merchant arrangement. Establish account setup, environment, feature availability, authentication, amount units, usage rules, and test capabilities before committing to hardware. Keep long-lived provider secrets out of display projects and public firmware resources. Devices should receive only the session data and authorization they need.

Razorpay QR creation documentation provides a concrete provider example with fixed-amount and single-use options. Check the current account and API requirements rather than treating those names as universal UPI behavior. This article describes an application architecture, not a promise that every merchant account supports every QR feature.

3. Render the right QR and clear stale sessions

Bind the displayed image to the active application session. Show the selected product, exact payable amount in rupees, machine reference, and understandable time or availability information. Verify QR readability on the actual display under representative viewing conditions. A crisp design screenshot does not establish scan performance through the installed front panel.

Specify what happens when the person presses back, changes the product, walks away, or returns after a screen reset. The display must not retain a payable QR from the previous customer while showing a new selection. Clear or replace resources deliberately, and ensure the controller rejects touch events belonging to an obsolete session. HMI specification covers the display contract.

4. Design expiry and late payment as a race

A screen countdown, reservation expiry, provider QR closure, payment notification, and device clock are not one atomic event. State which source governs each decision. Where the provider returns a resource expiry, retain that value and define how the UI represents it. Hiding the QR does not by itself cancel every payment already in progress.

Consider a hypothetical purchase paid close to expiry while notification is delayed. If stock has been released or the machine is unavailable, the payment still needs reconciliation. Decide whether the original reservation may be restored, whether fulfilment remains permitted, and when compensation is required. Do not assign a late payment to the next customer merely because the same machine is now showing another screen.

5. Verify payment and match the complete purchase

Authenticate provider events and match the intended merchant environment, reference, amount, currency, and accepted payment state. An unrelated successful payment must not unlock a compartment. Keep test and live identities separate. Use the provider-supported status query where required for reconciliation, and document what happens if the query itself is unavailable.

Process notifications with durable recording and duplicate protection. Provider webhook guidance explains delivery concerns for Razorpay; your business state should also tolerate repeated or reordered observations. A payment notification may arrive twice without representing two purchases. Verified payment authorizes a specific order, not a generic pulse on the next free output.

6. Authorize one operation and confirm its outcome

Before issuing the command, check the order remains eligible, the target is reserved, the machine reports appropriate readiness, and no fulfilment has already been authorized. Use an atomic application transition with a durable command delivery plan. Preserve the operation identity across retries. Separate transport acknowledgment from local acceptance and physical completion.

The controller should validate the target, command version, session or operation identity, prerequisites, and duplicate history before acting. Publish a result that the backend can reconcile after reconnect. Duplicate dispensing prevention explains why a single-use payment resource does not replace this device-side protection.

7. Reconcile inventory and money independently

Define reserved, available, unavailable, uncertain, and fulfilled inventory states appropriate to your mechanism. Do not decrement stock solely because a QR was displayed, and do not restore an uncertain item solely because a timeout elapsed. Door-based vending may require operator verification before the compartment is offered again.

Record the resolution path for paid-but-unfulfilled, overpayment or mismatch where relevant, expired sessions, machine faults, and operator cancellation. Provide a stable customer reference and an accountable owner. Provider settlement reports and your fulfilment ledger answer different questions; both matter when reconciling the business. Avoid implying that a payment captured state proves delivery or that a refund request proves money returned.

Application order -> item and price snapshot -> inventory reservation
Create provider QR -> store resource mapping -> show active QR
Verified payment observation -> match order and amount
Atomic fulfilment authorization -> durable command delivery
Controller accepts operation -> attempts physical action
Observed outcome -> durable result -> backend reconciliation
Uncertain or failed outcome -> controlled resolution and support

8. Commission the flow under realistic failures

Test duplicate touches, image creation failures, expired QR screens, payments near closure, delayed notifications, wrong references, repeated notifications, machine disconnects, and power loss after actuation. Confirm what the display, backend, controller, stock record, and support view each show. Record the software and configuration versions used in the test.

Use the provider-supported test process and an approved commissioning plan for any live validation. Agree expected results before running scenarios. The successful scan is only one case; the release decision should also show that an interrupted session cannot vend under a different customer or remain permanently lost between teams.

9. Ask for a transaction interface pack, not just a demo

A useful handover includes state diagrams, resource mapping, event authentication, amount conventions, expiry rules, command and result schemas, duplicate retention, reconciliation, customer messages, test cases, and operational ownership. Include environment setup and credential provisioning responsibilities without placing secrets in general documentation.

SolveMpire can discuss connected vending engineering across the backend boundary, electronics, firmware, and HMI. Bring your provider choice, product selection rules, stock model, connectivity assumptions, and support policy. A reviewable interface pack is a better starting point than a QR demo that works only while everyone stays connected and behaves politely.