QR payments
Static vs Dynamic QR Codes: Which Does Your Business Need?
A static payment QR generally provides a reusable code. A dynamic payment QR is usually generated for a particular payment request. Depending on the service, that request may include an amount, a reference or an expiry time.
The practical choice depends on how you collect payments and connect them to purchases.
What is a static payment QR?
A static QR can stay on your counter, packaging or printed payment sign. Different customers can scan the same code when they want to pay.
The payment service determines what happens next. The customer may need to enter an amount, or the code may contain a fixed amount.
Reusable does not necessarily mean “no amount included.” For example, NIBSS’s QR guidance distinguishes fixed amounts from static codes that allow customers to enter an amount.
For a shop selling items at different prices, check how the customer reaches the correct total.
What is a dynamic payment QR?
A dynamic payment QR is typically prepared for a particular checkout or payment request.
For example, a merchant may generate a request for ₦8,500 with a reference linked to that purchase. The customer scans it and checks the prepared details before authorising payment.
Features vary by provider. Do not assume that every dynamic QR:
- Expires after the same period.
- Includes an order reference.
- Automatically updates an order.
- Prevents another payment attempt.
- Works across every bank or payment app.
Ask the provider which details the request contains and how the result is recorded.
Compare the practical differences
Scroll sideways to compare the options.
| Question | Reusable static QR | Payment-specific dynamic QR |
|---|---|---|
| Can I display one code for multiple customers? | Usually the main purpose | Usually generated for individual requests |
| Who enters the amount? | Depends on the service and code | Often prepared in the request |
| Can I print it permanently at the counter? | Often suitable | A request may expire or become unsuitable for reuse |
| Will it identify the order? | May require a separate reference or record | May include a reference if supported |
| Does scanning confirm payment? | No | No |
| Does it work with every payment app? | Compatibility must be checked | Compatibility must be checked |
A payment-specific code can reduce manual entry when the necessary details are prepared. You still need to check that those details are correct.
When a reusable code can be enough
A reusable QR can suit a merchant who wants one clearly displayed way to receive payments.
Imagine a stall selling food at different prices. The seller confirms the customer’s total, the customer scans the displayed code, and both follow the payment service’s prompts.
The seller still needs to connect the received amount to that purchase. This becomes especially important when several customers pay similar amounts close together.
Keep the order details and payment reference together.
When payment-specific requests may help
A payment-specific QR may be useful when you need to prepare a particular amount or distinguish one checkout from another.
Before choosing it, check whether the service connects the request to the completed incoming payment. An amount inside a code is different from a full order-management system.
Also check what happens when a request expires or a connection drops after authorisation. Establish the result of the original attempt before generating a replacement and asking the customer to pay again.
What GoTap currently offers
GoTap currently provides a reusable business QR that merchants can display or share.
The GoTap business page marks QR codes for specific payments, including a prepared amount and reference, as coming soon.
If you use the reusable QR today, keep a separate order record where needed and confirm each completed payment in your own business account.
Does “dynamic QR” always mean the same thing?
Some QR services use “dynamic” to describe a printed code whose destination website can be changed later.
That is a different question from whether a payment request contains an amount, identifies an order or expires. Ask what the feature actually does.
Choose the code that fits how you sell. For either type, check the recipient, amount and completed payment.