Get the integration order wrong and your checkout will fail European customers before you even notice. To integrate a payment gateway into a web app, pick a provider that supports PSD2's Strong Customer Authentication out of the box, wire up server-side payment intents before touching the frontend, and verify webhooks with signatures, not response codes. Skip that order and you'll spend weeks debugging silent payment failures instead of building your product.
| Gateway | PSD2/SCA Support | Local Methods (EU/UK) | Best Fit | Typical Integration Time |
|---|---|---|---|---|
| Stripe | Built-in via Payment Intents | iDEAL, Bancontact, Klarna, SEPA | SaaS, subscriptions, global startups | 1-2 weeks |
| Adyen | Built-in, enterprise risk engine | Full European method coverage | High-volume e-commerce, marketplaces | 2-4 weeks |
| Mollie | Built-in, EU-focused | iDEAL, Bancontact, SOFORT, Klarna | Dutch/Belgian SMBs, simple checkout | 1 week |
| Hosted checkout page | Handled by provider | Depends on gateway | Fastest MVP launch | 2-5 days |
| Embedded Elements/Components | Handled by provider, custom UI | Depends on gateway | Branded checkout, better conversion | 1-2 weeks |
Founders searching for how to integrate a payment gateway into a web app usually land on this question after a first attempt breaks in production, often because a test-mode key made it live, or a webhook silently failed. This guide walks through the actual technical steps and the PSD2 checklist that prevents both.
Your target market decides the gateway more than your tech stack does. A SaaS selling to UK and US customers fits Stripe's subscription billing and Payment Intents API well. A Dutch e-commerce store needs iDEAL as the default option, which points toward Mollie or Stripe's iDEAL support rather than a US-centric gateway.
Adyen makes sense once transaction volume justifies its enterprise pricing and you need a single contract covering dozens of local methods across markets like Germany, Sweden, and Ireland. Below roughly a few thousand transactions a month, that overhead rarely pays off compared to Stripe or Mollie.
If you're still scoping which markets to prioritize, our e-commerce payment integration guide for Sweden breaks down method preferences by country in more depth than we can cover here.
In the Netherlands, over half of online purchases use iDEAL, not a credit card. In Sweden and Germany, Klarna and SEPA direct debit dominate certain categories. Building a checkout that only accepts cards means losing a meaningful share of buyers before they even reach the payment step.
PSD2 requires banks and payment providers operating in the EU and UK to apply Strong Customer Authentication to most electronic payments. In practice, that means a card payment needs two of three factors: something the customer knows, has, or is, verified through 3D Secure 2.
SCA doesn't apply to every transaction. Exemptions exist for low-value payments (typically under €30 with a cumulative cap), recurring merchant-initiated transactions after the first authenticated payment, and transactions where the customer's bank applies transaction risk analysis and decides authentication isn't needed.
The gateways covered here (Stripe, Adyen, Mollie) all implement 3DS2 and exemption logic natively. That's the actual reason to prefer them over a generic merchant account: you inherit their compliance work instead of building 3DS challenge flows yourself.
The fastest path to a compliant checkout is a hosted payment page, while embedded Elements give you brand control at the cost of a bit more setup time. Direct raw API integration handling card numbers yourself is rarely justified for an SMB or startup because it pulls your app into a much heavier PCI DSS compliance scope.
A hosted checkout page (Stripe Checkout, Mollie's hosted payment page) redirects the customer to a page the provider controls. You never touch card data, PCI scope stays minimal, and 3DS2 is handled entirely by the provider. This is the right call for most first launches and MVPs.
Embedded Elements or Components (Stripe Elements, Adyen Web Components) render the card form inside your own page using an iframe the provider controls behind the scenes. You get a fully branded checkout without ever seeing raw card numbers, which keeps you in the lightest PCI DSS self-assessment tier (SAQ A).
Direct API integration where your server touches card numbers moves you into SAQ D territory, the most demanding PCI compliance level. Unless you have a dedicated security team, this route isn't worth the operational overhead for most SMB or startup builds.
Start on the server, not the client. Your backend creates a Payment Intent (Stripe), Payment session (Mollie), or Payment object (Adyen) that specifies amount, currency, and any metadata tying it back to your order record.
This webhook-first pattern is the single most common thing missing from broken integrations we've reviewed. A customer closes the tab right after paying, the frontend never sees the "success" redirect, and your order stays marked as pending forever unless a webhook updates it independently.
Good checkout UX shows the customer's preferred local payment method first, keeps the form on one page, and surfaces errors inline instead of in a generic banner. Every extra redirect or unclear error message costs completed sales, particularly on mobile.
Detect the customer's country or let them pick it early, then reorder payment method icons so iDEAL appears before card entry for Dutch users, or Swish-style bank options rank higher for Nordic ones. Defaulting to a US-centric card-first layout for a European audience is a quiet conversion killer.
Keep form fields to a minimum. Auto-detect card type from the number, format expiry and CVC fields automatically, and never make the customer retype an amount or currency they already confirmed. If a 3DS challenge fails, explain what happened in plain language rather than a raw error code.
Our design team treats checkout screens the same way we treat any conversion-critical flow, testing real card and wallet inputs on mobile before launch. If your current checkout was bolted onto an existing site without this kind of review, a focused UI/UX design review often surfaces the exact friction points losing you sales.
The most frequent production failure is a mismatched webhook secret between environments, so a test-mode signature check silently rejects live events. Always store separate signing secrets per environment and log every rejected webhook rather than failing silently.
Currency mismatches cause a second common failure class. If your product prices are stored in GBP but the gateway account defaults to EUR, transactions can succeed at the gateway while your books record the wrong amount. Lock the currency explicitly on every payment intent instead of relying on account defaults.
Test-mode and production-key mixups happen more often than teams admit, usually when a developer copies an environment variable into the wrong deployment. Build a startup check that refuses to boot if a test key is detected in a production environment variable.
Finally, plan the fallback UX for a failed SCA challenge. Some customers will abandon the 3DS popup or their bank will decline the authentication. Show a clear retry path and, where the gateway supports it, an alternative payment method rather than a dead end.
Run through this list before you take payments live in the EU or UK:
A single gateway with card payments and one local method (like iDEAL) typically takes one to two weeks for an experienced team, covering server setup, frontend Elements, and webhook handling. Add subscription billing, multi-currency payouts, or a second gateway, and expect three to four weeks.
Before any of this begins, a short discovery step that maps your specific payment flows, currencies, and refund policy against the right gateway saves rework later. If you're earlier in planning, our MVP development FAQ covers how that discovery work fits into a broader build timeline.
Yes, Stripe's Payment Intents API handles 3D Secure 2 authentication and exemption logic automatically for EU and UK transactions. You still need to use Payment Intents (not the older Charges API) and pass through the correct customer and billing details for exemptions to apply correctly.
Yes, some businesses run Mollie for Dutch and Belgian local methods and Stripe for global card and subscription billing, routing by customer country. This adds integration complexity, since you need two webhook handlers and two reconciliation processes, so it's usually only worth it once volume in both regions justifies the overhead.
The discovery phase is the planning step where your development team maps out payment flows, target markets, currencies, and compliance requirements before writing integration code. Skipping it is the most common reason teams pick the wrong gateway or discover PSD2 requirements only after launch, when fixing them means reworking a live checkout.
If you want that discovery work done properly before a single line of integration code is written, our team at Axire Infotech maps out your gateway choice, PSD2 requirements, and checkout UX together, so nothing gets bolted on after the fact. For a deeper look at what these integrations cost across different use cases, see our development timeline and cost guide.
Ready to get your checkout live without the compliance guesswork? Contact our team for a technical scope of your payment integration, or browse our web development services to see how we approach full-stack builds end to end.
Let's discuss your project and create something amazing together.
