QR+ · SOUTH AFRICA'S INTEROPERABLE QR PAYMENT STANDARD South Africa's QR codes are about to work with every wallet. QR+ is the South African Reserve Bank's new standard for interoperable QR payments. Once it lands, a single code at a till or on an invoice can be scanned and paid by any participating app, regardless of who issued it. This page explains what it means for your business, and where Zapper can help. Talk to us about QR+ Start with the basics ↓ Prepared by Zapper's QR+ team· Last reviewed 19 August 2026 WHAT IS QR+? What is QR+? QR+ is the South African Reserve Bank's standard for interoperable digital payment initiation, introduced under its Payments Ecosystem Modernisation programme. It allows a single QR code, barcode or payment link to be read and paid by any participating payment provider, rather than only by the provider that issued it. Today, South African QR payments are closed loops. A code issued by one provider can generally only be paid by that provider's app, which is why a single counter often carries several codes, and a customer is sometimes told their app is not accepted here. ONE CODE, ONE STANDARD QR+ replaces the proprietary string inside a QR code with a standard payment instruction called a Paylink. Any participating app can read it, identify who issued it, and pay it. A CENTRAL REGISTRY DECIDES WHO IS REAL Every Service Provider is listed in a central registry. Each Paylink carries an indicator identifying its issuer, and the paying app verifies that issuer cryptographically before money moves. TWO ROLES, TWO REGISTRATIONS A Payee Service Provider acts for the party receiving money. A Payer Service Provider acts for the party paying. They are separate registrations. Most organisations need one. Some need both. QR+ does not move money. It carries standardised initiation data to whichever payment rail settles the transaction, PayShap first among them. That is why it is described as a standard rather than a payment method, and why it can support barcodes and payment links as well as QR codes. WHEN DOES QR+ ACTUALLY HAPPEN? When does QR+ actually happen? The programme is live and its milestones are dated. No organisation has yet been publicly confirmed as a certified QR+ Service Provider. August 2026 Service Provider entry and participation criteria submitted to SARB’s National Payment System Department for review and approval QR+ Directive in drafting, ahead of public consultation Registry testing under way at PayInc You are here September 2026 QR+ sandbox conformance testing Onboarding, registration and certification processes finalised October 2026 Service Provider onboarding and certification Cohort 1 go-live, first adopters The certification window opens in October. The organisations that will be ready are the ones building now. Programme milestones as published in the SARB QR+ Project Dashboard, 19 August 2026. Version 1.2 of the standard was published by SARB on 7 July 2026 and is publicly available, together with an overview document. Dates are the programme's own targets and are subject to change by SARB and the National Payment Utility. YOUR INSTALLED BASE Does QR+ replace the QR codes I already have? Probably not all of them, and not at once. But it is the right question to ask early, because the answer determines your cost, not your compliance date. South Africa's current interoperable QR estates are built on the EMV QR merchant-presented specification, adopted here on a voluntary, optional basis rather than mandated as a national standard. QR+ is a different and broader framework: it standardises the initiation instruction itself and introduces a central registry, rather than only the code format. Dynamic codes are the easy case. Anywhere a code is generated per transaction by your platform, a till, an invoice API, a checkout, the change happens in the code you already control. The estate does not need to be touched physically. Static codes are the real work. A printed code on a table or a statement carries whatever string was correct when it was printed. Making that estate QR+ interoperable means reissuing or redirecting it, and that is an operational programme, not an integration task. Codes that are not payments are unaffected. A code that opens a menu, joins a Wi-Fi network or loads a page sits outside the standard entirely. There is no published deprecation date for existing QR standards. Plan for a period of coexistence rather than a cutover, and do not let anyone tell you otherwise. Scoping this properly means looking at your actual estate, how many codes, where they live, who printed them and whether you control the string. It is the first thing we would work through with you, and it is usually the difference between a manageable project and an unpleasant surprise. WHICH SIDE ARE YOU ON Which side of the transaction are you on? The answer determines what you build, what you register for, and what a conversation with us looks like. Click a tile. PAYEE SERVICE PROVIDER Your merchants get paid Gateways, PSPs, acquirers, POS platforms and billers. Your merchants display QR codes, or you generate them on their behalf. What this requires ↓ IF YOUR MERCHANTS GET PAID, THE PAYEE SIDE You issue codes that any participating wallet can pay, and you carry the compliance work that makes each one valid and traceable. Your merchants gain a code more customers can pay. PAYER SERVICE PROVIDER Your users pay someone Wallets, banking apps, consumer apps and fintechs. Your users scan codes to pay. What this requires ↓ IF YOUR USERS PAY SOMEONE, THE PAYER SIDE You verify and pay codes issued by anyone in the market, not only your own, and you carry the checks that make that safe. Your users gain acceptance everywhere QR+ is presented. Both? Aggregators, PSPs and platforms with a consumer app usually need both sides. Zapper is registered on both, so one conversation covers both. WHERE WE ARE Where is Zapper on QR+? We contributed to authoring the QR+ specification. We do not own it and we cannot sell it, it is a public standard. What we can do is help you implement it. Zapper is a registered Payee and Payer Service Provider, which is the complete network position, and our implementation has been under construction since May 2026. ComponentStatus Registry service Built and deployed Authorisation authority, hardware-backed signing Built and deployed Payee and payer gateways In development · staging Merchant and consumer application integration Next SARB conformance and certification Ahead of us, on SARB’s timetable QR+ as-a-Service platform In development · design partners Q4 2026 We are a registered Service Provider with a working implementation. We are not yet certified, nobody in the market is, because the certification window has not opened. We would rather you knew exactly where that line sits. QR+ AS-A-SERVICE What is QR+ as-a-Service? You already have access to the network. What QR+ as-a-Service gives you is compliance with the regulation without integrating and certifying against it yourself, we carry that so you don't have to build it. The APIs Issue and resolve Paylinks through a documented API surface, payee side, payer side, or both, kept aligned to the standard as it evolves. Compliance, handled Registry, authorisation, signing, key custody, lifespan, quarantine and audit, already built and kept current as the standard changes, so you are compliant without running the machinery yourself. On registration How your organisation participates in QR+ depends on your regulatory position, your existing infrastructure and which flow types matter to your business. QR+ as-a-Service runs on Zapper's infrastructure, the fastest route to live, with the operational burden on us rather than on your engineering team, and we will work through what that means for you rather than assume it. WHO IT IS FOR Who is QR+ as-a-Service for? Gateways, PSPs and acquirersLive merchant QR estates, no appetite to register as Service Providers themselves. Wallets, banking apps and fintechsUsers who need to scan and pay any code in the market, not only their own. Banks and large institutionsApproaching QR+ as payments infrastructure rather than as a product line. Billers and closed-loop issuersMunicipal and utility billers, retailer wallets, closed-loop estates that will need to become interoperable. POS platforms and aggregatorsSub-merchant estates that inherit your compliance position. International walletsEntering South Africa and needing local QR acceptance from day one. FOR ENGINEERING TEAMS Want to integrate with our QR+ as-a-Service? Our developer documentation covers the API, registry and compliance requirements in full. View developer documentation → FAQ Questions worth going deeper on The detail behind the decisions above. Click a question to expand it. We already have interoperability. Why does QR+ change anything? ↓ Because the interoperability you have today is commercial, and the interoperability QR+ creates is regulated. Those are different things, and they fail in different ways. Bilateral versus universal. Today, reach comes from agreements, your provider has integrated with a set of banks and wallets, and that set is a commercial asset they control. Under QR+, reach comes from the registry. Any registered participant can resolve any Paylink without asking anyone’s permission. Who owns the relationship. Interoperability delivered through a single platform makes that platform the dependency. Interoperability delivered through a standard makes it a substitutable supplier. That is uncomfortable for incumbents and good for you. Optional versus mandated. SARB has stated its intention to mandate interoperability through technical standards and rules. A commercial arrangement can be renegotiated or withdrawn. A directive cannot. If you already have broad QR reach through an existing platform and no near-term compliance pressure, waiting is a defensible position, right up until a directive lands or a competitor in your segment goes live. What is not defensible is discovering the scope of the work at that point. Scoping is cheap now and expensive later. What does implementing QR+ actually take? ↓ The specification is public. Reading it is not the same as building against it. Based on our own build, this is the real shape of the investment. FOUR NEW SERVICES TO BUILD Not one integration but four: a local mirror of the industry registry, an authorisation layer, and a gateway on each side of the transaction you register for. COMPLIANCE MACHINERY UNDERNEATH Security, key management, code expiry rules and a full audit trail, all built to the standard and kept current as it evolves. REGISTRATION IS THE SLOW PART Beyond the technical build, registration involves multiple layers of regulatory approval, and no public application process exists yet. Certification then runs on SARB’s own timetable, not yours. Our own build began in May 2026 with a dedicated engineering team, and it has taken months of sustained work. That is the honest scale of it, and it is why most organisations will be better served buying the rails than building them. See the full technical requirements → What does QR+ do to the economics? ↓ Nobody can give you final numbers yet, and anyone who does is guessing. But the structure is already visible, and the structure is what you should be planning against. Direction determines who pays. A merchant-presented flow and a customer-presented flow are not commercially equivalent. Which party bears the transaction cost changes with the direction of the flow, and that choice has adoption consequences at the till, a cost that lands on the consumer behaves very differently from one that lands on the merchant. The settling rail sets the floor. QR+ does not price transactions; the rail underneath does. Where that rail is PayShap, its fee structure, not card interchange, determines the economics, which changes the picture materially at larger basket sizes. Compliance cost is fixed; transaction cost is variable. The four services and the compliance machinery cost roughly the same whether you process a thousand transactions or a million. That fixed cost is precisely what a shared platform is for, and it is the reason build-versus-buy usually resolves toward buy below a certain volume. What we will not do: publish a rate card on a web page. What a QR+ integration costs depends on your existing stack, whether you host or self-host, which flow types you need and which side of the transaction you are on. A number produced without that conversation is not a price, it is a guess, and you would be right not to trust it. QR+ payments settle instantly. What changes operationally? ↓ Where the settling rail clears and settles in the same moment, the payment is final when it completes. There is no window in which it can be pulled back. That is excellent for working capital and inconvenient for every process you built around a reversible transaction. Reversals are not reversals. When a transaction times out mid-flow, you cannot simply undo it. Your system needs a defined way to resolve an uncertain state and, where value moved, to return it deliberately rather than by cancellation. Refunds become separate payments. A refund is a new credit in the other direction, not the retraction of an old debit. It needs its own reference, its own record and its own reconciliation path. Traceability moves. Card-style transaction identifiers are not what you will be matching on. Query resolution depends on tying your own store, lane or invoice references to what actually appears on a bank statement, which means deciding what you write into the reference at the point of issue, not afterwards. None of this is theoretical for us. It is the layer where an implementation either holds up in production or generates support tickets for years, and it is the part of the specification that reading the document does not prepare you for. GET IN TOUCH Who do I talk to about QR+? Whether you are scoping a build, weighing build against buy, or still working out whether QR+ applies to you, a conversation is useful. We have been inside this standard from the beginning. 1Intro callWhat QR+ means for your business specifically. 2Technical discoveryYour stack, your estate, your flow types. 3Indicative commercialsOnce we both know what is actually being built.
