How do you integrate a payment gateway?
Short answer: Integrate a payment gateway through the provider’s SDK or hosted checkout so raw card data never touches your servers. That is what keeps you at the light PCI-DSS SAQ A level. A basic SDK integration runs $8,000–$25,000 and takes 1–3 weeks; a production build with subscriptions, webhooks, reconciliation and SCA reaches $30,000–$80,000+.
From the outside, payment gateway integration looks simple: capture a card, charge it. The decisions that actually matter sit elsewhere — in compliance scope and the asynchronous edge cases. Here are the essentials:
- One decision dominates: your integration model sets your PCI-DSS scope. Keep card data inside the provider's hosted page or SDK and you stay at the light SAQ A level. Touch raw card data yourself and you jump to SAQ A-EP or SAQ D.
- Default choice: embedded provider fields / SDK (e.g. Stripe Elements, Adyen Drop-in) — card data goes straight to the provider, you keep UI control, PCI scope stays minimal.
- Cost: a basic SDK integration runs $8,000–$25,000; a production integration with subscriptions, saved cards, webhooks, reconciliation and SCA runs $30,000–$80,000+.
- The hard part is asynchronous: webhooks, signature verification, idempotency and reconciliation — not the happy-path charge.
- For EU customers: 3-D Secure / SCA (PSD2) is mandatory for most online card payments.
- Never store raw card data — tokenize through the provider.
Gateway, processor, acquirer: who does what
Three roles sit behind every card payment. Modern providers blur them together, but keeping them straight helps you reason about cost and failure modes.
- Payment gateway — the technical entry point your app talks to. It securely captures payment details and forwards them. This is what you integrate.
- Payment processor — moves the transaction through the card networks (Visa, Mastercard) between the issuing bank and your bank.
- Acquirer — the bank or financial institution that holds your merchant account and receives the funds.
Providers like Stripe, Adyen and Braintree bundle all three into a single API, so as a developer you integrate one service. That bundling is also why per-transaction fees exist: you pay for gateway, processing and acquiring at once. Deeper integration work across systems calls for the same discipline as our API integration services.
Integration models and how they set PCI scope
Your integration model decides how much of the PCI-DSS burden you carry, which is why this is the choice to get right before any code is written. There are three of them.
1. Hosted checkout (redirect)
The provider hosts the payment page: the customer leaves your app, pays there, and comes back. Card data never reaches you at all. PCI scope: lowest (SAQ A). The trade-off is control — you get less say over the checkout UI, and the flow now includes a redirect. Good for simple stores and fast launches.
2. Embedded fields / SDK (the default)
The provider's secure input components (Stripe Elements, Adyen Drop-in, Braintree Hosted Fields) render inside your own page or app. Card data travels straight from the browser or device to the provider, and your server only ever receives a token. PCI scope: low (SAQ A in most configurations). You still control the surrounding UI. For almost every web and mobile product, this is the right default.
3. Direct / server-side API
Your backend receives raw card data and passes it on to the provider. PCI scope: maximum (SAQ D / Level 1 audit). Now you own a cardholder data environment, annual assessments, network segmentation and a heavy compliance program. Few products can justify it; some platforms and certain telephony or terminal flows are the genuine exceptions. For most teams, choosing this model is an expensive mistake. Our PCI-DSS software development service exists to keep you in the minimal-scope models by design.
Choosing a payment provider
Once the model is settled, pick the provider against your actual requirements rather than brand familiarity.
- Coverage: the cards and local methods your customers use — SEPA, iDEAL, Bancontact, Apple Pay, Google Pay, and regional wallets. Missing a key local method costs conversions.
- Pricing model: flat-rate (simple, e.g. ~2.9% + fixed fee) vs interchange-plus (cheaper at volume, more complex). Model your real volume before committing.
- Payouts: settlement speed and the currencies you can hold and pay out in.
- Model support: subscriptions, marketplaces/platforms (split payments, connected accounts), and saved cards.
- Developer experience: SDK quality, sandbox, documentation and webhook reliability — this directly affects your build cost.
- Fraud & 3-D Secure tooling: built-in risk scoring and SCA handling.
For US and EU products the usual shortlist is Stripe, Adyen, Braintree and Checkout.com. Stripe leads on developer experience and breadth. Adyen is strong for larger volumes and unified global acquiring. Which one is right depends on your markets, your payment methods, and whether you run a marketplace.
Cost and timeline
Two costs matter: the one-time integration build, and the ongoing per-transaction fees.
| Scope | Engineering cost | Timeline |
|---|---|---|
| Basic one-time payments (SDK, refunds, webhooks) | $8k–$25k | 1–3 weeks |
| + Subscriptions, saved cards, multi-currency | $25k–$50k | 4–7 weeks |
| Marketplace / split payments + fraud + full reconciliation | $50k–$80k+ | 8–12 weeks |
Per-transaction fees are separate and provider-set (commonly around 2.9% + a fixed fee on the flat model, lower with interchange-plus at volume). What drives the build cost is the asynchronous edge cases below, not the basic charge.
Tokenization, webhooks, idempotency, reconciliation
The asynchronous plumbing is where a payment integration is actually won or lost.
- Tokenization: the provider's SDK returns a token; your backend stores the token, never the card number. This enables saved cards, subscriptions and one-click checkout while keeping you out of PCI scope.
- Webhooks: the authoritative payment result arrives asynchronously via a signed webhook, not the initial API response. Verify the signature, and never trust a client-side "success" alone.
- Idempotency: use idempotency keys on charge requests and make webhook handlers idempotent — events can be delivered more than once. This prevents duplicate charges and double-fulfilment, the fastest way to lose customer trust.
- Reconciliation: match provider payouts against your own ledger so every transaction is accounted for. A correct ledger turns "did this charge happen?" into a question with a definite answer.
3-D Secure and SCA (PSD2)
If you serve EU customers, the EU's PSD2 mandates Strong Customer Authentication (SCA) for most online card payments, satisfied through 3-D Secure (3DS2). That authentication step does double duty: it reduces fraud and shifts liability to the issuer. Modern providers handle the heavy lifting, but your checkout must support the challenge flow (a step-up screen the customer may see). For US-only flows 3-D Secure is optional, though increasingly used for fraud reduction. The compliance backdrop here is the same one covered in our fintech app development guide.
Scoping the work with a partner
Whether you build in-house or with a partner, scope the integration deliberately:
- Decide the integration model (and therefore PCI scope) before writing code.
- List the payment methods and markets up front — they drive provider choice.
- Treat webhooks, idempotency and reconciliation as first-class requirements, not afterthoughts.
- Start provider onboarding/underwriting early; it runs in parallel with engineering.
- Abstract payment logic behind an internal interface so a future provider switch is cheap.
If you are building the surrounding product too, this fits inside the broader custom software development and fintech work we deliver.
FAQ
What is the difference between a payment gateway and a payment processor?
A gateway is the layer your app talks to — it captures payment details and passes them on. A processor moves the money between the cardholder's bank and yours over the card networks. Modern providers (Stripe, Adyen, Braintree) bundle gateway, processing and acquiring into one API, so you integrate a single service.
Does using Stripe or Adyen remove my PCI-DSS obligations?
It reduces them dramatically but not entirely. Keep raw card data within the provider's hosted page or SDK and your obligation typically drops to the light SAQ A self-assessment. Accept card data on your own pages or servers and you move into SAQ A-EP or SAQ D, which are far more demanding.
Which integration model should I choose?
Embedded fields / SDK (Stripe Elements, Adyen Drop-in) is the right default for almost every product: card data goes straight to the provider, PCI scope stays at SAQ A, and you keep UI control. Use hosted checkout for the simplest launch, and direct/server-side only when a specific requirement forces it.
How much does payment gateway integration cost?
A basic SDK integration runs $8,000–$25,000; adding subscriptions, saved cards, multi-currency, marketplace split payments, fraud handling and full reconciliation pushes a production integration to $30,000–$80,000+. Per-transaction provider fees (commonly ~2.9% + a fixed fee) are separate.
What is 3-D Secure and do I need it?
3-D Secure (3DS2) is an authentication step required to satisfy Strong Customer Authentication (SCA) under PSD2 for most online card payments to EU cardholders. If you serve EU customers, your checkout must support it; modern providers handle most of the work. For US-only flows it is optional but increasingly used for fraud reduction.
Last updated 3 July 2026. Cost and fee ranges reflect typical US/EU integrations and vary by provider, model and scope. Compliance and regulatory references are general guidance, not legal advice — consult a Qualified Security Assessor and qualified counsel for your situation. Request a scoped proposal for your specific integration.
