QR+ in South Africa: the SARB's QR standard and how to prepare for the pilot

QR+ is a payment initiation standard from the SARB. It covers starting a payment from a QR code, a barcode or a digital link, and is not limited to QR-based payments^{[SARB, checked 2026-11-05]}. That split is the whole idea. QR+ is not a new way of moving money and it is not an app. It is a common format for the instruction that starts a payment, so that participating apps can read the same code and send the money over a rail that already exists.

It sits inside the SARB's modernisation programme: the SARB published QR+ Standard 1.2 under PEM^{[SARB, checked 2026-11-05]}. The Governor named QR+ interoperability as one of four building blocks of a better payment system, alongside opening the system to non-banks, deepening the use of PayShap and a single digital ID for payments^{[BIS: Kganyago, checked 2026-11-05]}.

For where QR+ sits among South Africa's rails and regulators, start with how payments work in South Africa. For the programme around it, see the SARB's Payments Ecosystem Modernisation programme.

PayShap. Version 1.2 introduces targeted enhancements to support integration with the PayShap payment rail^{[SARB, checked 2026-11-05]}, and it was published on 7 July 2026^{[SARB, checked 2026-11-04]}.

That matters because PayShap is a rail the SARB is actively pushing, and acceptance is one of its weak points. The Governor named four things holding PayShap back: parity, pricing, promotion and the acceptance perimeter^{[BIS: Kganyago, checked 2026-11-05]}. A code that can start a PayShap payment goes straight at the last of those. Any printed code, invoice or screen becomes a place where PayShap can be accepted, with no card machine involved.

For a developer, it changes what "paid" looks like. The confirmation you wait for after a QR+ scan that runs on PayShap would be a credit notification from your bank or PSP, not a card authorisation. Your order system needs to handle that event, and the PayShap explainer covers how the rail behaves.

Today's QR payments belong to products. Payfast, for example, lists SnapScan and Zapper as separate payment methods^{[payfast.io fees page, checked 2026-11-05]}. A merchant who wants several QR products usually signs up for each one, and a customer can only pay with an app that reads the code in front of them. That is the interoperability gap the Governor's building block names.

App-based QR payments today and the QR+ standard

Question	App-based QR today	QR+
What it is	A payment product: one provider's codes, app support and merchant terms	A standard for starting a payment from a QR code, barcode or digital link
Who can read the code	Apps that support that provider	Any app that implements the standard: interoperability is the point
What carries the money	Whatever the provider has built behind its app	The selected payment rail; QR+ only passes the data that starts the payment
PayShap	Up to each provider	Version 1.2 adds enhancements to support PayShap integration
Where it stands	Live: Payfast lists SnapScan and Zapper as payment methods	Pilot planned for the first quarter of 2027

Last verified: 2026-11-04. Sources, checked 2026-11-04 to 2026-11-05: SARB, BIS: Kganyago, payfast.io fees page. The middle column describes app-based QR products in general, not any one provider's terms.

QR+ is meant to close the gap by standardising the code itself. If the pilot works as designed, one QR+ code could be read by any participating banking or payment app, and the payment would run on whichever supported rail sits behind it. The products you know need not disappear; they could read and produce QR+ codes too, the way different email apps all handle the same email standard.

If you accept SnapScan or Zapper online today, SnapScan for online merchants and Zapper for online merchants cover how those work while QR+ matures.

Whichever rails the standard and the participating providers support. QR+ passes standardised payment initiation data to the selected payment rail, which then processes the transaction^{[SARB, checked 2026-11-05]}, and version 1.2 adds enhancements to support integration with PayShap^{[SARB, checked 2026-11-05]}. For anything else, read the standard itself (the citations above link the SARB's overview) and ask your bank or PSP which rails its QR+ implementation will carry.

For a developer, the separation is the most useful idea in the standard. The code carries the instruction that starts a payment; the rail carries the money afterwards. Good payment code already makes the same split between a payment intent and the method that settles it, so a well-built checkout treats QR+ as one more way to start an existing intent.

One warning: do not assume the fields. Read the standard's data specification before you generate a single code, and do not copy field layouts from other QR formats you have worked with.

In the Governor's words: "In the first quarter of 2027, we will pilot QR+"^{[BIS: Kganyago, checked 2026-11-04]}.

Who takes part is a separate question. Lists of participating banks circulate in the press, but we have not found one in the SARB's own publications, so we do not repeat them here. If you need to know whether your bank or PSP is in the first group, ask them, and ask what they will support on day one: codes printed once and reused, codes generated per payment, digital links, and which rails.

A pilot is a test, not a launch. Expect limited acceptance, a short list of participating apps and rules that change once the pilot has taught everyone something. Plan for QR+ as a capability that arrives after the pilot, and keep your current methods running.

Mostly by asking questions and not printing anything yet.

• Keep what works. If customers pay you by card, SnapScan, Zapper or EFT today, keep those running through the pilot.
• Ask your bank and PSP about their QR+ plans. Will they offer it, from when, on which rails, and at what price?
• Think beyond the till. QR+ covers barcodes and digital links as well as printed codes, so invoices, delivery notes, payment requests sent by chat and online checkouts are all candidates.
• Plan reconciliation before signage. A single code on the counter that every customer scans tells you money arrived, not which order it was for. A unique code per invoice or order solves that, so ask whether your provider will generate them.

If you run a restaurant or collect school fees, restaurant payments and collecting school fees online cover the methods available today.

Build the parts QR+ will need that also pay off without it.

1. Start from the source. Read the SARB's overview of the latest QR+ standard, cited above, and the standard it describes. Generate nothing until you know the required fields and how a code identifies the payee.
2. Model intents and rails separately. One payment intent (order, amount, reference) with several possible rails behind it. If your code already treats a card payment and a PayShap payment as two methods on one intent, QR+ becomes another way to start that intent.
3. Use a unique reference per code. Codes tied to one order make reconciliation automatic. A reusable code needs another way to match money to orders, and that way is usually manual.
4. Confirm from the rail, never from the customer. Treat a payment as paid only when your bank or PSP confirms it by webhook or API. A screenshot of a banking app is not confirmation; fake payment screenshots are a common fraud pattern with any push payment.
5. Plan refunds as new payments. Your system cannot pull a push payment back. A refund is an outgoing payment you initiate, with its own reference and its own reconciliation.
6. Get PayShap working now. You do not need QR+ to accept PayShap. Ozow offers PayShap Request^{[Ozow blog, checked 2026-11-05]}, and Stitch said in August 2026 that its PayShap Request runs on a multi-acquirer architecture with automated routing^{[Stitch blog, checked 2026-11-05]}. The tutorials for PayShap Request with Stitch in Node.js and PayShap Request with Ozow cover the build. When QR+ arrives, the code that confirms and reconciles those payments is what you reuse.

Webhook handling across providers is covered in payment webhooks and reconciliation for South African PSPs. If you would rather have the PayShap and pay-by-bank side built for you, Mctaba Labs payment integration builds those integrations.

Four things are easy to get wrong by moving early.

• Printing codes that will outlive the pilot. Packaging, menus and permanent signage should wait until the standard and the participating apps have settled.
• Promising that any app can pay you. That depends on which banks and apps adopt the standard, and the pilot is where that gets decided.
• Inventing your own format to get ahead. A code that deviates from the standard is the opposite of interoperable, and you will rebuild it.
• Switching off methods customers use today. QR+ adds a way to pay; it does not remove the reasons customers chose card, EFT or an app.

QR codes are also a fraud surface. A sticker over a genuine code redirects payments, so whatever you deploy, check codes regularly and prefer codes generated per payment where you can. The card side of fraud is covered in 3D Secure 2, chargebacks and fraud rules.

For the regional picture beyond South Africa, see payments in Southern Africa. When you are ready to build for the pilot and the rails behind it, Mctaba Labs payment integration works on exactly these South African systems.