A customer finishes shopping at a weekend market and points a phone at a small printed square beside the till. The interaction looks simple. Behind it are several separate questions: which application reads the code, how the payment is authorized, how the seller confirms receipt and when the proceeds reach the business bank account.
QR payments are a useful example of financial technology becoming part of ordinary South African commerce. They can place a payment option on a counter, invoice or restaurant table without requiring the customer to type lengthy recipient details. Their value depends on the complete transaction, however, rather than the moment of scanning alone.
For a shop owner or independent trader, the best starting point is understanding what the code does. It is a way of presenting information that a compatible device can read. It is not, by itself, a bank account, a guarantee of payment or a universal agreement about fees. Those elements come from the service connected to it.
The code is the beginning of the transaction
EMVCo, the Organization that maintains specifications for several payment technologies, distinguishes between merchant-presented and consumer-presented QR payments. In the first, the business displays a code for the customer to scan. In the second, the customer displays a code for the merchant to read. Its specifications concern how payment information is represented; subsequent processing is handled by payment providers. [1]
This distinction explains why two similar-looking squares can lead to different experiences. One might open an appropriate payment application, while another contains an ordinary website address. A generic camera application and a banking application’s payment scanner should not be assumed to support every type of payment code equally.
For a trader, the practical question is compatibility. Which applications can customers use with the chosen service, and what instructions should appear beside the code? The answer needs to come from the provider’s supported process. A demonstration on one phone is useful, but it does not establish that every customer can complete the same transaction.
A South African example of the merchant experience
Standard Bank’s description of SnapScan explains a process in which a merchant creates an account linked to a QR code. Customers scan the code, enter an amount where required and authorize payment in the application. The merchant can use confirmation messages and a merchant portal or application to track transactions. [2]
The example shows how a printed display can connect to an administrative service. The business needs a reliable way to see its own transaction status and identify what a receipt relates to. The customer’s screen is only one side of that interaction.
Product conditions should be checked directly before adoption. A merchant’s account type, service configuration and provider arrangements can affect what is available. This article does not treat a particular product as the cheapest or most suitable option for every business. It uses documented functionality to explain the decisions a trader needs to make.
Standardization can reduce confusion without removing every difference
South Africa’s Payments Association discussed QR standardization in its 2021 integrated report, including the publication of a QR Code Standards Specification and work on interoperability. That is evidence of an industry effort at that time, rather than proof that every QR payment product now works with every other product. [3]
Interoperability means that different systems can work together in a defined way. For a customer, the desired result is straightforward: fewer situations in which a familiar payment application cannot read the code at a shop. For a merchant, it can mean fewer separate displays and less explanation at the counter.
Even when technical formats are aligned, commercial and operational arrangements still matter. Providers must support the relevant transaction, the customer needs an eligible funding method and the merchant needs the appropriate service. A common format is an important building block, but the complete user experience depends on the connections around it.
Static and transaction specific codes suit different situations
A permanent display can be convenient for a small stall because it is available whenever the stall opens. The customer may need to enter the amount or another reference during payment. This makes the presentation simple but places more responsibility on the surrounding checkout process.
A transaction-specific code can include information associated with a particular sale, depending on the system. The potential advantage is less manual entry and a clearer connection between payment and order. It may also require closer integration with the till or ordering software. Businesses should confirm exactly which details their provider supports.
Imagine a hypothetical café selling several orders with the same total. A receipt showing only an amount may be difficult to associate with the correct table. A bill reference or integrated checkout can help. At a quieter craft stall, a simpler process may be adequate because the seller handles one customer at a time.
The important choice is the one that fits the work. More automation is useful when it removes a genuine source of error or delay. It adds little value if the business cannot maintain it or if customers find the new steps harder than the existing process.
Confirmation and settlement happen at different stages
An accepted customer payment and money arriving in the merchant’s bank account are different events. Standard Bank’s SnapScan merchant page describes settlement in a lump sum on the following business day, with possible additional interbank delays for merchants banking elsewhere. Readers should verify the current terms applicable to their own arrangement. [2]
This distinction matters for a trader who needs to buy stock. A service may confirm a sale promptly while releasing proceeds according to a later settlement schedule. Calling the checkout quick does not establish that the funds can immediately be spent from the merchant’s bank account.
A business should map these stages before relying on the proceeds for a time-sensitive purchase. It can ask when transactions enter a settlement batch, how weekends or public holidays are handled and where unsettled transactions appear in reports. Clear answers make cash planning more realistic.
When an expected deposit does not match the sales total, the first step is to identify what period the deposit covers and which adjustments apply. Fees, refunds or timing differences may explain a mismatch. The merchant should use the provider’s records rather than assume that each individual sale produces an identical individual bank deposit.
Compare the cost of the same basket of sales
A payment price is easier to understand when applied to the business’s actual sales pattern. A provider may charge a percentage, a fixed amount or a combination of costs. Setup conditions and other charges can also matter. The applicable published terms are the starting point for a comparison.
Consider an arithmetic example that does not represent a particular provider’s fee. A hypothetical charge of three per cent would be R3 on a R100 sale and R15 on a R500 sale. An alternative fixed fee could affect those two sales differently. The average transaction size therefore influences which arrangement appears economical.
An owner should also consider whether the price is quoted before or after any applicable tax and whether other service costs apply. Comparing one provider’s headline percentage with another provider’s total monthly expense can produce a misleading conclusion. Use the same number and value of transactions for both calculations.
Administrative time belongs in the evaluation, although it need not be assigned an invented rand value. A clear transaction export may make bookkeeping easier. A system requiring frequent manual searches may create work. Record these practical differences separately so the decision reflects both the bill and the experience of running the shop.
Make the display easy to use and easy to check
The physical position of a code can affect the checkout. A customer needs to see it, hold a device at a workable angle and understand which payment method it represents. Poor lighting, a damaged print or an awkward location can make a theoretically simple interaction frustrating.
The merchant should use a provider-approved display and check that it belongs to the correct business. Staff should know what name customers are expected to see during the supported payment process. If the destination appears unfamiliar or the display has changed unexpectedly, the transaction needs to be checked before proceeding.
Instructions should remain brief. A sign can identify the accepted service and indicate whether the customer needs to enter an amount or reference. It should avoid surrounding the code with unrelated links or competing payment instructions that make the intended action unclear.
Printed material also needs maintenance. Businesses change contact details, accounts and service providers. An old code left on an invoice template or table can create confusion long after the main counter display has been updated. The owner should know every place where the business distributes its payment information.
Build a routine for busy periods
The busiest trading period is a useful test of a payment method. A process that works when the owner serves one customer may become difficult when several staff members accept orders at once. Confirmation needs to be visible to the people responsible for completing each sale.
A hypothetical market stall could assign one person to take orders and another to check confirmed payments before handing over goods. That arrangement is only helpful if both can connect the receipt to the order. Otherwise, customers may repeat details while staff search for a transaction that has already been found.
Clear references and consistent language reduce this work. Staff should understand what a completed transaction looks like in the merchant’s own system and how to respond when the status is unclear. A customer showing a screenshot should not substitute for the business’s established confirmation process.
Training should also cover mistaken amounts and duplicate attempts. The appropriate response depends on the provider, but staff can still follow an agreed escalation route. Having a named person responsible for exceptions prevents each employee from inventing a different solution during a queue.
Keep an alternative for customers who cannot scan
A QR option depends on the customer’s equipment and access. A compatible application, a working phone and any required connection need to be available at the moment of purchase. Some customers may prefer another method even when they could technically use the code.
The business should decide which alternatives it can reasonably support. It might accept cards, cash or another established payment method alongside QR payments. The important point is to communicate the options early enough that customers are not surprised after receiving a service or placing an order.
Accessibility is also part of design. A person who has difficulty reading a small screen or holding a camera steady may need clear assistance. Staff can explain the process without handling private credentials or pressuring the customer to reveal personal banking information.
The aim is a usable checkout for the intended audience. A digital method can add convenience for some people while leaving another route necessary for others. Retaining choice can be an ordinary commercial decision rather than evidence that the technology has failed.
Refunds and remote payments need clear records
Sending a payment link or code remotely can support orders placed outside the shop, where the provider offers that functionality. However, the business still needs to explain what is being purchased, the amount due and the conditions of fulfilment. A payment request should connect to a recognizable order.
If a customer asks for a refund, staff need to identify the original transaction and follow the service’s approved process. The amount returned and the reason should be recorded. A request to repay into unrelated details deserves verification through the established customer relationship rather than an improvised transfer.
Remote selling also separates payment from delivery. A confirmed receipt does not show that the item has been dispatched or that a customer has accepted it. Keeping these stages distinct helps the business answer later questions with evidence instead of reconstructing the sale from several message threads.
This record can be simple. An order reference, confirmed payment status, fulfilment status and any refund entry may be enough for a small operation. The objective is a traceable transaction, not collecting unnecessary personal details or building an administrative system larger than the business needs.
What a useful trial should reveal
A trader can evaluate QR payments by choosing a defined problem and observing normal trading. The question might be whether remote deposits become easier, whether the counter moves more smoothly or whether payments are simpler to reconcile. Each question calls for a different observation.
Record completed transactions, requests for assistance, unclear payment statuses and time spent matching receipts to sales. Include customers who tried and could not finish. Looking only at successful payments can hide a compatibility or usability problem affecting other buyers.
The result may support using QR payments for one purpose while keeping another method for a different setting. A business might find codes useful on invoices but prefer a card terminal during a crowded lunch service. That is a practical decision based on the transaction rather than a competition between technologies.
South Africa’s QR payment development is significant because it brings payment initiation into ordinary places and documents. Its lasting value comes when the full process is understandable: the customer knows how to pay, the merchant can verify the sale and the records explain where the money went. A small square works best when the service around it is equally clear.
Sources
[1] EMVCo. EMV QR Codes and payment specifications. Checked 23 September 2026.
[2] Standard Bank. SnapScan merchant services. Checked 23 September 2026.
[3] Payments Association of South Africa. Integrated Report 2021, QR code standardization discussion.