UPI: the customer returned to checkout. Can you fulfil the order?

The customer closes the payment app and returns to the store. The interface journey is over. The order still has a crucial open question: does the merchant have verified confirmation of the correct payment? With UPI, design two connected paths: the customer journey through Intent or QR, and independent verification of the business result.

That decision should come from the merchant’s verified payment records. The route used to present a payment request and the evidence used to complete an order are different parts of the system.

Understand the journeys before selecting one

NPCI describes UPI as an instant payment system and lists merchant integration modes including QR and Intent. That overview explains the vocabulary; it does not guarantee that every historical mode is available for a particular merchant today. NPCI’s UPI FAQ.

• Intent: checkout invokes a compatible payment app with payment details, and the customer completes the payment journey there.
• QR: the customer scans encoded payment information with an appropriate app.
• Collect: in the request-based model, a payment request is sent to the payer’s UPI identifier for approval.

NPCI’s product material describes these mechanisms. Treat older descriptions as explanations of how a flow works, not proof of current eligibility. NPCI product booklet.

Current provider rules matter. PayU’s Collect guidance directs new merchants toward Intent and QR and limits Collect to specified exceptions. Verify your own provider’s supported use case before building around a request flow. Merchant acceptance and personal P2P transfers must not be treated as interchangeable. PayU’s implementation guidance.

Make one order the unit of control

Consider a hypothetical INR 2,400 order. The merchant creates its own order reference and asks its approved provider to initiate the supported payment journey. Keep the expected amount, currency and merchant relationship attached to that reference. A customer returning to the website is an event to handle, not sufficient evidence to fulfil the order.

Razorpay’s integration instructions, for example, require payment-signature verification and provide dashboard, webhook and API methods for checking status. Its fulfilment guidance refers to the captured state. Those are Razorpay-specific semantics; map the equivalent documented completion state for your provider. Razorpay integration steps.

A practical internal design should compare the confirmed payment with the expected order. Check the relevant reference, amount and currency, and ensure the result belongs to the intended merchant arrangement. Record why the order moved to paid, so support can later explain the transition.

Plan for an answer that arrives late

In our example, the customer sees a delay and taps again. Your workflow should preserve the relationship between attempts and the original purchase rather than creating unrelated orders that are difficult to reconcile.

Design repeat notifications to be safe to process more than once: an already completed order should not release goods twice. When messages arrive out of order, use the provider’s documented status rules and verification process. These are engineering design recommendations, not claims that every UPI integration uses identical event behaviour.

For unresolved payments, give the customer a clear pending state and a reference for support. Avoid declaring failure merely because the browser has timed out, or asking the customer to pay again before checking the first attempt. Define who investigates, what evidence they consult and when they escalate to the provider.

Keep support away from unsafe confirmation shortcuts

A screenshot can help locate a case but should not replace verification in the merchant’s authorised records. Staff should never ask customers to reveal a UPI PIN. NPCI also warns that scanning a QR code and entering a UPI PIN is for making a payment, not receiving one. NPCI fraud-awareness guidance.

Use the established refund process instead of an unfamiliar request to “receive” money. NPCI directs merchants to their acquiring bank for transaction-status questions and grievances. NPCI merchant FAQ.

The QR expired, but confirmation came later

In a proposed training scenario, the store reserves stock for ten minutes and then closes the unpaid order. Confirmation subsequently arrives for a payment associated with it. Even where a QR or request has an expiry, the stock-reservation timer and permitted payment outcomes need separate definitions under the provider’s rules. An interface timer is not financial reconciliation.

Choose a process for late confirmation in advance: check whether fulfilment remains possible, agree an appropriate solution with the customer, or use a supported refund flow. Do not automatically promise unavailable stock, and do not lose sight of received money because the order record says closed. The exception needs an owner and a link to the original attempt.

One order can have two confirmed payments

Preventing duplicate fulfilment does not remove the need to account for excess money. If the customer retries and both attempts are genuinely confirmed, record two financial objects linked to one order. Resolve the excess through the provider’s authorised procedure. Hiding the second payment to keep the order status tidy is more dangerous than exposing it in an exception queue.

Support needs a neutral conversation path: locate the order, verify attempts, explain the established outcome and give the next update time. Asking for another screenshot must not substitute for access to verified records. Test these cases on the devices and flows supported by the provider. One successful return from an app does not prove identical behaviour across every application and operating system.

Do not infer international acceptance, available funding sources or pricing from the UPI name alone. Confirm the exact product and merchant agreement. A good integration combines an understandable customer journey with an independently verifiable operational result.