A receipt page has two jobs: reassure a buyer that the merchant has recorded a payment, and give support a reference if something needs review. It should appear after a verified server-side payment result, not merely after a QR scan, app handoff or browser redirect. That distinction protects both the customer and the merchant from accidental duplicate delivery.
- Your business order or invoice reference.
- The product, service or plan purchased.
- The verified amount and currency.
- The payment-recorded time.
- A support path that does not request secrets.
Wait for a verified outcome
When a buyer returns from a UPI app, load the local purchase from your server and check the saved Trust Gateway order. Only display a final paid receipt after the authenticated status reports a matching successful payment and your local fulfilment transition is complete. Until then, show a neutral “we are checking your payment” state with the order reference.
This protects against interrupted app switches, delayed reconciliation and a buyer reopening an older tab. A front-end success flag is easy to forge or interrupt; the merchant-side order record is the basis for a receipt. Follow the status verification reference for the server request.
Include business context, not sensitive data
A useful receipt names the merchant, purchased item or plan, amount, local order reference and date. It may include the gateway order ID when that helps merchant support trace the request. Keep the display concise and ensure values are pulled from your trusted database rather than browser query parameters.
Never put a UPI PIN, OTP, API key, webhook secret, password or receiving-account credentials into a receipt page, email or downloadable file. A genuine payment receipt does not need those values. If customers ask why their UPI app has a different transaction identifier, explain that the merchant order reference is for support and their bank/app record remains their own payment evidence.
Separate receipt generation from delivery work
Your verified payment handler can mark the purchase paid, create a fulfilment record and make the receipt available. Sending a receipt email, issuing a licence or generating an invoice can be queued after that atomic update. This way, a temporary email failure does not make the payment look unpaid or cause the buyer to attempt payment again.
On a later visit, load the existing receipt from the local purchase state. Do not call fulfilment again just because a customer opens the confirmation URL twice. The same idempotent rule used for webhooks protects a receipt page too.
Give pending buyers a helpful next step
For a pending order, state that the original payment request is being checked and ask the buyer not to pay the same QR again. Show the business order reference and a support route. Support should locate the saved order, compare the current authenticated result and any receiving-side evidence, then decide whether the original request is confirmed, still pending or safely expired.
Do not ask a customer for a PIN, OTP or password. A limited receipt detail can help an investigation, but it does not automatically produce a paid receipt. Use the pending-payment evidence checklist for a safe support process.
Receipt page checklist
- Render final paid text only from a verified local purchase state.
- Use a stable business order reference.
- Show the stored exact payable amount.
- Keep API and account secrets out of the page.
- Make every receipt URL safe to refresh.
- Provide a clear pending state before verification completes.
A good receipt is proof that your store recorded a verified business outcome, not a claim based on navigation. For checkout-side design, see UPI checkout trust signals, and for avoiding duplicate benefits, read the webhook retry strategy.