How Online Card Payments Work: Authorization, Capture, Settlement and Refunds

You type your card number, enter an OTP and the page says "Order confirmed". It takes ten seconds. In those ten seconds your bank has decided whether to let the payment happen; over the next day or two, money will actually move between banks; and if anything goes wrong later, there are three different ways for it to come back to you, each with its own rules.

This guide follows one card payment through every stage. It's written so that a customer, a business owner and a developer can each get what they need from it: what the words on your statement mean, what a merchant has to reconcile, and where each stage happens in the system.

Six parties take part in an online card payment:

Our guide to payment gateways, processors and aggregators explains the middle roles in more detail, including where each sits in Indian regulation.

Here's a ₹2,000 payment from start to finish. The stages before the line happen in seconds; the ones after it take place over the following days.

The customer enters their card details on the checkout page, or picks a card they saved before. Saved cards work differently in India than in many countries. Since 1 October 2022, under RBI's rules, no one in the card payment chain other than the card issuer and the card network may store the actual card number. Merchants and payment companies keep a token instead: a substitute number that's useless outside that merchant.

Creating a token needs the customer's explicit consent, confirmed with an additional factor of authentication from the issuer. So the first time you save a card, you'll be asked for an OTP. Our guide to card tokenisation covers the merchant side.

Authentication answers "is this really the cardholder?". In India, RBI requires an additional factor of authentication for digital payments, which for an online card payment usually means a one-time password on the bank's page (often called 3-D Secure), or an approval in the bank's app.

RBI lists exceptions. The best known are contactless tap payments in shops up to ₹5,000, and recurring payments under a registered e-mandate, which don't need an OTP each time up to ₹15,000 per payment (₹1 lakh for insurance premiums, mutual fund subscriptions and credit card bill payments). Setting up the mandate itself still needs full authentication.

Authentication isn't approval. The customer can get the OTP right and still be declined in the next step.

With the customer authenticated, the request travels from the merchant's acquirer, through the card network, to the issuing bank. The issuer checks the things only it knows: whether the card is active and enabled for online use, whether there's enough balance or credit limit, whether the payment fits its limits and fraud rules. Then it answers yes or no.

A yes doesn't move money yet. It places a hold for ₹2,000 on the customer's account or credit limit, so it can't be spent twice, and returns an authorization code. On a debit card, the hold often shows as a debit straight away; on a credit card, it reduces the available limit and may appear as a pending transaction.

A no is a decline: the issuer refused, and nothing is held. Our guide to why online payments fail goes through the common reasons.

Authorization reserves the money; capture is the merchant telling its acquirer, "yes, take it". Most online stores capture immediately, so authorization and capture look like one step. Some don't:

Captured payments are cleared and settled in batches, not one by one. The card network works out what each issuer owes each acquirer, the issuer pays, and the acquirer receives the money.

What happens next depends on the merchant's set-up. A merchant with its own acquiring bank is paid by that bank. A merchant using a payment aggregator, which is most of them, is paid by the aggregator out of its escrow account, on the schedule in their agreement. RBI requires that agreement to state the settlement timelines clearly. The merchant usually receives one combined amount for many payments, after fees.

For the ₹2,000 payment, that means the customer sees one debit, while the merchant sees ₹2,000 in its transaction report straight away and, once it's settled, a settlement that includes it, less the merchant discount rate and any other fees.

Money can return to the customer in three different ways, and they're often confused:

For refunds through a payment aggregator, RBI requires the money to go back to the original payment method, so a card payment is refunded to the card, unless the customer asks for another mode of their own. And the customer's chargeback rights stay in place regardless of what the merchant's refund policy says. Our guide to chargebacks covers how disputes run and how to respond, and the refund API guide covers the mechanics from the merchant's side.

A declined authorization ends the payment before any money is held, so there's nothing to refund. When a payment fails for a technical reason after the debit, because the merchant's side never got confirmation, the bank must reverse it. RBI's rules give five calendar days for that on online card payments, with ₹100 a day in compensation after that.

For a merchant, every one of these stages leaves a record, and reconciliation is making them agree:

Most mismatches come from timing (a payment captured late on the last day of the month), fees (settlements are net), or a refund or chargeback deducted from a later settlement. Our guide to payment reconciliation shows a daily routine that catches them.