DebiCheck explained, and how to integrate it

DebiCheck is a debit order with a second signature. In an ordinary debit order, the business holds the mandate and the customer's bank pays out on the strength of it. In DebiCheck, formally called Authenticated Collections^{[PASA, checked 2026-11-05]}, the customer also confirms the mandate with their own bank before the first collection. The bank, not just the business, has a record that the customer agreed.

That one change shapes everything about building it. Ordinary debit orders are a file you send. DebiCheck is a conversation with three parties: you ask, the customer's bank asks the customer, and only an approved mandate lets you collect. Your system has to wait for that answer, store what was approved, and keep every collection inside it.

PayInc runs DebiCheck^{[SARB media release and FAQ, checked 2026-11-05]}, along with EFT credits and debits, Registered Mandate, PayShap and real-time clearing. For how those rails fit together, see how payments work in South Africa; this page stays with DebiCheck and what a developer or product lead has to design.

The governance changed in two steps this year. The SARB took over rule-related functions and the licensing and registration of payment institutions from 11 August 2026, and the functions moving to PayInc transferred on 2 September 2026^{[SARB, checked 2026-11-04]}. Since then the SARB handles rules and standards for the national payment system and the licensing, authorisation and registration of payment institutions^{[SARB, checked 2026-11-04]}, while PayInc operates the schemes. If your contracts or help pages still name PASA, the PASA to PayInc transition guide explains what to update. Old integration guides may also name BankservAfrica: PayInc is the company formerly called BankservAfrica^{[PayInc Business Report 2025, checked 2026-11-04]}.

None of that means you integrate with PayInc. A merchant reaches the scheme through a bank. In the SARB Governor's words, "at the moment, anyone who wants to access the payment system has to go through a bank"^{[BIS: Kganyago, checked 2026-11-05]}. In practice you have two routes:

• Your bank's collections service. You contract with the bank that sponsors your collections and integrate with whatever interface it offers, an API or file exchange.
• A collections provider. A payment provider that collects on behalf of many businesses and connects to a bank for you. A provider doing this for others is a third-party payment provider, and authorisation and registration of third-party payment providers moved to the SARB on 11 August 2026^{[SARB, checked 2026-11-04]}. Ask any provider you consider for its registration status.

Our verdict: a business collecting from thousands of customers a month, with an operations team, can justify a direct bank integration. Everyone else should start with a provider, which turns bank file formats and response codes into an interface built for software.

Think of it as three stages, each with its own failure modes.

Stage one: the mandate request. Your sign-up flow collects what the mandate needs: the customer's bank and account, the amount, how often you will collect, the first collection date, and your contract reference. You submit the request through your bank or provider. Validate everything you can before you submit, because every rejected request costs you a customer who has to start again.

Stage two: the customer's approval. The customer's bank asks the customer to approve the mandate in its own channels. Your system cannot speed this up; it can only wait for a result and handle every answer: approved, rejected by the customer, or no response in time. Tell the customer, on screen and by email or SMS, that their bank is about to ask them to approve a debit order from you, and name your business the way it will appear. Customers tend to decline requests they do not recognise.

Stage three: collections. Once a mandate is approved, you submit collections against it on schedule, quoting the mandate reference. Each collection comes back paid or unpaid, not instantly, and sometimes as a response file rather than an API call. Your system marks the invoice, books the money and decides what happens next for an unpaid one, under the rules your bank or provider applies.

Changes are a fourth, quieter stage. A price increase, a new collection day or a cancellation goes back through your bank or provider, and may need the customer's approval again. Design for it from the start; mandates outlive the pricing you launched with.

Store the mandate as a first-class record, not as fields on the customer. The minimum:

Field	Why it matters
Mandate reference	Every collection must quote it, and every dispute will cite it
Contract reference	Ties the mandate to your own agreement with the customer
Account holder and bank account	Needed for collection; personal data you must protect
Agreed amount and collection frequency	Collections have to stay inside what was approved
First collection date and collection day	Drives your scheduler
Status and status history	Requested, awaiting approval, approved, rejected, expired, cancelled, each with a timestamp
Raw request and response payloads	Your evidence when a customer or bank queries a collection

Two rules on the data itself. Bank details and approval records are personal information, and POPIA requires the responsible party to ensure its conditions for processing personal information are complied with^{[POPIA, checked 2026-11-05]}, so encrypt account numbers at rest and keep access narrow. And never update a mandate record in place without keeping the old version: when a dispute arrives months later, you need to show what the customer approved at the time.

Treat every DebiCheck event as asynchronous and possibly duplicated.

• Key everything on references. Store the mandate reference and each collection's reference, and make every status update idempotent, so a repeated callback or a re-sent response file changes nothing the second time.
• Model states explicitly. A mandate moves from requested to awaiting approval to approved, rejected or expired. A collection moves from scheduled to submitted to paid or unpaid. Write these as a state machine and reject transitions that make no sense, such as collecting on a rejected mandate.
• Handle unpaid collections by reason. Insufficient funds, a closed account and a disputed debit need different responses: retry, ask for new details, or stop and investigate. Retry only as your bank or provider's rules allow. Our guide to failed recurring payments covers dunning design.
• Reconcile daily. Match every paid collection to an invoice and to the settlement your bank or provider reports. Anything unmatched goes to a person the same day, not at month end.

If you would rather have a team design the mandate flow and the reconciliation with you, Mctaba Labs payment integration builds collections integrations on South African rails.

The rule that matters most for builders is the dispute window. The dispute period for debit orders, DebiCheck and Registered Mandates fell from 365 days to 60 calendar days from 13 April 2026^{[PASA, checked 2026-11-05]}. That shortens how long a collection stays at risk, which affects how long you hold back revenue recognition, how you age disputes, and what your terms and help pages tell customers.

The other change is governance, covered above: PASA no longer manages the payment system, and the SARB said clearing and settlement would continue as normal throughout the transition^{[SARB, checked 2026-11-04]}. Existing integrations did not need code changes.

You may see other DebiCheck rules quoted elsewhere. We have not verified them against a primary source, so this page leaves them out. Ask your bank or provider for the current scheme rules in writing, and build those limits into your scheduler as configuration rather than constants.

Choose by how the customer pays and how predictable the amount is:

• DebiCheck fits predictable amounts collected monthly from a bank account: premiums, school fees, memberships, loan instalments. The customer's bank has confirmed the mandate, which gives you strong evidence against an unauthorised-debit claim.
• Card tokenisation fits digital subscriptions where customers expect to pay by card and sign up in seconds. See card tokenisation and subscription billing.
• Capitec Pay VRP is the newest option for variable amounts from bank accounts: Stitch announced it on 4 December 2025^{[Stitch blog, checked 2026-11-05]}. Read Capitec Pay VRP explained before committing to it.

For the side-by-side view, including ordinary debit orders and Registered Mandate, start with recurring payments in South Africa, and see debit orders vs DebiCheck for the collections detail.

Before your first live mandate:

1. Route chosen: bank collections service or registered collections provider, with the scheme rules they apply in writing.
2. Sign-up flow validates bank details and tells the customer their bank will ask them to approve.
3. Mandate record stored separately, versioned, with raw payloads kept.
4. State machine for mandates and collections, with idempotent updates.
5. Unpaid handling by reason, with retries set as configuration.
6. Daily reconciliation against settlement reports, with exceptions routed to a person.
7. Customer copy and terms updated for the shorter dispute window, with no references to PASA.

For the wider regional picture, see payments in Southern Africa. When you want the collections flow built and run properly, Mctaba Labs payment integration works on these rails.