Integrating a payment gateway means connecting your website to a service that accepts a card, UPI or wallet payment, authorises it, and settles the money to your account. Most builds follow the same three phases and six steps.
- Select: pick a gateway on fees, supported methods, currencies and your tech stack.
- Register: open a merchant account and clear KYC/KYB (PAN, business registration, GST).
- Get keys: generate sandbox and live API keys from the dashboard.
- Embed checkout: add a hosted checkout, hosted fields (iframe) or full API.
- Test in sandbox: run test cards, 3DS, webhooks, refunds and failure cases.
- Go live: switch to live keys, confirm settlement, monitor the first payments.
If you are choosing between providers first, compare international payment gateways before you write a line of code.
One decision shapes the rest: hosted checkout is quickest and carries the least compliance risk, full API gives the most control but the heaviest compliance load. The section below maps each option to its PCI tier.
What is the difference between a payment gateway and a payment processor?
People use the terms loosely, but they do different jobs.
A payment gateway is the software layer that captures the payment on your site and encrypts the card or UPI details.
A payment processor moves the authorisation request between the card networks, the acquiring bank and the issuing bank, then settles funds.
How and when that money reaches your bank account is the payment gateway settlements step, which runs on its own cycle set by the provider.
Most Indian gateways (Razorpay, Cashfree, PayU, Easebuzz) bundle both, so you integrate once. For selling to overseas customers there is a third layer many guides skip: cross-border receiving and settlement, which turns foreign currency into INR compliantly.
A gateway accepts the charge; it does not, on its own, handle the FX and RBI paperwork that inward foreign payments require.
Which integration type should I choose: hosted checkout, hosted fields or full API?
This is the decision that sets your build effort and your compliance burden. The more card data touches your own servers, the higher your PCI DSS Self-Assessment Questionnaire (SAQ) tier and the more you must prove.
| Integration type | How it works | PCI SAQ tier | Build effort | Best for |
|---|---|---|---|---|
| Hosted checkout (redirect) | Customer is redirected to the gateway's page | SAQ A (lightest) | 1-3 days | Small sites, fast launch |
| Hosted fields / iframe | Card fields are the gateway's, embedded in your page | SAQ A-EP | 1-2 weeks | Branded checkout, keep users on-site |
| Full API / direct post | Card data posts through your server | SAQ D (heaviest) | 3-8 weeks | Platforms, custom flows, high volume |
For most merchants, hosted checkout or hosted fields is the honest answer. Reach for a full API build only when you genuinely need control of the flow, for example a marketplace collecting on behalf of sellers.
That heavier route means PCI DSS compliance for SaaS at SAQ D, which is a real project, not a checkbox.
How do I keep a payment integration secure and PCI compliant?
Hosted checkout lowers your PCI DSS burden, but three security controls apply whichever route you pick.
- Tokenisation: the gateway swaps the raw card number for a one-time token, so your servers never store the primary account number (PAN). For Indian-issued cards the RBI card-on-file tokenisation rule, in force since October 2022, makes this mandatory, and it also shrinks your SAQ scope.
- TLS everywhere: serve the whole site over HTTPS with a valid TLS certificate. Card networks reject checkout pages that are not encrypted end to end.
- Additional Factor of Authentication (AFA): the RBI mandates AFA on Indian card payments, delivered through 3D Secure 2.0 as a one-time password or an in-app approval. A gateway that skips this challenge is a 2D payment gateway, which carries higher fraud and chargeback risk.
Verify every webhook signature server-side, and rely on the gateway's fraud-screening and chargeback tools rather than building your own.
What are the website payment integration steps end to end?
Here is the sequence once you have picked a gateway and an integration type.
Step 1: Register the merchant account
Register the merchant account and submit KYC/KYB documents for verification.
Step 2: Generate API keys
Generate API keys: a publishable key for the front end, a secret key kept server-side only.
Step 3: Embed the checkout
Embed the checkout using the gateway's SDK, plugin or API per your chosen tier.
Step 4: Configure webhooks
Configure webhooks so your server hears payment-success, failure and refund events.
Step 5: Handle the callback
Handle the callback: verify the signature, then mark the order paid on your side.
Step 6: Test in sandbox
Test in sandbox across the full checklist below.
Step 7: Go live
Go live: replace test keys with live keys and process a small real payment first.
If you sell a subscription, add recurring billing and mandate handling to this list, since the flow differs from a one-off charge, as this guide to SaaS payment processing sets out.
If you are on WordPress or Shopify, a plugin covers steps 3 to 5 for you.
A recurring community question is "how can I integrate a Paytm payment gateway on my website" on Shopify, where a native plugin may not exist, so you fall back to a supported gateway or a custom app.
Check plugin availability before you commit to a platform.
How much does payment gateway integration cost and how long does it take?
Costs split into setup, per-transaction fees and engineering effort. Domestic INR pricing and cross-border pricing are not the same, so treat them separately.
| Cost element | Typical range (India, domestic) | Notes |
|---|---|---|
| Setup / onboarding | ₹0 to ₹5,000+ | Many gateways waive this |
| Per transaction (domestic cards/UPI) | ~2% + GST | Varies by method and volume |
| Per transaction (international cards) | often ~3% + FX markup | The hidden cost when selling abroad |
| Integration effort | 1 day to 8 weeks | Hosted to full API (see table above) |
The number that surprises people is the international-card line. A domestic gateway can accept an overseas card, but it converts at a marked-up rate and the settlement is not built for compliant foreign-currency receiving.
That is where the true cost of international payments hides, and it is the gap the cross-border section below addresses.
How do I test a payment gateway before going live?
Most guides say "test in sandbox" and stop. A real go-live checklist covers the failure paths, not just the happy path. Run every item in the gateway's sandbox before you switch keys.
- Successful payment with the gateway's official test card numbers.
- 3D Secure (3DS) challenge flow, including a failed OTP.
- Declined card and insufficient-funds responses.
- Webhook delivery: confirm your server receives and verifies the signature.
- Refund (full and partial) and the resulting webhook.
- Idempotency: a repeated callback must not double-mark an order.
- Currency and amount edge cases: zero, very large, decimal rounding.
- Switch keys: replace sandbox keys with live keys, then run one small real transaction and confirm settlement lands.
Only after that last real transaction settles should you open checkout to all customers. These checks apply to any merchant payment gateway, whether you run Razorpay, Cashfree or PayU underneath.
How do I add a payment gateway to a website in India for international payments?
Here is the whitespace almost every guide misses. Bolting a domestic INR checkout onto your site works for local buyers.
When your customers pay from abroad, that same setup quietly costs you twice: an FX markup on every conversion, and gaps in your Foreign Inward Remittance Advice (FIRA) and RBI purpose-code paperwork.
A payment gateway accepts a charge. Cross-border receiving is a separate layer that settles foreign currency into INR at a fair rate, with the compliance evidence your CA needs.
Xflow sits in that layer, complementary to a domestic checkout rather than a replacement for it. It settles at the mid-market rate, the next business day (T+1), with documentation issued automatically.
Worked example, illustrative USD/INR at ₹95. An overseas customer pays $1,000 for a SaaS subscription.
| Route | Rate applied | You receive (approx.) | Compliance evidence |
|---|---|---|---|
| Domestic gateway, international card | ~3% fee + FX markup | ~₹91,000 or less | FIRA/purpose-code gaps |
| Xflow receiving account (Growth plan) | Mid-market rate, then 0.4% | ~₹94,600 | Auto eFIRA issued |
Figures are illustrative and vary with the live rate; verify current pricing on the site. Xflow holds final Payment Aggregator - Cross Border (PA-CB) authorisation from the Reserve Bank of India for both exports and imports, as of February 2026.
Can I accept payments on a website without a payment gateway?
Partly. A Quora regular asks "how can I accept payments without a payment gateway", and the honest answer depends on how much friction you accept.
- Payment links, QR codes and UPI intent let you collect without a full checkout integration, good for low volume.
- Bank transfer or wallet works but is manual to reconcile.
- Accepting credit cards directly with no third party is effectively impossible: you need an acquiring relationship and PCI DSS scope, which is why merchants use a gateway.
For overseas customers, a receiving account plus a hosted invoice can replace a card checkout entirely. That is often simpler than integrating a gateway just to take a handful of foreign payments a month.
Xflow Invoicing sends a payable invoice and settles to your receiving accounts without any front-end code.
When should a platform use an API instead of a hosted checkout?
If you run a marketplace or SaaS platform that collects on behalf of sellers and pays them out, hosted checkout will not carry you far. You need programmatic control: split settlements, multiple fee models and webhooks that drive your ledger.
That is a white-label API build. It gives you control of the fund flow and monetisation, at the cost of the SAQ D compliance work noted earlier.
For cross-border payouts specifically, a platform can use an API for international payments to collect foreign currency and settle in INR, rather than stitching a domestic gateway to a separate FX process.
Weigh build-versus-buy honestly: the API route is powerful but it is a project, not a plugin.
Payment gateway vs cross-border receiving: a quick reference
To keep the two layers straight before you build:
| Question | Payment gateway | Cross-border receiving |
|---|---|---|
| Core job | Accept and authorise a charge | Settle foreign currency into INR |
| Currency | Mostly domestic INR | Multi-currency to INR |
| FX handling | Marked-up on foreign cards | Mid-market rate |
| Compliance docs | Not its job | Auto eFIRA, purpose code |
| Integration | Plugin, SDK or API | Account, invoice or API |
The names overlap in search too.
If you are looking up "flow payment gateway" while comparing options, note that Xflow is a cross-border receiving platform, not a domestic card gateway, so it complements the gateway you pick rather than competing with it.
If you run a platform and are weighing an in-house build against a ready integration, the build vs buy platforms cross border payments comparison lays out the trade-offs.
See how you can integrate Xflow into your website for a better transaction experience.
Frequently asked questions
Hosted checkout can go live in one to three days. Hosted fields take one to two weeks. A full API build with SAQ D compliance runs three to eight weeks depending on your flows and testing.
Typically PAN, business registration proof, GST details where applicable, a bank account and authorised-signatory identity. For cross-border receiving, KYB verification is similar and often completes online.
Not automatically. Full API gives control but pushes you to PCI SAQ D. Hosted checkout is faster, lower-risk and enough for most merchants. Choose API only when you need custom flows or payments for platforms with split settlements.
PCI DSS is the card-data security standard. If you accept cards, it applies. Hosted checkout keeps you at the lightest SAQ A tier; handling card data yourself raises you to SAQ D.
No. Use the gateway's official sandbox test cards for all testing. Only after sandbox passes do you switch to live keys and run one small real transaction to confirm settlement.
It can accept a foreign card, but it applies an FX markup and does not issue the FIRA and purpose-code evidence RBI expects. A cross-border receiving layer handles that side compliantly.
Use the gateway's official plugin or app, enter your API keys, and configure webhooks. If no native plugin exists for your chosen provider, you build a small custom integration using its API.
