Payments Training Hub
Wallet funding sources PAYMENT OPERATIONS STARTED LIVE 01 Wallet funding sources - Loading money into a wallet is a pull from ACTIVE 02 Paying - merchant is the most frequent wallet transaction QUEUED 03 BA - authorisation, the confirmation message QUEUED 04 Sender balance falls by 2,500 rupees - receiver balance rises by the same QUEUED 05 BA - fee structure, the cooling period after QUEUED 06 Withdrawal of 5,000 rupees debits - customer wallet and credits the payout QUEUED Loading money into a wallet is a pull from a funding source, and the most common sources are UPI, a debit card, net banking or a bank transfer. Step 1 of 6 Wallet funding sources STARTED Wallet funding sources Loading money into a wallet is a pull from ACTIVE Paying merchant is the most frequent wallet QUEUED BA authorisation, the confirmation message QUEUED Sender balance falls by 2,500 rupees receiver balance rises by the same amount QUEUED BA fee structure, the cooling period after QUEUED Withdrawal of 5,000 rupees debits customer wallet and credits the payout QUEUED Loading money into a wallet is a pull from a funding source, and the most common sources are UPI, a debit card, net banking or a bank transfer.
Paying: most frequent wallet transaction PAYMENT OPERATIONS IN PROGRESS LIVE 01 Wallet funding sources - Loading money into a wallet is a pull from DONE 02 Paying - merchant is the most frequent wallet transaction ACTIVE 03 BA - authorisation, the confirmation message QUEUED 04 Sender balance falls by 2,500 rupees - receiver balance rises by the same QUEUED 05 BA - fee structure, the cooling period after QUEUED 06 Withdrawal of 5,000 rupees debits - customer wallet and credits the payout QUEUED Paying a merchant is the most frequent wallet transaction, and it is a transfer inside the issuer ledger when both the customer and the merchant hold wallets with the same issuer. Step 2 of 6 Paying: most frequent wallet transaction IN PROGRESS Wallet funding sources Loading money into a wallet is a pull from DONE Paying merchant is the most frequent wallet ACTIVE BA authorisation, the confirmation message QUEUED Sender balance falls by 2,500 rupees receiver balance rises by the same amount QUEUED BA fee structure, the cooling period after QUEUED Withdrawal of 5,000 rupees debits customer wallet and credits the payout QUEUED Paying a merchant is the most frequent wallet transaction, and it is a transfer inside the issuer ledger when both the customer and the merchant hold wallets with the same issuer.
BA should specify PAYMENT OPERATIONS IN PROGRESS LIVE 01 Wallet funding sources - Loading money into a wallet is a pull from DONE 02 Paying - merchant is the most frequent wallet transaction DONE 03 BA - authorisation, the confirmation message ACTIVE 04 Sender balance falls by 2,500 rupees - receiver balance rises by the same QUEUED 05 BA - fee structure, the cooling period after QUEUED 06 Withdrawal of 5,000 rupees debits - customer wallet and credits the payout QUEUED The BA should specify the authorisation, the confirmation message and the receipt fields for each channel. Step 3 of 6 BA should specify IN PROGRESS Wallet funding sources Loading money into a wallet is a pull from DONE Paying merchant is the most frequent wallet DONE BA authorisation, the confirmation message ACTIVE Sender balance falls by 2,500 rupees receiver balance rises by the same amount QUEUED BA fee structure, the cooling period after QUEUED Withdrawal of 5,000 rupees debits customer wallet and credits the payout QUEUED The BA should specify the authorisation, the confirmation message and the receipt fields for each channel.
Sender balance falls by 2,500 rupees PAYMENT OPERATIONS IN PROGRESS LIVE 01 Wallet funding sources - Loading money into a wallet is a pull from DONE 02 Paying - merchant is the most frequent wallet transaction DONE 03 BA - authorisation, the confirmation message DONE 04 Sender balance falls by 2,500 rupees - receiver balance rises by the same ACTIVE 05 BA - fee structure, the cooling period after QUEUED 06 Withdrawal of 5,000 rupees debits - customer wallet and credits the payout QUEUED The sender balance falls by 2,500 rupees, the receiver balance rises by the same amount, Step 4 of 6 Sender balance falls by 2,500 rupees IN PROGRESS Wallet funding sources Loading money into a wallet is a pull from DONE Paying merchant is the most frequent wallet DONE BA authorisation, the confirmation message DONE Sender balance falls by 2,500 rupees receiver balance rises by the same amount ACTIVE BA fee structure, the cooling period after QUEUED Withdrawal of 5,000 rupees debits customer wallet and credits the payout QUEUED The sender balance falls by 2,500 rupees, the receiver balance rises by the same amount,
BA must document the withdrawal limits PAYMENT OPERATIONS IN PROGRESS LIVE 01 Wallet funding sources - Loading money into a wallet is a pull from DONE 02 Paying - merchant is the most frequent wallet transaction DONE 03 BA - authorisation, the confirmation message DONE 04 Sender balance falls by 2,500 rupees - receiver balance rises by the same DONE 05 BA - fee structure, the cooling period after ACTIVE 06 Withdrawal of 5,000 rupees debits - customer wallet and credits the payout QUEUED A BA must document the withdrawal limits, the fee structure, the cooling period after a load, and the anti money laundering checks that apply to large withdrawals. Step 5 of 6 BA must document the withdrawal limits IN PROGRESS Wallet funding sources Loading money into a wallet is a pull from DONE Paying merchant is the most frequent wallet DONE BA authorisation, the confirmation message DONE Sender balance falls by 2,500 rupees receiver balance rises by the same amount DONE BA fee structure, the cooling period after ACTIVE Withdrawal of 5,000 rupees debits customer wallet and credits the payout QUEUED A BA must document the withdrawal limits, the fee structure, the cooling period after a load, and the anti money laundering checks that apply to large withdrawals.
Withdrawal of 5,000 rupees debits PAYMENT OPERATIONS COMPLETE LIVE 01 Wallet funding sources - Loading money into a wallet is a pull from DONE 02 Paying - merchant is the most frequent wallet transaction DONE 03 BA - authorisation, the confirmation message DONE 04 Sender balance falls by 2,500 rupees - receiver balance rises by the same DONE 05 BA - fee structure, the cooling period after DONE 06 Withdrawal of 5,000 rupees debits - customer wallet and credits the payout ACTIVE A withdrawal of 5,000 rupees debits the customer wallet and credits the payout clearing account. Step 6 of 6 Withdrawal of 5,000 rupees debits COMPLETE Wallet funding sources Loading money into a wallet is a pull from DONE Paying merchant is the most frequent wallet DONE BA authorisation, the confirmation message DONE Sender balance falls by 2,500 rupees receiver balance rises by the same amount DONE BA fee structure, the cooling period after DONE Withdrawal of 5,000 rupees debits customer wallet and credits the payout ACTIVE A withdrawal of 5,000 rupees debits the customer wallet and credits the payout clearing account.

Key points of this lesson, in order.

0:00 / 4:11 Step 1 of 6

Wallet Transactions: Load, Pay, Send and Withdraw

Digital Wallets and POS Systems, Lesson 2 of 7, Narration 4:11, D08 Cards and alternative payments

ReconciliationAuthorisationSettlement

What you will learn

Your objective. By the end of this lesson, you will be able to explain wallet transactions: load, pay, send and withdraw. Loading money into a wallet is a pull from a funding source, and the most common sources are UPI, a debit card, net banking or a bank transfer.

Why it matters. This matters because card payments are the highest-volume payments most banks process, and the four-party model decides who pays whom, when, and what happens when it goes wrong.

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

  • Wallet funding sources
  • Paying: most frequent wallet transaction
  • BA should specify
  • Sender balance falls by 2,500 rupees
  • BA must document the withdrawal limits
  • Withdrawal of 5,000 rupees debits

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

Authorisation: Approval by the issuer for a card transaction to proceed, confirming the card is valid and funds or credit are available.

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 Wallet Transactions: Load, Pay, Send and Withdraw.

Practise this lesson

Exercise

Work out what the beneficiary receives for a 1,000 rupees payment under OUR, SHA and BEN.

Use the charge arrangement rules in this lesson and the correspondent and beneficiary bank fees named in the lesson.

  1. What to do. Calculate the amount credited under each of the three arrangements and state who pays each fee.

Correct result. Under OUR the sender pays all charges and the beneficiary receives the full amount. Under SHA the sender pays the sending charges and the beneficiary pays the receiving charges. Under BEN the beneficiary pays all charges and receives the amount less all fees.

Why. The charge arrangement decides who pays and how much arrives. A customer who was promised the full amount and receives less will complain, and the complaint lands on the analyst.

Check your understanding

Practice question

A customer adds a card to a phone wallet and pays by tapping the phone. The merchant never sees the real card number. How does this work?

Takeaway and next step

What to remember

A withdrawal of 10,000 rupees that is debited from the wallet but never reaches the bank account is a high severity defect, so the reconciliation must catch it within hours.

Follow 1,000 rupees through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "Digital Wallet Architecture: Where the Money Actually Sits".

Transcript and full text

Show transcript

Loading money into a wallet is a pull from a funding source, and the most common sources are UPI, a debit card, net banking or a bank transfer. When a customer loads 1,000 rupees through UPI, the wallet system first collects the money from the customer bank account through the UPI rail, and only after the collection is confirmed does it credit the wallet ledger. This order is critical. Crediting the wallet before the funding is confirmed would create money that does not exist. If the UPI debit succeeds but the wallet credit fails, the system must either retry the credit with the same reference or reverse the UPI collection automatically. A BA must document the timeout window, the reversal logic and the customer message for each outcome, because a stuck load is one of the most common wallet complaints. Paying a merchant is the most frequent wallet transaction, and it is a transfer inside the issuer ledger when both the customer and the merchant hold wallets with the same issuer. The customer scans a QR code or selects a merchant in the app, enters 350 rupees, confirms with a PIN, and the system debits the customer wallet and credits the merchant wallet in a single atomic posting. The merchant sees the credit immediately, and the money is available for settlement to the merchant bank account on the agreed cycle, often the next working day. If the merchant is on a different wallet system, the payment must travel through an interoperable rail such as UPI, and the settlement then follows that rail rather than the internal ledger. The BA should specify the authorisation, the confirmation message and the receipt fields for each channel. Sending money to a friend, known as a peer to peer transfer, is similar to a merchant payment but carries different risk rules. In a full KYC wallet the customer can send money to another wallet holder instantly, and the ledger simply moves the balance from the sender wallet to the receiver wallet. In a minimum KYC wallet the regulator limits peer to peer transfers, so the product must block or restrict the feature based on KYC status. The system must also check the receiver wallet exists, apply daily and monthly limits, and screen the transaction against fraud and sanctions lists. A real example is a customer sending 2,500 rupees to a friend for a shared dinner bill. The sender balance falls by 2,500 rupees, the receiver balance rises by the same amount, and both customers receive a notification with the same transaction reference for easy dispute handling. Withdrawing money from a wallet means converting the stored value back into bank money, and this is where open and semi-closed wallets differ sharply. An open loop wallet linked to a card network can withdraw cash at an ATM, subject to limits and fees, while a semi-closed wallet can usually only transfer the balance back to the linked bank account of the same customer. The withdrawal flow debits the customer wallet and credits a payout account, and the payout is then executed through IMPS, NEFT or the card network. A BA must document the withdrawal limits, the fee structure, the cooling period after a load, and the anti money laundering checks that apply to large withdrawals. A withdrawal of 10,000 rupees that is debited from the wallet but never reaches the bank account is a high severity defect, so the reconciliation must catch it within hours. Double entry accounting is what makes all four transactions auditable, and a BA should be able to explain it with a simple example. Every wallet transaction touches at least two ledger accounts with equal debit and credit amounts, so the books always balance. A load of 1,000 rupees debits the pooled bank account and credits the customer wallet. A merchant payment of 500 rupees debits the customer wallet and credits the merchant wallet. A withdrawal of 5,000 rupees debits the customer wallet and credits the payout clearing account. At the end of the day the sum of all customer and merchant wallet balances must equal the balance in the pooled bank account minus the amounts already paid out. If the two sides differ by even one rupee, the reconciliation job raises an exception and finance must investigate before the next settlement cycle runs.

Loading money into a wallet is a pull from a funding source, and the most common sources are UPI, a debit card, net banking or a bank transfer. When a customer loads 1,000 rupees through UPI, the wallet system first collects the money from the customer bank account through the UPI rail, and only after the collection is confirmed does it credit the wallet ledger. This order is critical. Crediting the wallet before the funding is confirmed would create money that does not exist. If the UPI debit succeeds but the wallet credit fails, the system must either retry the credit with the same reference or reverse the UPI collection automatically. A BA must document the timeout window, the reversal logic and the customer message for each outcome, because a stuck load is one of the most common wallet complaints.

Paying a merchant is the most frequent wallet transaction, and it is a transfer inside the issuer ledger when both the customer and the merchant hold wallets with the same issuer. The customer scans a QR code or selects a merchant in the app, enters 350 rupees, confirms with a PIN, and the system debits the customer wallet and credits the merchant wallet in a single atomic posting. The merchant sees the credit immediately, and the money is available for settlement to the merchant bank account on the agreed cycle, often the next working day. If the merchant is on a different wallet system, the payment must travel through an interoperable rail such as UPI, and the settlement then follows that rail rather than the internal ledger. The BA should specify the authorisation, the confirmation message and the receipt fields for each channel.

Sending money to a friend, known as a peer to peer transfer, is similar to a merchant payment but carries different risk rules. In a full KYC wallet the customer can send money to another wallet holder instantly, and the ledger simply moves the balance from the sender wallet to the receiver wallet. In a minimum KYC wallet the regulator limits peer to peer transfers, so the product must block or restrict the feature based on KYC status. The system must also check the receiver wallet exists, apply daily and monthly limits, and screen the transaction against fraud and sanctions lists. A real example is a customer sending 2,500 rupees to a friend for a shared dinner bill. The sender balance falls by 2,500 rupees, the receiver balance rises by the same amount, and both customers receive a notification with the same transaction reference for easy dispute handling.

Withdrawing money from a wallet means converting the stored value back into bank money, and this is where open and semi-closed wallets differ sharply. An open loop wallet linked to a card network can withdraw cash at an ATM, subject to limits and fees, while a semi-closed wallet can usually only transfer the balance back to the linked bank account of the same customer. The withdrawal flow debits the customer wallet and credits a payout account, and the payout is then executed through IMPS, NEFT or the card network. A BA must document the withdrawal limits, the fee structure, the cooling period after a load, and the anti money laundering checks that apply to large withdrawals. A withdrawal of 10,000 rupees that is debited from the wallet but never reaches the bank account is a high severity defect, so the reconciliation must catch it within hours.

Double entry accounting is what makes all four transactions auditable, and a BA should be able to explain it with a simple example. Every wallet transaction touches at least two ledger accounts with equal debit and credit amounts, so the books always balance. A load of 1,000 rupees debits the pooled bank account and credits the customer wallet. A merchant payment of 500 rupees debits the customer wallet and credits the merchant wallet. A withdrawal of 5,000 rupees debits the customer wallet and credits the payout clearing account. At the end of the day the sum of all customer and merchant wallet balances must equal the balance in the pooled bank account minus the amounts already paid out. If the two sides differ by even one rupee, the reconciliation job raises an exception and finance must investigate before the next settlement cycle runs.

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.