Key points of this lesson, in order.
QR Codes and Soundbox: Payments for Small Merchants
What you will learn
Your objective. By the end of this lesson, you will be able to explain QR codes and soundbox: payments for small merchants. A QR payment starts with a code that contains the merchant payment address, usually a UPI ID or a merchant identifier, and sometimes the amount and a transaction reference as well.
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
- QR payment
- Static QR code
- Soundbox: small battery powered speaker
- Settlement to the merchant account
- Vegetable vendor who receives 15,000
- Project that only specifies
Key terms
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
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.
Capture: The step in a card transaction where the merchant collects the authorised amount from the issuer, usually when goods are shipped.
Payment flow diagram showing QR Codes and Soundbox: Payments for Small Merchants.
Practise this lesson
Exercise
Trace the card payment in this lesson through authorisation, clearing and settlement.
Use the four-party model and the stage timings in this lesson.
- What to do. State what happens at each stage, who pays whom, and when the merchant is actually credited.
Correct result. Authorisation holds the funds and returns a response code. Clearing sends the transaction in a batch file. Settlement moves the net amount between banks, and the acquirer credits the merchant after deducting interchange, scheme fees and its margin.
Why. A card payment is not one event. The customer sees it on Monday, the merchant gets it on Wednesday, and the difference is the clearing and settlement cycle.
Check your understanding
Practice question
Which of the following best describes QR codes and soundbox: payments for small merchants?
Takeaway and next step
What to remember
A BA must document the languages supported, the volume and battery requirements, the behaviour when connectivity drops, and the privacy rule that the soundbox must never announce the customer name or account details aloud.
Follow 120 rupees through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Payment Acceptance at POS: Authorization, Settlement and Reconciliation".
Transcript and full text
Show transcript
A QR payment starts with a code that contains the merchant payment address, usually a UPI ID or a merchant identifier, and sometimes the amount and a transaction reference as well. The customer opens any UPI app, scans the code, sees the merchant name, enters the amount if it is not already in the code, and confirms with a UPI PIN. The app then sends the payment through the UPI switch to the merchant bank, and the merchant receives a credit in seconds. The QR code itself holds no money and no card data, it is simply a pointer to the merchant, which is why a printed QR code is cheap to produce and easy to replace. A BA should document the fields encoded in the QR code, the validation that the merchant name matches the code, and the error message when a customer scans a damaged or expired code. A static QR code is printed once and stays the same for every transaction, so the customer must enter the amount manually each time. It is ideal for a small shop where the amount varies, and it costs almost nothing to deploy, but it cannot carry a unique reference for each sale, which makes reconciliation harder. A dynamic QR code is generated fresh for each transaction, on a screen or a printed slip, and it already contains the exact amount and a unique order reference. The customer only has to scan and confirm, which reduces errors and allows the merchant system to match each payment to a specific bill automatically. A BA should specify which merchants get static codes and which get dynamic codes, and should require that a dynamic code expires after a few minutes, so that an old code cannot be reused. The soundbox is a small battery powered speaker that announces each payment in the local language, and it solves a very practical problem. A busy merchant cannot keep staring at a phone to check every payment. When a customer pays 120 rupees for a cup of tea, the soundbox announces that 120 rupees have been received, often in Hindi, Tamil, Kannada or another local language, and the merchant can continue serving the next customer without checking the phone. The soundbox works by receiving a notification from the payment provider over a mobile data connection and playing a pre-recorded voice message with the amount. A BA must document the languages supported, the volume and battery requirements, the behaviour when connectivity drops, and the privacy rule that the soundbox must never announce the customer name or account details aloud. Settlement to the merchant account is the final step, and for UPI QR payments it is fast because the payment is a direct bank to bank transfer. When a customer pays through UPI, the money moves from the customer bank to the merchant bank almost immediately, and the merchant can see the credit in the bank account or app within seconds. For wallet QR payments the flow is different. The money first credits the merchant wallet, and it is then settled to the merchant bank account on the agreed cycle, daily or weekly. A BA should document the settlement timing for each payment method, the settlement report format, and the fees if any, so that a merchant is never surprised by a delay or a deduction. A vegetable vendor who receives 15,000 rupees in QR payments in a day needs to know when that money will be in the bank. From a BA perspective, the QR and soundbox solution is a good example of designing for the real user rather than for the ideal user. The requirements must cover the merchant onboarding journey, the printing and delivery of the QR code, the activation of the soundbox, the handling of a failed payment, the dispute process when a customer claims to have paid but the merchant did not hear the announcement, and the support process when a soundbox stops working. The BA should also capture the reporting needs, daily collection summaries, transaction level reports with UPI references, and settlement reports that match the bank statement. A project that only specifies the scan and pay flow and forgets the merchant support flow will fail in the field, no matter how elegant the technology is.
A QR payment starts with a code that contains the merchant payment address, usually a UPI ID or a merchant identifier, and sometimes the amount and a transaction reference as well. The customer opens any UPI app, scans the code, sees the merchant name, enters the amount if it is not already in the code, and confirms with a UPI PIN. The app then sends the payment through the UPI switch to the merchant bank, and the merchant receives a credit in seconds. The QR code itself holds no money and no card data, it is simply a pointer to the merchant, which is why a printed QR code is cheap to produce and easy to replace. A BA should document the fields encoded in the QR code, the validation that the merchant name matches the code, and the error message when a customer scans a damaged or expired code.
A static QR code is printed once and stays the same for every transaction, so the customer must enter the amount manually each time. It is ideal for a small shop where the amount varies, and it costs almost nothing to deploy, but it cannot carry a unique reference for each sale, which makes reconciliation harder. A dynamic QR code is generated fresh for each transaction, on a screen or a printed slip, and it already contains the exact amount and a unique order reference. The customer only has to scan and confirm, which reduces errors and allows the merchant system to match each payment to a specific bill automatically. A BA should specify which merchants get static codes and which get dynamic codes, and should require that a dynamic code expires after a few minutes, so that an old code cannot be reused.
The soundbox is a small battery powered speaker that announces each payment in the local language, and it solves a very practical problem. A busy merchant cannot keep staring at a phone to check every payment. When a customer pays 120 rupees for a cup of tea, the soundbox announces that 120 rupees have been received, often in Hindi, Tamil, Kannada or another local language, and the merchant can continue serving the next customer without checking the phone. The soundbox works by receiving a notification from the payment provider over a mobile data connection and playing a pre-recorded voice message with the amount. A BA must document the languages supported, the volume and battery requirements, the behaviour when connectivity drops, and the privacy rule that the soundbox must never announce the customer name or account details aloud.
Settlement to the merchant account is the final step, and for UPI QR payments it is fast because the payment is a direct bank to bank transfer. When a customer pays through UPI, the money moves from the customer bank to the merchant bank almost immediately, and the merchant can see the credit in the bank account or app within seconds. For wallet QR payments the flow is different. The money first credits the merchant wallet, and it is then settled to the merchant bank account on the agreed cycle, daily or weekly. A BA should document the settlement timing for each payment method, the settlement report format, and the fees if any, so that a merchant is never surprised by a delay or a deduction. A vegetable vendor who receives 15,000 rupees in QR payments in a day needs to know when that money will be in the bank.
From a BA perspective, the QR and soundbox solution is a good example of designing for the real user rather than for the ideal user. The requirements must cover the merchant onboarding journey, the printing and delivery of the QR code, the activation of the soundbox, the handling of a failed payment, the dispute process when a customer claims to have paid but the merchant did not hear the announcement, and the support process when a soundbox stops working. The BA should also capture the reporting needs, daily collection summaries, transaction level reports with UPI references, and settlement reports that match the bank statement. A project that only specifies the scan and pay flow and forgets the merchant support flow will fail in the field, no matter how elegant the technology is.
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.