How to Build a Mobile App With QR Codes: Payments, Tickets, Loyalty and Check-Ins for Nigerian Businesses

What QR codes do in a business app

A QR code is a two-dimensional barcode that stores text, typically a URL or a short identifier, readable by any phone camera. In an app, QR features fall into two roles, and many apps need both:

• Generating: the app or backend creates a code for the user or the business to show or print, such as a ticket, a customer loyalty ID, a payment request or a table code.
• Scanning: the app reads a code and acts on it, such as a staff app validating tickets, a customer app opening a menu, or a rider app confirming a hand-over.

Codes are also either static (the content never changes, like a menu URL printed on a table) or dynamic (the content is a unique, often time-limited reference generated per transaction, like a ticket or a payment). Static codes are cheap and durable; dynamic codes are what make QR secure and trackable.

QR use cases for Nigerian businesses

The table lists the common uses, who generates and who scans, and the key design need.

If a use case involves money, admission or rewards, treat it as dynamic and verified; if it is informational (a menu, a download link), static is fine.

Designing the payload: what goes inside the code

The difference between a secure QR feature and an insecure one is almost always the payload. The rule is: put a reference in the code, keep the data on the server.

• Never encode sensitive data. No names, phone numbers, amounts that the scanner should trust, or account details. Anyone can read a QR code with any camera.
• Use a short, unguessable identifier (a random token or a UUID) that your backend maps to the ticket, order or member. Short payloads also produce simpler codes that scan faster on low-end cameras.
• Sign it if it must be verified offline. A compact signed token (for example a JSON Web Token or a short HMAC-signed string) lets a staff app confirm authenticity without a network, while the backend remains the source of truth for whether it has been used.
• Add expiry for anything time-limited: payment requests, vouchers, session check-ins.
• Make it a URL when the code may be scanned by an ordinary camera app. A URL to your domain (with the token as a parameter) opens the web page or deep-links into the app if installed, and also lets you handle "app not installed" gracefully.
• Version the format so you can change it later without breaking printed codes.

Choose an error-correction level to suit the medium: higher levels survive smudges and allow a small logo in the centre, at the cost of a denser code.

Generating QR codes: app, backend and print

QR generation is a solved problem with libraries on every platform. The design choices are where and when to generate.

• Backend generation is right for anything that must be unique, tracked or verified: tickets, vouchers, payment requests, parcel labels. The backend creates the token, stores it, renders the image (or returns the string for the app to render) and logs it.
• In-app generation suits codes that represent the user themselves, such as a loyalty member code, refreshed periodically so screenshots expire.
• Print generation for tables, sites, product packs and posters needs export at print resolution (vector or high-resolution PNG), a quiet zone around the code, high contrast, and a test print scanned on several phones before mass printing.

For codes shown on screen, increase screen brightness while displaying, keep the code large, and avoid animations behind it.

Scanning QR codes: cameras, libraries and user experience

Scanning uses the device camera and an on-device decoder. As of 2026 the standard options are Google's ML Kit barcode scanning on Android (also usable on iOS), Apple's AVFoundation and VisionKit scanning on iOS, and cross-platform packages for Flutter and React Native that wrap them. All decode QR codes on the device with no network call and no per-scan cost; verify current library status when you start the build. Design for the scanning experience Nigerian staff and customers actually have:

• Request camera permission with a reason at the moment of first scan, not at app launch.
• Provide a torch toggle for dim venues and evening events.
• Handle low-end cameras with autofocus delays: show a framing guide, decode continuously, and give clear success feedback (sound, vibration, colour) so staff can move fast.
• Debounce repeated reads so one ticket is not scanned five times in a second.
• Offer manual entry of a short code for damaged or unreadable codes.
• Support scanning from screenshots and gallery images where customers arrive with a saved ticket.
• Test in real conditions: sunlight glare on printed codes, cracked screens, reflective phone cases, and crowds.

Verification: online, offline, single-use and replay protection

Scanning proves that a code was read; verification proves that it is genuine, valid and unused. Decide the verification mode per use case:

• Online verification: the scanning app sends the token to the backend, which checks existence, status, expiry and any limits, marks it used, and returns the result. Simplest and most secure; requires connectivity at the scan point.
• Offline verification with sync: the staff app downloads the list of valid tokens (or verifies signatures locally) before the event, marks scans locally, and syncs to the backend when connectivity returns, with conflict rules for duplicates scanned at two gates. Essential for venues with poor coverage.
• Replay protection: single-use tokens for tickets and vouchers; short-lived rotating codes for loyalty member IDs; per-device and per-hour limits for stamps and points.
• Audit: log who scanned what, where and when; it settles disputes at the gate and detects staff fraud in loyalty schemes.

Treat any code that grants value the same way you would treat a payment: verified on the server, used once, logged.

QR payments in Nigeria

QR payments in Nigeria typically work in one of three ways as of 2026, and each has a different integration path:

• Interoperable scheme codes. NIBSS operates the NQR scheme, an interoperable QR payment standard through which participating banks and payment providers let customers pay merchants by scanning with their banking or wallet apps. Merchants obtain codes through their bank or a licensed provider; availability and onboarding requirements vary, so verify with your bank or provider.
• Gateway-generated codes. Some payment gateways and wallet providers can generate a code encoding a payment link or a transfer request with a fixed amount and reference; the customer scans with a camera or wallet app and the gateway confirms by webhook to your backend.
• Payment-link codes. The simplest approach: your backend creates a normal payment link (card, transfer, USSD) for a specific amount and reference and renders it as a QR code on a screen, invoice or receipt. Confirmation flows through your existing payment integration.

For most Nigerian business apps, the third option delivers QR payments with no new provider relationship, while scheme codes make sense for physical counters serving many walk-in customers. In every case the amount and reference must be generated by your backend and confirmation must come from the provider, never from the customer's screenshot.

Step-by-step: building QR features into the app

1. List each QR use case with who generates, who scans, whether it is static or dynamic, and what must be verified.
2. Design the payload format (URL with token, or signed compact token) and the token store on the backend with status, expiry and usage rules.
3. Build backend endpoints: create token, render code, verify and consume token, list tokens for offline sync, and a scan log.
4. Implement generation on the backend and, where needed, in the app; produce print-ready assets for physical codes.
5. Implement scanning in the relevant app with camera permission, torch, framing guide, feedback, debounce and manual entry.
6. Implement verification in the chosen mode, including offline sync and duplicate-scan rules where needed.
7. Handle the "ordinary camera" path: the URL should open a web page that explains the next step and deep-links into the app if installed.
8. Add the admin views: issued codes, scans, redemptions, anomalies (one code scanned in two cities, one staff account with unusual redemptions).
9. Test on real devices and materials: several Android brands, an older iPhone, printed codes on paper and plastic, screens at low brightness, dim and bright venues, no connectivity.
10. Prepare operations: staff training, spare devices and power banks for events, and a fallback plan (manual list) if the system fails.

What changes for Nigerian businesses

QR features are generic technology; the conditions and the fraud patterns are local.

• Connectivity at venues. Event grounds, halls and markets often have weak or overloaded networks. Offline verification with sync is the difference between a smooth gate and a queue.
• Device quality. Staff scanning devices are often budget Android phones with slow autofocus and weak torches; design for continuous decoding and consider issuing a few known-good devices for high-throughput points.
• Screenshots and forwarding. Tickets and vouchers are forwarded on WhatsApp. Single-use verification is non-negotiable; rotating codes for member IDs stop shared loyalty accounts.
• Power. Long events drain scanners; plan power banks and a device rotation.
• Trust at payment. Customers are cautious of scanning codes to pay. Show the business name, amount and reference on the confirmation screen, and confirm payment through the provider's webhook so the customer sees an in-app receipt.
• Fake codes (quishing). Fraudsters paste their own QR stickers over legitimate ones at counters. Use tamper-evident materials for printed payment codes, show a verification message when a scan lands on your domain, and educate staff to check codes periodically.
• Data protection. Scan logs tie people to places and times. Keep them for a defined period, restrict access and disclose the processing, in line with the Nigeria Data Protection Act 2023; confirm obligations with the Nigeria Data Protection Commission.

Example (hypothetical): a Lagos event company's ticketing and check-in app

Example (hypothetical): an event company in Lagos runs concerts and conferences of several thousand attendees and sells tickets through its app and website, with many tickets bought by transfer and forwarded to friends on WhatsApp. Gate-crashing with screenshots of real tickets and slow gates were the two problems. The QR design chosen:

• Tickets are dynamic codes: a URL to the company's domain carrying a signed, single-use token; the ticket page in the app and the emailed PDF both display it, and a "transfer ticket" feature reissues a new token to the recipient and invalidates the old one.
• Gate app for staff downloads the event's valid token list an hour before doors open, verifies signatures locally, marks scans offline, and syncs continuously when the network allows; duplicate scans at different gates are flagged with the first-scan time and gate name.
• Scanner experience: torch on by default after dusk, continuous decode with a loud success tone and a red screen plus vibration for rejections, manual short-code entry for cracked screens.
• Admin dashboard: live entry counts per gate, rejection reasons, and an anomaly list.
• Sponsor activation: a static code on banners deep-links to a sponsor offer in the app with a per-attendee voucher limit.

The operational result the company cared about was faster gates and the end of screenshot entry, achieved almost entirely by the payload design (signed, single-use, transferable by reissue) and offline verification rather than by the scanning technology itself.

How much do QR features cost?

QR features are inexpensive relative to most app modules; the cost sits in verification logic, offline sync and admin tooling. The figures below are indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope.

Recurring costs are small: hosting for the token service, any provider fees for QR payments (transaction fees apply as with other methods; verify current schedules), printing and materials for physical codes, and maintenance at roughly 15–25% of the module's build cost per year. Scanning libraries themselves are free to use on-device.

Mistakes to avoid

• Encoding data instead of a reference. Names, amounts or phone numbers in the code can be read and altered by anyone.
• Trusting the scan without verification. A decoded string is not a valid ticket; the backend or a signature check decides.
• No single-use or expiry rules. Screenshots become unlimited tickets and vouchers.
• Online-only verification at a venue with no signal. Build offline validation with sync for events.
• Skipping real-device testing. Budget phones, dim halls and glossy print surfaces break demos that worked in the office.
• Poor printed codes. Low contrast, no quiet zone, too small, or a large logo at low error correction all reduce scan rates.
• Ignoring the ordinary-camera path. Many people will scan with the phone camera, not your app; the URL must land somewhere useful.
• Payment codes without provider confirmation. A customer's screenshot is not proof; wait for the webhook.
• No anomaly monitoring. Loyalty and voucher fraud by staff or customers shows up first in scan patterns.

Conclusion

Building QR codes into a mobile app is straightforward technically and unforgiving on design. Decide per use case whether the app generates, scans or both; put a reference or a signed token in the code rather than data; generate on the backend for anything that must be unique; scan with on-device libraries and a staff-friendly experience; verify every scan with single-use and expiry rules, offline where venues demand it; and confirm payments through your provider rather than a screenshot. In Nigeria, where tickets are forwarded on WhatsApp, venues have weak signal and scanners are budget phones, those design choices are what make QR features work at the gate, the counter and the doorstep. If you are planning an app that uses QR codes for tickets, loyalty, deliveries, check-ins or payments and want the payload, verification and offline behaviour designed properly, Linestech builds mobile apps with QR and scanning features for Nigerian businesses and can help you scope the right approach.

Frequently asked questions

Do customers need my app to scan a QR code?

Not necessarily. If the code contains a URL to your domain, any phone camera opens it in the browser, and the page can deep-link into the app if installed or show a web version if not. Codes that only your app can interpret (custom tokens) should be reserved for staff apps or in-app scanning.

Can QR ticket validation work without internet at the venue?

Yes. The staff app can download the valid token list (or verify signed tokens locally) before the event, record scans offline, and sync when connectivity returns. Duplicate-scan rules handle the case where two gates scan the same ticket while offline. This is the recommended design for Nigerian venues with weak coverage.

How do we stop people sharing screenshots of tickets or vouchers?

Make every code single-use and verified on scan, offer an official "transfer" that reissues a new code and cancels the old one, and show the first-scan time when a duplicate appears so gate staff can act. For loyalty member codes, rotate the code every minute or so, so a screenshot expires quickly.

Can my app take payments by QR code in Nigeria?

Yes. The simplest route renders a backend-generated payment link (card, transfer or USSD) as a QR code and confirms payment through your gateway's webhook. Interoperable scheme codes through NIBSS's NQR are available via participating banks and providers for merchant counters; check current availability and onboarding with your bank or payment provider.

Which library should we use to scan QR codes?

On Android, Google's ML Kit barcode scanning is the usual choice; on iOS, Apple's AVFoundation or VisionKit scanning; Flutter and React Native have well-maintained packages wrapping these. All decode on the device with no per-scan cost. Confirm current library support for your framework when the build starts.

Are QR codes secure?

The code itself is just readable text, so security comes from design: put only an unguessable reference or a signed token in the code, verify every scan on the backend or by signature, enforce single-use and expiry, log scans, and protect printed payment codes from tampering. Done this way, QR features are as secure as the backend behind them.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• Node.js documentation
• Google Play Console