What Happens Behind the Scenes of a Card Payment

Which systems touch every card payment

Six parties handle each transaction, and every one of them has a single job. The cardholder presents credentials. The merchant's point of sale (POS) terminal or online gateway captures and encrypts them. The acquirer holds the merchant's account and takes on the risk of accepting that sale. A switch or processor formats and routes the message. The card scheme carries it between banks and calculates who owes whom. The issuer decides yes or no and later funds the transaction.

The switch is where most integration work lives, because it operates at the message level and routes ISO 8583 messages between infrastructure participants, as PXP's payments glossary describes it. That's the part worth internalizing before you debug anything. When a payment fails, the failure has a home in one of those six boxes, and knowing which box owns the message format versus the funding decision cuts your triage time in half.

What starts when you tap or swipe

The terminal captures card data and builds an encrypted authorization request, then hands it off. No money moves. On a chip transaction, the card itself does cryptographic work: the chip generates an Authorization Request Cryptogram (ARQC) from card and transaction data, and the terminal wraps that into the outbound message. The primary account number is protected in transit under point-to-point encryption or replaced by a network token.

Visa's own chip terminology guide, quoted by PaymentsJournal on the ARQC, explains that validating the cryptogram assures the issuer the data came from a genuine card and wasn't copied from a skimmed one. That's why the card has to stay in the reader.

Here's the consequence nobody spells out. Because the cryptogram binds the amount at capture time, any later change to that amount breaks the match between authorization and clearing. Hotels and fuel stations live with this daily.

How authorization decides yes or no

Authorization is a round trip that returns a decision in seconds and places a temporary hold on the funds. Nothing is transferred. The message goes out and a decision comes back along the identical route, where the issuer earmarks the amount against the available balance or credit line.

The scale involved is worth a number. VisaNet is engineered for a peak of 65,000 transaction messages per second across more than 200 countries, and average authorization responses land inside two seconds.

That hold has a shelf life, and it isn't short. According to FYST's technical documentation, an authorization blocks funds for up to 7 days on debit cards and 28 days on credit cards if nothing follows it. So an abandoned authorization is a customer service problem waiting to happen, because the cardholder sees their money gone with no purchase attached to it and calls their bank.

Where the request travels first

The request travels from the POS or gateway through the acquirer or switch to the issuer. It's a relay of messages, and no account is debited at any hop. The gateway receives the transaction in JSON, and the acquiring processor translates it into the network's ISO 8583 format before the scheme carries it forward.

That translation layer is where the industry hides its complexity. As Increase's engineering write-up on ISO 8583 puts it, higher-level formats from the merchant get converted to the card network's ISO 8583-based format downstream.

Which means your logs and the scheme's logs describe the same event in two different vocabularies. If you don't map field-by-field between them during integration, reconciliation disputes become unwinnable arguments about which system is telling the truth.

What the issuer checks and returns

The issuer verifies the card is live and runs the transaction through fraud scoring, then returns an authorization code or a decline code back along the same path. On a chip transaction it also validates the ARQC and generates a response cryptogram so the card can confirm it's talking to its real issuer.

Insufficient funds dominates the decline picture. Ethoca's research, cited by Beast Insights on issuer declines, attributes 44.4% of all issuer declines in card-not-present transactions to insufficient funds or a reached credit limit.

If nearly half your declines are balance-driven, retry logic matters more than data hygiene. But retries only help on soft declines, and codes like 5C and 9G are permanent stops that will cost you network penalties if you queue them.

How clearing batches and reconciles

Clearing is the accounting step where authorized sales are submitted in batches and confirmed between the acquirer and the issuer. Still no funds move. The acquirer sends clearing files, and the scheme validates them before producing outbound files that tell the issuer what to post to the cardholder's statement.

Visa's legacy batch clearing runs on defined cut-off schedules, with acquirers submitting TC05 records for sales and TC15 for credits into BASE II. Clearing completes overnight or within one to two banking days.

Matching those clearing records back to their originating authorizations is harder than it sounds. Marqeta reports its transaction matching logic hits roughly 99% success against an 88% industry standard. A 12-point industry miss rate means one in eight transactions needs human attention somewhere, which is the real staffing cost of a card program.

When settlement actually moves money

Settlement is the only step where funds change hands. The scheme calculates each participant's net position across the clearing cycle, and issuers with a net debit remit to the settlement account while acquirers with a net credit receive funds. The merchant is then credited, minus interchange and processor markup.

Nothing settles transaction by transaction. Under the net settlement model, all obligations between participants are offset and only the net position moves, which reduces intraday liquidity requirements for smaller issuers and acquirers. Stripe puts the practical timeline at one to three business days after the transaction, with funding following.

What the merchant sees is the residue after fees. In 2024, average U.S. credit card interchange sat near 2.35% of transaction value, before assessments and processor fees. So the amount authorized and the amount deposited are never the same figure, and any reconciliation model built on gross authorization totals will drift every single day.

Why approval is not payment yet

Approval reserves money. Clearing and settlement transfer it. That gap is the source of most confusion between what a customer's app shows and what a merchant's bank account holds, and it explains almost every timing complaint in payments.

The gap has consequences on both ends of the transaction:

• A pending charge is a hold. It converts to posted only after settlement completes.

• A refund is a fresh transaction traveling the same rails in reverse.

• Chargeback rights don't exist before clearing, because there is no financial record to dispute yet.

Refunds show the lag most plainly. Paytia's breakdown puts credit card refunds at 5 to 10 working days to reach the cardholder, with debit refunds at 3 to 5.

Which gives you a concrete design rule. If a customer cancels before your batch cut-off, an authorization reversal releases the hold in about a day. After cut-off, you owe them a refund and a week of waiting, so your cancellation window follows the batch clock.

Build stronger rails with EGS

If your team can write software but hasn't shipped a payment product through scheme certification, the honest answer is to work with people who have already survived that cycle. Energize Global Services has been building for the banking and financial industry since 2007, with offices in Boston and Yerevan. The work covers POS terminal software and EMV kernels.

Payments is where the gap between "it works on the bench" and "it's certified for production" swallows timelines. EMV Level 1 tests the reader interface and Level 2 tests the kernel logic, while Level 3 validates the full path against a specific acquirer host. Each level carries its own fee and testing calendar.

Bring your architecture and your timeline to a call with the EGS engineering team and get a direct read on scope before you commit a roadmap to it.