Card Payment Rails: What Actually Happens When You Pay With a Card
You tap your card.
You see Payment Successful.
Your balance drops.
Or a user pays through your Paystack , Stripe or a bdp integration.
You receive a webhook.
You render the service.
Everything feels instant.
You even get settled later, usually T+1.
But nothing has actually moved yet.
Card payments feel instant.
But what’s instant is the approval, not the movement of money.
Settlement happens later.
What are Card Payment Rails?
Card payment rails are the infrastructure that allows payments to happen when someone uses a debit or credit card.
But what moves first is not money.
It is messages between systems. When you initiate a card payment, what actually travels across systems is a request and a response, not funds.
The system coordinates multiple institutions to agree on a transaction before any actual money movement happens.
A High-level Overview of the Flow
Customer → Merchant → PSP → Acquirer → Card Network → Issuer
Let’s make this much clearer.
The customer is the cardholder.
The merchant is the business receiving payment.
The PSP is the layer you integrate with.
The acquirer is the financial institution enabling the merchant to accept cards.
The card network is the system that connects banks globally.
The issuer is the bank that owns the customer’s account.
This structure is what allows a card issued by one bank to be used at a merchant connected to another, anywhere in the world.
The Card is Not Money
A card is not money. It is a way to access money or credit held by a bank.
Each card commonly contains a 12 - 19 digit number called the PAN, an expiry date, a CVV, and sometimes a PIN.
These numbers aren't random, they are used to construct a request that flows through the system.
At its core, every card transaction is asking one thing:
Can this account spend this amount?
The Key Players
Issuer
The issuing bank is the one that gave the customer their card. The card you use daily.
This is where the actual money or credit lives.
The issuer checks if funds or credit are available, evaluates fraud risk, and decides whether to approve or decline.
This is the final authority in a transaction.
If the issuer says no, nothing else matters.
Acquirer
The acquirer is the merchant’s side of the system.
This is the institution that makes card acceptance possible for businesses.
It onboards merchants, connects them into the card network, routes authorization requests, guarantees payment to the merchant, and handles disputes and chargebacks.
Banks are the traditional acquirers. Companies like Stripe and Adyen sit on top of that layer as PSPs, and in some regions, they also operate as direct acquirers
A key point here is:
Merchants and most fintechs cannot connect directly to card networks.
The acquirer is the gateway.
Card Network
The card network sits between acquirers and issuers.
Examples include Visa, Mastercard, American Express, and UnionPay.
The card network routes transaction requests to the correct issuing bank, defines the rules that all participants must follow, and standardizes communication across the system.
Without this layer, global card payments would not work.
How Card Numbers Decide the Destination
Every card has a PAN.
From that, the system already knows where to send the request.
The first digit identifies the card network.
The first six digits, called the BIN, identify the issuing bank.
So when a transaction starts, it is not random routing.
The destination is already determined from the card details.
But the PAN contains more than just routing information.
The digits between the BIN and the last digit represent the cardholder account number. This is not the user’s bank account number. It is an internal reference used by the issuing bank to identify the specific card account.
The last digit is the Luhn check digit. This is used to validate that the card number is structurally correct. It helps detect errors like mistyped numbers before the transaction is even processed.
What Actually Happens When You Pay
Now let’s walk through the lifecycle properly.
1. Authorization
This is the most critical step.
The payment request flows:
Merchant → PSP → Acquirer → Card Network → Issuer
At the issuer, balance or credit is checked, fraud systems run, and the card status is verified.
The issuer then responds with a code using ISO 8583 standards.
00 - means approved.
51 - means insufficient funds.
05 - means do not honor.
54 - means expired card.
91 - means issuer unavailable.
These codes are what your PSP maps into something simple:
Payment successful or payment declined.
So when you see success, what actually happened is this:
The issuer approved the transaction.
2. Authorization Hold
If approved, the issuer places a hold on the amount.
If you had 100 dollars and spent 10, your available balance becomes 90.
But the 10 dollars has not moved.
It is still in the account.
It is just reserved so it cannot be spent again.
3. Capture
Authorization is not the final step.
After approval, the transaction still needs to be captured.
In most cases, this happens automatically through the PSP, immediately converting the authorization into a charge.
In other cases, the merchant explicitly sends a capture request. That amount you approved, I now want to collect it.
This usually aligns with when the service has been delivered or the order is ready to be fulfilled.
Without capture, the transaction can expire and the hold is released.
4. Clearing and Settlement
Only after capture does actual money movement begin.
Behind the scenes, transactions are grouped, obligations between banks are calculated, and funds are moved between issuing and acquiring banks.
This process is coordinated through the card network.
This is when money actually moves.
What PSPs Hide From You
When you integrate with a PSP, you do not see ISO message formats, raw response codes, routing logic, or network level communication.
You only see outcomes like success or failure.
But underneath, a full financial protocol is running.
Why You Cannot Connect Directly to Card Networks
Connecting directly to card networks requires regulatory licensing, large capital requirements, fraud and risk systems and strict compliance with network rules.
That is why acquirers exist.
They provide controlled access into the system.
The Key Insight
Card payments are not instant transfers.
They are:
authorization first, settlement later
That is why users see success immediately, merchants act immediately, but actual money movement happens later.
Where This Gets Interesting
If approval happens first and settlement happens later,
then there is a window where transactions can be reversed, disputes can be raised, and funds can be clawed back.
Next
Card Networks and Schemes: The Rules Behind the System