TL;DR — key facts at a glance
Payment gateway integration looks simple from the outside — capture a card, charge it — but the decisions that matter are about compliance scope and the asynchronous edge cases. 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, and modern providers blur them — but understanding them 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, which is why, as a developer, you integrate one service. The bundling is also why per-transaction fees exist: you are paying for gateway, processing and acquiring at once. For deeper integration work across systems, this is the same discipline as our API integration services.
Integration models and how they set PCI scope
This is the most important section. Your integration model decides how much of the PCI-DSS burden you carry. There are three.
1. Hosted checkout (redirect)
The customer is redirected to the provider's payment page, pays there, and is returned to your app. Card data never reaches you at all. PCI scope: lowest (SAQ A). Trade-off: least control over the checkout UI and a redirect in the flow. 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. The card data goes directly from the browser/device to the provider; your server only ever receives a token. PCI scope: low (SAQ A in most configurations). You keep full control of the surrounding UI. This is the right default for almost every web and mobile product.
3. Direct / server-side API
Your backend receives and transmits raw card data to the provider. PCI scope: maximum (SAQ D / Level 1 audit). This means a cardholder data environment, annual assessments, network segmentation and a heavy compliance program. It is rarely justified — only specific cases (some platforms, certain telephony or terminal flows) need it. 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 decided, choose 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/EU products the common 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; the right choice depends on your markets, 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). The build cost is driven by the asynchronous edge cases below, not the basic charge.
Tokenization, webhooks, idempotency, reconciliation
This 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). The authentication step both 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 16 June 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.
