How to Show Payment QR on the POS Customer Display
Wallet payments happen on the phone, not on the card reader
Staff hold up a printed QR laminated to the counter while shouting the amount. Customers mistype am= and pay the wrong total, then blame the till.
A static QR without amount works for tips but fails for exact ticket totals. Dynamic UPI strings are error-prone if typed by hand.
The customer-facing screen already shows thank-you graphics but not the payment instruction, so guests look at the wrong display.
Why this happens
- No link between the open sale amount and the QR payload.
- Using a single printed QR for every ticket size.
- Confirming payment before the customer finished the bank app flow.
- Expecting the ERP to auto-match bank UPI callbacks that were never integrated.
Biznsbook addresses this through QR tenders, customer display second screen, UPI template QR when the POS module is licensed — terminal and back-office checkout share unified SaleBill posting.
Finance teams lose days each month reconciling versions that should never have diverged. Naming Biznsbook screens as the system of record — and closing periods when agreed — prevents silent edits that auditors flag immediately.
Step-by-step: Show Payment QR on the POS Customer Display
Built for retailers who need a fast till, float discipline, and the same INV-* sale bill in stock and GL — not a standalone cash register.
- Create a WalletQr tender. Payments → Tender types → add a wallet tender with kind WalletQr (or similar). Give it a clearing account like other tenders.
- Choose static or template. Upload a static QR image for a fixed payee code, or set QrMode to Template with a UPI string using amount placeholders such as upi://pay?pa=…&am={amount}.
- Open the customer display. Launch the POS customer display second screen for the register so payment state can push QR and amount.
- Select the QR tender at checkout. On the till, choose the wallet tender for the amount (or as one multi-tender leg). Biznsbook renders the QR for cashier and customer display.
- Wait for the customer to pay. The guest scans and pays in their banking or wallet app. Watch for their success screen — Biznsbook is not watching the bank.
- Confirm Received and complete. Cashier confirms Received, completes the sale, and the clearing account is debited. Settle the processor or bank later via Tender settlements if needed.
Review results after the first full weekly cycle. Adjust roles, mappings, or approvals where the same exception repeats.
Screen-level flows live in the Help Center. This guide focuses on the business process; help articles cover click-by-click navigation.
Common mistakes to avoid
- Mistake 1: No link between the open sale amount and the QR payload. Repeating this each month usually shows up first in cash reconciliation and till speed.
- Mistake 2: Using a single printed QR for every ticket size. Repeating this each month usually shows up first in cash reconciliation and till speed.
- Mistake 3: Confirming payment before the customer finished the bank app flow. Repeating this each month usually shows up first in cash reconciliation and till speed.
- Mistake 4: Expecting the ERP to auto-match bank UPI callbacks that were never integrated. Repeating this each month usually shows up first in cash reconciliation and till speed.
Track recurring exceptions in month-end notes; each should map to a control above.
Best practices that hold up as you scale
- Create a WalletQr tender — Payments → Tender types → add a wallet tender with kind WalletQr (or similar).
- Choose static or template — Upload a static QR image for a fixed payee code, or set QrMode to Template with a UPI string using amount placeholders such as upi://pay?pa=…&am={amount}.
- Open the customer display — Launch the POS customer display second screen for the register so payment state can push QR and amount.
- Select the QR tender at checkout — On the till, choose the wallet tender for the amount (or as one multi-tender leg).
- Wait for the customer to pay — The guest scans and pays in their banking or wallet app.
Teams that open on a named register, park holds, and close with expected cash keep variance disputes short.
How Biznsbook supports this workflow
QR tenders is documented in Biznsbook POS capabilities. Use it as part of a controlled finance process — posting, review, and period close — not as an isolated export. When Sales, Purchase, Inventory, Taxation, Expense, or Finance Management modules are enabled, related documents can post through the central accounting posting service with double-entry validation.
customer display second screen is documented in Biznsbook POS capabilities. Use it as part of a controlled finance process — posting, review, and period close — not as an isolated export. When Sales, Purchase, Inventory, Taxation, Expense, or Finance Management modules are enabled, related documents can post through the central accounting posting service with double-entry validation.
UPI template QR is documented in Biznsbook POS capabilities. Use it as part of a controlled finance process — posting, review, and period close — not as an isolated export. When Sales, Purchase, Inventory, Taxation, Expense, or Finance Management modules are enabled, related documents can post through the central accounting posting service with double-entry validation.
Sessions, barcode, split tender, X/Z reports, and receipt branding are covered in Docs/POS — use Help Center for click-level screens.
Suggested implementation timeline
- Week 1: Document current process gaps and configure QR tenders with finance owner sign-off.
- Weeks 2–3: Pilot on one month or one entity; post all test transactions through Biznsbook; freeze parallel spreadsheet journals.
- Week 4: Run first trial balance or report tie-out; fix mapping and permission issues.
- Month 2–3: Roll out to full team; add approvals and period close cadence from this guide.
- Ongoing: Monthly review using honesty beats fake automation and leadership dashboard.
Customer display payment state
The customer display previously reused the thank-you screen during payment. For QR tenders it now shows amount due, payee name, and the QR image data URL pushed from the POS display update API. Cashiers still see the same QR on the till so they can help guests who cannot see the second screen.
If no QR is configured on the tender, the display falls back to amount messaging without inventing a code. Always test one sale on the floor after uploading a new static image so compression or storage permissions do not surprise you mid-shift.
UPI templates substitute the open sale amount into the payload and render a PNG through the existing barcode/QR helper used elsewhere in Biznsbook. That keeps dynamic QR generation inside the product instead of asking cashiers to type upi:// strings by hand.
Remember the non-goals: Biznsbook will not drive a third-party card terminal from this QR path, and it will not auto-complete the sale from a bank webhook. Those limits keep stock and tax posting under human confirmation.
Metrics to track monthly
- Open sessions with a selected POS terminal
- Cash sales with ClientRequestId retries that stay single INV-*
- Parked bills resolved before close
- X-reports run mid-shift without closing
- Terminal Z generated per register/day
Start with three metrics; trend direction matters more than a single point-in-time snapshot.
Spreadsheet / manual books vs integrated ERP
Compare typical manual finance work with Biznsbook QR tenders and related capabilities.
| Capability | Manual / Spreadsheet | Biznsbook |
|---|---|---|
| Amount on QR | ❌ Printed fixed QR | ✅ Template fills amount from the sale |
| Customer view | ❌ Phone camera only | ✅ Customer display shows QR + amount + payee |
| Confirmation | ❌ Hope and shout | ✅ Cashier confirms Received |
| Ledger | ❌ Cash mis-key | ✅ Named QR tender clearing |
| Multi-pay | ❌ Separate tickets | ✅ QR as one leg among others |
| Auto bank match | ❌ Promised by some apps | ✅ Out of scope — honest cashier confirm |
Honesty beats fake automation
Auto-confirming QR via bank APIs sounds attractive and is deliberately out of scope. A wrong auto-complete posts stock and tax with no money. Cashier confirmation is the control that matches how most independent shops already work.
Document this in your finance SOP and revisit each quarter as transaction volume or entity structure changes.
Frequently asked questions
Which QR schemes work today?
Static uploaded images work for any wallet that shows a fixed QR. Dynamic payload builders ship with UPI first. Other EMVCo market encoders can be added later as demand appears.
Does Biznsbook know when UPI succeeds?
No. There is no bank confirmation API in this flow. The cashier confirms Received after the customer’s app shows success.
Can QR work with multi-tender?
Yes. Put part of the total on a QR tender and the rest on cash or card as separate legs.
Is the QR stored in file storage?
Static QR images use the file storage provider under the POS tender QR category. Template mode generates a PNG from the payload at display time.
What about Stripe Terminal?
Stripe uses a physical reader, not this QR flow. Keep Stripe as the card tender and QR as a separate wallet tender.
How this differs by industry
Retail
Fashion and gift shops show Venmo or local wallet QR on the customer display for guests who prefer phones to cards.
Wholesale & distribution
Trade counters use bank QR for exact invoice amounts on counter collections.
Manufacturing
Outlet tills use UPI templates where card readers are scarce but smartphones are common.