Taking card payments online looks simple from the outside: a form, a button, a confirmation page. Most of the work in a payment gateway integration sits behind that page. Where the card number travels decides how much security compliance you carry. How your system learns that a payment succeeded decides whether orders and money ever disagree. And if you sell to UK customers, bank-side authentication rules shape your checkout flow.

This guide explains how an online card payment works, the three ways to build a checkout, and the parts of an integration that are easy to underestimate. It is written for US and UK businesses briefing a development team. It is general guidance, not legal or compliance advice; your acquirer, payment provider and advisers have the final word on your obligations.

Quick answer

• Keep card data off your servers. A hosted checkout page or provider-hosted payment fields leave you with the smallest PCI DSS footprint. A direct API integration, where your own systems receive card numbers, brings the largest.
• Treat the provider's server-to-server notification (webhook) as the source of truth for payment status, not the customer's browser returning to your site.
• Design for authentication. UK-issued cards are subject to strong customer authentication, normally delivered through 3-D Secure, so the checkout must handle an extra step mid-payment.
• Build refunds, disputes and reconciliation in the first release. They are part of the integration, not later additions.
• Choose a provider on fit: markets, payment methods, payout currencies, reporting and support matter more than a headline rate.

How an online card payment works

Seven parties are involved in a typical card payment. Knowing who they are makes provider conversations and error messages far easier to follow.

• Customer (cardholder): enters card details or approves a wallet payment.
• Merchant: your business.
• Payment gateway: the technical front door. It collects payment details securely and passes them on.
• Payment processor: routes the transaction to the card network and returns the response.
• Acquirer (merchant bank): the bank that holds your merchant account, accepts card payments on your behalf and settles funds to you.
• Card network (scheme): Visa, Mastercard, American Express and others. They set the rules and connect acquirers with issuers.
• Issuer: the customer's bank, which approves or declines the payment.

Many modern providers bundle the gateway, processor and acquiring relationship into one account, so you may sign a single contract. The roles still exist underneath, and they explain why a payment has stages:

1. Authorization: the issuer checks the card and funds and approves or declines. The money is reserved, not moved.
2. Capture: you confirm you want to take the payment. This can happen immediately or later, for example when goods ship.
3. Settlement and payout: funds move through the network to your acquirer and are paid to your bank account, usually in batches and net of fees.

Your system needs to model these stages separately. "Authorized" is not "paid," and "paid" is not "in your bank account."

Hosted checkout, embedded fields or direct API

This is the most consequential design decision, because it determines whether card data ever touches your website or servers.

The PCI Security Standards Council describes PCI DSS as baseline requirements "intended for all entities that store, process, or transmit cardholder data," regardless of size or transaction volume. The Council writes the standard; your acquirer and the card brands run the compliance programs and tell you how you must validate. Many smaller merchants do this with a Self-Assessment Questionnaire (SAQ), and which SAQ applies depends heavily on how the checkout is built.

On versions: the Council published PCI DSS v4.0.1 in June 2024 as a limited revision with no new or deleted requirements, and stated that v4.0 would be retired on 31 December 2024, leaving v4.0.1 as the only active version. The requirements that were future-dated in v4.0 became effective on 31 March 2025. When we checked in October 2026, the Council's site referred to the standard as PCI DSS v4.x. Confirm the current version in the Council's document library before you rely on it.

The distinction between the first three rows comes from the Council's own wording. For SAQ A, "all elements of the payment pages must only originate from PCI DSS compliant service provider(s)"; for SAQ A-EP, each element may originate from either the merchant website or a compliant service provider (PCI SSC FAQ). All eligibility criteria for a given SAQ must be met, so treat the table as a starting point for a conversation with your acquirer, not a ruling.

Outsourcing the form does not remove every obligation

Two points from the Council are frequently missed:

• Script attacks on embedded checkouts. In January 2025 the Council updated SAQ A, adding an eligibility criterion that merchants confirm their site is not susceptible to attacks from scripts that could affect their e-commerce systems. A follow-up FAQ clarified that this applies to merchants who embed a provider's payment form, for example in an iframe, and not to those who redirect customers to the provider. A merchant can meet it by deploying script protections or by obtaining confirmation from a PCI DSS compliant provider that its solution includes them when implemented as instructed.
• Vulnerability scanning. The Council states that merchants completing SAQ A remain responsible for its requirements, including external scans by an Approved Scanning Vendor, whether they redirect or embed an iframe.

The practical consequence: third-party scripts on your checkout page (analytics, chat widgets, tag managers) are a security matter, not just a marketing one. Ask your developers to keep that page lean and to inventory every script on it.

Which should you pick?

For most small and mid-sized online businesses, hosted checkout or provider-hosted fields are the sensible default. A direct API integration is justified only when there is a specific need that the hosted options cannot meet, and a budget for the security program that comes with it.

Strong customer authentication and 3-D Secure

If you sell to UK customers, authentication is part of your checkout whether you plan for it or not.

The Financial Conduct Authority explains that strong customer authentication (SCA) rules come from the Payment Services Regulations 2017 and related technical standards, and apply when a payer initiates an electronic payment transaction, unless an exemption applies. Authentication is based on independent elements drawn from knowledge (something only the user knows), possession (something only the user has) and inherence (something the user is), and for remote payments it must be dynamically linked to the amount and the payee (FCA technical standards). The FCA set 14 March 2022 as the latest date for full compliance for e-commerce transactions.

The obligation sits with payment service providers such as the customer's bank, not with you as the merchant. But the bank can only authenticate if your checkout lets it. In card payments that is done through EMV 3-D Secure, which EMVCo describes as an exchange of data between the merchant and the issuer to authenticate the consumer. Often the customer sees nothing extra. For higher-risk payments the issuer can require a challenge, such as a one-time passcode or a biometric check in a banking app.

What this means for the build:

• The checkout must handle a payment that pauses for a challenge and then resumes, including the customer abandoning it or the challenge timing out.
• The FCA's technical standards list exemptions, including low-value remote transactions, transaction risk analysis, recurring transactions and trusted beneficiaries. They are applied by payment service providers. Your developers can request them through the gateway where supported, but cannot grant them, so the challenge flow must always work.
• Subscriptions and saved cards need care: authenticate when the customer sets up the arrangement, and flag later charges correctly so issuers can recognize them.

US note: the FCA rules described above are UK regulation. They do not govern domestic US card payments, where the use of 3-D Secure is generally a choice made by merchants, providers and issuers. A US business with UK customers should still expect UK issuers to request authentication. Ask your provider how authentication affects who bears the loss on a fraud dispute, since that is set by card network rules.

Wallets and local payment methods

Cards are not the whole picture in either market.

• Apple Pay and Google Pay (both markets). Apple states that your site receives an encrypted payment token containing a device-specific account number and a one-time cryptogram, not the actual card number, and recommends integrating through a payment provider's SDK or JavaScript API. Google Pay similarly returns a payment token to your website and requires adherence to its brand guidelines and production access approval. Both need setup steps beyond adding a button.
• Bank payments in the US. The ACH Network, which Nacha describes as reaching all US bank and credit union accounts, supports direct debits. It is common for subscriptions, invoices and larger B2B payments. It is not instant in the way card authorization is, and payments can fail after you think they have succeeded, so order logic must wait for confirmation.
• Bank payments in the UK. Open banking lets a customer pay directly from a bank account, approving the payment with their own bank. Open Banking Limited reports that the UK ecosystem has passed one billion payments. Direct Debit remains the familiar route for recurring UK billing.

Each added method brings its own confirmation timing, refund behavior and dispute process. Add the methods your customers actually use rather than every option the provider offers.

Webhooks and reconciliation

A common and expensive mistake is to mark an order as paid when the customer's browser lands on the "thank you" page. Browsers close, connections drop and some payment methods confirm minutes or days later. The reliable signal is the webhook: a message the provider sends from its servers to yours when something happens.

Provider documentation is specific about how to handle these. Stripe's webhook guidance, used here as one example, advises verifying the signature on every event, returning a success response quickly and processing the work in a queue, expecting duplicate deliveries, and not relying on events arriving in order. Other providers publish similar rules. Ask your developers to show you how each is handled.

Reconciliation is the accounting counterpart. A payout to your bank is a net figure: sales, minus refunds, minus disputes, minus fees, sometimes across currencies. Your system should be able to tie each payout back to individual orders using the provider's settlement reports. If finance staff are matching these by hand in a spreadsheet, the integration is unfinished.

Refunds, disputes and fraud tooling

Refunds

Decide who in your team may issue refunds, whether partial refunds are allowed, and how a refund updates stock, invoices and tax records. Refunds should be triggered from your own admin system through the provider's API so both stay in step, with an audit trail.

Disputes (chargebacks)

A dispute starts with the cardholder's bank, and you respond with evidence within a deadline set by the card scheme and your provider. The consumer-side rules differ by country:

• US: the Consumer Financial Protection Bureau explains that consumers can send a billing error notice to their credit card company within 60 calendar days after the charge appeared on their statement.
• UK: the Financial Ombudsman Service describes chargeback as a process run under each card scheme's rules, usually with around 120 days to raise one, and separately describes Section 75 of the Consumer Credit Act 1974, which lets consumers claim against their credit provider for purchases with a cash price of more than GBP 100 but not more than GBP 30,000.

For your developers, the requirement is the same in both markets: keep the evidence. Store order details, delivery confirmation, customer communication and the authentication result against each payment, and route dispute notifications to a named person.

Fraud tooling

Most providers offer address and security code checks, risk scoring, rules you can configure (for example, limits on repeated attempts) and 3-D Secure on demand. Tighter rules block more fraud and more genuine customers, so someone in the business should own the settings and review declined orders regularly.

Testing in the sandbox

Every serious provider offers a test environment with test cards. A successful test payment proves very little. Ask for evidence that these cases were tested:

• Declined cards, expired cards and insufficient funds
• A 3-D Secure challenge that succeeds, fails and is abandoned
• Webhooks that arrive late, twice or out of order
• The customer double-clicking "Pay" or refreshing mid-payment
• Full and partial refunds, and a simulated dispute
• Each wallet and local method on real devices
• A payout report reconciled against test orders

Before launch, confirm that live and test keys are stored separately and that no secret key appears in website or mobile app code.

For technical readers

• Idempotency: send an idempotency key with every payment-creating request so a retry after a network error cannot charge twice. Stripe's API reference describes the pattern; most major providers have an equivalent.
• State machine: model orders and payments as separate entities with explicit states (pending, requires action, authorized, captured, refunded, disputed). Make transitions idempotent and driven by verified webhook events, de-duplicated by event ID.
• Webhook endpoint: verify signatures against the raw request body, exempt the route from CSRF checks, acknowledge fast and process asynchronously.
• Amounts: store money as integers in the minor unit with an explicit currency code. Never use floating point.
• Tokens only: store provider tokens and non-sensitive display data such as the last four digits. Do not log request bodies from payment pages.
• Abstraction: keep provider calls behind one internal interface so that adding a second provider or a new method does not touch order logic.
• Checkout page hygiene: apply a Content Security Policy and keep an inventory of scripts on pages that host payment fields.

Choosing a provider

We are deliberately not quoting fees: they vary by provider, card type, country and volume, and they change. Ask each provider for a written quote and compare it against your own transaction mix. Beyond price, these questions separate providers in practice:

• Can it onboard your legal entity, and does it support both US and UK customers from one account or require separate ones?
• Which currencies can customers pay in, and which can you be paid out in?
• Which wallets and bank methods are supported in each market?
• What are the payout schedule and any reserve or holding terms for your business type?
• Which integration types does it offer, and what PCI DSS documentation does it provide to support your validation?
• How good are the settlement reports, and can they be exported or pulled by API?
• Does it support subscriptions, marketplaces or split payments if your model needs them?
• How are disputes handled, and what support will you get when something breaks?
• How easily could you move your saved card tokens to another provider later?

Your platform matters too. An off-the-shelf store usually has maintained payment extensions, while a custom build gives more control and more responsibility. Our ecommerce development page outlines both routes. If an external team is doing the work, our guide to outsourcing software development from the US and UK covers contracts and handover.

Frequently asked questions

What is the difference between a payment gateway and a payment processor?

The gateway securely collects payment details from your checkout and passes them on. The processor routes the transaction through the card network to the issuing bank and returns the result. Many providers now sell both, plus the merchant account, as one service.

Do I need to comply with PCI DSS if my provider handles the card data?

Yes, though with a much smaller footprint. The PCI Security Standards Council states the standard is intended for all entities involved in payment processing, and that merchants who outsource payment processing remain responsible for the requirements in their self-assessment. Your acquirer or provider will tell you how to validate.

This is general information, not compliance advice.

Is 3-D Secure mandatory?

For UK payments, strong customer authentication is a regulatory requirement on payment service providers unless an exemption applies, and 3-D Secure is how it is normally carried out for cards. For domestic US card payments it is generally optional. A checkout serving both markets should support it.

How long does a payment gateway integration take?

It depends on the drivers, not a standard number: the integration type, how many payment methods and currencies, whether you need subscriptions or split payments, the depth of refund and reconciliation features, and how long provider onboarding and wallet approvals take. A hosted checkout on an existing platform is at the short end; a custom multi-method checkout with accounting integration is at the long end.

Can we store customers' card details for repeat purchases?

Store a token issued by your provider, not the card number. The provider holds the card data and your system keeps a reference it can charge with the customer's consent.

Should we use one provider or several?

Start with one unless you have a clear reason, such as a market or method it cannot serve. A second provider adds resilience and negotiating room but doubles reconciliation and testing work. Building behind an internal interface keeps the option open.

Conclusion

A sound payment integration comes down to a handful of decisions made early: keep card data with the provider, let verified webhooks drive order status, make the checkout handle authentication, and build refunds, disputes and reconciliation into the first release. Then choose the provider that fits your markets and operations.

A practical next step is to write down your markets, payment methods, subscription needs and accounting system, and put the sandbox test list above in front of whoever builds your checkout. Entrant Technologies builds websites, web applications, mobile apps and custom software; if you would like a second opinion on a planned integration, you can request a quote with those details.