Key points of this lesson, in order.
Digital Wallet Architecture: Where the Money Actually Sits
What you will learn
Your objective. By the end of this lesson, you will be able to explain digital wallet architecture: where the money actually sits. A digital wallet is a prepaid stored value account held by a licensed issuer, and the balance you see on your phone is a claim on the issuer rather than money sitting in your own bank account.
Why it matters. A business analyst must document this clearly, because confusing a wallet balance with a bank deposit leads to wrong requirements for interest, deposit insurance and account closure.
Chapter objective: Learner explains digital wallets and point-of-sale systems, including token provisioning, NFC, QR payments, and settlement, and designs a wallet payment flow for a retailer. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Digital wallet
- Wallet ledger
- BA should require that no wallet balance
- Open loop wallet
- BA writing requirements should never
- Why the BA must specify
Key terms
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
Idempotency: The property that repeating the same request has the same effect as sending it once. In payments, an idempotency key lets a client safely retry a request after a timeout without creating a duplicate...
Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.
Payment flow diagram showing Digital Wallet Architecture: Where the Money Actually Sits.
Practise this lesson
Exercise
Map the payment in this lesson through the hub components.
Use the hub components and their order in this lesson.
- What to do. List each component the payment passes through, what it does, and what happens if it fails.
Correct result. The payment enters through a channel, passes the gateway, validation, fraud and sanctions checks, routing, and the ledger, then leaves through the right clearing system. A failure at any component stops or holds the payment, and the hub must record where it stopped.
Why. The hub is where most payment requirements live. If you cannot map a payment through it, you cannot specify, test or fix it.
Check your understanding
Practice question
What is tokenisation in a digital wallet such as Apple Pay or Google Pay?
Takeaway and next step
What to remember
The wallet ledger is the heart of the system, and it is usually built as a double entry ledger where every transaction creates at least two entries that always balance.
Send a payment through the hub and watch it pass each component named in this lesson.
Open the Payment Hub Architecture Simulator →
Builds on "Chargebacks in Depth".
Transcript and full text
Show transcript
A digital wallet is a prepaid stored value account held by a licensed issuer, and the balance you see on your phone is a claim on the issuer rather than money sitting in your own bank account. When you load 2,000 rupees into a Paytm or PhonePe wallet, the issuer receives the funds into a pooled escrow account held with a partner bank, and your wallet balance is simply a record in the issuer ledger that says the issuer owes you that amount. This distinction matters because the wallet balance is a liability of the issuer, the pooled funds are safeguarded separately, and the wallet cannot pay interest like a savings account. A business analyst must document this clearly, because confusing a wallet balance with a bank deposit leads to wrong requirements for interest, deposit insurance and account closure. The wallet ledger is the heart of the system, and it is usually built as a double entry ledger where every transaction creates at least two entries that always balance. A typical wallet ledger has a customer wallet account, a merchant settlement account, a fees and revenue account, and a pooled bank account that mirrors the real money held outside the system. When a customer pays a merchant 500 rupees, the ledger debits the customer wallet and credits the merchant wallet or a merchant payable account, so the total of all wallet balances always equals the money in the pooled account. Reconciliation runs daily to prove this equality, and any difference is an exception that must be investigated the same day. A BA should require that no wallet balance can go negative and that every ledger entry carries a unique transaction reference. A closed loop wallet can only be used with one merchant or one group of merchants, and the classic example is a metro card, a coffee chain wallet or a gift card issued by a single retailer. The money never leaves that merchant ecosystem, so the regulatory burden is lighter and the issuer does not need a full payments licence in many cases, but the customer cannot use the balance anywhere else. A semi-closed wallet, such as Amazon Pay or a typical PPI wallet in India, can be used at a network of merchants who accept it, but it cannot be used to withdraw cash or to transfer money freely to another person in the early PPI models. An open loop wallet is linked to a card network, so a Visa or Mastercard prepaid wallet can be used at any merchant that accepts that network, including ATMs in some cases. The wallet versus bank account comparison is a favourite interview topic, and the differences go beyond regulation into product design. A bank account is held directly with a bank, it can receive salary credits, pay interest, offer overdrafts and cheques, and it is covered by deposit insurance up to the applicable limit. A wallet is a prepaid instrument, it holds only the amount loaded into it, it cannot offer an overdraft, and its balance is limited by the KYC status of the holder. A wallet is faster to open, it works well for small value payments, and it is ideal for customers who want to separate spending money from their main account. A BA writing requirements should never describe a wallet as an account with a bank, and should always state the issuer, the pooled bank and the settlement arrangement in the design document. From a systems perspective, a wallet platform has several layers that must be documented separately, the customer app, the wallet core ledger, the payment gateway and switch connections, the KYC and risk engine, and the settlement and reconciliation module. The app talks to the wallet core through secure APIs, the core checks the balance, applies velocity limits and fraud rules, and then posts the ledger entries atomically so that a transaction either completes fully or fails fully. If the app shows success but the ledger did not post, the customer has been misled and the dispute team inherits a problem. That is why the BA must specify idempotency keys, timeout handling and a single source of truth for transaction status, and why load testing must prove the ledger stays balanced under peak traffic such as a festival sale.
A digital wallet is a prepaid stored value account held by a licensed issuer, and the balance you see on your phone is a claim on the issuer rather than money sitting in your own bank account. When you load 2,000 rupees into a Paytm or PhonePe wallet, the issuer receives the funds into a pooled escrow account held with a partner bank, and your wallet balance is simply a record in the issuer ledger that says the issuer owes you that amount. This distinction matters because the wallet balance is a liability of the issuer, the pooled funds are safeguarded separately, and the wallet cannot pay interest like a savings account. A business analyst must document this clearly, because confusing a wallet balance with a bank deposit leads to wrong requirements for interest, deposit insurance and account closure.
The wallet ledger is the heart of the system, and it is usually built as a double entry ledger where every transaction creates at least two entries that always balance. A typical wallet ledger has a customer wallet account, a merchant settlement account, a fees and revenue account, and a pooled bank account that mirrors the real money held outside the system. When a customer pays a merchant 500 rupees, the ledger debits the customer wallet and credits the merchant wallet or a merchant payable account, so the total of all wallet balances always equals the money in the pooled account. Reconciliation runs daily to prove this equality, and any difference is an exception that must be investigated the same day. A BA should require that no wallet balance can go negative and that every ledger entry carries a unique transaction reference.
A closed loop wallet can only be used with one merchant or one group of merchants, and the classic example is a metro card, a coffee chain wallet or a gift card issued by a single retailer. The money never leaves that merchant ecosystem, so the regulatory burden is lighter and the issuer does not need a full payments licence in many cases, but the customer cannot use the balance anywhere else. A semi-closed wallet, such as Amazon Pay or a typical PPI wallet in India, can be used at a network of merchants who accept it, but it cannot be used to withdraw cash or to transfer money freely to another person in the early PPI models. An open loop wallet is linked to a card network, so a Visa or Mastercard prepaid wallet can be used at any merchant that accepts that network, including ATMs in some cases.
The wallet versus bank account comparison is a favourite interview topic, and the differences go beyond regulation into product design. A bank account is held directly with a bank, it can receive salary credits, pay interest, offer overdrafts and cheques, and it is covered by deposit insurance up to the applicable limit. A wallet is a prepaid instrument, it holds only the amount loaded into it, it cannot offer an overdraft, and its balance is limited by the KYC status of the holder. A wallet is faster to open, it works well for small value payments, and it is ideal for customers who want to separate spending money from their main account. A BA writing requirements should never describe a wallet as an account with a bank, and should always state the issuer, the pooled bank and the settlement arrangement in the design document.
From a systems perspective, a wallet platform has several layers that must be documented separately, the customer app, the wallet core ledger, the payment gateway and switch connections, the KYC and risk engine, and the settlement and reconciliation module. The app talks to the wallet core through secure APIs, the core checks the balance, applies velocity limits and fraud rules, and then posts the ledger entries atomically so that a transaction either completes fully or fails fully. If the app shows success but the ledger did not post, the customer has been misled and the dispute team inherits a problem. That is why the BA must specify idempotency keys, timeout handling and a single source of truth for transaction status, and why load testing must prove the ledger stays balanced under peak traffic such as a festival sale.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.