Payment Integration: How Payment Gateways Work, Explained

A checkout button looks simple. Behind it, a single card payment passes through four or five companies, several security checks and two separate processes, one that takes seconds and one that takes days. This guide explains how payment gateways work at the technical level, the integration options, what security and compliance require, and how to build a payment integration that holds up in production.

What is payment integration?

Payment integration is connecting your website, app or business system to one or more payment providers so that it can accept, track and reconcile payments. In practice that means three things: collecting payment details securely at checkout, talking to the provider’s API to create, capture and refund payments, and keeping your own records in step with what actually happened to the money.

The core of most integrations is a payment gateway: the service that takes payment details from the customer, encrypts them and passes the transaction into the banking networks. The gateway is what your code talks to.

Who is who in a card payment

Card payments run on what Visa calls the “four-party model”: the cardholder, the issuing bank, the acquiring bank and the merchant, with the card network in the middle (Visa 10-K, fiscal 2025). Gateways and processors are the technology providers that connect a merchant to this system.

Today most businesses deal with a PSP that covers the first three roles, so the line between “gateway” and “processor” matters less than it used to. It still matters when something fails, because the decline reason tells you which party said no.

Payments in numbers

• 258 billion transactions were processed by Visa alone in fiscal 2025, out of 329 billion Visa-branded transactions in total, about 901 million a day (Visa 10-K).
• $1.9 trillion in total volume ran through Stripe in 2025, up 34% (Stripe). Adyen processed €1.39 trillion (Adyen) and PayPal $1.79 trillion (PayPal).
• $33.41 billion was lost to payment card fraud worldwide in 2024, on card volume of $51.9 trillion (Nilson Report).
• 70.22% of online shopping carts are abandoned on average. Among shoppers who abandon for reasons other than just browsing, 19% did not trust the site with their card details, 17% found checkout too long or complicated, 10% had their card declined and 9% did not find enough payment methods (Baymard Institute).

The last point is the business case for doing integration well: trust, a short checkout, fewer false declines and the right payment methods are all things the integration controls.

How do payment gateways work?

Every card payment goes through two separate processes. Authorization happens in real time while the customer waits. Clearing and settlement happen later, in batches, and are when the money actually moves.

1. Collecting and protecting the card data

At checkout, the card number, expiry date and security code should never touch your servers in plain form. With a hosted payment page or embedded fields, the browser sends them directly to the gateway over TLS. The gateway stores the card in its own secure vault and gives your system a token, a meaningless reference you can store and reuse for refunds or later payments.

Card networks now issue their own network tokens, which replace the card number across the whole chain and are updated automatically when a card is reissued. Visa had provisioned more than 16 billion tokens by September 2025 (Visa 10-K). For merchants with stored cards and subscriptions, network tokens mean fewer failed payments after a card expires.

2. The authorization request

The gateway builds an authorization request: amount, currency, card or token, merchant details and risk data such as the device, IP address and billing address. Inside the banking networks these travel as ISO 8583 messages, the standard format for card transactions, where an authorization request and its response have their own message types and fixed fields, such as the response code.

3. Routing through the acquirer and card network

The acquirer, or the processor working for it, forwards the request to the right card network, which identifies the issuer from the first digits of the card number (the BIN) and routes the message to it. PSPs that run their own acquiring can optimize this step, for example by choosing local acquiring in the customer’s country, which tends to raise approval rates.

4. The issuer’s decision

The issuer checks that the card is valid, the account has funds or credit, and the transaction does not look like fraud. In the European Economic Area and the UK, most online card payments also need strong customer authentication under PSD2, usually done with 3-D Secure 2. The issuer either approves without bothering the customer, based on the risk data it received (a frictionless flow), or asks for a challenge, such as a confirmation in the banking app. Merchants that send more data get more frictionless approvals.

5. The response

The issuer returns an approval code or a decline reason, and the response travels back through the network, acquirer and gateway to your system. The whole round trip usually takes a second or two. Approved means the funds are reserved on the customer’s card, not yet transferred.

6. Capture, clearing and settlement

To collect the money, the merchant captures the authorization, either immediately or later, for example when goods ship. An authorization that is never captured expires and the reserve drops off the customer’s statement. Captured transactions are sent in batches for clearing, where the acquirer and issuer exchange the final transaction details through the network. During settlement the issuer pays the acquirer, minus the interchange fee, and the acquirer pays the merchant, minus its own fees. Payouts typically arrive one or more business days later.

7. After settlement: refunds and chargebacks

A refund is a new transaction from the merchant back to the card. A chargeback is started by the cardholder through their bank, for example over fraud or goods not received. The money is pulled back from the merchant, who can contest it with evidence. Chargebacks cost a fee each time, and too many of them can lead to penalties from the card networks.

Payments without cards

A growing share of payments skips the card networks entirely. Account-to-account payments move money directly between bank accounts, often started through open banking APIs, while digital wallets such as Apple Pay and Google Pay are a tokenized card under the hood. In the euro area, all payment service providers have had to send instant credit transfers, with the money arriving within seconds, since 9 October 2025, and to offer a Verification of Payee check that warns the payer if the name does not match the IBAN (European Central Bank). For businesses that collect large payments, instant transfers are now a realistic alternative to cards.

Types of payment gateway integration

How you integrate decides how much control you have over the checkout and how much of the PCI DSS security standard you have to comply with yourself. There are four main options:

For most businesses, embedded fields are the right default: a checkout that looks like yours, while card data goes straight to the provider. A direct API integration makes sense mainly for payment companies and platforms that need full control and are ready to carry the compliance cost.

Security and PCI DSS compliance

Anyone who stores, processes or transmits card data must comply with the PCI DSS standard. Version 4.0.1 is the current one, and its last new requirements became mandatory on 31 March 2025. Two of them target web skimming, where malicious JavaScript on a checkout page steals card details: requirement 6.4.3 to control the scripts on payment pages, and 11.6.1 to detect unauthorized changes to them.

For merchants using a hosted page or embedded fields, the PCI Security Standards Council removed these two requirements from the simplest self-assessment, SAQ A, but added an eligibility criterion instead: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems (PCI SSC, January 2025). In other words, using iframes does not make the page around them someone else’s problem.

Practical rules that apply to any integration:

• Never log or store card numbers or security codes, and keep secret API keys on the server only.
• Verify the signature of every webhook before trusting it.
• Use a content security policy and keep an inventory of the scripts on your checkout pages.
• Use the provider’s fraud tools and 3-D Secure, and send as much risk data as you are allowed to.

How to build a reliable payment integration

Most payment bugs are not about the API call. They come from networks that time out, events that arrive twice, and records that drift out of step with the provider. The first thing to get right is the model: a payment is a state machine, not a yes or no.

Make every request idempotent

If a request to create a payment times out, you do not know whether it went through. Retrying blindly can charge the customer twice. Providers solve this with idempotency keys: a unique value sent with the request so that a retry returns the original result instead of creating a second payment. Stripe, for example, accepts keys up to 255 characters and suggests random UUIDs, and it may remove keys once they are at least 24 hours old (Stripe docs). Generate the key once per payment attempt and store it with your order.

Treat webhooks as the source of truth

Many payment events happen after the customer has left: 3-D Secure completes, a bank transfer arrives, a refund settles, a chargeback opens. Providers report these through webhooks, HTTP calls to your system. They are not delivered exactly once or in order. Stripe retries failed deliveries for up to three days in live mode, warns that the same event can arrive more than once, and advises returning a success status quickly, before running complex logic (Stripe docs). A handler in Java with Spring looks like this:

@PostMapping("/webhooks/payments")
public ResponseEntity<Void> onEvent(@RequestBody String rawBody,
                                    @RequestHeader("Signature") String signature) {
    PaymentEvent event = verifier.verifyAndParse(rawBody, signature); // reject forged calls
    if (!processedEvents.markIfNew(event.id())) {                      // duplicate delivery
        return ResponseEntity.ok().build();
    }
    queue.publish(event);              // do the real work asynchronously
    return ResponseEntity.ok().build(); // answer fast, or the provider retries
}

The event ID is recorded first so a repeated delivery is acknowledged and ignored, and the actual work happens on a queue so the endpoint answers quickly. Do not rely on the redirect back from the checkout to mark an order paid: customers close tabs, and redirects can be faked.

Reconcile every day

Your database, the provider’s dashboard and your bank account should agree. A daily reconciliation job compares your payments with the provider’s settlement reports and payouts, line by line, including fees, refunds and chargebacks. It catches lost webhooks, currency rounding issues and fee changes before the finance team does.

Store money correctly

Never use floating-point types for amounts. Store integer minor units, such as cents, or use BigDecimal in Java, always together with the currency code. Keep an append-only ledger of payment events rather than overwriting a status field, so you can always explain how a balance came about.

Plan for more than one provider

Larger businesses often use two or more PSPs for better approval rates in different countries, lower fees or a fallback when one provider is down. Hiding providers behind your own payment interface from the start makes adding a second one a project of weeks, not months.

Test the unhappy paths

Every major provider offers a sandbox with test cards that simulate declines, 3-D Secure challenges, disputes and delayed events. Test timeouts, duplicate webhooks and partial refunds as carefully as the happy path. Those are the cases that cost money in production.

Popular payment gateway providers in 2026

Most businesses choose from a handful of global PSPs, plus local providers for specific countries and payment methods.

When comparing providers, look beyond the headline fee: approval rates in your markets, the payment methods your customers use, payout times, the quality of the API and webhooks, dispute handling, and how hard it would be to leave.

When to bring in a development partner

A standard checkout with a hosted page is a job for a few days. It is a different story when payments sit inside a larger system: a marketplace that splits payments between sellers, a SaaS product with usage-based billing, a platform with several PSPs, or a finance system that has to reconcile millions of transactions. Then the hard part is the architecture around the API: state, ledgers, reconciliation, throughput and audit trails.

That is the kind of work we do in Java. For Legerity, our team built the FastPost accounting platform, which processes a billion financial transactions in under an hour.

If you are planning a payment integration in a financial or high-volume system, see how we work with banking and fintech companies, or read about the fintech trends and banking technology trends shaping payments in 2026. Our list of the best fintech software development companies compares ten partners for this kind of work.