Hosted checkout: ship first, optimise later
A hosted checkout sends the buyer to a payment URL and brings them back with a callback. There is no front-end rewrite: one link, one integration, and the page handles intent links and collect fallback behind it. In Titan Pay’s sandbox, the hosted baseline is 60% success. That is a reasonable starting point for web and H5, especially when you need to go live before you know which apps your buyers use.
The trade-off is control. The buyer leaves your page, and you inherit the checkout’s own drop-off. Use hosted checkout to learn, then move high-intent traffic to a rail that removes steps.
Intent wake-up: fewer taps on mobile
A upi:// link opens the UPI app already installed on the phone. The buyer does not type a VPA, and the callback carries the UTR. On mobile web and inside an app, this is usually the shortest path from tap to payment. Titan Pay’s native and intent baseline is 70% success, ten points above hosted in the same sandbox.
Intent links need a mobile context. On desktop, fall back to a dynamic QR; do not show a dead button. And because the buyer can edit the amount in some apps, confirm the order before you wake the app.
Native collect: server-initiated, built for repeat
Collect is a request from your server to the UPI rail. VPA checks and amount locks return in under 2 seconds, and you poll the status to a final state. It fits subscriptions, batch collection and cases where the buyer is not sitting in a checkout. It is a poor first payment: the buyer must already have a VPA and trust the request.
Use collect when you already know the payer, and keep intent as the fallback when a collect request expires.
A simple decision rule
| Situation | Start with | Why |
|---|---|---|
| Web or H5, first launch | Hosted checkout | Fastest to ship; one link with fallback built in |
| Mobile web or app, one-tap | Intent wake-up | Opens the installed app; no VPA typing |
| Subscription or batch | Native collect | Server-initiated and pollable to a final state |
| High-value order | Hosted + intent | Wider fallback when one rail fails |
What stays the same
Whichever rail you start with, keep one callback format, the same four final states and the same D0 settlement file. Retries should be bounded: three attempts is enough to recover a transient failure and still leave a clean audit trail. If the callback is late, poll; do not mark the order failed while it is still pending.
The rail is a product decision. The contract around it—callback, UTR, settlement—should not change when you add one.
FAQ
Which rail should a new merchant start with?
Start with hosted checkout if speed matters. Move mobile traffic to intent links once you can measure app-level success.
Can we use intent and collect together?
Yes. Use collect for repeat or server-initiated payments and keep intent as the fallback when a collect request expires.
Start with a ₹1 test payment
Sandbox keys, integration guide and rate card on Telegram.