Adding a payment gateway to an e-commerce platform looks simple until you're past the demo checkout. This guide covers every real gateway option (not just the five names every comparison repeats), what each one is actually built for, and the parts, webhooks, PCI scope, and settlement that decide whether the integration is smooth or a six-month headache.
✓Key Takeaways
Quick answer: Payment gateway integration means connecting your e-commerce platform to a service that authorizes and processes card and digital payments - Stripe, PayPal, Adyen, and a much longer list than most comparisons cover. The API calls are usually the easy part. The real decisions are which gateway (or combination of gateways) fits your markets and volume, how much PCI compliance scope you take on, how you handle payment methods beyond cards, and how you handle the failure cases - declined payments, webhook retries, disputes, delayed settlement - that a demo checkout never shows you.
How Payment Gateway Integration Actually Works
There are four ways to integrate a payment gateway, and the choice changes your PCI DSS compliance burden more than almost anything else:
- Hosted checkout (Stripe Checkout, PayPal Smart Buttons): the customer is redirected to or embeds an iframe hosted by the provider. Card data never touches your servers. Lightest PCI scope (SAQ A), fastest to ship.
- API/Elements-based (Stripe Elements, Braintree Drop-in): the payment form lives on your page but tokenizes card data client-side before it reaches your server. More control over UX, still relatively light PCI scope (SAQ A-EP), more integration work.
- Direct-post: card data is submitted straight from the customer's browser to the gateway's servers, bypassing your backend entirely, but the form itself is still styled and hosted on your page. A middle ground between hosted and Elements-based, less common today but still used by some legacy and B2B platforms.
- Fully custom (raw card data touching your backend): maximum control, maximum PCI scope (SAQ D), full compliance audit territory. Rarely worth it unless you have a specific reason (a payments product, not just a store).
Most e-commerce platforms should start with hosted or Elements-based integration. Full custom is a decision to make deliberately, not by default, it's also, by a wide margin, the most expensive path: agencies that build fully custom payment infrastructure typically scope it in the low-to-mid six figures and several months of engineering time, against a fraction of that for integrating an existing gateway. Verify current scoping with whoever quotes it; the point is the order-of-magnitude gap, not a specific number.
The Full Landscape of Payment Gateway Options (2026)
Most "best payment gateway" comparisons stop at five or six household names. The actual landscape e-commerce teams choose from is wider, and the right pick depends heavily on category:
| Category | Gateways | Best fit |
|---|---|---|
| Developer-first / custom builds | Stripe, Checkout.com | Custom platforms, best-in-class API/docs, teams that want full control over UX |
| Brand-trust / marketplace | PayPal, Braintree | Buyer-facing trust signal, marketplaces, split-payment/multi-party payouts |
| Enterprise / multi-currency | Adyen, Worldpay | High volume across many countries, negotiated interchange-level pricing, local acquiring |
| Combined online + in-store (POS) | Square | Retailers running both e-commerce and physical checkout |
| Traditional / legacy | Authorize.Net | Established businesses on older stacks, still widely supported by ecommerce platforms |
| Regional specialists | Mollie (EU-native, strong in NL/DE/BE), Razorpay (India/APAC), PayU (Latin America, CEE, emerging markets) | Teams selling into a specific region where a global gateway's local payment method coverage is thinner |
| Buy Now, Pay Later (BNPL) | Klarna, Affirm, Afterpay | Layered on top of a primary gateway, not a replacement - see below |
| Digital wallets | Apple Pay, Google Pay, Amazon Pay | Not gateways themselves - payment methods your primary gateway needs to support |
| Crypto | BitPay, Coinbase Commerce | Niche but growing for specific verticals (digital goods, cross-border, Web3-adjacent products) |
Fee figures for the major providers (commonly ~2.9% + $0.30 per transaction in the US for card payments, with variations by region, card type, and negotiated volume) are standard published rates as of this writing - verify current pricing directly with each provider before quoting a client or making a build decision.
The category a gateway falls into tells you roughly where it fits - but "roughly" isn't enough to actually decide. Here's what each of the major players is specifically built for, and where it falls short.
Gateway Profiles: What Each One Is Actually Built For
Stripe
The default developer-first choice, and usually the right one absent a specific reason otherwise. Best-in-class API documentation, broad language/SDK support, and a single integration surface (Payment Element) that covers cards, digital wallets, and 40+ local payment methods without separate integrations for each. Revenue collection reaches 195+ countries, though direct local acquiring (which affects approval rates and fees) is more limited to a smaller set of markets than that headline number implies, worth checking for your specific target countries rather than assuming full parity everywhere.
PayPal
The value here is buyer trust, not technical differentiation. PayPal Checkout offered as an additional option alongside cards measurably lifts conversion for a meaningful share of buyers, independent of PayPal's own processing quality. Two integration paths exist: PayPal's own Checkout SDK directly, or through Braintree if you want PayPal and card processing unified under one contract and one integration.
Braintree (PayPal-owned)
Card processing plus PayPal plus Venmo (US) under a single PayPal-owned platform and merchant contract. The Drop-in UI is genuinely fast to implement for a standard checkout; the underlying GraphQL/REST API gives full control when you need a custom flow. The common reason teams pick Braintree specifically over PayPal-direct-plus-a-separate-card-processor: one merchant relationship and one settlement account instead of two.
Adyen
Enterprise-grade and structurally different from Stripe or Braintree: Adyen owns more of the payment stack itself, including direct local acquiring in many of the 30+ markets it operates in. That's why high-volume teams get better authorization rates and more visibility into decline reasons - but it comes with a heavier sales and onboarding process than a self-serve signup, and the implementation is a genuinely bigger lift than Stripe's. Worth it past a certain volume threshold; overkill below it.
Worldpay
One of the oldest processors in the market, with deep enterprise and omnichannel (in-store plus online) relationships, particularly strong in the UK and EU. The developer experience and API documentation are generally considered behind Stripe's or Adyen's, but Worldpay's advantage is legacy enterprise integrations and support for specific verticals - travel, gaming, and other higher-risk categories some newer processors decline to underwrite.
Square
The case for Square is almost entirely about unification: one dashboard, one settlement account, and one reporting layer across online and physical point-of-sale. For a retailer actually running both channels, that's a real operational simplification. For a pure online play with no in-store component, Square rarely beats Stripe or Braintree on developer experience or feature depth - the unification is the whole pitch.
Authorize.Net
Visa-owned since 2010 (via CyberSource) and one of the longest-running gateways still in active use. Its relevance today is less about being anyone's first choice for a greenfield build and more about compatibility - a large share of legacy e-commerce platform plugins and mid-market ERPs integrate with Authorize.Net by default, so a business migrating off an older stack frequently finds it's already the path of least resistance rather than something worth actively choosing from scratch.
Mollie (regional specialist)
Built around the payment method mix that actually matters in the Netherlands, Belgium, and Germany specifically - iDEAL, Bancontact, and SEPA Direct Debit alongside cards, with local settlement. For a team selling primarily into these markets, Mollie's coverage and support for these methods is typically stronger than a global gateway's secondary support for the same methods, the pattern that holds for most regional specialists (Razorpay for India/APAC, PayU for Latin America and CEE) versus their global counterparts.
Regional Payment Methods and BNPL: The Gap Most Comparisons Skip
This is the part almost every payment gateway article treats as an afterthought, and it's often the difference between a checkout that converts and one that doesn't:
- Local bank transfer/debit methods matter more than card rails in some markets. iDEAL is the dominant online payment method in the Netherlands; SEPA Direct Debit matters across the Eurozone, including Germany; a checkout that only offers card payments in these markets is leaving conversion on the table, not just missing a nice-to-have.
- BNPL is no longer niche. Klarna, Affirm, and Afterpay sit on top of your primary gateway rather than replacing it, most integrate as an additional payment method alongside cards, not as a swap. Whether to add one depends on average order value and audience, but it's a decision worth making deliberately rather than defaulting to "cards only" because that's what the tutorial covered.
- Digital wallets are a checkout-speed lever, not a separate integration. Most modern gateways (Stripe, Braintree, Adyen) support Apple Pay and Google Pay as a configuration flag rather than a separate build - the mistake is treating wallet support as a future phase instead of a default-on setting.
- Currency display and settlement currency are two different decisions. Showing prices in a customer's local currency doesn't mean you're settling in that currency; mixing these up is a common source of finance-team headaches after launch, not just a checkout UX detail.
What Actually Slows Teams Down
The comparisons above are the easy part to research. What tends to eat real engineering time once this ships to production traffic, and what almost none of the guides ranking for these keywords cover in any depth:
- PCI scope creep. A hosted checkout that later needs a custom step (saved cards, a multi-step checkout with card entry mid-flow) can silently push you from SAQ A into a heavier compliance tier. This is an architecture decision, not something to discover during a compliance review.
- Webhook reliability, the single most commonly underestimated piece. Payment status changes (successful charge, failed charge, dispute opened, refund issued) arrive as webhooks, not as a response to your API call. Three things break in production that never show up in a tutorial: idempotency (the same webhook event arriving twice and your system double-processing it), ordering (a "refund" webhook arriving before the "charge succeeded" webhook it refers to, because delivery isn't guaranteed in order), and retry storms (a provider retrying a webhook your endpoint is silently failing on, until you notice from a spike in support tickets, not from monitoring).
- Multi-gateway routing and failover. Once you're processing real volume, a single point of failure on one payment provider becomes a real business risk. Routing logic (by region, by decline reason, by cost) is a project of its own, not a config flag.
- Settlement timing and reserves. Funds don't land in your account the moment a charge succeeds - settlement is typically 1-3 business days for established accounts, longer for new merchant accounts or higher-risk categories, and some providers hold a reserve (a percentage of volume held back against future chargebacks) especially in a merchant's first few months. This affects cash flow planning directly and is rarely mentioned in gateway comparison content at all.
- Reconciliation. Matching what the gateway says it processed against what your order system says was paid - across refunds, partial captures, and currency conversion, is one of the most commonly underestimated pieces of a payments integration.
- Fraud and chargeback handling. Built-in fraud tools (Stripe Radar, PayPal's fraud protection) cover the basics; e-commerce-specific fraud patterns (card testing, friendly fraud) usually need additional rules tuned to your actual order data. Chargeback fees ($15-50 per dispute, on top of losing the sale) add up fast at volume.
- Migrating between gateways. Almost no comparison content covers this, but it's a real, common project: a store outgrows its original gateway's pricing, needs a feature only a competitor supports, or wants to add a second gateway for redundancy. Migration means re-tokenizing saved cards (a real technical constraint most gateways don't make trivial), running both systems in parallel during cutover, and reconciling historical transaction data across two providers.
None of this means the integration is hard to start. It means "add a payment gateway" is a small architecture project once it's handling real transactions, not a weekend API integration.
Signs you can integrate this yourself
- Single gateway, single primary market, and hosted or Elements-based checkout covers your use case.
- Transaction volume is predictable enough that you're not yet worried about failover or multi-gateway routing.
- No unusual compliance or regional-payment-method requirements (no marketplace split-payments, no saved-card-on-file flows beyond what the gateway handles natively).
Signs it's worth bringing in help
- You're expanding to multiple markets/currencies and need routing logic, local payment methods (iDEAL, SEPA, BNPL), or negotiated processing rates.
- The integration touches an existing order/inventory system, and getting reconciliation or settlement timing wrong has real financial consequences.
- You need this built once, correctly, by a team that has already hit webhook idempotency bugs, PCI scope surprises, and gateway migrations in production - rather than finding them after launch.
That's the point where some teams bring in a dedicated engineering partner rather than building it solo under deadline pressure. If that's where you are, a few things matter about how a partner handles this kind of work: you keep 100% ownership of the code and IP, you approve every engineer before they touch your codebase, and you talk directly to the engineers building it, not through a project manager relay. InApps holds ISO 27001 certification, which matters directly here - payment data handling is exactly the kind of workload that certification is meant to cover.
InApps' E-commerce & Marketplace team builds storefronts and checkout flows engineered for real transaction volume, and the Fintech & Payments team handles payment systems specifically - built for compliance, security, and the reliability a payments workload needs. For a broader build, Custom Software Development covers the platform work around the checkout itself.
Building or scaling e-commerce checkout, payment infrastructure, or the platform around it? Talk to our team about what a dedicated engineering partner can take off your plate.
Frequently Asked Questions
Related Articles
Best Countries to Outsource Software Development (2026 Guide)
Software development outsourcing means hiring an external engineering team - usually based in another country- to design, build, or maintain software on your behalf, instead of hiring in-house. Most US, UK, and Australian companies do this to access skilled engineers faster and at a lower fully-loaded cost than domestic hiring allows.
How to Choose an Offshore Software Development Company in 2026
Search for "offshore software development company" and you'll get the same result every time: a list. Ten names, fifteen names, twenty-five names, each with a logo and a two-line pitch, and no real way to tell which one is actually right for your project
Are Developers Becoming Too Dependent on AI Tools?
AI coding tools went from novelty to daily habit in under two years, and the tools themselves keep getting better. But using a tool every day is not the same as trusting it, and a wave of 2026 research is starting to show a real gap between feeling faster with AI and actually being better at the job. Here is what the data says, and what it means for how you build and evaluate an engineering team.