Building a wallet on PayShap and QR codes? Do not tie it to one bank

South Africa will open its national payments system to non-banks from mid-2027, so telcos, fintechs and retailers can connect directly "instead of relying on banks as intermediaries", TechCentral reported on the Reserve Bank's plan. I think this is the right move. But if you are building a payments product today, the useful part of the story is what has not been decided yet.

The reform is good, and the rules are not final

Opening payments to non-banks is overdue. Cash still accounts for about 56% of consumer transactions by volume and costs about R88.5bn a year, according to a recent study cited by Business Day. Millions of people still need cash to pay for the minibus taxi to work. PayShap handles about 60 million transactions a month, and the Reserve Bank's Arif Ismail puts the target at 500 million a month by 2029. That gap does not close while banks are the only way in.

The detail is still moving. Pradeep Maharaj, who heads the Reserve Bank's payments modernisation programme, says the rules on payment activities and exemptions should be published by November, with the first licensed non-banks going live around March 2027. Until those rules are out, you cannot know which non-banks will be licensed to hold customer money, or what they will charge. If your product only works with one bank, you are locking in before the market has taken shape.

How we scoped a taxi fare wallet

When we scoped a scan-to-pay wallet for a minibus taxi platform, the question of who holds the money was still open. Commuters would load funds into a mobile wallet and pay fares by scanning a QR code. The driver would only display a fixed QR code and never hold or receive money. The card funding provider would move money in, not hold it. The custody partner, meaning the licensed bank or e-money issuer that actually holds the funds, was not yet selected, and we did not let that block the design. We designed the ledger as append-only: every top-up and every fare is a separate record, and the balance is calculated from those records instead of stored as one running total. The ledger is designed to work with any properly licensed custody partner, so picking one stayed a business decision and switching later would mean integration work.

What to do if you are building a payments product now

Before you sign with a bank or a payment provider, ask your developer where the balance lives. If the answer is "in the provider's system", you do not own your customer records, and leaving will mean a migration under pressure. Then ask what it would take to swap the partner that holds the money. The answer you want is new integration work and a new contract, not a new app. This is the kind of decision we put at the start of a custom software development project. On the taxi wallet it was settled in the ledger data model, planned as the first phase, before the funding rails and scan-to-pay. We take the same approach to regulation, building compliance into the software from the start.

Watch the cost side too. Maharaj says a standardised QR+ payment code, due in November, should let even a car guard accept digital payments without fees. If that happens, QR code payment on its own stops being a reason to choose you. What stays yours is the customer experience and the transaction history you own.

Whether you need your own licence or a licensed partner is a question for a lawyer, once the November rules are out.

The banks losing their grip is good news for founders. It also means the partner you sign with in 2026 may not be the one you want in 2028.