How a payment gateway works

Who is actually involved

Almost every confusion about payments comes from treating this as two parties. There are at least five, and they each fail differently.

Most small businesses use a provider that is the gateway and the aggregator at once, which is why onboarding takes a form rather than a bank relationship. The trade is that you are a sub-merchant under somebody else's account, which affects how quickly you are paid and how abruptly you can be cut off.

Authorisation and capture are two different things

A card payment has two distinct steps, and treating them as one is the most common modelling error in a first integration.

1. Authorisation. The issuer checks the card is valid and the funds exist, and places a hold. No money has moved. The hold expires on its own after a period the issuer decides.
2. Capture. You tell the network to take the authorised amount. This is the point the charge becomes real.

Many providers capture automatically the moment authorisation succeeds, which hides the distinction until the day it matters. It matters when you sell something that may not be available, when you take a deposit, or when you want to charge only what was actually delivered. Authorising at checkout and capturing at dispatch is a normal pattern, and it needs deciding up front because it changes the data model.

An expired authorisation is not a refund and does not appear as one. The customer sees a pending amount disappear, which they will read as either a cancelled order or a bug, and only your records can tell them which.

Why the money arrives days after the confirmation

Capture does not put money in your bank account. Captured transactions are batched, netted against refunds and fees, and paid out on a settlement schedule that depends on your provider and your risk profile. A new account is often held longer, and that is a business fact rather than a technical one.

This has a practical consequence people meet the hard way: the amount that lands in your bank is not the sum of your orders. It is orders minus refunds minus fees for that settlement period, which means your accounting cannot reconcile order totals against bank deposits directly. Reconciliation has to work off the provider's settlement report, and that requirement should be in the build rather than discovered by an accountant later.

Where payments actually fail

Declines are normal and are not errors. A decline is the issuer's decision and is usually returned with a reason code that is deliberately vague, because telling an attacker exactly why a card failed is a way to help them.

• Soft declines, such as an authentication step being required, which succeed if you retry the right way. Hard declines, such as a closed account, which never will.
• Additional authentication. The customer is sent to their bank to confirm, and comes back, which turns a single request into a multi-step flow that can be abandoned halfway.
• The timeout. Your request to the gateway times out and you genuinely do not know whether the charge happened. This is the important one.
• The customer closing the tab after paying, which happens constantly and is why the redirect back to your site cannot be what marks an order paid.

The timeout case is where double charges come from. If a request fails without an answer and your code retries it, the second attempt can succeed alongside a first attempt that also succeeded. The fix is an idempotency key: a value you generate per payment attempt and send with the request, so a repeat of the same request returns the original result rather than creating a second charge. Every serious provider supports this, and it is not optional.

The rule that follows from all of this: the payment is confirmed by the provider telling your server, through a signed webhook you verify, not by the customer's browser arriving at a success page. The browser is a convenience. It can be closed, replayed, or forged.

What you must not store, and why it is not your call

Card data is governed by the PCI Data Security Standard, which the card networks enforce through your provider rather than through a government. The practical effect for a normal business is that raw card numbers should never reach your servers at all.

That is what hosted fields and hosted checkouts are for. The card details go from the customer's browser to the provider directly, and your server receives a token that stands in for the card. You can charge the token later without ever having held the number. Handling raw card data yourself moves you into a compliance burden that is entirely disproportionate for almost everyone.

Card storage rules also differ by country and change. India, in particular, moved saved-card storage towards network-issued tokens rather than merchant-held details. Treat the current rules in your market as something to confirm at build time with your provider and your own advisers, not something to take from any article.

Refunds, chargebacks and the difference

A refund is you returning money voluntarily. A chargeback is the customer's bank taking it back on their instruction, usually because they dispute the charge, and it is a different process with a different outcome. You are told after the fact, you have a window to provide evidence, and you may lose the money and a fee regardless of who was right.

• Refunds are not instant from the customer's side even when your dashboard says complete. The money moves back through the same chain.
• A refund does not always return the processing fee. Whether it does is a matter of your provider's terms.
• A high chargeback rate is an existential problem with an aggregator. Accounts are closed over it.
• The best defence is boring: a clear descriptor on the statement, an obvious refund path, and records of what was delivered and when.

What this means for the build

1. Treat the provider's webhook as the source of truth for payment state, verify its signature, and make handling it idempotent, because it will be delivered more than once.
2. Send an idempotency key on every payment request you make.
3. Store the provider's identifiers against your own order, so any figure on your side can be traced to a transaction on theirs.
4. Model payment state explicitly rather than as a boolean. Pending, authorised, captured, failed, refunded and disputed are all real states with different consequences.
5. Never compute the amount from anything the browser sent. The price comes from your server.
6. Build reconciliation against the settlement report from the start. Retrofitting it is painful and always happens under time pressure.

None of this is exotic and all of it is cheap while the feature is being built. Every item on that list is expensive to add after the first month of real transactions, because by then there is data in the wrong shape.

What this does not cover

• We have not shipped a payment integration from this codebase. This describes mechanics that are public and stable, taken from the specifications and vendor documentation cited above, rather than lessons from running one in production. Where a page of ours is written from our own build, it says so, and this one is not.
• It contains no fees, rates or settlement periods for any provider. Those change, they vary by account, and copying them would put a number here that is wrong within months.
• Card storage and authentication rules are set by regulators and card networks and differ by country. The point about Indian tokenisation is directional. Confirm the current position with your provider and your own advisers rather than from this page.
• Nothing here is legal, tax or compliance advice, and PCI scope in particular depends on exactly how you handle card data. A provider's compliance does not transfer to you automatically.
• It covers card payments. Bank transfers, UPI, wallets, direct debit and buy-now-pay-later each work differently, and several of the statements above do not hold for them.
• It names no best provider and makes no recommendation, because we have not run a comparison we would be willing to publish.

Sources

• PCI Data Security Standard, PCI Security Standards Council. Retrieved 31 August 2026.
• EMV 3-D Secure, the additional authentication step described above, EMVCo. Retrieved 31 August 2026.
• Payments documentation, including authorisation, capture and idempotency, Stripe. Retrieved 31 August 2026.
• Strong customer authentication, and how additional authentication changes a flow, Stripe. Retrieved 31 August 2026.
• Payments documentation for the Indian market, Razorpay. Retrieved 31 August 2026.

Revisions

• 31 August 2026 First published.

This page is revised in place rather than replaced, so its address does not change.