You press Pay. A few seconds later, you see Payment successful.
It feels simple.
Behind that button, however, several banks, payment networks, databases, and security systems have to agree on one very important question:
Can this money safely move from one account to another?
And interestingly, the money usually does not fully move during those few seconds.
What Happens When You Pay?
A card payment normally involves four main players:
Merchant: the business you are buying from.
Acquirer: the bank or payment provider working with the merchant.
Card network: a network such as Visa or Mastercard.
Issuer: the bank that gave you your card.
A payment then goes through three broad stages: authorization, clearing, and settlement.
1. Authorization: Can You Make This Payment?
Authorization happens immediately.
When you press Pay:
Merchant → Acquirer → Card Network → Your Bank
Your bank checks things such as:
Is the card valid?
Is the transaction suspicious?
Do you have enough available money?
Are there any account or card limits?
If everything looks good, the bank approves the payment.
But the merchant usually has not received the money yet.
Instead, your bank normally places a hold on the amount.
Imagine you have $500 and spend $100.
Your account may temporarily show:
Current balance: $500 Available balance: $400
The $100 is reserved so you cannot spend the same money twice.
The approval then travels back:
Your Bank → Network → Acquirer → Merchant
That is why you can see "Payment successful" within seconds.
2. Clearing: Who Owes What?
Later, approved transactions are sent for clearing.
Instead of immediately moving money for every individual purchase, payment systems can collect many transactions and calculate what different banks owe each other.
This is also where fees, transaction details, and final payment amounts are worked out.
The temporary authorization now becomes a final transaction.
3. Settlement: The Money Actually Moves
Finally comes settlement.
This is when banks settle their obligations to each other.
Rather than transferring money separately for millions of purchases, payment systems can calculate the net amount one bank owes another.
For example:
Bank A owes Bank B: $100 million Bank B owes Bank A: $80 million
Instead of moving $180 million back and forth, the final settlement may only need to move the $20 million difference.
Depending on the payment system and country, settlement may happen through accounts banks hold at a central bank or through other settlement arrangements.
The merchant then receives the funds according to its agreement with its bank or payment provider.
What Does the Bank Store?
Behind all of this is a database.
A simplified payment system might contain several important pieces of data.
Balances keep track of how much money an account currently has and how much is available to spend.
Holds track money that has been temporarily reserved after authorization.
Transactions track the payment from its beginning until it succeeds, fails, or is reversed.
Ledger entries record the actual financial changes. A good financial ledger is designed to be auditable: instead of silently rewriting history, new entries record what happened.
And idempotency keys help prevent an especially dangerous problem.
Imagine your phone sends:
Pay $100.
The payment succeeds, but your connection dies before you receive the response.
Your phone retries:
Pay $100.
Without protection, you might be charged twice.
An idempotency key lets the server recognize that the second request is really the same payment and return the previous result instead of processing it again.
All of these protections make financial systems reliable.
But reliability has a price.
Why Can Banking Systems Be Hard to Scale?
A social-media application can sometimes accept slightly outdated information.
A bank cannot casually say:
"We think you have about $500. We'll synchronize everything later."
Money requires much stronger guarantees.
That creates some difficult database problems.
The Hot Row Problem
Imagine a very busy merchant account receiving thousands of payments.
In a simple database design, every payment might update the same balance row:
Merchant balance = Merchant balance + payment
But two transactions must not update that balance incorrectly at the same time.
So the database may need to lock or otherwise coordinate access to that account.
Now imagine thousands of transactions trying to change the same value.
Most of the database may be perfectly capable of handling more traffic, but everyone is waiting for access to one extremely busy piece of data.
That is called a hot spot or hot row.
It is similar to having 100 supermarket checkout lanes that all require approval from the same manager.
The store has plenty of capacity.
The manager has become the bottleneck.
Sharding Helps — Until Transactions Cross Shards
One common way to scale a huge database is sharding.
Instead of keeping every account on one database server, accounts are divided between many servers:
Shard A: customers 1–1,000,000 Shard B: customers 1,000,001–2,000,000 Shard C: customers 2,000,001–3,000,000
Now many transactions can happen in parallel.
Great.
But what happens when someone on Shard A sends money to someone on Shard B?
Both databases need to agree.
The payer must lose the money only if the receiver gets it.
You cannot safely allow:
Payer: −$100 ✅ Receiver: +$100 ❌
or:
Payer: −$100 ❌ Receiver: +$100 ✅
The operation needs to behave like one transaction even though two machines are involved.
Two-Phase Commit
One classic solution is Two-Phase Commit, or 2PC.
A coordinator first asks every database involved:
Are you ready to commit this transaction?
This is the prepare phase.
The databases prepare their changes and may need to hold locks or resources while they wait.
If everyone answers yes, the coordinator sends:
Commit.
Then all participants apply the transaction.
This gives strong guarantees.
But it also creates coordination.
Servers must communicate with each other. They must wait for responses. Failures become harder to handle. Locks may remain held while the system waits.
And network latency matters.
A transaction inside one database is much easier than coordinating several machines across a distributed system.
That is one reason scaling financial systems is not simply a matter of adding more servers.
What's Next?
The main problem is a trade-off:
The more consistency and safety you demand, the more coordination the system needs. In banking, 100 percent consistency is critical because even a small inconsistency can cause serious financial damage.
So how do modern fintech companies and Neobanks architecture handle this?
They try to reduce unnecessary coordination, move more work to asynchronous systems, split data more carefully, and design their systems so that only the parts that truly need strong consistency have to wait for it.
In the next article, we’ll look at how modern payment systems and Neobanks are designed differently — and how they scale while still keeping financial data safe.
Want to see these ideas visually? Watch the full video here:
Top comments (0)