Architecture·October 2024·9 min read

Choosing the Right Payment Gateway for Your E-Commerce Site

The gateway decision that actually matters isn't which logo goes on the checkout button. It's whether card data ever touches your servers, because that single architectural choice decides your PCI compliance scope, your settlement flexibility, and how much of the integration work in building the integration you'll own versus outsource.

Start with PCI scope, not the feature list

Every payment gateway comparison starts with fees and features. Start instead with a narrower question: does raw card data ever pass through code you control, even briefly?

If the answer is no — the customer is redirected to a hosted page, or a client-side element (an iframe or tokenizing field) collects the card and sends a token to your server — your PCI DSS scope shrinks to the shortest self-assessment questionnaire, SAQ A. If your servers ever see, even transiently, the raw card number, you're in SAQ A-EP or SAQ D territory, with a much longer control set to implement and attest to annually.

SAQ A's eligibility criteria require that no code on your site captures payment data at all — full redirect or full tokenization, no exceptions. SAQ D applies once you don't meet any narrower SAQ's criteria. Those are two different compliance programs, not two flavors of the same checklist.

Why this decision comes before the feature comparison

A gateway with a slightly worse feature set but a hosted or tokenizing checkout can be live in weeks. A gateway with a richer feature set that requires raw card handling on your servers means a PCI assessment, a qualified security assessor engagement (if you cross SAQ D volume thresholds), and a much longer path to launch.

Decide your PCI posture first. Then compare gateways that fit that posture — not the other way around.

Settlement: when the money actually arrives

Settlement terms vary by gateway, by region, and by your account's risk profile, and they're negotiated, not published as a flat rate. What you should ask every shortlisted provider directly:

What's the standard settlement window, and does it change based on transaction volume or account age?
Is a rolling reserve held against chargebacks, and for how long?
Can settlement currency differ from the currency the customer paid in, and what FX spread applies?
What happens to settlement timing during a dispute or chargeback investigation?

None of these have a universal answer worth quoting as a statistic — they're contract terms specific to your account, your vertical, and your processing history. Get them in writing before you sign, not after your first chargeback.

Methods coverage isn't just "which wallets"

Payment method coverage decisions look like a checklist — cards, PayPal, Apple Pay, Google Pay, buy-now-pay-later — but the real question is which methods your specific customer base actually uses, by region.

India is the clearest example of region-specific rails mattering

A gateway serving Indian customers needs UPI support, not just card rails, because UPI is the dominant instant-payment method in that market. It also needs to handle a regulatory constraint that doesn't exist in most other markets: since the Reserve Bank of India's card-on-file tokenisation mandate took effect, merchants are barred from storing customers' actual card numbers — only card networks and issuers can hold detokenizable card data, and merchants store a network token instead.

This changes your saved-card architecture directly. "Save this card for next time" in an Indian checkout has to be built against token storage from day one, not retrofitted later — this is exactly the kind of vault design decision covered in the integration engineering piece.

A payment method list that reads "cards, wallets, BNPL" without naming region-specific rails (UPI in India, iDEAL in the Netherlands, Pix in Brazil) is a global-default list, not a coverage plan for your actual customers.

3-D Secure and authentication obligations vary by region too

Card-not-present fraud liability and authentication requirements are governed by EMVCo's 3-D Secure specification, now in its second major version, which most card-scheme-mandated authentication flows (Visa Secure, Mastercard Identity Check) are built on. Whether a given transaction requires a full authentication challenge or can go through frictionlessly depends on risk signals the gateway and issuer exchange during the flow.

Evaluate gateways on how much of this exchange they automate for you versus how much you have to orchestrate yourself — this is a real engineering cost, covered in detail in the companion piece on integration mechanics.

Integration model	PCI scope	Build effort	Checkout control
Hosted checkout page (redirect)	SAQ A	Lowest — mostly configuration	Limited — customer leaves your domain briefly
Embedded tokenizing element (iframe/SDK)	SAQ A or A-EP	Moderate — client-side integration, server never sees raw PAN	High — stays on your domain, styled to match
Direct API with raw card handling	SAQ D	Highest — full compliance program required	Full — but rarely worth the compliance cost today

Chargebacks and fraud liability shift by rail, not just by policy

Who eats the cost of a fraudulent transaction depends on the payment method and the authentication path used, not just your own fraud rules. When a transaction goes through a full 3-D Secure authentication challenge and the issuer approves it, liability for fraud on that transaction typically shifts to the issuer — this is the core commercial incentive behind 3DS adoption, not just a security nicety.

A gateway comparison that doesn't specify how liability shift works for each method you plan to support is missing the term that determines who pays when a chargeback happens. Ask directly: for cards, for wallets, and for any local rail like UPI, who holds liability under which authentication conditions?

Dispute handling operations matter more than the dispute rate

Every gateway will show you an aggregate chargeback rate benchmark in a sales deck. What matters operationally is how disputes actually get contested: does the gateway provide a structured evidence-submission API, or does your team manually upload documents through a portal for every case?

At meaningful transaction volume, the difference between an API-driven dispute workflow and a manual one is the difference between a process and a part-time job for someone on your team.

Recurring payments change the evaluation entirely

If your business has any subscription or recurring-charge component, evaluate gateways on their stored-credential and authentication-exemption handling specifically — this is a different capability than one-time checkout support, and not every gateway treats it the same way. Under card network rules and regional SCA frameworks, an initial subscription charge with the customer present can require full authentication, while subsequent recurring charges without the customer present can qualify for a merchant-initiated-transaction exemption.

A gateway that automates this exemption handling correctly saves every recurring charge from an unnecessary authentication attempt against an absent customer, which would otherwise fail outright. Ask specifically how the shortlisted gateway flags and processes merchant-initiated transactions before assuming your one-time-checkout evaluation covers subscriptions too.

Data portability: what happens if you switch gateways later

Every gateway decision is also a lock-in decision, whether or not it's framed that way in the sales conversation. Tokenized card-on-file data is usually gateway-specific — a token issued by one provider generally can't be redeemed by another, which means switching gateways later can mean asking every returning customer to re-enter their card.

Ask whether the gateway supports token portability or a migration path to another provider, in writing, before signing.
Ask what happens to your transaction and dispute history on export — some gateways provide full API-based export, others require a support ticket.
Model the switching cost explicitly as part of the decision, not as a hypothetical you'll deal with later. A slightly worse gateway with a documented migration path can be the safer long-term choice.

The gateway with the best rate today and no documented exit path is the gateway you're negotiating from a position of weakness with in two years. Price the lock-in into the decision now.

A realistic evaluation timeline

Gateway evaluations that drag on for a quarter usually stall because the team is comparing feature lists instead of running the two or three tests that actually differentiate providers for your specific business: your PCI posture, your regional method mix, and your dispute volume profile.

A feature-list comparison treats every gateway's marketing page as equally trustworthy, which is exactly backwards — the things that actually differ between providers rarely make the front page of a comparison chart. Settlement terms, dispute API quality, and token portability are negotiated or discovered, not advertised.

A team that skips straight to a pilot integration against sandbox credentials, armed with the PCI posture and methods list decided up front, will reach a defensible decision faster than one still requesting feature matrices from five vendors in month three.

An evaluation process that doesn't drag on for a quarter

Define your PCI posture target (almost always: hosted or tokenizing, not raw card handling) before requesting a single demo.
List the payment methods your actual customer base uses, by region, from real transaction data — not a generic global list.
Shortlist 2-3 providers that meet both, and request their SAQ type, settlement terms, and 3DS handling in writing.
Run a pilot integration against sandbox credentials before signing a volume-based contract.
Confirm webhook reliability and idempotent retry behavior during the pilot — this is where integration-level engineering problems surface, not in the sales demo.

FAQ

Does a hosted checkout page hurt conversion compared to an embedded one?

It can, if the redirect breaks visual continuity with your brand. A well-styled embedded tokenizing element gets you the same reduced PCI scope as a hosted page with better checkout continuity.

Do we need a separate gateway for international customers?

Not necessarily a separate gateway, but you likely need a gateway that supports region-specific methods and settlement currencies natively, rather than forcing every region through a cards-only flow.

What's the real cost difference between SAQ A and SAQ D?

The direct fee difference is negotiated per contract, but the operational cost is the bigger factor — SAQ D requires ongoing security controls, more extensive documentation, and often a qualified security assessor engagement at higher volumes.

Should transaction fees be the deciding factor?

Only after PCI posture, methods coverage, and settlement terms are equivalent across your shortlist. Fees are the easiest thing to compare and the least likely to be the actual constraint.

Is UPI relevant if we don't sell in India yet?

Not immediately, but if India is on your expansion roadmap, choosing a gateway with existing UPI and RBI-compliant tokenisation support now avoids a second integration project later.

How does this decision connect to the actual API integration work?

The gateway you choose here determines the idempotency, webhook, and 3DS implementation patterns you'll build — covered directly in the companion integration engineering post.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.