A receiving account can become unavailable for many reasons: a provider review, a changed account setting, a connection error, or an operational decision to stop taking new payments. The safe response is not to keep sharing the same QR and hope it settles. Stop new payment attempts on that receiver, preserve the evidence for existing orders, and only resume after a controlled verification.
- Identify the exact receiving UPI ID and affected route.
- Stop new checkouts from using it.
- Keep existing order records for reconciliation.
- Choose and test an approved replacement route.
- Resume only after a new end-to-end test passes.
Identify what is actually affected
Start with the receiving UPI ID, the gateway connection, and the time the problem began. Do not assume every Trust Gateway merchant or every payment method is affected because one receiver is unavailable. Review the orders created around that time and separate them into pending, confirmed, expired, and already fulfilled records.
Write down your own business order ID beside the Trust Gateway order ID, exact payable amount, checkout creation time, and receiving account. This makes it possible to answer a customer accurately later. A branded checkout can show a merchant logo while the actual payment receiver is configured separately, so always check the UPI identity that was issued for the order.
Stop new payment attempts first
New orders must not point to a receiver that should not receive money. In Trust Gateway, use the connected merchant and default-routing settings to select a working approved route, or temporarily stop checkout creation when no route is ready. If an application passes an explicit gateway choice in its create-order request, update that application too; changing only a dashboard default will not override an explicit route.
Do not solve this by editing an already-issued QR or changing a receiver behind an existing order. An order keeps its payment identity so that its result can be checked later. A new customer payment should always receive a fresh order and checkout URL from the approved configuration. The routing guide explains the difference between default and explicit gateway selection.
Protect pending orders without guessing
Customers may already have a QR open when you pause a route. A pending order is not automatically unpaid, and an expired screen is not proof that no money arrived. Check the authenticated order status, then compare any available receiving-account evidence with the exact order ID and payable amount. Keep fulfilment paused while the outcome is uncertain.
A customer should not be told to pay the same QR twice. If the first attempt is still unresolved, explain that it is being checked and give them the original order reference. If a replacement order is needed after the first one is conclusively expired or cancelled, keep both records linked to the same business purchase. The payment status lifecycle shows which states can be treated as terminal.
Test a replacement before announcing it
When another supported receiver is available, connect it through the dashboard and confirm its identity in a controlled low-value test. Create a genuinely new order, inspect the receiver and exact amount in the paying app, make the payment, and confirm the authenticated status before fulfilling the test purchase. This checks routing, checkout, verification and your own delivery path together.
Do not claim a replacement route is ready merely because it displays a Connected badge. Connection settings, account eligibility, payment acceptance and automated verification are separate questions. Record the test time, gateway order ID, and result so the team can trace the change later. Use the checkout release matrix to cover phone, desktop, expiry and duplicate-check cases.
Resume with clear controls
After the test passes, enable the intended default route and update any explicit route configuration in your application. Monitor the first real orders closely. Keep old receiver credentials private, avoid publishing provider-review details in checkout messages, and use a generic availability notice only when it helps customers choose a different payment method.
The goal is a reliable record, not a fast-looking status. A pause protects customers from paying an account that cannot currently be reconciled. A deliberate resumption protects the merchant from duplicate orders and mistaken fulfilment. For an API-side recovery pattern, read how to verify an existing order without webhooks.