What Happens Behind the Scenes When a QR Code Is Scanned?
In the first post, I talked about what closed-loop payment systems are and where they differ from open-loop payment systems.
After sharing it, a significant share of the messages I received came down to the same question:
“We understand closed-loop payment systems. But how do these systems actually work?”
Honestly, I think this is a very natural question. When we talk about payment systems, the first things that come to mind are the tools we see and use: cards, POS devices, mobile apps, digital wallets, and, increasingly in recent years, QR codes…
After all, these are the layer we touch as users. When paying in a store, we tap our card on a POS device, when boarding public transport we tap our transit card, or we open an app on our phone and scan a QR code. The transaction completes within a few seconds, and most of the time we carry on with our lives without thinking about what happened behind the scenes.
So what really happens behind the scenes of a transaction that takes only a few seconds from the user's point of view?
When a QR code is scanned, where does the money go? How is the transaction approved? At what moment is the user's balance updated? By what rule is the merchant's receivable calculated? When and how are commissions deducted?
The interesting part is that a payment the user completes within a few seconds sets off a fairly extensive financial process behind the scenes.
Over the years, while working on different payment systems projects, this is one of the things that caught my attention. Those who use payment systems and those who build them look at the same structure, but they do not actually see the same thing.
The user sees the card or the mobile app. The merchant sees the POS device. The business manager cares about the amount that will land in the account at the end of the day. The teams building the payment system see transaction records, balances, commissions, settlement, reconciliation, fraud risks, and financial movements.
In fact, the real story of a payment system begins exactly here.
What is the real product of a payment system?
Let's start with a simple example.
Imagine that tomorrow morning the design of the digital wallet app you use changes completely. The colors, menus, icons, and all the screens have been redone. At first you might struggle a bit. Perhaps you have trouble finding some features. But within a few days you get used to the new design and keep using the app.
But what would happen if you noticed that the 1,000 TL that should be in your account shows up as 900 TL?
Most likely you would stop thinking about the app's design and try to understand why your balance is missing. If the problem is not resolved quickly, your trust in the app starts to be questioned.
This example actually reveals a very important truth about payment systems. User experience matters. An easy-to-use app, fast transactions, and clear screens directly influence user preferences. But when it comes to payment systems, trust comes before all of that.
And the foundation of trust is not the design of the card, the look of the QR code, or the colors of the mobile app, but keeping financial records correct.
Perhaps for this reason, the real product of a payment system is often not what users see. The real product works on the side that users do not see.
Is building a QR code the same as building a payment system?
One of the sentences I have heard many times in the industry over the years is this:
“Let's build a QR payment system too.”
At first glance it sounds quite logical. Because the thing visible on the customer side is the QR code, we assume that the QR code is also at the center of the system.
But is that really the case?
How hard is it to create a QR code today? Many teams with the right technical skills can generate a QR code, scan it, and process the data inside it. Developing a mobile app or building a POS integration can also be done with the right team and technology.
The real question is none of these. The real question is what happens after the payment takes place.
The user scanned the QR code and approved the transaction. So who does the money belong to now? At what moment will the user's balance be reduced? When will the merchant's receivable arise? Will the commission be calculated at transaction time, or at the end of the day? Will a portion of the transaction be passed on to another partner? Will the merchant receive its payment the next day, or a week later?
If a refund request comes in, what happens to the commission calculated earlier? If the user tries to submit the same transaction twice, will the system be able to detect it? When a suspicious transaction occurs, who will detect it and by which rules?
In fact, scanning the QR code is the visible and often the easiest part of the payment transaction. The real complexity begins after the “Transaction successful” message appears on the user's screen.
Who sets the rules in a closed-loop system?
In structures that work with international card schemes such as Visa and Mastercard, a significant portion of the transaction standards, participant roles, message formats, and many operational processes is predefined.
Of course, banks, payment institutions, and merchants still have quite complex processes to manage. But the basic rules within which the system will operate are clear.
In closed-loop payment systems, however, the rules are largely set by the owner of the network.
In the first post, I mentioned that this is one of the biggest advantages of closed-loop payment systems. Because you set the rules yourself, you can shape the payment experience according to the needs of your industry and your business model.
But this freedom comes with an important responsibility.
If you set the rules, you also have to provide the answers to all the questions that will arise. Who will set the transaction limits? How will refund processes work? Who will decide when a dispute occurs? Who will bear the loss arising from fraud transactions? At what intervals will merchant payments be made? By which rule will commissions be calculated? How will millions of transactions be reconciled?
The strongest aspect of closed-loop payment systems is that control is in your hands. But the hardest aspect is also that control is in your hands.
It is exactly at this point that the difference emerges between using a payment infrastructure and truly building a payment system.
Does money really move in payment systems?
Here we need to ask another question.
Does money really move within a payment system?
This question may sound a bit strange at first. After all, when we make a payment, we think the money leaves our account and goes into the merchant's account. On the technical side, however, the process works a bit differently.
In fact, financial records move first.
The available balance in the user's account decreases, a receivable record is created for the merchant, and the commission amount is calculated. Taxes and other deductions, if any, are determined. If there is another party that will take a share of the transaction, the relevant amount is recorded separately. Then the financial records to be used in the settlement and reconciliation processes are prepared.
All of these movements need to be managed in a consistent, traceable, and retrospectively verifiable way.
This structure, where financial records are kept and movements between accounts are managed, is generally called the ledger, that is, the financial record layer.
At first glance, the term ledger may be perceived as just a technical database. In my view, however, the ledger represents both the memory and the current financial state of the payment system.
How much balance does each user have? How much does each merchant have receivable? Which commissions have not yet been collected? Which transactions have been sent to settlement? Which records have been cancelled or refunded? In the event of a dispute, how will we find out which transaction a financial movement originated from?
The answers to these questions live in the ledger.
Everyone sees the QR code, no one sees the ledger
If you asked me today what the most critical component of a closed-loop payment system is, my answer would probably not be the QR code, the POS device, or the mobile app.
I would choose the ledger layer.
Because a significant part of the layers users see can be changed over time. You can renew the mobile app, change the QR infrastructure, switch to another POS brand, or add new payment channels. You can even remove the physical card entirely and run the system only through the mobile app.
The system can keep working after all of these changes.
But the moment you start changing the financial record layer, you begin to touch the heart of the system. Even a small mistake here does not affect just a single screen or user. It can affect the entire financial structure, from user balances to merchant receivables, from commission calculations to accounting records.
For this reason, in closed-loop payment architectures the ledger is not merely one of the system components. It is the fundamental layer that ensures the financial accuracy and reliability of the system.
Is the job really done when the payment is completed?
The user made the payment and the “Transaction successful” message appeared on the screen.
So is the transaction really complete?
From the user's perspective, yes. From the payment system's perspective, the process may only be beginning.
The conditions under which a merchant is onboarded to the system need to be managed. Contract details, commission rates, payment periods, service points, and any sub-merchant structures need to be kept on record. This is where merchant management comes into play.
How much the merchant is owed based on the transactions it has processed must be calculated, and the date on which the payment will be made must be determined. This is where the settlement engine comes into play.
The transaction records in the payment system must be compared with bank movements, merchant reports, and accounting records. This is where reconciliation processes come into play.
Suspicious transactions, account takeover attempts, malicious users, and unusual transaction behavior must be detected. This is where risk and fraud management comes into play.
The funds collected within the system, merchant payments, and financial obligations that will arise on different dates must be managed. This is where liquidity and treasury management comes into play.
As you can see, a payment transaction that takes a few seconds from the user's perspective sets in motion many interconnected financial and operational processes behind the scenes.
An organization that wants to build a closed-loop payment system must be willing to take on not only accepting payments but also managing all of these processes that follow the payment.
No one remembers the color of the card
Over the years, I have seen many different payment products launch. Some had very stylish designs. Some had truly impressive user experiences. Some had very strong marketing.
But looking back, I see that these are not the things people remember most.
People forget the color of the card. They forget the old design of the mobile app. They often don't even remember the brand of the POS device they use.
But they don't forget a balance that was calculated incorrectly.
They don't forget a merchant payment that came up short.
They don't forget a commission that was charged wrongly.
And for the operations teams running the system, forgetting a reconciliation problem that stayed unresolved for days is almost impossible.
Because in payment systems, a loss of trust stays in the memory of users and businesses far longer than technology does.
For this reason, I think that before asking institutions that want to build a closed-loop payment system today “Which POS device will you use?” or “Which QR standard will you choose?”, much more fundamental questions should be asked.
How will you manage your financial records? By which rules will a user's balance be kept? How will a merchant's receivable be calculated? How will commissions be managed? How will refund and cancellation records be created? How will reconciliation be done? When a record is wrong, will you be able to trace the entire financial movement retrospectively?
Because in closed-loop payment systems, the real value often appears not on the screen the user sees, but in the financial operating system running behind that screen.
From the invisible architecture to real life
In the first post, we tried to understand what closed-loop payment systems are and why they differ from open-loop systems. In this post, we looked at the invisible world that runs behind the scenes after a QR code is scanned.
We discussed why concepts such as the ledger, merchant management, settlement, reconciliation, risk, fraud, and liquidity form the foundation of a payment system.
But honestly, the part that interests me most starts from here.
Because in theory, it is possible to describe an architecture. A fairly comprehensive payment system diagram can be drawn with boxes, arrows, and technical layers. But the experience I have gained in payment systems over the years has shown me that the best way to truly understand a system is to look at how it works in real life.
Why is Istanbulkart not just a transit card? What is the real difference that sets meal cards apart from classic bank cards? At what point does a retail brand's loyalty app stop being a campaign platform and turn into a payment system? Why do companies like Starbucks want to keep their customers' money inside their own ecosystems?
When a closed-loop system grows, does it have to turn into an open-loop payment network? Or will the distinction between open-loop and closed-loop systems gradually lose its meaning in the future?
Some of these questions can be answered technically. But I think some of the answers must be sought not on the technology side, but in the business model, customer behavior, and ecosystem strategy.
Honestly, this is exactly why I have found closed-loop payment systems interesting for years. The subject was never just about cards, POS devices, or QR codes. What was truly interesting was how an organization builds its own financial ecosystem, how it sets the rules of that ecosystem, and why it wants to keep its users within its own network.
In the first post, we talked about what closed-loop payment systems are. In this post, we looked at the architecture working behind the visible screens.
In the next post, I want to put theory aside for a bit. Because sometimes the best way to understand a system is not to look at architecture diagrams, but to look at the products we use every day with a different eye.
Is Istanbulkart really just a transit card?
What is the real difference that separates a meal card from a bank card?
Why does the Starbucks app have a model that many fintech startups want to reach?
Of the structures we see today as ordinary loyalty apps, which could turn into the independent payment networks of tomorrow?
Honestly, this is the subject I am most curious about too.
Perhaps the strongest players of the new payment systems world will emerge from structures that we see today not as payment systems, but as transportation, retail, food, loyalty, or technology platforms.
In the next post, let's take a closer look at these systems. Because behind some products that we see in daily life as simple cards or mobile apps, there may be a payment economy far larger than we imagine.
