Building a Digital Voucher and QR Redemption System: From Issuing to Scanning to Reconciliation

What you sold is not a QR code — it is an unfulfilled liability

A dessert chain launched a NT$398 afternoon-tea-for-two voucher and sold 4,200 of them online in three months. Redemption was a tablet, an Excel sheet, and Ctrl+F on the ticket number. At month-end, finance found 143 more servings than redemption records, 37 of which traced back to a single screenshotted QR code passed around — roughly NT$14,000 unaccounted for. Worse, the voucher was printed with a six-month expiry, a customer cited Taiwan's gift-voucher rules, and the company refunded in full. The hard part of digital vouchers was never generating the QR code.

When it fits, and when it does not

Good fit

300+ prepaid or experience vouchers redeemed per month, across two or more stores or staff members
Tickets bound to an identity or a session (event tickets, class passes, health-check bookings, hotel credits)
Redemption data must flow back into CRM to compute repeat rate and campaign returns
Batch issuance to travel agents or corporate buyers, requiring batch control and revenue split

Not yet

Single store, fewer than 100 redemptions per month: a numbered paper book plus a reconciliation sheet is cheaper
Only one or two events a year: just use ACCUPASS or KKTIX
Voucher rules still undecided (transferable? partial use? refundable?) — undefined rules guarantee a rebuild

Alternatives matrix

Option	Cost per ticket	Strengths	Limits
ACCUPASS ticketing platform	5% of face value + NT$10; events over 400 tickets add NT$799–1,000 upgrade fee (official fee page)	Selling on day one, with platform traffic	No layout or flow control; attendee and redemption data stay off your CRM
ECPay e-ticket or a POS voucher add-on	Plan fee + payment fees	Payments and e-invoicing in one place	Fixed voucher logic; partial redemption, revenue split and multi-tier resale are hard
Google Forms + spreadsheet	Near zero	Usable today	No double-redemption guard, no audit trail, no evidence when disputed
Custom build (Laravel + PWA scanner)	From NT$150,000 one-off + 2.75% payment fee	Full control of rules, splits and data	4–6 weeks of build plus ongoing maintenance

Break-even formula: build cost ÷ per-ticket fee gap = tickets to break even. On a NT$500 ticket, ACCUPASS costs about NT$35; a custom build on ECPay standard rates (2.75% credit card + NT$1 order processing fee + 5% VAT) costs about NT$15.4, a gap of NT$19.6. An NT$180,000 build breaks even around 9,200 tickets.

Full build process (4–6 weeks)

Stage	Time	Deliverables	Tools
Voucher types and legal review	3–5 days	Voucher-type matrix, gift-voucher applicability test, refund rules	Notion, Google Sheets
Data model and redemption state machine	5–7 days	ERD, state transition diagram, anti-double-redemption strategy	dbdiagram.io, Figma
Issuance, payments and e-invoicing	7–10 days	Order-to-voucher pipeline, ECPay payment and invoice integration, signed ticket codes	Laravel, ECPay API
Scanner client and offline tolerance	7–10 days	PWA scanner, staff permissions, offline queue, audit log	html5-qrcode/ZXing, LINE LIFF, Apple Wallet PKPass
Reconciliation, load test, launch	5–7 days	Redemption reconciliation report, outstanding-liability report, monitoring alerts	Metabase, UptimeRobot

Real cost breakdown

Build: base version (issuance + QR redemption + reconciliation admin) from NT$150,000; with LINE LIFF wallet, multi-store permissions and split reports, around NT$280,000
Payments: ECPay domestic credit card 2.75% (minimum NT$5 per transaction) + NT$1 order processing fee, plus 5% VAT at settlement
E-invoicing: NT$3,600 setup, NT$3,600 per year for 5,000 invoices, NT$1.5 per SMS notification
Scanning hardware: NT$0 using staff phones; about NT$19,100 per handheld touch register unit
Performance protection: prepaid gift vouchers require a bank guarantee or trust account; the rate is negotiated with the bank based on issuance volume
Maintenance: roughly 15% of build cost per year (from NT$22,500), covering payment API upgrades and store account changes

Client expectation vs implementation reality

Expected: "just a scan, live in two weeks." Reality: about 60% of hours go into the state machine, refund reversals and exception handling
Expected: "staff can scan with their own phones." Reality: older Android cameras take 3–5 seconds to focus in dim light, and queues still form at peak
Expected: "print an expiry date to push people to come in." Reality: Taiwan's Ministry of Economic Affairs mandatory and prohibited terms for gift vouchers forbid stating an expiry date, and refund handling fees may not exceed 3% of the returned amount
Expected: "paper goes away on launch day." Reality: run both tracks for the first month, with paper as the network-outage fallback

Common traps and how to avoid them

QR encodes only a plain ticket number, so codes get guessed or forwarded: embed an HMAC-signed token and reject anything that fails verification
Double-redemption blocked only by a disabled front-end button: add a database unique constraint and lock the row with SELECT FOR UPDATE inside the redemption transaction
Network drops freeze the whole entry line: give the scanner an offline queue with local signature verification, sync on reconnect, resolve conflicts by earliest timestamp
Screenshots forwarded to a second person: use rotating QR codes (refreshing every 30–60 seconds) for high-value tickets, or require the holder to operate the phone on site
Wrong invoice timing: commodity vouchers are invoiced at sale, cash vouchers at redemption — confirm with your accountant before writing the spec
No audit trail: log operator, store, device, timestamp and IP for every redemption, and retain it for at least a year

Success metrics and the 90-day roadmap

Day 30: redemption success rate ≥ 99%, under 3 seconds per scan, 100% of duplicate attempts blocked, store support ticket volume
Day 60: redemption rate (redeemed / sold), outstanding voucher liability, peak redemptions per minute
Day 90: total operating cost per ticket, savings versus platform commission, repeat-purchase rate and upsell value from voucher holders

Decision checklist

☐ Will monthly redemptions exceed 300?
☐ Are there two or more redemption locations or operators?
☐ Are vouchers transferable?
☐ Can one voucher be redeemed in multiple visits?
☐ Are unused vouchers refundable, and how is the handling fee calculated?
☐ Do these vouchers legally count as gift vouchers?
☐ Is a bank guarantee or trust account required?
☐ Has the invoice issuance timing been confirmed?
☐ Is on-site network stable, and if not, is offline mode acceptable?
☐ Does redemption data need to reach CRM?
☐ Is someone accountable for monthly reconciliation and outstanding liability?

FAQ

Do digital vouchers always need rotating QR codes?

No. For vouchers under NT$500 redeemed face-to-face by staff, a static signed QR plus a one-time redemption lock is enough. Rotating QR codes are worth it above NT$2,000 face value or for unattended self-service gates.

Can we print an expiry date on the voucher?

If it qualifies as a commodity or service gift voucher under Ministry of Economic Affairs rules, no expiry date may be stated, and unused balances may not be voided. Event tickets tied to a specific session are a different category — check each case with an accountant or lawyer before fixing the rules.

What if on-site connectivity is bad?

Build the scanner as a PWA that caches the day's signing public key and blacklist locally, verifies signatures offline, queues writes, then batch-syncs on reconnect. In testing this survives roughly 30 minutes of complete outage during peak entry.

Next step

ScriptWalker's Digital Voucher and Redemption System package starts at NT$150,000 and covers voucher-type planning, QR signing, offline redemption and a reconciliation back office. Book a free 30-minute consultation and we will walk through the voucher-type matrix and break-even math with you to decide whether to build or stay on a platform.