A pending payment is a support problem only when the team loses the link between the customer, the business purchase and the gateway order. The fastest safe response is a structured record—not a request for passwords, OTPs, API keys, or a screenshot treated as final proof. This checklist helps a merchant investigate while keeping fulfilment controlled.
- Your business order or invoice reference.
- The Trust Gateway order ID.
- Exact payable amount and approximate payment time.
- The configured receiver and the order's current status.
- Any available transaction reference from the receiving account.
Start with the order you created
Ask support staff to find the local business order first. It should identify what the buyer intended to purchase, when the checkout was issued, and which Trust Gateway order ID it maps to. Use the saved exact payable amount, not a rounded product price copied from memory. A small matching adjustment can make two otherwise identical orders distinguishable.
Then check the authenticated gateway status from the merchant server or dashboard. The order ID is the stable join between your store and the checkout. A recipient name, customer name, equal amount, QR image, browser return event, or a generic UPI alert can help the investigation but cannot replace that order mapping.
Never request secrets from a payer
Do not ask a customer for a UPI PIN, OTP, bank password, full card details, Trust Gateway API key, Gmail password, or reset link. None of those improve order verification, and collecting them creates a serious security risk. Support should be able to investigate with merchant-side order data and the receiving account's own transaction record.
A customer can share a limited reference from their payment receipt if your policy permits it, but treat it as a lead, not an automatic success signal. Match it against the receiving record and the expected order details. The daily reconciliation checklist gives the same principle for a larger batch of orders.
Compare the right records
| Record | What to compare | What it cannot prove alone |
|---|---|---|
| Gateway order | Order ID, payable amount, status, creation time | That a similar bank alert belongs to it |
| Receiving account | Credit amount, time, available transaction reference | Which local product should be fulfilled |
| Local purchase | Customer, product, fulfilment state, gateway order ID | That funds arrived |
| Customer message | Approximate time and non-secret receipt details | That payment is confirmed |
These records answer different questions. The gateway order describes the requested checkout; the receiving account is financial evidence; your own purchase record controls delivery. When they agree, complete one idempotent fulfilment. When they disagree, leave the purchase pending or move it to a documented review state instead of guessing.
Handle same-amount and concurrent payments carefully
Two customers can pay the same price within minutes. Never match an incoming credit to an order only because the amount is equal. Compare the exact returned payable amount, timing, order reference when available, and receiving-account evidence. If the payment route deliberately adjusted an amount to avoid a collision, use the amount returned at order creation as the expected total.
Do not turn a customer-provided UTR into a universal success key. A transaction reference may be absent, malformed, delayed, or connected to another order. Store it only after validating it against the appropriate receiving record and keep it protected in your own operational logs.
Close the support loop without duplicate delivery
When the order becomes verified, mark the local purchase paid and fulfil it once. If support checks the same order again, show the existing fulfilment result. When the order is truly expired without a matching credit, offer a fresh checkout only after explaining that the earlier payment was not confirmed. Keep the earlier order reference in the support history so a later credit is not lost.
Give customers one clear status sentence: “We are checking the original payment request; please do not pay the same QR again.” This is better than asking them to repeat a payment or promising a delivery before confirmation. For the full merchant-side status sequence, see the server-side verification guide and the API documentation.