Payment Gateway Integration: Hosted Checkout, Redirect or API?

Choosing a payment provider is half the decision. The other half is how you connect it: whether customers leave your site to pay, pay in a window your provider controls, type into fields embedded in your page, or hand their details to your own servers. That choice decides how long the build takes, how the checkout looks, and, most importantly, how much of the security burden for card data lands on you.

Providers use different names for the same things ("standard", "seamless", "custom", "S2S"), so this guide describes each method by what actually happens to the customer and their data. It's written for founders and product owners deciding, and for developers planning the work.

Almost every provider offers some version of these. They differ in one thing above all: where the customer's payment details are typed and which systems they pass through.

The trade-offs, in one table:

A redirect is the least work and the least risk. Your server creates an order with the provider, the customer is sent to the provider's page with that order, and after paying they're returned to a URL you choose. Card numbers, UPI handoffs and bank logins all happen on the provider's side.

The cost is control and a moment of doubt for customers, who see a different page and domain. The return to your site is also the least reliable part: customers close tabs, lose signal or come back before the result is final, which is why the redirect can't be your proof of payment (more on that below).

A provider's checkout script opens a payment window over your page. You pass it an order created on your server; it shows the methods you've enabled, handles authentication and returns a result to your page. It keeps card data off your systems while the customer stays on your site, which is why many online stores use it.

If you want the payment form to look and behave like the rest of your checkout, embedded fields let you place the provider's secure fields inside your own form. Your page never reads what's typed into them; the provider's code turns the details into a token or a payment reference that your server then uses. You get control over layout, but your page now hosts the payment form, so its security matters more.

In a direct integration your systems collect the payment details and send them to the provider. For UPI and net banking, that mostly means handling redirects and handoffs to apps and banks. For cards, it means card numbers pass through your servers, and that changes your obligations significantly.

PCI DSS, the card industry's data security standard, applies to any entity that stores, processes or transmits cardholder data, or could affect the security of the environment where that happens. A direct card integration puts your servers squarely inside that scope. Separately, RBI's rules on card-on-file data don't allow merchants to store customers' full card numbers at all: saved cards work through tokens issued under RBI's tokenisation framework. Most businesses that think they need a direct card integration actually need embedded fields plus tokenised saved cards.

Whatever the method, a sound integration follows the same lifecycle. The method changes who draws the payment screen; it doesn't change these steps.

The integration method is the frame; each payment method behaves a little differently inside it.

In a native Android or iOS app, the same four methods exist, but they're usually delivered through the provider's mobile SDK rather than a web page. The SDK opens the provider's checkout screen inside your app, or provides native components for the payment fields, and returns a result to your code.

A typical project, whichever method you choose:

Integrations rarely fail on the successful payment. They fail on the customer who closes the tab, the webhook that arrives twice, the payment that stays pending for ten minutes. Test these before your customers find them:

Whichever method you pick, some security work is always yours, and some grows with the method:

A simple way to decide:

You don't have to pick a method for life. A common path for a growing business looks like this:

Adding a second provider for resilience or better approval rates doubles the integration work unless you plan for it: two order formats, two webhook formats, two sets of statuses and two settlement reports. Businesses in that position often put an orchestration layer between their checkout and the providers, so they integrate once and route each payment to a provider by rules. The providers still authorise, collect and settle under their own agreements; the layer decides where each payment goes. Our explainer on smart payment routing shows how those routing decisions are made.