Most payment failures are not the customer changing their mind. They are an acquirer timing out, an issuer declining intermittently, or a bank having a bad hour. Routing treats those as recoverable rather than final.
How it works
Cards, UPI, net banking or a wallet, presented in the order most likely to succeed for that customer. Unavailable banks are hidden rather than shown and then failing.
The request goes to the acquirer with the best current success rate for that method, card network and issuing bank.
Where the failure is recoverable — a timeout, a temporary decline, an acquirer outage — the transaction is retried through an alternate path before the customer sees an error.
However many attempts it took, you receive one transaction record with the final status, the method used and a reason code if it ultimately failed.
Capabilities
Cards, UPI, net banking and wallets behind one integration. Routing moves a failed transaction to a working path instead of returning an error to your customer.
For businesses selling online that want fewer abandoned checkouts and one reconciliation view across every payment method.
Credit and debit, with saved-card tokenisation
Intent, collect, and static or dynamic QR
Major banks, with live availability checks
The wallets your customers already hold
Shareable links for invoices and one-off collection
Retry through an alternate acquirer on failure
Businesses negotiate hard on MDR and then lose more revenue to failed checkouts than the negotiation ever saved. A few basis points on a successful transaction is a smaller number than the full value of one that never completed.
Recovery is worth more than rate. That is the argument for routing, and it is the reason we build it into the base product rather than selling it as an add-on.
When a transaction fails permanently, you get a reason code that says what happened — insufficient funds, issuer declined, card expired, limit exceeded, authentication abandoned.
That distinction matters operationally. "Insufficient funds" is a customer you follow up with tomorrow. "Card expired" is a customer you prompt to update. "Authentication abandoned" is a checkout problem you fix.
Card numbers are replaced with network tokens. Raw card details do not reach your servers and are not stored on ours, which keeps card data out of your compliance scope.
Returning customers can pay with a saved card without you handling the underlying number.
Questions
Credit and debit cards, UPI intent and collect, static and dynamic UPI QR, net banking across major banks, and wallets. All through one integration.
Each transaction is sent to the acquirer with the best current success rate for that combination of method, network and issuing bank. Where a failure looks recoverable, the transaction is retried through an alternate path before the customer is shown an error.
Your scope depends on how you integrate. Using our hosted checkout or tokenisation keeps raw card data off your systems, which substantially reduces what you have to certify. If you capture card details directly in your own interface, your scope is larger. We will tell you which applies before you build.
Yes. You can use the hosted checkout as it comes, theme it, or build your own interface against the API and keep full control of the experience.
TrustPay is built so these work together. Money in, money out, and the ledger in between.
Your volume, category, payment methods and settlement cycle. Four answers and you have a rate.