QR payments in Namibia: one standard across many rails, and the trust question inside every code

The fragmentation problem

Without a national standard, each bank or wallet issues its own codes, and a merchant ends up with a wall of stickers. NAMQR version 5.0 sets out to prevent this. It is based on the Bank’s guidelines on standardising QR codes, the EMVCo QR specification and the instant payment programme’s own specification, and it aims to make payment QR codes interoperable, safe and acceptable to every acquirer in the National Payment System.

The standard covers payee-presented, payer-presented and merchant-presented codes, in static and dynamic form, for person-to-person and person-to-merchant payments, ATM withdrawals, agent cash-out, international merchant payments and mandates for recurring payments. It makes its own comparison: by its count it supports all fourteen use cases in its matrix, against nine for the earlier Namclear specification and three for EMVCo. This is the standard’s own claim.

Alias, not account

A privacy decision sits at the centre. The standard treats code content as non-confidential because the code carries an alias, such as a number assigned by the payee’s provider, instead of account details. A payer’s app resolves the alias through the provider. Anyone who photographs a code learns an alias, not a bank account.

The standard also supports payment by feature phone. The code displays a short reference below the picture, and a payer without a smartphone enters it through a USSD menu. Inclusion is built into the design, because the people who most need low-cost acceptance are often the ones without smartphones.

Three defences against a bad code

The standard names the threats: stickers placed over real codes, spoofed codes sent online, unencrypted data, insecure transmission, malware and weak code generation. It answers with layers. Every payload ends in a check value which a scanning app must validate, prompting a re-scan if it fails. A certified validation service, which the standard calls a token vault, holds the parameters stored when a code was generated, and a scanning provider compares what it scanned with what was stored. A mismatch in merchant identifier or amount fails the request before money moves.

The third defence is signing. For payments on the instant payment programme through mobile apps, a code carries a digital signature checked against a public key held in a central registry of verified entries. If the signature checks out, the app treats the source as verified. If the code is unsigned, the app must warn the user the source is unverified. If the signature fails, the request must be declined as tampered or corrupt. Keys are refreshed daily by the checking provider.

The signing annexure names the signature algorithm differently in two places. An implementer should confirm the algorithm against the programme specification, not this standard alone.

Where PSD-12 meets the code

Paragraph 12.2 of PSD-12 requires two-factor authentication before every payment transaction on a payment instrument, website or mobile application. The QR standard repeats the rule for its own scope and points to PSD-12 as the minimum for safety and privacy. A QR payment is therefore never a one-tap approval of a scanned code. The code starts the payment. The authentication ends it.

A payment, step by step

The standard describes how a payee-presented code is made and used. The payee asks their provider’s app to generate a code, choosing the account, amount, currency and other parameters. The provider assigns an alias for the payee and sends the parameters to a validation service, which stores them against a unique reference and returns it. The provider builds the code with the alias and the reference and displays it. The payer scans it with their own app, the payer’s provider asks the validation service to check the scanned parameters, and the check passes or fails. If it passes, the payer authenticates with two factors, the payer’s provider debits the account and sends the request to the payment network, for example near real-time credit, enhanced credit or the instant payment programme. The payee’s provider checks the alias, resolves it to an account, credits the amount and tells both parties.

For a payer without a smartphone, the same code carries a short reference printed below the picture. The payer enters the reference in a USSD menu, the provider retrieves the stored parameters from the validation service, and the flow continues as above. A payer-presented code supports a request to pay, in which the person asking for money shows a code and the person paying scans it. The standard also describes strawman flows for interoperable transactions from a customer bank account at a merchant and for cash withdrawal at an ATM using a dynamic code.

Reading the technical rules

The standard fixes the encoding. All data uses byte mode, with a character set indicator for UTF-8 when characters beyond the basic set appear. Elements use a tag, length and value format with two-digit lengths. A recommended maximum payload of 512 characters follows the EMVCo specification. Error correction at level M, recovering about 15 percent of damage, or Q, about 25 percent, is the common choice, and versions 1 to 10 suit most payee-presented codes. The standard suggests level M with versions 3 to 5 as typical for merchant use, and level Q where a code sits outdoors or at a kiosk.

A few rules prevent bugs. Null values must not be passed into messages as the string null. A space is encoded as a percent sign followed by 20, in line with the internet standard for percent-encoding. Only the QR operator assigns reserved tags, and a scanning app must not act on a reserved tag. A merchant code includes a merchant identifier, store and terminal identifiers echoed in messages for reconciliation. A merchant offers an invoice: the app shows a view-invoice option which opens a PDF or web page before the payer authorises.

Measured against the Bank’s guidelines

The standard includes a table of nine Bank guidelines on QR standardisation, and states compliance with each. Banks, non-bank providers and fintechs should be able to offer both merchant-presented and customer-presented codes. Both types are static or dynamic. One open specification should serve both. Use cases should be defined before the specification. A common structure and format should be set, including size, error correction and encoding. Codes should work across platforms, banks and wallets. Security and privacy should follow PSD-12, with two-factor authentication for every QR payment. Codes should be accessible and usable, and solutions should serve the public interest, promote competition and comply with the Bank’s standards.

The payment streams covered are near real-time credits, enhanced debit orders, enhanced credit, ATM, point-of-sale debit, point-of-sale credit and the proposed instant payment programme. Role definitions stay with the Bank: the standard says it neither enhances nor diminishes the roles of participants. It carries a payload so a code is generated appropriate to the stream. This keeps the standard modest. It standardises the picture, and the money still moves by the rules of each stream.

What this means for organisations in Namibia

A merchant should display one standard code from its provider, protect it from tampering by placing it where staff see it, and train staff to check for stickers over the code. Signed codes shift the checking from the customer to the app.

A provider building scanning or acquiring features should treat the check value, the validation service and signature checks as three separate controls, and test each one with an altered code.