What is PayShap and how does it work?

PayShap is South Africa's scheme for rapid payments from one bank account to another. It came out of the Rapid Payments Programme^{[SARB, checked 2026-11-04]}, went live on 13 March 2023^{[SARB media statement, checked 2026-11-05]}, and is now one of the retail schemes PayInc runs, alongside EFT credits and debits, DebiCheck, Registered Mandate and real-time clearing^{[SARB media release and FAQ, checked 2026-11-05]}. If your bank contracts or older integration guides name BankservAfrica instead, PayInc is the company formerly called BankservAfrica^{[PayInc Business Report 2025, checked 2026-11-04]}, so they mean the same operator.

Three features separate PayShap from an ordinary bank transfer:

• You can pay an alias. The payer does not need the payee's account number.
• A business can start the payment. With PayShap Request, the business sends the request and the payer approves it.
• It is built for rapid payments. The programme it came out of was named for exactly that.

This page explains how a PayShap payment moves, what ShapIDs and PayShap Request are, what limits apply, how big the scheme really is, and when a business should offer it. For how PayShap fits next to cards, EFT and debit orders, start with how payments work in South Africa.

From the payer's side, it looks like any other payment in a banking app:

1. The payer chooses PayShap, enters the payee's ShapID or account number, and types the amount.
2. The payer's bank checks the amount against the PayShap limit it applies to that account.
3. The payer confirms, and the payer's bank sends the payment to the payee's bank.
4. The payee's bank credits the payee's account.

Behind those steps, the two banks clear and settle the payment under the scheme's rules, which PayInc administers as the operator of PayShap^{[SARB media release and FAQ, checked 2026-11-05]}. A business building on PayShap never touches that layer. Its bank or payment provider does.

The design choice that matters most for builders is that PayShap is a push payment. The payer's bank sends the money; nobody pulls it from the payer's account. Two things follow. First, the payer has to take part in every single payment, so there is no stored permission to collect against later. Second, a checkout cannot treat the customer's click as the payment. Your system waits for the confirmation your bank or provider sends once the payment has gone through, and it handles the customer who never approves.

PayShap includes a pay-by-proxy feature: you can pay to an alias instead of a bank account number^{[SARB retail CBDC background note, checked 2026-11-04]}. That alias is called a ShapID.

For a payer, an alias removes the most error-prone part of a bank transfer, which is copying an account number correctly. It also means people can get paid without sending their account details around in messages.

For a business, the alias changes what a customer has to type and what you have to show. A payout screen that asks for a ShapID is shorter than one that asks for an account number and branch, and it leaves fewer digits to mistype. The ShapID explainer covers how proxy payments work in more detail.

PayShap Request went live in December 2024 with eight banks^{[PayInc Business Report 2025, checked 2026-11-04]}. It changes who starts the payment. The business sends a request for a set amount, and the payer approves it with their bank. The money still moves as a push from the payer's bank, so the payer still has to act.

What a business gains is control of the details. The request starts in your system, so you know which order or invoice it belongs to before any money moves. That removes two familiar reconciliation problems: a customer paying the wrong amount, and a payment arriving with a reference nobody can match. For invoices, account top-ups and online orders, that alone makes the difference between a payment you can match automatically and one somebody has to chase.

Payment providers have built Request into their APIs. Stitch offers PayShap Request alongside Capitec Pay and Capitec Pay VRP^{[Stitch, checked 2026-11-05]}, and it said in August 2026 that its PayShap Request runs on a multi-acquirer architecture with automated routing^{[Stitch blog, checked 2026-11-05]}. Ozow supports PayShap as well^{[Ozow blog, checked 2026-11-05]}. The PayShap Request explainer walks through the flow for merchants, and two tutorials build it: PayShap Request with Stitch in Node.js and PayShap Request with Ozow.

Through a bank or a payment service provider. PayShap runs between banks, and today a business that is not a bank reaches it through one. As Governor Kganyago put it in October 2026, "at the moment, anyone who wants to access the payment system has to go through a bank"^{[BIS: Kganyago, checked 2026-11-05]}.

That leaves two practical routes:

• Your own bank. If your business bank offers PayShap collections or payouts to business clients, you integrate with that bank's channel. You get one relationship, but you also get that bank's API, its onboarding timeline and its pricing, and moving banks later means rebuilding.
• A payment provider. PayShap Request appears as one more payment method in the provider's API, next to cards and Capitec Pay. One integration covers several methods, and the provider deals with bank connectivity.

For most startups and product teams the provider route is quicker to ship and easier to change later. A business with heavy payout volumes and an existing treasury relationship may prefer its bank. PayShap for developers compares the routes and what each gives you.

If you would rather hand the build over, Mctaba Labs payment integration covers PayShap Request alongside the other South African methods.

The PayShap transaction limit was raised from R3,000 to R50,000 in October 2024, although the payer's bank sets the threshold it applies^{[PayInc Business Report 2025, checked 2026-11-04]}. So the scheme sets a ceiling and each bank decides how much of it a customer gets. Two people paying the same invoice from different banks can hit different limits, and neither the merchant nor the payment provider can raise them.

Fees work the same way: what a payer pays to send depends on their own bank and account. Because those figures change, we keep the ones we could verify in one place, PayShap limits and fees by bank, and refresh it monthly rather than repeat numbers here that would go stale. On the merchant side, each provider sets its own price for PayShap Request: Ozow, for example, charges 1.5% with a minimum of R1^{[Ozow pricing page, checked 2026-11-04]}.

For builders, the practical rule is to treat a limit decline as a normal outcome. Show a clear message, offer another method on the same screen, and never hard-code one bank's figure as if it applied to every customer.

Large in absolute terms, and small next to cards.

Governor Kganyago said on 20 October 2026 that PayShap had processed more than 1 billion transactions worth more than R1 trillion since launch^{[BIS: Kganyago, checked 2026-11-05]}. Read that total with one piece of context: PayInc's 2025 business report says PayShap's transaction volumes grew to 329 million, mainly from payments migrating from RTC to PayShap^{[PayInc Business Report 2025, checked 2026-11-05]}. RTC is real-time clearing, another scheme PayInc runs^{[SARB media release and FAQ, checked 2026-11-05]}. Much of PayShap's growth, then, is payments that already cleared in real time on RTC and switched schemes, not people paying in a new way.

The comparison with cards is the sobering part. By the Governor's figures for last year, PayShap processed only about 6% as many transactions as cards, roughly one-seventeenth, and under 40% of EFT credit volumes^{[BIS: Kganyago, checked 2026-11-04]}.

For a merchant deciding what to put on a checkout, that ratio is the number to remember. PayShap is real and growing, but cards still carry far more transactions, so a checkout that offers only PayShap asks many customers to change their habits at the worst possible moment. The PayShap statistics page tracks the totals as they are published, each with the same migration context.

The Governor named four things holding PayShap back: parity, pricing, promotion and the acceptance perimeter^{[BIS: Kganyago, checked 2026-11-05]}. Read from a builder's side, and in our words rather than his, each of the four points at something concrete:

• Parity: whether paying by PayShap feels as complete as paying by card, from the steps in the app to what happens when something goes wrong.
• Pricing: what the payer and the merchant each pay per payment, compared with the methods they already use.
• Promotion: whether people know PayShap exists and trust it enough to choose it at the moment of paying.
• Acceptance perimeter: how many places, online and in person, actually let you pay this way.

These read as adoption problems more than technical ones, which is why the work sits with banks, providers and merchants as much as with the regulator. Our page on the Governor's four blockers takes each one in turn.

Wider acceptance, starting with QR codes. The Governor listed deepening the use of PayShap among four building blocks of a better payment system, with opening the system to non-banks, QR+ interoperability and a single digital ID for payments^{[BIS: Kganyago, checked 2026-11-05]}.

QR+ is the piece most merchants will meet first. QR+ is a standard for starting a payment from a QR code, barcode or digital link, and is not limited to QR-based payments^{[SARB, checked 2026-11-05]}. Version 1.2 of the standard adds enhancements to support integration with PayShap^{[SARB, checked 2026-11-05]}, so PayShap can be the rail underneath a QR code at a till or on an invoice. The SARB will pilot QR+ in the first quarter of 2027^{[BIS: Kganyago, checked 2026-11-04]}.

That goes straight at the acceptance perimeter. One code that many banking apps can read, with PayShap underneath, is the point of an interoperable standard: a shop does not have to sign up for every wallet its customers carry. The QR+ explainer covers the standard, and the Payments Ecosystem Modernisation programme page covers the wider plan, including how non-banks will get their own access.

Here is our verdict by use case.

• Payouts to people and small suppliers: yes, if your bank or provider offers PayShap payouts. An alias makes payout forms shorter and leaves fewer digits to mistype. Keep each payout under the threshold your own bank applies, and fall back to EFT for larger amounts.
• Invoices, account top-ups and bill payments: yes. PayShap Request starts from your system, so each payment is tied to the invoice or account it belongs to and reconciles without manual matching.
• Online checkout: yes, as one option, never the only one. Add PayShap Request through a provider next to card and Capitec Pay. With volumes at a fraction of cards, it is not yet most customers' habit. Our PayShap vs instant EFT vs Capitec Pay comparison helps you choose the mix.
• Subscriptions and other recurring billing: no. Every PayShap payment needs the payer to approve it, so there is no mandate to collect against. PayShap for SaaS billing explains what to use instead.
• Large business-to-business payments: usually not. Amounts above the payer's bank threshold have to move another way.

If you are coming from Kenya, where M-Pesa set expectations, PayShap vs M-Pesa explains why South Africa built a bank scheme instead of a wallet. For the rails in the rest of the region, see payments in Southern Africa. And when you want PayShap Request built into your checkout, invoicing or payouts, Mctaba Labs payment integration can build it for you.