A payment link should be valid long enough for a customer to complete an intended purchase, but not so long that an old request becomes confusing months later. Expiry is also a payment-safety feature: it helps a merchant separate a current request from an abandoned or already-investigated checkout.
- Keep the original order record.
- Check whether it is paid, pending or expired from the merchant side.
- Do not ask the customer to repeat a payment while the result is uncertain.
- Create a fresh link only after the earlier request is safely closed or reconciled.
Why a payment link needs an expiry
A fixed payment request is connected to a product, amount, receiver and moment in your sales process. Keeping it active indefinitely can expose customers to outdated prices, old fulfilment terms or a receiver route that is no longer approved. An expiry gives both the buyer and the merchant a clear boundary for the checkout attempt.
When creating a link in the dashboard, choose a duration that matches the sale. A short event registration may need a shorter window than an invoice sent to an established client. State the deadline in your own message or invoice where helpful, but avoid claiming that payment will be fulfilled instantly; verification still happens after the UPI app approval.
Write the customer message around the original order
Include the purpose, amount and your business reference when sharing a payment link. A concise message such as “Invoice TG-1042 — ₹499 — use this link before 6 pm” gives the customer useful context without exposing credentials. The hosted checkout then shows the QR and app handoff for that saved order.
Do not send multiple active links for the same business purchase just because a customer has not replied. That makes it difficult for them to know which QR is current and increases the risk of duplicate payment. If a buyer needs another attempt, first inspect the original order status from your merchant server or dashboard.
A customer says they paid after the link expired
Do not assume the claim is impossible or automatically successful. Find the original Trust Gateway order by its saved ID and check its authenticated status. Compare any available receiving-side credit with the exact amount and timing. An expiry state changes how new attempts are handled, but your support process should preserve the historical order for investigation.
Ask for no secrets. A UPI PIN, OTP, password, API key or Gmail access cannot prove an order and must never be collected. A limited payer receipt detail may help support locate a possible record, but fulfilment should only follow merchant-side verification. See what to collect for a pending UPI payment.
When to issue a replacement link
Create a new link only after the previous order is confirmed unpaid, expired without a matching credit, or otherwise resolved according to your review process. Link the replacement to the same local sale so your team can understand the history. Use a new order ID and checkout URL; never edit an older QR to silently change its receiver or amount.
If the original payment is still pending, show a waiting state and tell the customer not to pay again yet. A repeat payment can become an avoidable refund or support problem. The payment status lifecycle explains why a browser return or QR scan is not final proof of an outcome.
Avoid collisions during busy sales
For a public product, every buyer should receive their own saved order or payment link. Do not use one generic QR for all customers if you need to identify purchases automatically. Individual orders give your server an order ID, checkout time and exact payable amount to compare before fulfilment.
During a busy launch, keep a small operational view of open orders and review exceptions before resending links. If two customers report payment for the same amount, reconcile each against its own business sale and gateway order. The small-business reconciliation guide shows the three records needed for that decision.
Simple operational rules for payment links
- Use one active payment request per business sale.
- Save the link, gateway order ID, amount and expiry beside the local purchase.
- Explain the deadline clearly in customer-facing text.
- Check the original order before sending a replacement.
- Fulfil only after a verified server-side payment result.
- Keep an audit note for manually reviewed late-payment cases.
Expiry should make your payment flow clearer, not create a dead end. Preserve the original record, check it with the authenticated status endpoint, and create a fresh request only when that is safe. For dashboard use, start with the payment links guide or read the verification reference for an API integration.