A customer should understand a UPI payment request before they open a payment app. A clean checkout does not need to promise instant success or hide important information. It needs to show who is collecting the payment, the exact amount, what the payment is for, and what happens after the customer approves it in their UPI app.
- Shows the merchant or product identity.
- Shows the exact payable amount.
- Provides a QR and supported app handoff.
- Explains that payment is being checked after approval.
- Lets support trace the saved order if something is delayed.
Start with a recognisable payment identity
Place the merchant name where a customer can see it before scanning the QR. If your Trust Gateway workspace uses checkout branding, keep the logo and display name consistent with the business name used in your invoice, website and support channel. Branding helps recognition, but customers should still inspect the receiver inside their UPI app before approving any payment.
A short order description can also help. For example, a customer buying a digital template should see the product or invoice reference, not only a generic “payment requested” message. Do not put confidential customer data, API keys, tokens or private fulfilment details in the public checkout note.
Make the amount unambiguous
Show one clear total with the currency. Your application should calculate that amount on its server from a trusted product catalogue, create a gateway order, and save the returned order ID and payable amount with its own purchase record. Do not allow the browser to choose a final price after the order has been created.
For some receiving routes, Trust Gateway can return an exact payable amount that differs slightly from a requested amount to help distinguish simultaneous payments. Show the returned amount consistently throughout that one checkout. Your backend must compare the same saved amount when it verifies the result; a similar product price is not enough to identify an incoming payment.
Give customers a useful mobile and desktop path
On a phone, a customer may continue to a supported UPI app. On a desktop, they may scan the QR from a different device. These are two ways to open the same order, not two separate payment requests. Keep the order reference visible so a customer can report it if they return to the page after an app switch.
Do not automatically create a replacement order just because the customer returns to the browser. UPI app switching can take time, connectivity can be slow, and the original order may still be pending. Reload the known order state from your server and show a calm “checking payment” message until it can be confirmed or reaches a terminal state.
Explain the status without making unsupported promises
“QR opened”, “UPI app launched”, “payment submitted” and “browser redirected” are user-interface events. They do not prove that a credit reached the receiving account. A good checkout labels the request as waiting or pending until Trust Gateway has a verified order result. Avoid displaying a success badge solely because JavaScript received a callback from a mobile app.
Your own return page should use the saved gateway order ID to ask the server for the current status. The server then calls the authenticated status endpoint and compares the response with the local purchase record. The status API documentation and the safe return URL guide show this flow in detail.
Design for support before a payment is delayed
Include a non-secret order or invoice reference that the merchant can use to locate the payment request. If an order remains pending, ask the customer not to pay the same QR again while the original request is being checked. Never ask for a UPI PIN, OTP, password, bank login, API key or Gmail access. Those details are neither safe nor needed for merchant-side verification.
A support team needs the local business order, the Trust Gateway order ID, exact payable amount and the current verified status. A screenshot or payer-provided reference can be a useful lead, but it cannot by itself cause delivery. For a full investigation record, read the pending payment support checklist.
Checkout launch checklist
- Confirm the merchant name, receiver and amount are visible and accurate.
- Test a phone app handoff and a desktop QR scan using a controlled order.
- Return without paying and confirm nothing is delivered.
- Refresh a confirmed return page and confirm fulfilment only runs once.
- Let an order expire and confirm the same checkout is not reused.
- Test two same-priced orders near the same time and reconcile each one separately.
The goal is not an elaborate payment page. It is a request that customers can recognise and a merchant can verify. Start with a server-created order, use the hosted checkout URL, and complete the business action only after the server confirms the exact order. For implementation steps, use the UPI QR checkout guide.