Payment Gateway Integration Services in India
Payment gateway integration services in India for CTOs, founders and heads of product in the US, UK, Canada, Australia and New Zealand who need money to move correctly on every single attempt. We build the idempotency, webhook and reconciliation layers that stop double charges, silent failures and month-end surprises, across Stripe, Adyen, Braintree, PayPal and Razorpay. Payments code is the one place in your product where a bug becomes a refund, a chargeback and an angry tweet on the same afternoon.
Why Is a Double Charge a Business Incident and Not a Bug?
Take a normal bug. A price renders wrong on a category page. You fix it, deploy, and by lunchtime nobody remembers. Now take the payments version. A network blip between your API and the gateway causes a retry, and two hundred customers are charged twice on a Friday evening.
What follows is not a bug fix. It is a support queue that doubles overnight. It is a finance person building a spreadsheet of who to refund and by how much. It is refund fees you pay whether or not the original charge was your fault. It is a proportion of those customers going straight to their bank instead of to you, which turns a refundable mistake into a chargeback with a fee attached and a mark against your dispute ratio. It is a public post that ranks for your brand name for the next two years. And if you are on a card network monitoring programme because of it, the conversation with your acquirer stops being about engineering entirely.
That asymmetry is the whole reason payment code is written differently from the rest of your product. Everywhere else, you optimise for shipping speed and accept that some defects will reach production and get patched. In the charge path you optimise for never doing the wrong thing twice, because the cost of the wrong thing is external, financial and immediate.
The failures we get called in to fix are almost never exotic. A mobile client retried a request after a timeout that had actually succeeded. A load balancer replayed a POST. A customer double clicked a button with no disabled state. A background job requeued after a deploy and re-ran a batch of captures. A webhook arrived twice, which every gateway warns you about, and the handler created a second order. None of these require an attacker or an unusual stack. They require only that somebody assumed a request happens exactly once, which over a network is never true.
The other half of the problem is quieter and costs more over time. Payments that succeeded at the gateway but were never recorded in your system. Refunds issued in the gateway dashboard by a support agent that your database has never heard of. Fees, adjustments and dispute deductions that make your reported revenue and your bank balance disagree by an amount nobody can explain. Nothing is on fire. The numbers are just wrong, and they stay wrong until someone reconciles them line by line.
What a Payment Gateway Integration Engagement Actually Covers
Scope moves with your business model, but the pieces below are what we build and hand over. All of it lands in your repository, in your language, running in your pipeline.
A written payment model before any code
Every state a payment can be in, every transition, who or what causes it, and what your system does at each one. This document is short and it settles arguments for years. Teams that skip it end up encoding the state machine accidentally across four services and a cron job, and then nobody can answer whether a partially refunded, disputed order should still ship.
The charge path, built to survive retries
Idempotent creation of payment intents and captures, keyed per checkout attempt, with the key persisted before the outbound call and the response persisted after it. Timeouts treated as unknown rather than failed, with a reconciliation path that resolves the unknown from the gateway rather than guessing.
Webhook ingestion that you can trust
Signature verification, replay protection, deduplication on event identifier, fast acknowledgement with processing moved to a queue, and handlers written to tolerate arriving out of order or twice. Plus a poller that catches anything the webhook never delivered, because eventual delivery is a promise about the average case.
Saved payment methods and recurring billing
Vaulting through the gateway, network tokens where the provider supports them, mandate capture for recurring charges, and the retry and dunning logic that decides what happens when a renewal declines.
Refunds, partial refunds and reversals
Modelled properly, including the cases teams forget: refunding more than one line of an order, refunding after a dispute has already been raised, voiding an authorisation that was never captured, and the reversal that arrives from the network without you asking for it.
Dispute and chargeback handling
Ingesting dispute webhooks, freezing the affected order, assembling the evidence package from data you should have been collecting all along, and submitting it inside the window your provider gives you.
Reconciliation against the settlement file
A daily job that pulls the processor payout report, matches every transaction, fee, refund, adjustment and dispute deduction against your ledger, and raises exceptions for anything that does not tie out. This is the piece most teams postpone and most finance teams desperately want.
Test coverage that includes the ugly paths
Gateway sandbox tests for declines, 3D Secure challenges, expired authorisations, duplicate webhooks and network failure mid capture. Definition of done for every batch is the same: reviewed by your engineers, green in your CI, running against gateway test mode, with a written runbook for the failure modes.
Observability and a runbook
Authorisation rate, decline reasons grouped by code, webhook lag, reconciliation exception count and refund volume, all on a dashboard your on call engineer can read at two in the morning. Payments monitoring that only alerts on 500s tells you nothing about the day your authorisation rate quietly drops eight points.
Idempotency Is the First Thing to Get Right, Not the Last
If you fix one thing in your payment code this quarter, fix this. Every other correctness property in the charge path sits on top of it.
Where the key comes from matters more than the key itself
A random identifier generated at the moment you call the gateway protects you against nothing, because a retry generates a new one. The key has to be derived from the customer's intent, not from the request. In practice that means one key per checkout attempt, created when the customer lands on the payment step and carried through every retry of that attempt. If the customer deliberately starts again, they get a new key and a new charge, which is correct.
Store the key before you call out, not after
Insert a row with a unique constraint on the key, then make the gateway call, then update the row with the result. Do it in that order. If the process dies between the call and the response, the row exists in a pending state and your reconciliation job can ask the gateway what actually happened. Store the result first and you have a window where money moved and you have no record of it.
Same key, different payload, is a bug you want surfaced
Gateways hash the request body against the key. Stripe returns an error if the same idempotency key is reused with different parameters, and that error is a gift. It usually means your key generation is broken, or a stale cart is being submitted. Catch it, log it loudly and do not swallow it into a generic payment failure.
Keys expire, so your reconciliation cannot rely on them forever
Provider retention windows are short. Stripe documents holding idempotency keys for a limited period measured in hours, so check the current figure in their reference rather than assuming. A retry that arrives after expiry is a fresh request as far as the gateway is concerned, which is exactly why the local uniqueness constraint in your own database matters as much as the header you send.
The same discipline applies to webhooks and background jobs
Every gateway delivers webhooks at least once, which is documentation speak for sometimes twice. Every queue worth using redelivers on failure. So dedupe on the event identifier, make handlers safe to run repeatedly, and never let a webhook handler perform an action whose second execution has a different effect from its first. Sending the receipt email twice is embarrassing. Issuing the refund twice costs you the money.
Never Trust the Redirect: Webhooks as the Source of Truth
Here is a checkout that works in every demo and fails in production. The customer completes payment at the gateway. The gateway redirects them to your success URL. Your success handler marks the order paid and fulfils it.
Now run it in the real world. The customer pays and closes the tab before the redirect fires. The customer pays on a phone in a lift and the return request never completes. The customer pays, the redirect works, and your success page is also reachable by anyone who types the URL with an order identifier in it. A bank redirect for an alternative payment method takes ninety seconds to confirm and your handler runs before the payment has settled anywhere. In three of those four cases your database is now wrong, and in one of them you shipped goods for free.
What the redirect is actually for
It is a user experience signal and nothing else. Use it to show a confirmation screen, or a polite spinner that polls your own API. It should never be the thing that changes financial state. That distinction alone removes an entire class of production incidents.
Verifying the webhook properly
Every serious gateway signs its webhooks. Stripe sends a signature header with a timestamp and expects you to reject payloads outside a tolerance window, which is what stops a captured request being replayed at you later. Adyen signs notifications with an HMAC key and expects an explicit acknowledgement in the response body. Razorpay signs with a webhook secret. Verify with the raw request body, before any JSON parsing or middleware has touched it, using a constant time comparison. Frameworks that helpfully re-serialise the body are the single most common reason signature verification fails in staging and gets disabled in a hurry.
Treat the payload as a notification, not as data
The most reliable pattern is read through: the webhook tells you which object changed, and you fetch that object from the gateway API before acting. It costs one extra call and removes an entire category of race conditions, because you always act on current state rather than on a snapshot that may already be stale. It also means a replayed old event cannot walk your order backwards.
Ordering is not guaranteed, so state transitions must be defensive
A capture succeeded event can arrive after the refund event for the same payment. A dispute can open before your system has finished recording the original charge. Handlers that assume sequence will corrupt state under load and pass every test in a quiet environment. Encode allowed transitions explicitly and ignore anything that would move a payment backwards.
Always build the poller
Webhook delivery fails. Your endpoint has an outage, a certificate expires, a deploy takes the consumer down for four minutes. Providers retry on a schedule and then give up. A scheduled job that lists payments changed since the last successful sync and reconciles them against your records catches everything the webhook missed, and it is a hundred lines of code. Teams that skip it discover the gap during their first outage, usually while a customer is on the phone.
Your Order Table Is Not a Payment State Machine
A boolean called paid is where most payment bugs are born. A payment is not paid or unpaid. It moves through a set of states, some of which your business cares about deeply and some of which your customers never see.
The states that matter
Authorised means the issuer has approved and reserved the funds, and nothing has moved. Captured means you have claimed those funds. Settled means the money has actually been paid out to you, typically days later and net of fees, which is the state your finance team means when they say paid. Refunded and partially refunded are separate states with separate amounts. Disputed means the cardholder has gone to their bank and the funds have usually already been pulled back pending the outcome. Reversed covers the cases where the money comes back without a refund being requested. Voided is an authorisation cancelled before capture. Expired is an authorisation that aged out because you never captured it, and hold periods vary by card type and acquirer, so confirm yours rather than assuming a week.
Why authorised and captured must be separate columns
If you sell physical goods, you should usually authorise at checkout and capture at dispatch, because charging for something you have not shipped invites disputes and, in some markets, breaches card scheme rules your acquirer will enforce. That means an order can be authorised for one amount and captured for a lower one when an item goes out of stock. Collapse those into a single amount field and you lose the ability to answer basic questions, like how much money you are currently holding on unfulfilled orders.
The transitions people forget to model
Partial capture followed by expiry of the remaining authorisation. Refund of a payment that is already disputed, which usually needs to be blocked outright because you can end up returning the money twice. A dispute that is later resolved in your favour, which returns funds and needs its own state rather than being folded back into captured. A payment that succeeds at the gateway while your service was down and arrives as a webhook eleven minutes after the customer gave up and paid again.
Where the state should live
In a payments table that is separate from your orders table, with the gateway identifier stored as the join. One order can have several payment attempts, several partial captures and several refunds. Modelling them as columns on the order is the decision teams regret most, because unpicking it later means a migration across live financial data, which is the migration nobody wants to run.
An immutable event log underneath it all
Append every gateway event and every internal transition to a log you never update in place. When finance asks why a customer was refunded eleven pounds on a Tuesday, you can answer in thirty seconds. When a dispute needs evidence, the log is the evidence. Storage is cheap and the alternative is archaeology through application logs that rotated out a month ago.
What Do 3D Secure and SCA Actually Do to Your Conversion Rate?
If you sell into the European Economic Area or the United Kingdom, strong customer authentication under PSD2 is part of your checkout whether you designed for it or not. Getting it wrong in either direction costs you money, and the two failure modes look nothing alike.
The two ways teams get it wrong
Some apply 3D Secure to everything. Every customer gets a challenge, a proportion abandon at the bank's screen, and conversion drops in a way that shows up in the weekly numbers before anyone connects it to the payment change. Others apply it to nothing and watch their decline rate climb as issuers refuse unauthenticated transactions, which is worse because the customer sees a failure rather than a friction.
How the exemption framework is meant to work
The regulation anticipates that not every payment needs a challenge. Low value payments, transactions your provider's risk analysis scores as safe, merchant initiated transactions such as subscription renewals, and beneficiaries the customer has trusted are all handled differently from a first time card entry for a large basket. The mechanics differ per provider and the eligibility rules are a compliance question, so this is one to work through with your payment provider and your counsel rather than taking from a services page.
What 3D Secure 2 changed technically
The older flow bounced the customer to a full page bank screen and was hostile on mobile. The current protocol passes a much richer set of data elements from the merchant to the issuer, which lets a large share of transactions authenticate without the customer seeing anything at all. The quality of what you send matters. Sparse device data, a missing billing address or an absent cardholder email push transactions towards a challenge that a fuller payload would have passed silently.
Liability shift is the part your finance team cares about
An authenticated transaction generally moves fraud chargeback liability from you to the issuer. That is a real commercial benefit and it changes the arithmetic on whether to challenge a borderline payment. On a high value order, a challenge that costs you a few percent of completions can be cheaper than absorbing the fraud. Model it with your own numbers rather than adopting a blanket rule.
Building it so it can be tuned later
We implement authentication behind a policy layer rather than scattering conditionals through the checkout. Thresholds, exemption requests and challenge behaviour become configuration you can change without a deploy, and every decision is logged with its inputs. Six months later, when someone asks why authorisation rates in Germany differ from France, the data is there.
Card on File, Network Tokens and Saved Payment Methods
Saving a card looks like a small feature. It is actually the point at which your payment integration acquires long lived state, and the decisions you make here are expensive to reverse.
Vault at the gateway, always
Every provider we work with stores the card and hands you an opaque reference. Stripe gives you a payment method attached to a customer, Braintree gives you a vaulted payment method token, Adyen gives you a stored payment method identifier. That reference is what your application keeps. It is useless to an attacker who steals your database and it keeps the card data out of your systems entirely.
Network tokens sit underneath and are worth understanding
Visa and Mastercard both operate token services that replace the underlying card number with a network issued token bound to your merchant relationship. The practical benefits are twofold. Authorisation rates are usually higher, because issuers treat network tokens as lower risk. And when the customer's physical card is reissued after loss or expiry, the token keeps working, which quietly removes a large slice of subscription failures. Most gateways can enable this for you. Ask, because it is often off by default.
Mandates, and why the first charge is different from the rest
A card on file charge that the customer initiates is a different beast from one your system initiates while they sleep. The networks distinguish them, issuers price and score them differently, and authentication rules treat them differently. Your integration must flag the initiating party correctly on every transaction. Getting this wrong is a common cause of unexplained declines on renewals when the first payment went through fine.
Migrating a vault between providers
If you have thousands of saved cards on one gateway and want to move, you do not export the card numbers. The providers run a vault migration between themselves under their own compliance controls. It takes planning and lead time, and it is the single most underestimated task in a gateway migration. Discover it in the planning phase, not the week before cutover.
What the customer sees
Show the brand, the last four digits and the expiry. Let them delete a card and make sure delete actually detaches it at the gateway rather than hiding a row. If a card is about to expire and you bill it monthly, tell them before the failure rather than after, because a dunning email that starts with an apology converts far worse than a reminder that starts with a heads up.
Subscriptions, Retries and the Involuntary Churn Nobody Budgets For
For a subscription business, a meaningful share of cancellations are not decisions. They are failed renewals where the customer never intended to leave. That is involuntary churn, and it is an engineering problem dressed as a retention problem.
Read the decline reason before deciding what to do
A soft decline, such as insufficient funds or a temporary issuer refusal, is worth retrying, because the same card frequently works days later when a salary lands. A hard decline, such as a card reported stolen or a closed account, will never succeed and retrying it wastes fees and irritates issuers. Bucketing declines by response code and treating the buckets differently is a small piece of work with a direct revenue effect.
Retry timing is a real decision
Hammering a failed card daily is the worst option available. It burns transaction fees, damages your standing with issuers, and the card networks limit how many times a declined authorisation may be retried and can penalise merchants who exceed it. Confirm the current limits with your acquirer. A schedule spread over a couple of weeks, avoiding weekends and aligned with common pay cycles, materially outperforms a naive loop.
Updating credentials automatically
Visa and Mastercard both run account updater services that refresh a stored card when it is reissued, and network tokens give you similar behaviour without a separate lookup. Combined, they recover renewals that would otherwise fail for no reason other than a card expiring. Ask your provider what they support and whether it is enabled.
Dunning is a product surface, not a cron job
The emails, the in app banner, the grace period during which service continues, and the point at which access is finally revoked all belong to a single designed flow. Give the customer a one click way to update their card that does not require logging in, remembering a password and finding a settings page. Most dunning recovery is lost at the point where fixing the problem takes four steps.
Proration, upgrades and the arithmetic that goes wrong
Mid cycle plan changes, seat count adjustments, trials converting on a different day from the billing anchor, and tax applied to a prorated amount are where subscription billing actually gets difficult. If your provider's billing product handles your cases, use it and stop writing invoice logic. If it does not, we build it deliberately and test it against a set of scenarios you sign off, because billing arithmetic that is quietly wrong shows up as support tickets months later.
Multi-Currency, Cross-Border and What Actually Lands in Your Bank
Displaying prices in three currencies is a frontend change. Collecting, converting and settling in three currencies is an accounting change, and the two get conflated constantly.
Presentment currency and settlement currency are different things
What the customer is charged in and what you receive in are separate decisions. You might present in euros, have the payment converted by your provider, and settle in pounds. That conversion carries a margin, and that margin is a cost of goods sold that belongs in your unit economics rather than being discovered at year end.
Local acquiring changes your authorisation rate
A card issued in Germany processed through a German acquiring connection is treated as domestic. The same card processed through an acquirer in another region is cross border, which typically means a higher decline rate and different interchange. If a meaningful share of your revenue comes from one overseas market, local acquiring is one of the few payment changes that shows up in revenue rather than only in cost. This is a large part of why Adyen wins enterprise deals.
Store the amount three times
Presentment amount and currency, settlement amount and currency, and the rate used. In minor units as integers, never as floats. Rounding a monetary value in a float is a bug that surfaces once every few thousand transactions and takes a day to find. Every gateway API works in minor units for exactly this reason.
Dynamic currency conversion is usually a trap
Letting the customer choose to be billed in their home currency at the point of sale looks customer friendly and typically carries a poor rate, which is why the revenue share is offered to you in the first place. It also generates disputes when customers compare the amount on their statement to the price they saw. We would rather price properly in each market.
Refunds do not reverse the exchange rate
A refund issued weeks after the payment converts at the rate on the refund date, not the original one. On a volatile pair you can refund a customer the exact amount they paid and still be out of pocket. Your ledger has to model that difference explicitly, or your reconciliation will throw exceptions it cannot explain.
Refunds, Partial Refunds and Reversals
Refunds get built in an afternoon at the end of a project and then cause problems for years. The full call refund endpoint is the easy ten percent.
Partial refunds against lines, not against orders
If a customer returns one of four items, someone has to decide how much of the shipping and how much of the tax comes back. Encode that policy once, apply it consistently, and record which lines a refund relates to. Support agents refunding arbitrary amounts through the gateway dashboard is how order totals and refund totals stop agreeing.
Guard against over refunding
Sum existing refunds server side and reject anything that would exceed the captured amount, with the check inside the same transaction that creates the refund record. Two support agents acting on the same angry email thirty seconds apart is not a hypothetical.
Void is not refund
Cancelling an authorisation before capture releases the hold and usually costs nothing. Capturing and then refunding moves money twice, may cost you the processing fee, and leaves the customer waiting days for funds that never needed to leave. If the order is cancelled before dispatch, void it.
Refunds after a dispute are dangerous
Once a chargeback exists, the funds are typically already withdrawn. Issue a refund on top and you can pay twice with no route to recovery. Block refunds on disputed payments in code and require an explicit override with a reason recorded.
Reversals you did not ask for
Issuers and networks reverse transactions for their own reasons: a duplicate detected upstream, an authorisation reversal after a partial capture, a payout returned by a bank because account details changed. These arrive as webhooks and your system needs a state for them. Treating an unexpected reversal as an error and dropping it means the money left and your records say it did not.
Chargebacks and the Evidence You Wish You Had Collected
A dispute is a deadline with a form attached. You get a limited window to respond, the window is set by the network and your provider rather than by you, and the response is only as good as the data you were already storing when the transaction happened.
Categories behave differently and should be handled differently
Fraud disputes, where the cardholder says they did not make the purchase, are won with authentication records, device and address matching and delivery proof. Authorisation and processing disputes are usually operational errors on your side and are often not worth fighting. Consumer disputes, where the customer says the product never arrived or was not as described, are won with fulfilment evidence and a clear record of your communications. Sorting incoming disputes into these buckets automatically saves your team from spending an hour on cases that cannot be won.
Collect the evidence at purchase time
By the time a dispute lands, the transaction may be months old. What wins representment is data you captured on the day: the IP address and device fingerprint at checkout, the address verification and card verification results, the authentication outcome, the delivery tracking number and its confirmed delivery event, the customer's login history, and previous undisputed purchases on the same card. Building a dispute flow before you build this collection is building a form with nothing to put in it.
Automate the packaging, keep a human in the loop
The right shape is a system that assembles the evidence bundle automatically, presents it to whoever owns disputes, and submits on approval with a countdown against the deadline. Fully automatic submission tends to send weak evidence on cases that were winnable with one extra document.
Prevention beats representment
The cheapest dispute is the one that never opens. Descriptors that clearly show your trading name so customers recognise the line on their statement. An easy refund path so the annoyed customer contacts you before their bank. Notification services offered through your acquirer that let you refund a pending dispute before it becomes a formal chargeback. And accurate delivery expectations, since a large share of item not received cases are really item arrived later than promised.
Watch your ratio, not just your losses
Card networks operate monitoring programmes based on your dispute rate, and crossing a threshold brings fees, remediation plans and in serious cases the loss of your ability to accept cards. Your acquirer will tell you the thresholds that apply to your account. The engineering consequence is that the dispute ratio belongs on a dashboard with an alert, not in a monthly report.
Reconciliation Against the Processor's Settlement File
This is the least glamorous part of payments work and the part finance teams remember you for. Your application knows what it asked for. The processor knows what happened. The bank knows what arrived. Reconciliation is the job of proving all three agree, every day, automatically.
Three way matching
Match your ledger against the processor's transaction and payout reports, then match the payout total against the credit on your bank statement. Two way matching, which most teams do, catches application bugs. Three way matching also catches the payout that never arrived and the deduction nobody expected.
What breaks the match
Fees deducted at transaction level or netted off the payout. Dispute amounts and their reversals. Currency conversion on cross border payments. Payouts that batch several days of activity into one credit. Refunds issued in the dashboard by a human. Adjustments the processor makes for its own reasons. Each of these needs a rule, and the set of rules is specific to your provider and your payout schedule.
Exceptions are the product
The output of a reconciliation run is not a green tick. It is a queue of things that did not match, each with enough context for a human to resolve it, and a record of how it was resolved. Aim for an exception queue that is normally empty and loud when it is not. A reconciliation report nobody opens is worse than none, because it creates the belief that someone is checking.
Automate the fetch, always
Every provider exposes settlement data through an API or scheduled export. Stripe balance transactions, Adyen settlement detail reports, Razorpay settlement reports. Pull them on a schedule into your own store with the raw file retained, so a question about a payout from four months ago is a query rather than a support ticket to your processor.
The historical pass usually pays for the work
When we run reconciliation across a year of past activity for the first time, something is almost always found. Refunds processed in the dashboard and never recorded. Disputes lost by default because nobody was watching the queue. Duplicate charges refunded manually with no trace. Fee changes that took effect quietly. None of it is dramatic on its own, and it adds up to a number worth knowing.
How Do You Keep Card Data Out of Your PCI DSS Scope?
Start with the framing that matters. We are an engineering team, not an assessor. We build integrations designed to minimise how much of your estate touches cardholder data, and we will tell you honestly where a design choice increases your exposure. What your obligations actually are, which self assessment questionnaire you are eligible for and whether your implementation satisfies it are determinations to work through with your QSA, your acquirer and your counsel. Nothing on this page is a compliance opinion or a certification claim.
The architectural principle
Card data your servers never see cannot be stolen from your servers, cannot be logged accidentally, cannot appear in a database backup and cannot end up in an error report. Every design decision below follows from that single idea, and it is the reason the answer to should we build our own card form is almost always no.
Hosted fields and how they work
Stripe Elements, Adyen Components, Braintree Hosted Fields and the equivalents elsewhere render the card inputs inside an iframe served by the provider. Visually the field sits inside your checkout and you style it to match. Technically the keystrokes belong to the provider's document, your JavaScript cannot read them, and the card number goes directly from the browser to the provider in exchange for a token. Your server receives the token.
Full redirect and hosted checkout
Sending the customer to a provider hosted payment page removes even more surface, at the cost of design control and a step in the funnel. For low volume or early stage products it is often the right trade, and it is straightforward to move to embedded fields later once the volume justifies the work.
Why self hosting card data is almost always wrong
Accepting the primary account number on your own servers pulls your web tier, application servers, databases, backups, logging pipeline and every engineer with production access into scope. It changes your assessment burden, your network segmentation requirements, your key management obligations and your breach exposure, permanently. There are businesses with genuine reasons to do it, typically those operating their own vault across many acquirers at large volume. If you are a product company selling a service, you are almost certainly not one of them, and the engineering cost is the smallest part of the bill.
Scope leaks that surprise people
Even with hosted fields, the page hosting them matters. Recent versions of the standard pay explicit attention to scripts on payment pages and to change detection on them, because a compromised third party tag can read a form it has no business reading. So the analytics, session replay and tag manager scripts on your checkout page are part of this conversation. So are support tools that let agents take a card over the phone, call recordings that capture card numbers being read aloud, screenshots pasted into ticketing systems, and the log line somebody added while debugging. We look for these during the work and flag them, because they are the ones that get missed.
Choosing a Gateway: Stripe, Adyen, Braintree, PayPal and Razorpay
There is no best gateway. There is a best fit for where you sell, what you sell, how much you process and how much engineering time you want to spend. Here is how we actually advise, including where each one is the wrong answer.
Stripe
The best developer experience in the category and the fastest route from nothing to taking money. The API is coherent, the documentation is genuinely good, test mode behaves like production, and the surrounding products for subscriptions, invoicing, marketplaces and reporting mean you write less code. If you are a SaaS or digital product business selling internationally, this is usually the default and usually correct. Where it stops being obvious is at high volume with concentrated geography, where pricing and local acquiring performance start to favour a provider that acquires locally, and in markets where local payment method coverage matters more than API elegance.
Adyen
Gateway, risk engine and acquirer in one, which is the structural difference that matters. For a business processing serious volume across several countries, local acquiring and a single platform across web, app and physical retail can move authorisation rates by a margin that dwarfs any difference in fees. The trade is effort. Onboarding is a commercial process rather than a signup, the API is more explicit and less forgiving, and the platform assumes a team that understands payments. For an early stage product it is overkill. For a business with a real international footprint it is frequently the upgrade that pays for itself.
Braintree
Owned by PayPal, and its strongest argument is exactly that: card payments, PayPal and the wallets through one integration and one vault, rather than bolting a separate PayPal flow onto a card gateway. Mature vaulting, a reasonable drop in UI and a clear transaction lifecycle. It tends to appear in businesses where PayPal is a large share of volume and the team wants one reconciliation surface. Compared to Stripe the surrounding product ecosystem is thinner, so more of the billing logic stays yours.
PayPal
Not really a competitor to the others, more a payment method your customers expect to see. In several markets a visible PayPal button measurably lifts completion, particularly for first time buyers who will not type a card number into a brand they do not know. The integration is straightforward through the Orders API. The things to plan for are that its dispute process runs on PayPal's own terms rather than the card networks', that the money sits in a PayPal balance with its own payout behaviour, and that reconciliation is a second data source your finance team has to handle.
Razorpay and the Indian stack
If you are selling to customers in India through an Indian entity, a domestic provider is not a preference, it is a requirement of the payment methods your buyers use. Razorpay, Cashfree and PayU give you UPI, netbanking, domestic cards and wallets natively, settle into an Indian bank account and handle the local mandate mechanics for recurring payments. Razorpay's developer experience is the closest of the group to what a Stripe user expects. The constraint is the reason to plan early: this path assumes an Indian entity and an Indian bank account, and the regulatory and settlement details change more often than in other markets, so confirm the current position with the provider and your counsel rather than with a blog post.
How we run the decision
Where your revenue comes from by country, what proportion is recurring, whether you need a marketplace payout model, what your finance team needs to close the month, and what your engineers will actually maintain. Then a shortlist of two, a sandbox integration of the primary flow for each, and a written recommendation with the trade you are accepting. Abstracting over several gateways to keep options open sounds prudent and usually produces a layer that fits none of them properly. Pick one deliberately, isolate it behind your own payment service boundary, and switch later if the numbers say so.
Selling Into India: UPI, Mandates and Local Expectations
For overseas businesses, India is the market where an otherwise excellent checkout underperforms for reasons that have nothing to do with the product.
UPI is the default, not an alternative
Indian buyers reach for UPI first. A checkout that offers only international cards is asking a large share of the market to use their least preferred method, and the conversion difference is not subtle. Presenting UPI properly, with the app handoff and the collect flow working on mobile, is usually the single highest impact change on an India facing checkout.
Recurring payments work differently here
Subscriptions in India run on mandate frameworks with their own registration, notification and authentication mechanics rather than on a simple stored card charge. The rules are set by the regulator and implemented differently by each provider, and they have changed several times. Treat the mandate lifecycle as a distinct piece of work with its own test plan, and get the current requirements from your provider and your counsel before you design around them.
Tokenisation of stored cards
Indian regulation has moved storage of card credentials away from merchants and towards tokens issued through the networks and providers. Practically, this means the pattern of keeping a card reference in your own database that you might use elsewhere does not apply in the same way. Your provider will tell you what they support. Confirm rather than assume, because this is an area where guidance has been revised repeatedly.
Settlement timing affects your cash flow
Domestic Indian settlement runs on cycles that differ from what a US or UK finance team expects, and the reconciliation data arrives in a different shape. If you are consolidating Indian revenue into overseas accounts, plan that with your finance team and your provider at design time. It has more effect on the month end close than any code you write.
Three Situations We Get Called Into
These are the shapes of problem, described generically rather than tied to named clients.
The marketplace that double charged during a deploy
A rolling deploy causes a handful of API instances to time out mid checkout. The mobile client, which retries automatically on timeout, retries. The charge had already succeeded. Nothing catches it because the charge call has no idempotency key and the order lookup happens before the second charge is created. The team finds out from customer support, not from monitoring. The fix is three pieces: a key generated at the start of the checkout attempt and stored with a unique constraint before the outbound call, a pending payment record that survives a crash, and a sweeper that resolves anything still pending against the gateway a few minutes later. Then a duplicate detection alert that fires on two authorisations for the same customer and amount inside a short window, so the next variant of this problem is found by a dashboard rather than by a customer.
The subscription business bleeding customers it never lost
Monthly renewals fail, the retry logic is a daily loop that gives up after three attempts, dunning is one email to an address the customer stopped using, and cancelled accounts are counted as churn in the board pack. Nobody has separated voluntary from involuntary. The work is to bucket declines by response code and stop retrying the hard ones entirely, spread retries for soft declines across a schedule aligned to pay cycles, turn on network tokens and account updater so reissued cards keep working, and rebuild dunning as a flow with a one click card update link that does not require a login. Then report involuntary churn separately, because until it has its own number nobody can tell whether any of it worked.
The finance team that cannot close the month
Revenue in the application, the processor dashboard and the bank statement all disagree. Three people spend two days a month in spreadsheets. Nobody trusts the number in the board pack. What is missing is not a report, it is a matching engine: settlement files ingested daily, every transaction, fee, refund, adjustment and dispute deduction matched to a ledger entry, and an exception queue for the rest. The first historical run is the interesting one, because it produces a list of refunds issued in the dashboard and never recorded, disputes lost by default, and fee changes nobody noticed. After that the month end close stops being an investigation.
The migration nobody scoped properly
A team decides to move gateways for commercial reasons and scopes the API rewrite. What they miss is the vault of saved cards, which has to move provider to provider under compliance controls with lead time, the subscription mandates that may need re-registration, the reconciliation history that now spans two processors, and the period during which both integrations are live and both sets of webhooks must be handled. We plan migrations backwards from the vault, because it is the constraint everything else waits on.
How the Engagement Runs
Payments work is unusually sensitive to sequence. Building the charge path before the state model is settled produces code you throw away.
First, read what exists
We read your current payment code, your order and payment schema, your gateway dashboard settings and a sample of recent failures. If you have a reconciliation gap, we quantify it before proposing anything. The output is a short written assessment of what is correct today, what is fragile, and what will break under load or under an outage.
Then agree the model on paper
States, transitions, who owns each, what happens on each webhook, what your business rules are for capture timing and refund policy. Signed off by you before implementation. This is the cheapest hour in the project.
Build the charge path first, behind a flag
Idempotent creation, webhook ingestion with verification and dedupe, the state machine and the event log. Running against gateway test mode, in your pipeline, exercised by tests that include declines, challenges, duplicate webhooks and mid flight failures. Behind a feature flag so it can go live for a percentage of traffic rather than all of it.
Then the surrounding surfaces
Saved cards, subscriptions and dunning, refunds and partial refunds, disputes, then reconciliation. Reconciliation deliberately comes late, because it needs real transactions flowing through the new path to be worth anything.
Cut over carefully
New payments through the new path, old payments still refundable and disputable through the old one, both webhook consumers live, and a reconciliation run spanning both. Migrations of live payment traffic are done in slices with a tested way back, never as a single switch on a Friday.
Hand over so you own it
A runbook covering the failure modes, what each alert means and what to do about it. A written model document that matches the code. Tests your engineers reviewed. If the integration only works while we are on it, we have built you a dependency instead of an asset, and that is a failure regardless of whether the code is good.
How We Run Payments Delivery From India
You are hiring a team you will not meet, working on the part of your product that touches money. The questions that follow are fair, and vague answers to them should worry you.
The overlap window, honestly
Our standard working day is roughly 09:30 to 18:30 India time. Against the UK that gives you a comfortable overlap of about five hours across our afternoon and your morning. Against Australia our morning is your afternoon, which is around three usable hours, and New Zealand is tighter still. Against US Eastern, standard hours give you almost nothing, and anyone who tells you otherwise is selling. Making US overlap work means people on shifted hours, typically starting in the early afternoon India time to cover your morning. That is a real arrangement with a real cost in coordination and in the lives of the people doing it, so we agree the shape with you up front rather than discovering it in week three.
Written first, because payments decisions need a record
Decisions live in pull requests, architecture notes and tickets, not in a call somebody half remembers. For payment work this is not a remote working nicety. When a dispute arrives in eight months and someone asks why capture happens at dispatch rather than at checkout, the answer needs to be findable. Every day ends with a written handover: what shipped, what is stuck, and any call we need you to make, so your morning starts with a document instead of a status call.
Review and definition of done
Every change goes through pull request review, and for anything in the charge, refund or webhook path we require a second reviewer with payments context. Done means merged, tested against gateway sandbox including the failure paths, documented in the model, and observable. Not merged and demoed.
Access, and what we deliberately do not want
Almost all of this work happens in gateway test mode against sandbox credentials and synthetic data. We do not want your production card data and there is no engineering reason for us to have it. Where production access is genuinely necessary, for example investigating a reconciliation gap, we ask for the narrowest scoped read only credentials your provider supports, time limited, with the access model written down and agreed with you before anyone uses it. Company managed devices, disk encryption, no production data on local machines. If your security team has requirements of their own, they go into the agreement rather than being negotiated after the fact.
The one thing the timezone is genuinely good for
Settlement files, payout reports and reconciliation runs happen overnight for a US or UK merchant. That is our working day. An exception queue that appears at 02:00 your time can be investigated and either resolved or written up before you are awake, which is one of the few places where the timezone gap is an advantage rather than a cost to manage.
Contracts, IP and exit
Ownership of the code, confidentiality, data handling and the terms for handover and for ending the engagement all belong in the agreement, settled before work starts. We will not put numbers on a web page that belong in a signed document, and you should be sceptical of anyone who does. What is worth insisting on with any vendor, us included: code ownership assigned to you, the work living in your repository from the first commit rather than being delivered as a zip at the end, and handover documentation treated as a deliverable in its own right.
Risks, Blockers and the Parts That Go Wrong
Every payment project hits some of these. Naming them early is cheaper than discovering them in week six.
Provider onboarding is not an engineering task
Underwriting, account verification, enabling specific payment methods and getting production credentials all run on the provider's timetable and depend on your documents, not on our code. Enterprise providers in particular can take weeks. Start it in parallel with the build, on day one.
The existing data model is usually the real work
If payment state currently lives as columns on an orders table, adding proper states means migrating live financial data. That is doable and it needs a plan, a backfill, a period of dual writing and a verification pass. Teams that budget for the integration and not for the migration are the ones that run late.
Sandboxes lie
Test environments do not reproduce real issuer behaviour, real fraud scoring or real decline distributions. Some conditions cannot be simulated at all. We plan for a controlled production pilot on a slice of real traffic, with a rehearsed way back, rather than treating a green sandbox suite as proof.
Decisions we cannot make for you
Capture timing, refund policy, how aggressively to fight disputes, which exemptions to request, whether to add a payment method, and your appetite for friction against fraud loss are commercial decisions. We will bring the trade offs and a recommendation. We will not decide them, and a project stalls fast when there is nobody on your side authorised to.
Regulatory questions belong with your advisers
PCI DSS scope and self assessment eligibility, obligations under PSD2 and its authentication requirements, consumer protection and refund rules in each market you sell into, tax on digital services, and Indian requirements around mandates and stored credentials are all matters for your QSA, your acquirer and your counsel. We build to what they tell us and we flag where a design choice has a compliance consequence. We do not give the advice and we do not claim certifications.
Fraud and payments are different problems
A payment integration reduces fraud incidentally. Deliberate fraud reduction is separate work: rules, scoring, velocity checks, manual review queues and the tuning cycle that follows. It is worth doing and it should be scoped as its own thing rather than assumed to be included.
Engagement Models
Three shapes, picked by what you actually need rather than by what is easiest to sell.
Payments audit
A time boxed review of what you have. We read the charge path, the webhook handling, the state model and a sample of failures, run a historical reconciliation pass, and report where you are exposed to double charges, silent failures and revenue you cannot account for. You get the findings and the reasoning whether or not you continue with us.
Project engagement
A defined outcome with a start and an end. A new gateway integration, a migration between providers, a subscription and dunning rebuild, or a reconciliation system. Scope agreed in writing, built into your repository and your pipeline, with the runbook and model document as deliverables rather than afterthoughts.
Dedicated engineers
Payments engineers who plug into your existing standups and backlog rather than running a separate process, for businesses whose payment surface keeps changing as they expand into new markets, currencies and methods. Team composition, working hours and commercial terms are settled directly with you and written into the agreement.
Where This Sits Alongside Our Other Work
Payment work rarely arrives alone. If the checkout itself is being rebuilt rather than rewired, the storefront, cart and fulfilment decisions constrain the payment model, and that work sits with our ecommerce development services. If the problem is recurring revenue, plan changes and invoicing rather than the charge path, start with SaaS product development and treat billing as the core domain it is.
The interface your gateway talks to is an API like any other, and the retry, timeout and versioning discipline that makes it reliable is the same discipline described on our API development services page. Before a payment path goes live it is worth having someone try to break it deliberately, which is security testing rather than functional QA, and the two find different things. And where the better fit is engineers on your own backlog rather than a scoped engagement, hiring dedicated Node.js developers in India or Java developers in India puts the same skills under a different commercial arrangement.
Frequently Asked Questions About Payment Gateway Integration in India
How do you stop a customer being charged twice?
With an idempotency key generated once per checkout attempt, stored against a unique database constraint before the gateway is called, and replayed if the same key arrives again. The stored record holds the request fingerprint and the response, so a retry returns the original result rather than creating a second charge. Webhook handlers get the same treatment, keyed on the event identifier.
Why can we not just mark the order paid when the gateway redirects the customer back?
Because the redirect is a browser event and browsers are unreliable. Customers close the tab, lose signal on a train, or hit back. The redirect also carries no proof of anything, since query parameters can be edited. Treat the return page as a hint about what to show the customer, and let the signed webhook and a server side fetch of the payment object decide what is actually true.
Do we have to store card numbers to offer saved cards and subscriptions?
Almost never, and you should be actively looking for reasons not to. Every major gateway vaults the card and gives you a token to charge later. That token, plus the network token issued by Visa or Mastercard underneath it, is enough for saved cards, one click checkout and recurring billing. Storing the primary account number yourself expands your PCI DSS obligations enormously for no product benefit.
Which gateway should we use if we sell to customers in India?
It depends on whether you have an Indian entity. Razorpay, Cashfree and PayU settle into Indian bank accounts and give you UPI, netbanking and local cards natively, which is what Indian buyers expect. Without an Indian entity you are looking at international card acceptance through Stripe or Adyen and accepting lower conversion. Confirm the current regulatory position with your payment provider and your counsel before committing.
What does 3D Secure do to our conversion rate?
It adds friction and removes fraud liability, and the net effect depends entirely on how you apply it. Blanket 3D Secure on every transaction costs you completed checkouts. Applied through the exemption framework, so that low risk and low value payments pass frictionlessly and only genuinely risky ones get challenged, most of the cost disappears. Which exemptions you may claim is a question for your provider and your counsel.
How long does a payment gateway integration take?
A single gateway, card payments only, into a codebase that already has a clean order model is a few weeks of build plus a test cycle. Add subscriptions, saved cards, multiple currencies, local payment methods, refunds and reconciliation and it becomes a programme rather than a task. The honest answer comes after we have read your current payment code, not before.
Can you reconcile payments that have already happened, or only new ones?
Both, and the historical pass is usually where the surprises are. We pull the processor settlement reports for the period you care about, match them against your own ledger and your bank statements, and produce a list of every payment that exists in one system and not the others. Teams routinely find missing refunds, unclaimed disputes and fees that were never booked.
Does your team need access to our production payment data?
No, and we would rather not have it. Almost all of this work is done against gateway test mode with sandbox credentials and synthetic data. Where production access is genuinely needed, for a reconciliation investigation for example, we ask for scoped read only keys with the narrowest permission set your provider supports, and the access model is agreed with you in writing before anyone logs in.