Connecting several receiving accounts introduces an important operational question: which one will receive the next payment? Trust Gateway resolves the gateway when an order is created. A connection badge, a preferred brand or the app used by the customer does not independently decide that route. This guide explains the current selection rules and a practical way to change them without confusing customers.
- An explicit gateway request takes precedence over the saved default.
- Without an explicit request, the merchant's saved default is used.
- Automatic routing chooses the first configured connection in the current priority list.
- A configured connection still needs an end-to-end payment test.
A receiving route is different from a payer's app
The gateway route chooses the merchant-side connection and receiving UPI identity used to create the request. The customer's UPI app is the tool they use to approve that request. Selecting Paytm as your gateway does not mean that every customer must use the Paytm app. Customers should inspect the receiver and exact amount in whichever supported UPI app opens the request.
Keep these concepts separate in customer instructions. Say which business is receiving payment and tell customers to confirm the displayed details. Avoid describing a route preference as a guarantee of approval, instant verification or provider availability. The Paytm connection guide covers the receiving-account setup itself.
How a new order chooses its gateway
The current resolver accepts auto, fampay, bharatpe and paytm. An order request can supply gateway, with route supported as an alternative. Send one clear field rather than conflicting values. If neither is supplied, the merchant's stored default applies; without a stored preference, selection falls back to automatic routing.
An explicit auto request is also a choice: it invokes automatic selection even when the merchant has saved a particular provider as the default. That distinction matters when an integration library silently inserts gateway: "auto". Inspect the request sent by your own server if changing the dashboard preference appears to have no effect.
| Request | Saved default | Selection rule |
|---|---|---|
| Gateway omitted | paytm | Use the configured Paytm connection |
| gateway: fampay | paytm | Use the configured FamPay connection |
| gateway: auto | paytm | Use the automatic priority list |
What automatic routing currently means
As of this guide's publication, automatic routing checks eligible connections in this order: FamPay, BharatPe, then Paytm. Eligibility is based on the stored connection status and required configuration fields. It is not a live speed comparison, a fee optimiser or a guarantee that the selected provider can verify the next transaction.
The Paytm recommendation shown in the interface is guidance; it does not reorder that automatic list. If you specifically want Paytm for new orders, connect it and save it as the default, or request it explicitly from your server. An explicitly selected but unconfigured gateway returns an error instead of silently falling through to a different receiver. Unsupported route names are rejected too.
Set and verify your default
- Open Connect Merchant in the dashboard and confirm that the intended account is connected.
- Find Default Payment Gateway Setting or the Default Routing tab.
- Select the connected gateway and click Save Routing.
- Create a new order without an explicit route override.
- Check the returned receiving UPI ID, checkout amount and merchant identity before paying.
For API integrations, keep credentials and order creation on your server. Use the payload and authentication instructions in the API documentation; this guide describes selection behaviour, not a replacement authentication scheme. Record your chosen route alongside the returned gateway order reference in your own application.
Treat existing orders separately
Saving a new default affects route resolution for new orders. An already-created order stores its gateway and receiving UPI identity; changing a default is not a way to move an in-flight payment to another account. Keep the old order reference available and check its outcome before asking a customer to use a replacement request.
A reusable payment link may create separate checkout attempts. Test your routing change with a genuinely new order, because reopening a pending checkout can reuse that session. Do not disconnect an old receiving connection while unresolved payments still depend on it. Reconcile those attempts first using your receiving records and the daily reconciliation checklist.
Troubleshoot an unexpected receiver
Start with three facts: the gateway field your server submitted, the default saved for that merchant, and the order's returned UPI ID. Confirm that you are testing the correct merchant account and a new order. A custom checkout logo does not change the receiver. If the selected gateway is not configured, correct its connection settings before trying another checkout.
Finally, complete one controlled payment and check the verified order status and your application's fulfilment record. A successful routing decision proves where the request points; payment evidence is still needed to establish that it was paid. Use the checkout release test matrix to record that end-to-end result.