# Payments Knowledge Centre

Welcome to the Kwik Payments Knowledge Centre. Browse a category below to find answers to general and technical questions about how payments work in South Africa.

## Categories

- [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [Accepting Payments](https://docs.switchtransact.com/faq/accepting-payments)
- [Card Payments](https://docs.switchtransact.com/faq/card-payments)
- [Debit Orders](https://docs.switchtransact.com/faq/debit-orders)
- [DebiCheck](https://docs.switchtransact.com/faq/debicheck)
- [Registered Mandates](https://docs.switchtransact.com/faq/registered-mandates)
- [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers)
- [Billing and Recurring Payments](https://docs.switchtransact.com/faq/billing)
- [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance)
- [Payment Operations and Integrations](https://docs.switchtransact.com/faq/payment-operations)
- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [Payment Reference Centre](https://docs.switchtransact.com/faq/reference)


# What Is a Payment?

A payment is the transfer of value from one party to another, usually in exchange for goods, services or the settlement of a debt. In South Africa, most non-cash payments move rand between bank accounts through the national payment system, using rails such as EFT, real-time clearing (RTC), PayShap, DebiCheck and the card networks.

Behind every payment there are always at least two parties: the payer, whose account is debited, and the payee (often a business), whose account is credited. Between them sit banks, clearing houses and payment providers such as Kwik that move the instruction and the money.

## What actually moves when you make a payment?

When you pay electronically, no physical money changes hands. Instead, two things happen:

- A **payment instruction** travels between the banks, telling them which account to debit and which to credit.
- **Settlement** happens between the banks themselves, typically through accounts held at the South African Reserve Bank (SARB).

The payer's bank reduces the payer's balance, the payee's bank increases the payee's balance, and the banks square up with each other in the background. How quickly each step happens depends on the payment rail. See [What Is the Payment Lifecycle?](https://docs.switchtransact.com/faq/how-payments-work/payment-lifecycle) for the full journey.

## What is the difference between push and pull payments?

Every electronic payment is either pushed by the payer or pulled by the payee.

| Type         | Who initiates it                                                          | South African examples                                                                                                                                                         |
| ------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Push payment | The payer instructs their own bank to send money                          | EFT credit, [real-time clearing](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing), [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) |
| Pull payment | The payee (or their provider) instructs the payer's bank to release money | Debit orders, [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works), card payments                                                                    |

The distinction matters for risk and authority:

- **Push payments** are authorised at the moment the payer sends them, so they rarely bounce, but the payer controls the timing.
- **Pull payments** rely on prior authority, such as a debit order mandate or a card authorisation. The payee controls the timing, which makes pull payments ideal for recurring collections, but they can fail or be disputed if the authority or funds are missing.

## What types of payments do South African businesses use?

Common payment types include:

- **Once-off payments** — a single purchase, invoice payment or payment link.
- **Recurring collections** — [debit orders](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order) and DebiCheck mandates that collect subscriptions, premiums or instalments on an agreed schedule.
- **Card payments** — in-person or online payments using debit, credit or prepaid cards.
- **Payouts** — money a business pushes out to suppliers, staff or customers, usually by EFT or PayShap.

## Why does a payment take time?

A payment can look instant to the customer while the money is still moving between banks. Authorisation, clearing and settlement are separate steps, and each rail treats them differently: PayShap clears in near real time, while a standard EFT is processed in batches and may only reflect on the next banking day. Cut-off times, weekends and South African public holidays also affect when funds land — see [Cut-Off Times and Value Dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).

Because "paid" can mean different things at different stages, businesses track payments using statuses and references, explained in [Payment Statuses and References](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [Who Are the Participants in a Payment?](https://docs.switchtransact.com/faq/how-payments-work/payment-participants)
- [Payment Methods, Rails and Channels Explained](https://docs.switchtransact.com/faq/how-payments-work/methods-rails-and-channels)
- [Glossary of payment terms](https://docs.switchtransact.com/faq/reference/glossary)


# What Is the Payment Lifecycle?

Every payment moves through a series of stages between the moment it is initiated and the moment the money is finally settled and reconciled. This journey is called the payment lifecycle, and it applies to card payments, debit orders, EFT transfers and PayShap alike — even though the timing of each stage differs by rail.

Understanding the lifecycle helps you interpret payment statuses correctly, know when funds are actually yours, and troubleshoot payments that appear stuck.

## What are the stages of a payment?

Most payments in South Africa follow the same broad sequence:

1. **Initiation** — the payment is created. A customer taps a card, approves a payment link, or a business submits a debit order collection for its action date.
2. **Authentication** — the payer proves they are who they claim to be, for example with a card PIN, 3D Secure, or bank app approval of a DebiCheck mandate.
3. **Authorisation** — the payer's bank checks the account and approves or declines the instruction.
4. **Clearing** — the payment instruction is exchanged between the banks, typically through BankservAfrica, and each bank updates its customer's account.
5. **Settlement** — the banks settle the resulting obligations between themselves through the South African Reserve Bank.
6. **Reconciliation** — the business matches the settled funds to individual payments using references and reports.

The middle four stages are covered in detail in [Authentication, Authorisation, Clearing and Settlement Explained](https://docs.switchtransact.com/faq/how-payments-work/authentication-authorisation-clearing-settlement).

## How long does each rail take?

The lifecycle is the same, but the clock runs differently on each rail.

| Rail                                                                                              | Authorisation                                                          | Funds reflect for the payee                                           |
| ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------- |
| [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap)                             | Real time                                                              | Within seconds, any day of the week                                   |
| [Real-time clearing (RTC)](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) | Real time                                                              | Typically within an hour on the same day                              |
| EFT credit                                                                                        | Batch                                                                  | Same banking day or the next banking day, depending on cut-off        |
| EFT debit order                                                                                   | Batch, on the action date                                              | Outcome (paid or unpaid) confirmed after the processing cycle         |
| [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)                    | Mandate authenticated upfront; collection processed on the action date | Outcome confirmed after the processing cycle                          |
| Card                                                                                              | Real-time authorisation                                                | Settled to the merchant later, per the acquirer's settlement schedule |

Batch rails depend on banking days and submission cut-offs, so weekends and South African public holidays can shift when a payment completes. See [Cut-Off Times and Value Dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).

## Can a payment fail after it starts?

Yes. A payment can exit the lifecycle at several points:

- **Declined at authorisation** — insufficient funds, an invalid account, a closed account or a risk decline.
- **Returned after clearing** — debit orders in particular can be returned as unpaid after the action date, for example when there were insufficient funds on the day.
- **Reversed or disputed later** — a payer may dispute a debit order or raise a card chargeback after settlement.

This is why a successful early stage does not guarantee final payment. Pull payments such as debit orders carry more post-clearing failure risk than push payments, which are checked for funds before they leave the payer's account.

## Which status applies at each stage?

Payment statuses are labels for lifecycle positions: a payment that has been initiated but not yet processed is pending, one approved by the payer's bank is authorised, and one where the money has arrived is settled or paid. Statuses and the references used to track them are covered in [Payment Statuses and References Explained](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references), and the operational side of tracking asynchronous outcomes is covered under [Payment Operations](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [What Is a Payment?](https://docs.switchtransact.com/faq/how-payments-work/what-is-a-payment)
- [Who Are the Participants in a Payment?](https://docs.switchtransact.com/faq/how-payments-work/payment-participants)
- [Debit order action dates and processing cycles](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles)


# Authentication, Authorisation, Clearing and Settlement Explained

Authentication, authorisation, clearing and settlement are the four core stages that every electronic payment passes through. They answer four different questions: is this really the payer, may the money move, how does the instruction get between the banks, and when do the banks actually exchange the money.

The stages are easy to confuse because customers experience them as a single moment — a tap, an approval, a confirmation screen. For a business, though, the difference between an authorised payment and a settled payment is the difference between a promise and money in the bank.

## What is authentication?

Authentication verifies the identity of the payer before a payment or mandate is accepted. South African examples include:

- A card PIN at a point-of-sale terminal, or [3D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure) for online card payments.
- Bank app, USSD or ATM approval of a [DebiCheck mandate](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) before collections begin.
- Logging in to internet banking before sending an EFT or PayShap payment.

Authentication protects the payer. It proves the person authorising the payment controls the account or card, which in turn reduces fraud and strengthens the payee's position in later disputes.

## What is authorisation?

Authorisation is the payer's bank approving the specific payment. The bank checks that the account exists and is open, that funds or credit are available, and that nothing on the account (such as a stop payment) blocks the instruction. The result is an approval or a decline.

For card payments, authorisation happens in real time and often places a hold on the cardholder's funds before the merchant captures the amount — see [Authorisation, capture and pre-authorisation](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation). For batch debit orders, there is no upfront funds check; the "authorisation" is the mandate, and the funds check only happens when the collection is processed on the action date.

## What is clearing?

Clearing is the exchange of payment instructions between banks and the calculation of what each bank owes the others. In South Africa, interbank clearing for EFT, debit orders, DebiCheck, RTC and PayShap runs through BankservAfrica, the country's automated clearing house.

During clearing:

- The instruction moves from the sponsoring or acquiring side to the payer's bank (or the reverse for credits).
- Each bank posts the debit or credit to its customer's account.
- The net obligations between banks are calculated for settlement.

Clearing determines when the payee sees the money in their account, but it is still an interbank IOU until settlement completes.

## What is settlement?

Settlement is the final transfer of value between the banks themselves. South African banks settle their obligations through the South African Reserve Bank's real-time gross settlement system (SAMOS). High-value payments settle individually in real time; retail streams such as EFT and cards settle on a netted basis in scheduled settlement windows.

Once settlement completes, the interbank leg of the payment is final. Note that finality between banks does not prevent all later reversals: a debit order can still be disputed by the payer, and a card payment can still be charged back. See [Refunds, reversals, disputes and chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/refund-reversal-dispute-chargeback).

## Why does authorised not mean paid?

The stages complete at different times, so a payment can be approved and still never become money you keep:

| Stage          | Question it answers                 | Can it still fail afterwards?                                       |
| -------------- | ----------------------------------- | ------------------------------------------------------------------- |
| Authentication | Is this really the payer?           | Yes — the bank can still decline                                    |
| Authorisation  | May the money move?                 | Yes — capture, clearing or settlement can still fail                |
| Clearing       | Has the instruction been exchanged? | Yes — debit orders can be returned unpaid; disputes remain possible |
| Settlement     | Have the banks exchanged value?     | Interbank leg is final; customer disputes remain possible           |

Treat a payment as reliably yours only once it is settled and reconciled, and remember that pull payments carry dispute risk even after that. Reconciliation practices are covered under [Clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [What Is the Payment Lifecycle?](https://docs.switchtransact.com/faq/how-payments-work/payment-lifecycle)
- [What Is the South African National Payment System?](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system)
- [Payment Statuses and References Explained](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references)


# Who Are the Participants in a Payment?

A payment that takes a customer two seconds to approve passes through the hands of several organisations, each with a defined role. Knowing who does what helps you understand where fees come from, who to contact when something goes wrong, and why some problems (like a payer's bank declining a debit order) are outside your provider's control.

The participants differ slightly between card payments and bank-based payments such as EFT, DebiCheck and PayShap, but the roles map closely onto each other.

## Who is involved in every payment?

- **Payer** — the person or business whose account or card is debited. In debit order terminology, the payer is also called the debtor or account holder.
- **Payee or merchant** — the business receiving the money. In collections terminology, the payee is the creditor or user.
- **Payer's bank** — the bank that holds the payer's account and decides whether to approve each debit. For card payments this is the **issuing bank** (the bank that issued the card).
- **Payee's bank** — the bank that receives and credits the funds. For card payments this role is played by the **acquiring bank**, which contracts with the merchant to accept cards. In debit order collections, the equivalent role is the **sponsoring bank**, which sponsors the collections into the clearing system.
- **Payment service provider (PSP)** — a company such as Kwik that connects businesses to the payment rails, handling submission, mandates, statuses, reporting and settlement so the business does not need a direct bank integration. Related roles such as gateways, processors and switches are unpacked in [Gateway, processor, switch and acquirer explained](https://docs.switchtransact.com/faq/accepting-payments/gateway-processor-switch-acquirer).

## Who operates the infrastructure between the banks?

- **BankservAfrica** — South Africa's automated clearing house. It clears interbank EFT, debit order, DebiCheck, real-time clearing and PayShap transactions, exchanging instructions between banks and calculating settlement obligations.
- **South African Reserve Bank (SARB)** — the central bank. It oversees the national payment system under the National Payment System Act and operates SAMOS, the settlement system in which banks settle their obligations to each other.
- **Payments Association of South Africa (PASA)** — the payment system management body recognised by the SARB. It sets the rules its member banks and system operators follow in each payment stream, including debit order and DebiCheck rules.
- **Card schemes** — networks such as Visa and Mastercard, which set the rules for card payments and route authorisations between acquirers and issuers.

## How do the roles line up across payment types?

| Role                      | Card payment   | Debit order / DebiCheck        | EFT / PayShap credit |
| ------------------------- | -------------- | ------------------------------ | -------------------- |
| Pays                      | Cardholder     | Debtor (account holder)        | Sender               |
| Gets paid                 | Merchant       | Creditor (business collecting) | Beneficiary          |
| Payer's bank              | Issuing bank   | Debtor's bank                  | Sender's bank        |
| Bank on the business side | Acquiring bank | Sponsoring bank                | Beneficiary's bank   |
| Interbank network         | Card scheme    | BankservAfrica                 | BankservAfrica       |

## Why does it matter who does what?

- **Declines and unpaids originate at the payer's bank.** If a debit order is returned for insufficient funds or a card is declined, the decision was made by the payer's bank, not by Kwik or your own bank. See [Card declines and response codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes) and [Unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).
- **Rules come from PASA, the schemes and the SARB.** Requirements such as valid mandates, DebiCheck authentication and dispute timelines are industry rules, not provider preferences.
- **Each participant adds a step and often a fee.** The chain of participants explains the cost structure described in [Payment Fees and Interchange Explained](https://docs.switchtransact.com/faq/how-payments-work/payment-fees-and-interchange).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [What Is the South African National Payment System?](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system)
- [Authentication, Authorisation, Clearing and Settlement Explained](https://docs.switchtransact.com/faq/how-payments-work/authentication-authorisation-clearing-settlement)
- [Payment industry acronyms](https://docs.switchtransact.com/faq/reference/acronyms)


# Payment Methods, Rails and Channels Explained

Method, rail and channel are three words that often get used interchangeably, but they describe different layers of a payment. The method is what the customer chooses, the rail is the interbank infrastructure the money travels on, and the channel is where the payment is accepted.

Separating the three layers makes payment conversations much clearer — especially when choosing which payment methods to offer, or when diagnosing why one payment arrives instantly and another takes a banking day.

## What is a payment method?

A payment method is the customer-facing way of paying. Common methods in South Africa include:

- Debit, credit and prepaid cards, including digital wallets such as Apple Pay and Google Pay
- Debit orders — both EFT debit orders and [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- Manual EFT (the customer pays from their own banking app using your reference)
- [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap), including pay-by-proxy using a ShapID
- Instant EFT and other bank-login or open banking methods
- Cash and retail vouchers

Choosing which methods to offer is covered in [How to choose payment methods](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods).

## What is a payment rail?

A payment rail is the underlying interbank system that clears and settles the money. South African rails include:

| Rail                                                                                              | Type                                    | Speed                                     | Typical use                                        |
| ------------------------------------------------------------------------------------------------- | --------------------------------------- | ----------------------------------------- | -------------------------------------------------- |
| EFT credit                                                                                        | Push, batch                             | Same or next banking day                  | Salaries, supplier payments, manual EFT            |
| EFT debit order                                                                                   | Pull, batch                             | Processed on the action date              | Recurring collections                              |
| DebiCheck                                                                                         | Pull, batch with authenticated mandates | Processed on the action date              | Recurring collections with bank-confirmed mandates |
| [Real-time clearing (RTC)](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) | Push, real time                         | Minutes                                   | Urgent once-off transfers                          |
| PayShap                                                                                           | Push, real time                         | Seconds, every day                        | Instant low-value payments                         |
| Card networks                                                                                     | Pull (authorised per transaction)       | Real-time authorisation, later settlement | Card and wallet payments                           |
| SAMOS (RTGS)                                                                                      | Push, real time gross                   | Immediate and final                       | High-value interbank settlement                    |

Most retail rails are operated by BankservAfrica and settle through the South African Reserve Bank — see [What Is the South African National Payment System?](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system).

## What is a payment channel?

A channel is where and how the payment is accepted:

- **Online checkout** — hosted payment pages, embedded forms or API integrations on your website or app.
- **Payment links** — a URL sent by email, SMS or WhatsApp that opens a payment page, useful for invoicing and remote sales. See [Payment links](https://docs.switchtransact.com/faq/accepting-payments/payment-links).
- **In person** — card terminals, SoftPOS on a phone, or QR codes at the till.
- **Batch or API submission** — how businesses submit debit order collections and payouts, without the payer being present at all.

## How do the three layers fit together?

One method can run over different rails, and one rail can serve many methods. Examples:

- A customer paying "by bank transfer" might use a standard EFT, RTC or PayShap — the same action for the customer, three different rails with different speeds and cut-offs.
- A card can be used in person, online or saved for recurring billing — one method, one rail, three channels.
- A debit order collected via Kwik uses the pull rails (EFT debit order or DebiCheck) and reaches the payer through no channel at all on collection day, because the mandate authorised the collection in advance.

When you evaluate a payment option, ask three questions: what does the customer experience (method), how fast and final is the money (rail), and where does the transaction happen (channel)? The rail usually determines cut-off times, value dates and failure behaviour, which is why the same "payment" can behave very differently — see [Cut-Off Times and Value Dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [What Is a Payment?](https://docs.switchtransact.com/faq/how-payments-work/what-is-a-payment)
- [EFT vs RTC vs PayShap vs RTGS](https://docs.switchtransact.com/faq/bank-transfers/eft-vs-rtc-vs-payshap-vs-rtgs)
- [How to accept payments online](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)


# Payment Statuses and References Explained

A payment status tells you where a transaction currently sits in the payment lifecycle, and a payment reference tells you which transaction you are looking at. Together they are the tools you use to answer the two questions every business asks daily: has this customer paid, and which payment is this money for?

Statuses matter because most South African payment rails are asynchronous — the final outcome of a debit order, for example, is only known after the processing cycle completes, which can be a banking day or more after submission.

## What do the common payment statuses mean?

Exact status names vary by provider and rail, but most map to these stages:

| Status                | What it means                                                                              | Is the money yours?                                   |
| --------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------- |
| Pending / submitted   | The payment has been created or sent for processing, with no outcome yet                   | No                                                    |
| Authenticated         | The payer has been verified (for example a DebiCheck mandate approved via the bank)        | No — this confirms authority, not payment             |
| Authorised / approved | The payer's bank has approved the instruction                                              | Not yet — funds still need to clear and settle        |
| Paid / successful     | The payment cleared and the funds are due to you                                           | Effectively yes, subject to settlement timing         |
| Settled               | The funds have been paid over to you                                                       | Yes, though disputes remain possible on pull payments |
| Failed / declined     | The payer's bank rejected the payment                                                      | No                                                    |
| Unpaid / returned     | A debit order was processed but returned afterwards, for example due to insufficient funds | No — treat it like a failed collection                |
| Disputed / reversed   | The payer disputed the payment after the fact                                              | Funds may be clawed back                              |
| Refunded              | You returned the funds to the payer                                                        | No                                                    |

Two practical warnings:

- **Authorised is not paid.** The difference is explained in [Authentication, Authorisation, Clearing and Settlement](https://docs.switchtransact.com/faq/how-payments-work/authentication-authorisation-clearing-settlement).
- **A debit order can succeed and then be returned.** Always process unpaid notifications, not just the initial submission response. See [Unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

When a payment fails or is returned, the bank supplies a reason code describing why. Do not assume what a code means — check it against the rail's definitions, as covered in [Error and reason codes](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes).

## What is a payment reference?

A payment reference is an identifier attached to a transaction so it can be tracked and matched. A single payment usually carries several:

- **Your reference** — the invoice number, contract number or customer reference you assign. This is what makes reconciliation possible.
- **Provider reference** — the unique ID Kwik assigns to each transaction, used when querying a payment.
- **Bank statement reference** — what the payer sees on their statement. For debit orders this includes the abbreviated short name identifying the collecting business, which must match the mandate.
- **Interbank references** — identifiers used between the banks and BankservAfrica, occasionally needed when tracing a missing payment.

## How do references help with reconciliation?

Reconciliation is matching money received to the transactions that produced it. Good reference practice makes this nearly automatic:

- Use one unique reference per expected payment, and never reuse it.
- For manual EFT, give each customer their own reference, since you cannot control what payers type — see [Proof of payment and reconciliation](https://docs.switchtransact.com/faq/bank-transfers/proof-of-payment-and-reconciliation).
- Keep the statement descriptor recognisable so payers do not dispute payments they do not recognise.
- Store the provider reference against every transaction so queries and disputes can be traced quickly.

## How should systems handle status changes?

Because outcomes arrive asynchronously, treat statuses as events rather than a single answer: record each change, act only on final states (paid, failed, unpaid, disputed), and design for the possibility that a "successful" pull payment is later returned. Webhooks and polling patterns for this are covered under [Asynchronous payment statuses](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [What Is the Payment Lifecycle?](https://docs.switchtransact.com/faq/how-payments-work/payment-lifecycle)
- [Cut-Off Times and Value Dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates)
- [Payment status directory](https://docs.switchtransact.com/faq/reference/payment-status-directory)


# What Are Payment Cut-Off Times and Value Dates?

A cut-off time is the deadline by which a payment instruction must be submitted to be processed in a given cycle, and a value date is the date on which the payment takes effect. Together they explain one of the most common payment questions in South Africa: why a payment made today only reflects tomorrow — or, around a long weekend, several days later.

Cut-offs and value dates matter most for batch rails such as EFT credits and debit orders. Real-time rails like PayShap largely remove the problem, which is one of their main advantages.

## What is a banking day?

A banking day (or business day) is a day on which the interbank clearing and settlement systems run normal processing cycles. In South Africa:

- **Banking days** are Mondays to Fridays that are not public holidays.
- **Non-banking days** are Saturdays, Sundays and South African public holidays.

Batch payments submitted on or for a non-banking day are not processed that day — they are handled according to the rail's date rules. Real-time rails such as [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) operate every day of the year, including weekends and public holidays.

## What is a submission cut-off time?

Each batch processing cycle has a submission deadline. Instructions received before the cut-off are included in that cycle; instructions received after it roll into the next cycle, which may be the next banking day.

Practical implications:

- An EFT credit sent before your bank's cut-off on a banking day typically reflects the same day or the next banking day; sent after the cut-off, add another banking day.
- Debit order collections must be submitted before the cut-off ahead of the action date. Kwik publishes its submission deadlines so collections are always delivered to the banks in time — see [Action dates and processing cycles](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles).
- [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) adds an earlier step: the mandate must be authenticated before the collection can be submitted, so plan for both deadlines.

Exact cut-off times differ by bank, rail and provider, so always work from the published deadlines that apply to your setup rather than a general rule.

## What is a value date?

The value date is the date a payment is treated as taking effect — the date interest, availability of funds and the action of a debit order are anchored to. It is not always the same as:

- **Submission date** — when the instruction was sent, which may be one or more days earlier.
- **Statement date** — when the entry appears on a statement, which can lag the value date.

For debit orders, the value date is the **action date**: the day the payer's account is debited, agreed in the mandate.

## What happens when the action date falls on a weekend or public holiday?

Batch debits cannot be processed on non-banking days, so the date must be adjusted. The standard convention for debit orders is to collect on the **previous business day** when the agreed action date falls on a Saturday, Sunday or South African public holiday.

For example, if a monthly debit order runs on the 1st and the 1st is a Sunday, the collection is processed on the preceding Friday (assuming Friday is a banking day). Key points:

- The date adjustment rule should be disclosed in the mandate so payers are not surprised by an earlier debit — see [Minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
- Adjustment can move a collection into the previous calendar month, which affects billing and reconciliation around month-end.
- Salary-date collections need particular care in months where the usual pay date shifts.

## How do cut-offs differ across rails?

| Rail                         | Processes on non-banking days?                        | Cut-off sensitivity                               |
| ---------------------------- | ----------------------------------------------------- | ------------------------------------------------- |
| PayShap                      | Yes — every day, in seconds                           | None in practice                                  |
| Real-time clearing (RTC)     | Limited windows outside business hours                | Low                                               |
| EFT credit                   | No                                                    | High — submission time sets the value date        |
| EFT debit orders / DebiCheck | No — action dates adjust to the previous business day | High — submission and action-date deadlines apply |

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [Payment Statuses and References Explained](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references)
- [What Is the Payment Lifecycle?](https://docs.switchtransact.com/faq/how-payments-work/payment-lifecycle)
- [EFT vs RTC vs PayShap vs RTGS](https://docs.switchtransact.com/faq/bank-transfers/eft-vs-rtc-vs-payshap-vs-rtgs)


# Payment Fees and Interchange Explained

Every electronic payment involves several organisations doing work — authenticating the payer, moving the instruction, carrying risk and settling the money — and each layer of that work has a cost. Payment fees are how those costs are recovered, and understanding the components helps you compare providers and pricing models on a like-for-like basis.

The fee structure differs between card payments and bank-based payments such as debit orders, EFT and PayShap, so it is worth looking at each separately.

## What fees make up a card transaction?

When a customer pays you by card, the total fee you pay (often called the merchant service fee or merchant discount rate) is typically built from:

- **Interchange** — a fee paid by the acquiring side to the card issuer for each transaction. In South Africa, interchange rates are determined through a process overseen by the South African Reserve Bank, and they vary by card type and how the transaction is processed (for example card-present versus card-not-present).
- **Card scheme fees** — charged by networks such as Visa and Mastercard for using their rails and rules.
- **Acquiring and processing fees** — the margin of the acquiring bank and payment provider for authorisation, clearing, settlement, risk management and support.

Because interchange differs by card type, a premium credit card usually costs a merchant more to accept than a standard debit card, even for the same purchase amount.

## What fees apply to debit orders and bank transfers?

Bank rails have no interchange in the card sense, but there are still costs at each step. Typical fee components include:

- **Transaction or collection fees** — a fee per debit order submitted, or per EFT or PayShap payment processed.
- **Unpaid or failed collection fees** — returned debit orders often carry a fee, which is one reason reducing unpaids matters. See [Unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).
- **Mandate authentication fees** — [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) involves an authentication step through the payer's bank, which has an associated cost.
- **Dispute-related fees** — handling disputes and reversals carries operational cost.
- **Platform or monthly fees** — some providers charge for access, reporting or minimum volumes.

Actual amounts depend on your provider, rails and volumes. For what applies to your Kwik account, refer to your agreement and the published [pricing](https://docs.switchtransact.com/pricing).

## How do pricing models differ?

Providers package these components in different ways:

| Pricing model                | How it works                                                           | Trade-off                                                                      |
| ---------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Blended rate                 | One flat percentage or fee across all transactions                     | Simple and predictable, but averages cheap and expensive transactions together |
| Interchange-plus (unblended) | Actual interchange and scheme fees passed through, plus a fixed margin | Transparent and often cheaper at volume, but statements are more complex       |
| Per-transaction fee          | A fixed rand amount per payment, common for debit orders and EFT       | Very predictable; percentage-based costs do not apply                          |
| Tiered pricing               | Rates that step down as volume grows                                   | Rewards scale, but tiers need checking against your real mix                   |

When comparing quotes, compare the full picture: the headline rate, unpaid and dispute fees, monthly fees, and settlement timing all affect the true cost of collecting a rand.

## Why do fees vary between payment methods?

Cost tracks risk and infrastructure. Card-not-present payments carry more fraud and chargeback risk than card-present payments, and so tend to cost more. Debit order collections are inexpensive per transaction but carry unpaid and dispute risk, which DebiCheck's authenticated mandates were introduced to reduce. Real-time rails like PayShap involve instant, irrevocable clearing infrastructure. Choosing methods is therefore partly a pricing decision — see [How to choose payment methods](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods).

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [Who Are the Participants in a Payment?](https://docs.switchtransact.com/faq/how-payments-work/payment-participants)
- [Payment Methods, Rails and Channels Explained](https://docs.switchtransact.com/faq/how-payments-work/methods-rails-and-channels)
- [How card payments work](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)


# What Is the South African National Payment System?

The national payment system (NPS) is the collective name for the infrastructure, rules and institutions that move money in South Africa — from a tap at a card machine to the settlement of billions of rand between banks each day. Every EFT, debit order, DebiCheck collection, card payment and PayShap transfer runs inside it.

You do not need to interact with the NPS directly to accept payments, but knowing how it is organised explains where the rules that govern mandates, disputes and processing cycles come from, and why they apply to every provider and bank in the same way.

## Who runs the national payment system?

Three institutions anchor the NPS:

- **South African Reserve Bank (SARB)** — the central bank oversees the NPS under the National Payment System Act, sets policy for its safety and efficiency, and operates **SAMOS**, the real-time gross settlement system in which banks settle their obligations to one another in central bank money.
- **Payments Association of South Africa (PASA)** — the payment system management body recognised by the SARB. PASA organises its members into payment streams and maintains the rules for each, including the debit order and DebiCheck rules that mandate requirements are based on.
- **BankservAfrica** — the automated clearing house that operates the retail clearing systems. It receives payment instructions from banks, exchanges them, and calculates the net positions that are then settled through SAMOS.

Individual banks participate in the clearing streams as members, and non-bank players such as payment service providers access the system through sponsoring banks. See [Who Are the Participants in a Payment?](https://docs.switchtransact.com/faq/how-payments-work/payment-participants).

## What are the main clearing streams?

The NPS is organised into streams, each with its own rules, cycles and use cases:

| Stream                                                                                            | Direction                              | Speed                                      | Typical use                                    |
| ------------------------------------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------ | ---------------------------------------------- |
| EFT credits                                                                                       | Push                                   | Batch, banking days                        | Salaries, supplier payments, manual EFT        |
| EFT debits (debit orders)                                                                         | Pull                                   | Batch, on the action date                  | Recurring collections                          |
| DebiCheck                                                                                         | Pull, with bank-authenticated mandates | Batch, on the action date                  | Recurring collections with confirmed authority |
| [Real-time clearing (RTC)](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) | Push                                   | Near real time                             | Urgent once-off credits                        |
| [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap)                             | Push                                   | Seconds, every day                         | Instant low-value payments, pay-by-proxy       |
| Card                                                                                              | Pull per authorisation                 | Real-time authorisation, netted settlement | Card and wallet payments                       |
| SAMOS (RTGS)                                                                                      | Push                                   | Immediate and final                        | High-value and interbank settlement            |

Batch streams follow banking-day cycles and cut-off times, while the real-time streams operate continuously — the practical consequences are covered in [Cut-Off Times and Value Dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).

## How does clearing connect to settlement?

Retail payments clear through BankservAfrica, where each bank's obligations to every other bank are netted off. Those net positions are then settled in SAMOS across the banks' accounts at the SARB. High-value payments skip the netting and settle individually in real time. This two-layer design keeps everyday payments cheap while keeping interbank risk controlled — the mechanics are explained in [Authentication, Authorisation, Clearing and Settlement](https://docs.switchtransact.com/faq/how-payments-work/authentication-authorisation-clearing-settlement).

## Why does the NPS matter to your business?

- **Rules are industry-wide.** Requirements such as valid debit order mandates, DebiCheck authentication and dispute processes come from the NPS framework, so they apply regardless of which bank or provider you use.
- **The system is being modernised.** The SARB's payments modernisation agenda has already produced DebiCheck and PayShap, and continues to shape how South Africans pay — including broader participation by non-banks.
- **Reliability is systemic.** Because clearing and settlement are centralised and regulated, a payment cleared through the NPS behaves predictably: the same cycles, reason codes and finality rules apply across all participating banks.

## Related topics

- Back to the hub: [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)
- [Payment Methods, Rails and Channels Explained](https://docs.switchtransact.com/faq/how-payments-work/methods-rails-and-channels)
- [How DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [Regulators and industry organisations](https://docs.switchtransact.com/faq/reference/regulators-and-industry-organisations)


# How Payments Work

Start here to understand the building blocks of every payment: who is involved, how money actually moves, and the terminology used across the rest of the knowledge centre.

## Topics in this section

- [What Is a Payment?](https://docs.switchtransact.com/faq/how-payments-work/what-is-a-payment)
- [What Is the Payment Lifecycle?](https://docs.switchtransact.com/faq/how-payments-work/payment-lifecycle)
- [Authentication, Authorisation, Clearing and Settlement Explained](https://docs.switchtransact.com/faq/how-payments-work/authentication-authorisation-clearing-settlement)
- [Who Are the Participants in a Payment?](https://docs.switchtransact.com/faq/how-payments-work/payment-participants)
- [Payment Methods, Rails and Channels Explained](https://docs.switchtransact.com/faq/how-payments-work/methods-rails-and-channels)
- [Payment Statuses and References Explained](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references)
- [What Are Payment Cut-Off Times and Value Dates?](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates)
- [Payment Fees and Interchange Explained](https://docs.switchtransact.com/faq/how-payments-work/payment-fees-and-interchange)
- [What Is the South African National Payment System?](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system)


# Clearing, Settlement and Reconciliation Explained

A payment that shows as successful on screen is not the same as money in your bank account. Between the moment a transaction is approved and the moment funds are available, it passes through clearing and settlement, and only reconciliation confirms that what you expected to receive actually arrived.

Understanding these three stages helps operations teams explain timing differences to finance, spot missing funds early and close the books with confidence.

## What is clearing?

Clearing is the process of exchanging and confirming payment instructions between banks. For card payments, the acquirer and issuer exchange transaction details through the card schemes. For debit orders and EFT payments, instructions flow through the South African national payment system on defined processing cycles.

During clearing:

- Transaction details are validated and matched between the paying and receiving banks.
- Each bank works out what it owes or is owed.
- Nothing has moved yet; clearing establishes the obligation, not the funds.

## What is settlement?

Settlement is the actual transfer of value between banks, typically across accounts held at the South African Reserve Bank. Once interbank settlement completes, the receiving bank credits the beneficiary, and the funds become real.

Settlement timing differs by payment method:

- **Card payments** settle to the merchant on the acquirer's settlement schedule, usually a day or more after authorisation.
- **EFT credits and debit orders** settle on batch cycles tied to [cut-off times and value dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates), and debit order collections can still be reversed afterwards as unpaids.
- **Real-time payments** clear and settle within seconds, so the distinction is less visible to the merchant.

A key point for collections: a debit order that settled successfully today can still come back as an unpaid over the following days, so settled does not always mean final. See [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions) for how returns work.

## What is reconciliation?

Reconciliation is the process of matching three views of the same money:

1. **Your system's view**: the payments you submitted or expected to receive.
2. **The provider's view**: transaction reports, response files and settlement statements.
3. **The bank's view**: actual credits and debits on your bank statement.

A payment is fully reconciled when it appears consistently in all three, with the same reference and amount.

### What should you reconcile daily?

- Submitted collections against response and unpaid files or API status updates.
- Settlement batches against individual transactions, so every batch total can be broken down to line level.
- Bank statement credits against expected settlement amounts, after fees.
- Unpaids and reversals against the original transactions they relate to.

## Why do reconciliation breaks happen?

Common causes of mismatches include:

- **Timing differences**: a transaction cleared today but settles tomorrow, so it appears in one view and not the other.
- **Reference problems**: truncated, reused or missing references make matching unreliable. Unique references per instruction, as covered in [payment statuses and references](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references), are the foundation of clean reconciliation.
- **Unpaids and reversals**: funds arrive and are later clawed back, which must be matched to the original item rather than treated as a new transaction.
- **Fees and netting**: providers may settle gross with fees invoiced separately, or net of fees, and the model must match what finance expects.

## How do you build a reliable reconciliation process?

- Assign a unique reference to every payment instruction and carry it through every system.
- Store the interim and final status of each transaction, since many outcomes are [asynchronous](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses).
- Ingest settlement reports and unpaid files automatically rather than manually.
- Investigate breaks the same day; aged breaks are far harder to resolve.
- Keep an audit trail of every status change, as described in [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).

For more operational topics, return to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# Sandbox, UAT and Production Environments Explained

Payment integrations are built and proven in stages, moving from a simulated sandbox to formal user acceptance testing (UAT) with the bank or provider, and finally to production. Each environment answers a different question: does my code work, does it work against the real counterparty's test systems, and does it work with real money.

Skipping or rushing a stage is how duplicate collections, malformed files and failed go-lives happen. Planning the environment journey early, including the bank's certification requirements, keeps project timelines realistic.

## What is a sandbox environment?

A sandbox is a simulated environment the provider hosts for development. It accepts the same API calls or file formats as production but no real money moves and no real bank processing occurs.

Use the sandbox to:

- Build and unit-test your integration: authentication, request formats, [webhook handling](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) and error paths.
- Simulate outcomes, since sandboxes typically let you trigger specific results, such as a successful DebiCheck authentication, a decline or an unpaid, using designated test values.
- Exercise failure handling: timeouts, invalid requests and signature errors are cheap to rehearse here.

Sandbox behaviour is a simulation, so treat it as a functional test of your code, not proof of end-to-end behaviour. Response timing in particular rarely matches production's [asynchronous reality](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses).

## What is UAT and why do banks require certification?

UAT connects you to the bank's or provider's test environment, which behaves much closer to production. For bank integrations, particularly host-to-host file channels and corporate APIs, UAT is usually a formal, scheduled exercise rather than an open playground:

- The bank issues UAT credentials, certificates and connectivity details separately from production.
- You work through a defined test pack: mandate creation, collections, unpaids, cancellations, response file handling and exception cases.
- Testing windows may be scheduled, since bank test environments run processing cycles like production does.
- The bank signs off (certifies) your integration before issuing production access.

Certification is commonly mandatory before go-live for file-based channels and DebiCheck flows. Book UAT slots early; they are a frequent critical path in payment projects.

## How is production go-live managed?

Go-live is not a switch to flip at full volume. A staged ramp-up reduces the blast radius of anything the test environments did not catch:

1. **Pilot**: process a small number of low-risk live transactions and reconcile them end to end, including settlement and any unpaids.
2. **Ramp-up**: increase volumes in agreed steps while monitoring error rates, [reason codes](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes) and reconciliation breaks.
3. **Business as usual**: full volumes with standing monitoring and alerting.

Keep a rollback plan: know how you would pause submissions, and what happens to instructions already in flight if you do.

## How should you keep environments separated?

Environment bleed, such as production credentials in a test config, or test URLs in production, is a recurring cause of incidents:

- Use separate credentials, certificates, webhook URLs and encryption keys per environment, as covered in [API authentication and signatures](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures).
- Never use real customer card numbers, bank account numbers or ID numbers in sandbox or UAT; use the provider's test data.
- Make the environment visible in logs and dashboards so a misrouted transaction is obvious, following the practices in [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
- Gate production configuration changes behind review.

## Environment comparison

| Aspect       | Sandbox                   | UAT                             | Production                      |
| ------------ | ------------------------- | ------------------------------- | ------------------------------- |
| Money moves  | No                        | No                              | Yes                             |
| Counterparty | Simulator                 | Bank/provider test systems      | Live banking rails              |
| Access       | Self-service              | Bank-issued, often scheduled    | After certification             |
| Purpose      | Build and functional test | End-to-end proving and sign-off | Live processing, staged ramp-up |

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# How Do Payment Error and Reason Codes Work?

Every payment outcome comes with a code: a structured value that explains why a transaction succeeded, failed, was rejected or was returned. Banks and providers return these codes in API responses, webhook payloads, response files and unpaid files, and each rail has its own code set defined in the relevant specification.

Raw codes are precise but not actionable on their own. The real work is mapping them into categories your systems and teams can respond to consistently: retry, fix the data, contact the customer, or stop.

## Where do reason codes come from?

- **API responses** return validation and processing errors immediately, usually with a code, a field reference and a human-readable message.
- **Webhooks and callbacks** carry the reason for each status change, for example why a DebiCheck authentication was declined or a collection was unpaid. See [webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks).
- **Response and unpaid files** in host-to-host integrations report a status and reason code per record, defined in the bank's file specification.

The same underlying event can surface with different codes in different channels, which is why a mapping layer matters.

## What are the main categories of codes?

Rather than memorising individual codes, think in categories:

### Validation errors

The instruction was rejected before processing: malformed fields, invalid branch codes, failed check-digit validation on the account number, missing mandatory data or a reference that breaches format rules. These fail the same way every time, so fix the data rather than retrying. Account validation is covered in [account validation and CDV](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv).

### Account errors

The instruction reached the paying bank but the account cannot be debited: account closed, account not found, account frozen, or account type not supported for the stream.

### Authorisation and mandate failures

The customer or their bank declined authority: a DebiCheck authentication rejected or expired, a mandate suspended or cancelled, or a collection that does not match the mandate terms.

### Unpaid reasons

The collection processed but was returned: insufficient funds, payment stopped by the account holder, or the debit disputed. These are business outcomes with rules about what you may do next; see [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

### System and technical errors

Timeouts, unavailable services and internal bank errors. These are usually retryable with backoff, as described in [retries and stuck payments](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments).

## How should you map codes into your system?

- **Store the raw code and the source** (which bank, channel and spec version) with every transaction. Never overwrite it with your internal interpretation only.
- **Map to internal categories** that drive behaviour: retryable, data fix required, customer action required, final failure, disputed.
- **Keep the mapping in configuration**, not scattered through code, so a new code from a spec update is a data change rather than a release.
- **Handle unknown codes safely**: route unmapped codes to a review queue with a sensible default (usually non-retryable) instead of failing or guessing.

DebiCheck has its own well-defined status and reason model, covered in [DebiCheck statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

## How do reason codes drive operations?

- **Dashboards**: unpaid and failure rates broken down by reason category show whether a spike is a data-quality problem, a customer-affordability trend or a bank incident.
- **Automation**: category-driven rules decide which failures re-queue automatically and which create work items.
- **Customer communication**: map codes to plain-language messages; never show a raw bank code to a customer as the explanation.
- **Disputes and audits**: the original code, with its source and timestamp, is part of the evidence trail described in [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).

Exact code values differ per bank and specification version, so always work from the current specification for your integration rather than a copied list.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# Logging, Data Masking and Audit Trails for Payments

Payment systems need two kinds of records that pull in opposite directions: enough detail to investigate any transaction months later, and strict limits on the sensitive data those records contain. Good logging answers "what happened and when" for every instruction; good masking ensures the answer never exposes card numbers, bank accounts or identity numbers to anyone who does not need them.

In South Africa this is shaped by two frameworks: PCI DSS for cardholder data and POPIA for personal information generally. Both apply to logs just as much as to databases.

## What should you log for every payment?

For each instruction, mandate and status change, record:

- Your unique reference and the provider's or bank's reference
- Timestamps for every submission, acknowledgement and status change
- The channel used: API endpoint and message ID, or file name and record number
- Each status transition with its [reason code](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes) and source
- Webhook events received, including delivery attempts and de-duplication decisions
- The credential or system identity that performed each action

This is what makes [stuck payment investigations](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments) and reconciliation breaks resolvable in minutes instead of days.

## What must be masked in logs?

### Card data (PCI DSS)

The full primary account number (PAN) may not appear in logs. Standard practice:

- **Truncate** the PAN when displayed or logged, showing at most the first six and last four digits.
- **Tokenise** where a persistent card identifier is needed, storing the token rather than the PAN.
- **Never log** the CVV, full magnetic stripe data or PIN under any circumstances; PCI DSS prohibits storing these even encrypted.

The requirements are covered in [PCI DSS](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss), and the mechanics of tokenisation in [tokenisation, encryption and hashing](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing).

### Personal information (POPIA)

Bank account numbers, South African ID numbers, passport numbers and contact details are personal information. In logs and error messages:

- Mask bank account numbers, showing only enough digits to distinguish records.
- Mask ID numbers; they are especially sensitive because they encode date of birth.
- Keep unmasked values in the systems designed to hold them, with access control, not in application logs, crash reports or third-party monitoring tools.

### Where masking commonly fails

- Raw request and response bodies logged verbatim on errors
- Debug logging left enabled in production
- Stack traces and exception messages containing input data
- Log shipping to external tools without field-level filtering

Mask at the point of logging, with a shared sanitisation layer, rather than trusting every developer to remember.

## What makes an audit trail different from a log?

A log records events for troubleshooting; an audit trail is an authoritative, tamper-evident history intended as evidence. For payments the critical audit trails are:

- **Mandate history**: creation, the exact terms accepted, authentication outcomes, amendments, suspensions and cancellations. When a debit order is [disputed](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments), you must be able to produce the mandate and its full history to defend the collection.
- **Instruction history**: every submission and status change, with references linking resubmissions to the original instruction.
- **Administrative actions**: who changed configuration, credentials, webhook URLs or mandate records, and when.

Audit trails should be append-only: corrections are new entries, never edits to old ones. Retain them for the period your bank, sponsor and regulators require, which for mandate-related records is typically measured in years after the last transaction.

## Practical checklist

- One correlation reference carried through every log line for a transaction
- Centralised, searchable log storage with access control and retention policies
- A sanitisation layer that truncates PANs and masks account and ID numbers before write
- Append-only audit tables for mandates, instructions and admin actions
- Periodic sampling of production logs to catch masking regressions
- Clock synchronisation across systems so timelines are trustworthy

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# How Does API Versioning and Change Management Work?

Payment interfaces change. Banks revise their file specification documents, providers release new API versions, and industry changes such as new DebiCheck rules or ISO 20022 migrations ripple through every integration built on them. Versioning is how those changes are introduced without breaking systems that move money every day.

For integrators, change management is not optional maintenance: a missed migration deadline can mean rejected files or failed API calls on a production collection run.

## How are payment APIs and file specs versioned?

- **API versioning** typically appears in the URL path or a header. Providers run multiple versions in parallel, introduce changes in a new version and give consumers a window to migrate before retiring old ones.
- **File specification versioning** works through numbered specification documents. The bank publishes a new version of the layout, communicates an effective date and migration window, and may require re-certification through UAT before you submit files in the new format. See [sandbox, UAT and production](https://docs.switchtransact.com/faq/payment-operations/sandbox-uat-and-production) for how certification fits in.

Providers also distinguish between the interface version and the underlying scheme rules: an industry rule change (for example to DebiCheck processing) can force a change even when the API surface looks the same.

## What counts as a breaking change?

Breaking changes require you to modify your integration:

- Removing or renaming fields, or changing a field's type, length or format
- Making an optional field mandatory
- Changing the meaning of a status or [reason code](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes)
- Changing authentication requirements, such as new signature algorithms or certificate standards
- Changing file layouts, record structures or delimiters

Non-breaking changes should be absorbed without a release:

- New optional fields in responses or webhook payloads
- New enum values, statuses or reason codes
- New endpoints or message types you do not use

## How do you build a tolerant integration?

The single most valuable defence is a tolerant parser:

- **Ignore unknown fields** rather than failing when a new one appears. Strict schema validation that rejects unrecognised fields turns every additive change into an outage.
- **Handle unknown enum values** gracefully: route an unrecognised status or reason code to a review queue with a safe default rather than crashing.
- **Do not depend on field order** in JSON, or on undocumented behaviour anywhere.
- **Pin the version explicitly** in requests and file headers, so behaviour changes only when you choose to migrate.

## How should you manage a migration?

1. **Track announcements**: subscribe to the provider's and bank's technical bulletins, and assign ownership so notices are actioned, not just received.
2. **Assess impact**: diff the new specification against the current one and identify affected fields, flows and mappings.
3. **Update and test in sandbox**, then complete any required UAT or re-certification in the bank's test environment.
4. **Deploy ahead of the deadline**, leaving buffer for issues; never plan to migrate on the retirement date itself.
5. **Migrate progressively where possible**: run the new version on a subset of traffic first, watching error rates and [webhook payloads](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) before switching fully.
6. **Keep a rollback path** during the migration window while both versions are supported.

## What should you have in place permanently?

- An inventory of every provider and bank interface you consume, with its current version and announced end-of-life dates
- Contract tests that validate your integration against the specification, run in CI
- A configuration-driven mapping for statuses and reason codes, so additive changes are data updates
- A change log of your own migrations, useful in incident reviews and audits, alongside the records described in [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Version upgrades handled this way become routine engineering work instead of emergencies.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# How Does Merchant Settlement Work and What Are Reserves?

Merchant settlement is the process of paying out the funds you have collected from customers, after clearing completes and fees are accounted for. Reserves are amounts a provider or acquirer holds back from settlement to cover the risk of refunds, chargebacks and unpaids that may arrive after the money has been paid out.

Both affect your cash flow directly, so it is worth understanding how settlement is batched, what can delay it, and why reserves exist.

## When do merchants receive settled funds?

Settlement timing depends on the payment method and the provider's settlement schedule:

- **Card payments** are typically settled in daily batches, one or more business days after the transactions were authorised and cleared.
- **Debit order collections** settle on the processing cycle for the action date, but providers may delay paying out collected funds until the main unpaid window has passed, because collections can be returned after settlement.
- **Real-time and EFT payments** follow the clearing cycles described in [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

Settlement is usually batched: all transactions for a period are grouped, fees are calculated, and a single amount is paid to your bank account with a settlement report that breaks the batch down to transaction level.

## What is gross vs net settlement?

- **Gross settlement** pays out the full transaction value, with fees invoiced or debited separately. This makes reconciliation simpler because bank credits match transaction totals.
- **Net settlement** deducts fees, refunds and adjustments before paying out. The settlement report is essential here, because the bank credit will not match the sum of transaction amounts on its own.

Confirm which model applies to your account and make sure your finance team reconciles against the settlement report, not just the bank statement.

## What can delay or reduce a settlement?

- Transactions still in an interim state, since many outcomes are [asynchronous](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses).
- Unpaids, refunds and chargebacks deducted from the batch.
- Public holidays and weekend cut-offs shifting value dates, as covered in [cut-off times and value dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).
- Risk reviews or verification requests on unusual volumes.
- Bank account detail changes, which providers verify before redirecting funds.

## What is a rolling reserve?

A rolling reserve is a percentage of each settlement that the provider holds for a defined period before releasing it. For example, a portion of each batch might be held and released on a rolling basis some weeks or months later. The reserve exists because liabilities can arrive after payout:

- Card [chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks) can be raised long after the sale.
- Debit order disputes can reverse collections that were already settled.
- Refund obligations remain if a business stops trading before delivering goods or services.

### What other reserve types exist?

- **Fixed or upfront reserve**: a set amount held when the account is opened, common for higher-risk industries.
- **Capped rolling reserve**: a rolling reserve that stops growing once it reaches an agreed ceiling.
- **Conditional holds**: temporary holds on specific batches during a risk investigation.

## How are reserve levels decided?

Providers set reserves based on the risk profile of the business, including industry, delivery timelines, chargeback and unpaid history, and processing volumes. Reserves are typically reviewed over time; a clean processing history is the strongest argument for reducing or removing a reserve.

## How should you manage settlement operationally?

- Reconcile every settlement batch to transaction level on the day it arrives.
- Track reserve balances and release dates so cash flow forecasts are accurate.
- Monitor unpaid and chargeback rates, since they drive both deductions and reserve levels.
- Query discrepancies quickly, with the batch reference and affected transaction references to hand.

For related topics, see the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# Why Are Payment Statuses Asynchronous?

Many South African payment outcomes are not known at the moment you submit the transaction. A debit order submitted today may only show its final result days later, a DebiCheck mandate authentication may come back in about two minutes or by end of the next business day, and a batch file only produces its response files on the next processing cycle.

Systems that assume an instant yes-or-no answer break in production. Designing for asynchronous statuses from the start avoids duplicate collections, misleading customer messages and reconciliation gaps.

## Why are payment outcomes delayed?

Different rails confirm at different speeds because of how clearing works:

- **Debit order collections** are processed in batch cycles. The instruction is accepted for processing first, and unpaids (insufficient funds, closed accounts, disputes) flow back over the following days. See [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).
- **DebiCheck mandate authentication** depends on the customer. A real-time authentication may complete in about 120 seconds, while a delayed authentication gives the customer until end of the next business day to respond on their banking channel. See [mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication).
- **Batch file submissions** produce acknowledgement files and then response or unpaid files on a schedule, not per request.
- **Card payments** authorise in real time, but settlement, refunds and chargebacks arrive later.

## What do interim statuses mean?

A well-designed status model distinguishes between interim and final states:

- **Interim statuses** such as submitted, accepted for processing, pending authentication or in progress mean the outcome is not yet known. The transaction may still succeed or fail.
- **Final statuses** such as successful, failed, rejected or disputed mean processing has concluded, although some final states (like a successful collection) can still be reversed later by an unpaid or dispute.

Treat an interim status as exactly that: do not release goods, mark invoices as paid or trigger downstream fulfilment on a pending state unless your business model accepts that risk. The general status model is covered in [payment statuses and references](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references).

## How should your system handle asynchronous outcomes?

### Store a status per instruction, not a single flag

Keep a status history for every payment instruction, with timestamps and the reason code for each change. This supports queries, disputes and reconciliation.

### Consume updates from webhooks and files

Final outcomes arrive through [webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) or through response and unpaid files. Build your processing around these updates rather than polling alone, and use polling or status queries as a safety net for missed events.

### Design business logic around state transitions

- Only act on transitions you have defined, for example pending to successful, or successful to unpaid.
- Handle out-of-order delivery: an unpaid notification might arrive after you have already reconciled the collection as successful.
- Make handlers idempotent so a repeated notification does not double-process, as explained in [idempotency and duplicates](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates).

### Set expectations with customers and staff

- Show customers a pending state honestly, with an indication of when the outcome will be known.
- Give operations teams a view of transactions that have been pending longer than expected, so stuck items are investigated rather than discovered at month end. See [retries and stuck payments](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments).

## What time frames should you plan for?

| Flow                               | Typical outcome timing                                 |
| ---------------------------------- | ------------------------------------------------------ |
| Card authorisation                 | Real time                                              |
| DebiCheck real-time authentication | About 120 seconds                                      |
| DebiCheck delayed authentication   | Up to end of next business day                         |
| Debit order collection result      | Interim on submission; unpaids over the following days |
| Batch file response files          | On the next processing cycle after cut-off             |

Exact windows depend on the bank, stream and cut-off, so confirm them for your integration rather than hard-coding assumptions.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# What Are Payment Webhooks and Callbacks?

Webhooks and callbacks are how a payment provider tells your system that something happened: a DebiCheck mandate was authenticated, a collection was unpaid, a card payment settled. Instead of your system repeatedly asking for updates, the provider sends an HTTP request to an endpoint you host whenever a status changes.

Because so many South African payment outcomes are [asynchronous](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses), callbacks are usually the primary channel for final results. Getting the receiving side right is one of the most important parts of a payments integration.

## How do payment webhooks work?

1. You register a callback URL with the provider, typically per environment.
2. When a mandate or payment changes state, the provider sends an HTTPS POST to your URL with a structured payload: a message ID, the event type, your original reference and the new status with its reason code.
3. Your endpoint acknowledges receipt, usually with an HTTP 200 response.
4. If the provider does not receive an acknowledgement, it retries delivery on a backoff schedule for a defined period.

## How do you verify that a webhook is authentic?

Never trust an inbound request just because it arrived at your endpoint. Verify it using the mechanisms your provider supports:

- **Request signatures**: the provider signs the payload (for example with an HMAC or asymmetric signature) and you verify the signature against the raw request body before parsing it.
- **Mutual TLS (mTLS)**: both sides present certificates, so only the provider can establish a connection.
- **IP allow-listing**: a supporting control, useful alongside signatures but weak on its own.

Also check timestamps to reject stale or replayed messages. Signature and authentication mechanics are covered in more depth in [API authentication and signatures](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures).

## How should your endpoint behave?

- **Acknowledge fast**: validate the signature, persist the raw event, return 200, and do the heavy processing asynchronously. Slow endpoints cause timeouts and unnecessary retries.
- **De-duplicate by message ID**: retries mean you will receive the same event more than once. Record processed message IDs and ignore repeats, as described in [idempotency and duplicates](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates).
- **Handle out-of-order events**: an earlier status may arrive after a later one. Apply updates based on your state model, not arrival order.
- **Fail safely**: if your processing fails after acknowledgement, you own the recovery. If you reject the request, expect a retry.

## What happens if you miss webhooks?

Endpoints go down, deployments break routes and certificates expire. Plan for gaps:

- Monitor for delivery failures and alert on sustained error rates.
- Use the provider's status query API to reconcile any payment still pending beyond its expected window.
- Where the provider offers event replay or a redelivery mechanism, know how to trigger it.
- Reconcile daily against reports or response files so missed events surface as breaks, as covered in [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

## Webhooks vs polling: which should you use?

| Aspect      | Webhooks                            | Polling                                 |
| ----------- | ----------------------------------- | --------------------------------------- |
| Latency     | Near real time                      | Depends on poll interval                |
| Load        | One request per event               | Constant requests, mostly empty         |
| Reliability | Needs retry handling and monitoring | Simple, but can miss short-lived states |
| Best use    | Primary channel for status updates  | Safety net and gap recovery             |

The practical answer is both: webhooks as the primary channel, with scheduled status queries as the backstop for anything still pending.

## Checklist for a production-ready webhook consumer

- HTTPS endpoint with signature or mTLS verification
- Raw payload persisted before processing
- Acknowledgement within the provider's timeout
- De-duplication by message ID
- Idempotent, asynchronous processing
- Alerting on failures and a reconciliation backstop

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# What Is Idempotency and How Do You Prevent Duplicate Payments?

An operation is idempotent when performing it more than once has the same effect as performing it once. In payments, idempotency is what stops a network timeout, a double-clicked button or an automated retry from debiting a customer twice or paying a beneficiary twice.

Duplicates are one of the most damaging operational failures in payments: they create refund work, disputes, complaints and reconciliation breaks. The defences are simple in principle and worth building properly.

## Where do duplicate payments come from?

- **Timeouts and retries**: your system submits a collection, the response times out, and a retry submits it again. The first request may have succeeded even though you never saw the response.
- **User behaviour**: a customer clicks pay twice, or an operator resubmits a batch that already went through.
- **Duplicate webhook processing**: the same status event is delivered more than once and your handler acts on it twice.
- **File resubmission**: a batch file is uploaded twice, or a corrected file overlaps with the original.

Notice the common thread: the retry itself is usually correct behaviour. The problem is retrying without a way for the receiving system to recognise the repeat.

## How do idempotency keys work?

An idempotency key is a unique value your system generates for each logical operation and sends with the request. The provider stores the key with the outcome of the first attempt:

1. You generate a unique key for the instruction, for example when the collection is created in your system.
2. You send the key with the API request.
3. If the request is retried with the same key, the provider returns the original result instead of processing it again.
4. A genuinely new operation gets a new key.

The key must be tied to the business operation, not the HTTP attempt. Generating a fresh key on every retry defeats the purpose entirely.

## Why do unique client references matter?

Even where a formal idempotency key is not part of the interface, a unique client reference per instruction achieves much of the same protection:

- Banks and providers can reject or flag instructions that reuse a reference.
- Duplicate collections in a batch file can be detected before processing.
- Reconciliation can match every response, unpaid and settlement entry back to exactly one instruction, as covered in [payment statuses and references](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references).

Rules of thumb:

- Generate one reference per payment instruction and never reuse it, even for a resubmission of a failed collection: a resubmission is a new instruction referencing the old one.
- Persist the reference before submitting, so a crash between submission and confirmation still leaves you able to query the outcome.

## How do you de-duplicate inbound events?

Idempotency applies to what you receive as well as what you send. [Webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) are delivered at-least-once, so:

- Record the message ID of every processed event and skip repeats.
- Make status updates idempotent: setting a payment to successful twice should be harmless.
- Apply state-transition rules so a replayed older event cannot overwrite a newer status.

## What about batch files?

For [batch file integrations](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis), duplicate protection works at two levels:

- **File level**: unique file names or sequence numbers, so the bank can reject a file it has already received. Verify acknowledgement files before assuming a submission needs to be resent.
- **Record level**: unique instruction references within and across files, so an overlapping resubmission cannot debit the same customer twice.

## A practical checklist

- One unique reference or idempotency key per logical payment operation, generated and persisted before submission.
- Retries always reuse the original key or reference.
- Never resubmit on timeout without first querying the status of the original attempt, as discussed in [retries and stuck payments](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments).
- De-duplicate inbound events by message ID.
- Alert on duplicate references detected anywhere in the pipeline.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# How Do You Handle Payment Retries and Stuck Payments?

Retries are unavoidable in payments: networks time out, endpoints go down and batch windows are missed. The difference between a resilient integration and a dangerous one is whether retries are safe, deliberate and informed by the actual status of the original attempt.

A stuck payment is one that has been in an interim state longer than expected. Since many South African payment outcomes are [asynchronous by design](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses), the first question is always whether a payment is genuinely stuck or simply still within its normal processing window.

## When is it safe to retry a payment?

Distinguish between technical failures and business outcomes:

- **Safe to retry**: connection failures, timeouts before submission was confirmed, HTTP 5xx responses, and rejected requests where the error clearly indicates the instruction was never accepted.
- **Retry only after querying**: timeouts after submission may mean the instruction was processed even though you never received the response. Query the status by your unique reference before resubmitting, and always reuse the same reference or idempotency key so a duplicate cannot slip through. See [idempotency and duplicates](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates).
- **Do not blindly retry**: validation errors will fail identically every time, and definitive business outcomes such as insufficient funds, account closed or authentication declined are results, not errors. Resubmitting a failed debit order collection is a business decision governed by the mandate, not an automatic technical retry. See [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries) for how DebiCheck handles re-presentment.

## What does a good retry strategy look like?

- **Exponential backoff with jitter**: space retries out increasingly, with randomness so a recovering system is not hammered by synchronised retries.
- **A retry limit**: after a defined number of attempts, stop and raise the item for investigation rather than retrying forever.
- **Idempotent submissions**: the same key or client reference on every attempt.
- **Classification before retry**: map the [error or reason code](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes) to retryable or non-retryable before acting.
- **Respect cut-offs**: a retry after the processing cut-off may land in the next cycle with a later action date, as covered in [cut-off times and value dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).

## How do you identify a stuck payment?

Define an expected-outcome window per flow, then alert on anything that exceeds it:

- A DebiCheck real-time authentication still pending well beyond its short window.
- A delayed authentication with no result after end of the next business day.
- A batch file submitted with no acknowledgement file by the expected time.
- A collection with no response or unpaid outcome after the normal cycle.
- A card payment authorised but never captured or settled.

An operations dashboard listing every transaction pending beyond its window, ordered by age, turns stuck payments from month-end surprises into same-day investigations.

## How do you investigate a stuck payment?

1. **Check your own pipeline first**: was the instruction actually submitted, acknowledged and recorded? Logs and audit trails answer this quickly if they are structured well, as described in [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
2. **Check for missed events**: a [webhook](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) may have failed delivery while the payment completed normally. Query the provider's status API by your reference.
3. **Check acknowledgement and response files** for batch submissions: a missing acknowledgement means the file may never have arrived; a rejection in the acknowledgement explains why nothing followed.
4. **Escalate with details**: when querying the provider or bank, supply your unique reference, submission timestamp, file name or message ID and the last known status. Precise references shorten investigations dramatically.

## What should you never do with a stuck payment?

- Resubmit it without confirming the status of the original.
- Mark it as failed in your system while the rail may still deliver a success.
- Refund a customer for a payment that may still settle, without recording the linkage.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# Which Payment Integration Model Should You Choose?

There is no single right way to integrate payments. A sole trader sending payment links has very different needs from an insurer submitting hundreds of thousands of debit orders per month. Integration models sit on a spectrum from no-code to deeply technical, and the right choice depends on your volumes, your team and how much control you need over the payment experience.

This page compares the common models and gives a framework for choosing between them.

## What are the main integration models?

| Model                      | Technical effort | Best for                                          |
| -------------------------- | ---------------- | ------------------------------------------------- |
| Payment links              | None             | Invoicing, once-off payments, small volumes       |
| Platform plugins           | Low              | Standard e-commerce platforms                     |
| Hosted checkout / redirect | Low to medium    | Online stores wanting PCI scope reduction         |
| Embedded components        | Medium           | Custom checkouts with provider-hosted card fields |
| Direct API                 | Medium to high   | Real-time flows, custom products, automation      |
| Host-to-host batch files   | High             | Very high volumes of collections and payouts      |

### Payment links

A [payment link](https://docs.switchtransact.com/faq/accepting-payments/payment-links) is a URL you share by email, SMS or WhatsApp. The customer pays on a page hosted by the provider. No development is needed, which makes links the fastest way to start accepting payments.

### Plugins and platform integrations

Pre-built modules for e-commerce platforms handle checkout, callbacks and reconciliation with configuration rather than code. Suitable when your store runs on a supported platform and you do not need custom payment flows.

### Hosted checkout and embedded components

With a hosted checkout, the customer is redirected to the provider's payment page and returned afterwards. Embedded components keep the customer on your site while sensitive fields are hosted by the provider. Both dramatically reduce your [PCI DSS](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss) scope because card data never touches your servers. The trade-offs are compared in [hosted, embedded and API checkout](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout).

### Direct API integration

Your systems call the provider's APIs to create mandates, submit collections, initiate payouts and query statuses, and receive results via [webhooks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks). APIs give real-time feedback and full control, at the cost of building and operating the integration: authentication, retries, idempotency and status handling all become your responsibility.

### Host-to-host batch files

Fixed-format or ISO 20022 files exchanged with the bank or provider over secure channels such as SFTP, on defined submission cut-offs with acknowledgement and response files. This model suits organisations processing very large volumes of debit orders or payouts on predictable cycles. The detailed comparison lives in [batch files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis), and for DebiCheck specifically see [API vs host-to-host](https://docs.switchtransact.com/faq/debicheck/api-vs-host-to-host).

## How do you choose a model?

Work through these questions:

- **Volume and cadence**: occasional payments favour links and hosted pages; large recurring collection runs favour APIs or files.
- **Latency**: do you need a result while the customer waits (API), or is next-cycle confirmation acceptable (files)?
- **Team capability**: APIs and host-to-host integrations need developers to build them and operations staff to monitor them. No-code models need neither.
- **Compliance appetite**: hosted and embedded models keep card data off your systems; direct card APIs pull you into much heavier PCI DSS obligations.
- **Control**: the more you customise the experience and automate downstream processes, the further you move toward APIs.

## Can you combine models?

Yes, and most growing businesses do. A common pattern is payment links for ad-hoc invoices, a hosted checkout for the online store, and an API integration for recurring debit order collections. Some large collectors run APIs for real-time DebiCheck mandate authentication and host-to-host files for bulk collections.

Whichever mix you choose, the operational fundamentals stay the same: unique references, [idempotent submissions](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates), status handling and daily reconciliation.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# Batch Files vs APIs: Which Integration Is Right for You?

South African banks and payment providers generally support two integration styles for collections and payouts: real-time APIs and host-to-host batch files. Both can carry the same payment instructions, such as DebiCheck mandates, EFT debit orders and credit payouts, but they differ in latency, operating model and the skills needed to run them.

Most banks publish both an API specification and a file specification for the same streams, so this is a genuine architectural choice rather than a forced one.

## How does a batch file integration work?

In a host-to-host model, you exchange structured files with the bank or provider over a secure channel such as SFTP or Connect\:Direct. Files follow a fixed-format or ISO 20022 layout defined in the bank's specification document.

A typical cycle looks like this:

1. You generate a file of instructions with a unique file name or sequence number and unique references per record.
2. You transmit it before the submission cut-off for the processing cycle.
3. The bank returns an **acknowledgement file** confirming the file was received and passed structural validation, or rejecting it with reasons.
4. **Response files** follow on the processing cycle, reporting per-instruction outcomes.
5. **Unpaid files** arrive over subsequent days for collections that are returned.

Missing a cut-off moves the whole file to the next cycle, so [cut-off times and value dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates) drive the operating rhythm.

## How does an API integration work?

With an API, your system submits instructions individually or in small batches over HTTPS, authenticated as described in [API authentication and signatures](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures). Validation results come back immediately in the response, and asynchronous outcomes, such as DebiCheck authentication results and collection unpaids, are delivered through [webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) or status queries.

## Batch files vs APIs: side-by-side

| Aspect                             | Batch files (host-to-host)                           | APIs                                           |
| ---------------------------------- | ---------------------------------------------------- | ---------------------------------------------- |
| Latency                            | Next cycle; outcomes via response files              | Immediate validation; near real-time updates   |
| Volume sweet spot                  | Very high volumes on predictable cycles              | Low to high volumes, event-driven              |
| Real-time DebiCheck authentication | Not suited (delayed flows only)                      | Supported, with results in about 120 seconds   |
| Error feedback                     | Acknowledgement and response files after submission  | Field-level validation errors on the request   |
| Transport                          | SFTP / Connect\:Direct with encryption               | HTTPS with OAuth, API keys or mTLS             |
| Operational model                  | Scheduled jobs, file monitoring, cut-off management  | Service monitoring, webhook handling, retries  |
| Change management                  | File spec versions with migration windows            | API versions, usually with overlapping support |
| Recovery from failure              | Resend or correct files; file-level duplicate checks | Idempotent retries per instruction             |

## When are batch files the better fit?

- You submit large, predictable runs, for example monthly premium collections across hundreds of thousands of policies.
- Your outcomes are naturally cyclical and next-day results are acceptable.
- Your organisation already operates file-based bank integrations and has the scheduling, monitoring and support processes in place.

## When are APIs the better fit?

- You need real-time DebiCheck mandate authentication while the customer is on the phone or in your app.
- Instructions are created continuously rather than in periodic runs.
- You want immediate validation feedback instead of discovering errors in a response file the next day.
- Lower latency matters for customer experience or downstream automation.

## Can you use both?

Yes, and larger collectors often do: APIs for real-time mandate authentication and ad-hoc instructions, files for bulk collection runs. The DebiCheck-specific view of this decision is covered in [API vs host-to-host for DebiCheck](https://docs.switchtransact.com/faq/debicheck/api-vs-host-to-host).

Whichever channel you use, the same disciplines apply: unique references per instruction, [duplicate protection](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates) at file and record level, structured handling of [reason codes](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes) and daily reconciliation of outcomes.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# How Do API Authentication and Request Signatures Work?

Payment APIs move money, so proving who is calling them, and that the message has not been altered in transit, is non-negotiable. South African banks and payment providers typically layer several mechanisms: transport security, caller authentication and message-level signatures.

Understanding what each layer protects against helps you implement them correctly and troubleshoot failures such as expired tokens, certificate mismatches and signature errors.

## What authentication methods do payment APIs use?

### API keys

A static secret issued per merchant and environment, sent with each request. Simple to implement, but the key is long-lived, so it must be stored in a secrets manager, never committed to source control, and rotated on a schedule. Keys for sandbox and production must never be interchangeable; see [sandbox, UAT and production](https://docs.switchtransact.com/faq/payment-operations/sandbox-uat-and-production).

### OAuth 2.0 client credentials

Your system authenticates with a client ID and secret to obtain a short-lived access token, then presents the token on API calls. This is the dominant pattern for bank corporate APIs. Practical points:

- Cache tokens and refresh before expiry rather than requesting a new token per call.
- Handle rejected-token responses by refreshing once and retrying, not by looping.
- Treat the client secret with the same care as an API key.

### Mutual TLS (mTLS)

Standard TLS proves the server's identity to you; mutual TLS also proves your identity to the server using a client certificate. Banks commonly require mTLS for host-to-host channels and high-value APIs. Certificates expire, so track expiry dates and renew ahead of time; an expired client certificate is a classic cause of sudden total integration failure.

## What do request signatures add?

Transport security protects data in transit, but it does not prove that the message body itself is authentic and unmodified end to end. Message signatures close that gap:

- The sender computes a signature over the request body (and often selected headers and a timestamp) using a shared secret (HMAC) or a private key (asymmetric signing).
- The receiver recomputes or verifies the signature before trusting the payload.
- A timestamp inside the signed content lets the receiver reject stale messages, defending against replay attacks where an old, valid request is resent.

Signatures matter in both directions: providers verify your signed instructions, and you must verify the signatures on inbound [webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks) before acting on them. Always verify against the raw request body exactly as received; re-serialising JSON before verification is a common cause of spurious signature failures.

## How do these layers fit together?

| Layer             | Proves                                             | Typical mechanism                           |
| ----------------- | -------------------------------------------------- | ------------------------------------------- |
| Transport         | The channel is encrypted and the server is genuine | TLS                                         |
| Client identity   | The caller is you                                  | API key, OAuth token, mTLS certificate      |
| Message integrity | The payload was not altered and is fresh           | HMAC or asymmetric signature with timestamp |

High-assurance integrations use all three. The cryptographic building blocks are explained in [tokenisation, encryption and hashing](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing).

## How should you manage credentials operationally?

- Store secrets and private keys in a secrets manager with restricted access, and log access to them.
- Use separate credentials per environment and per system, so a leaked credential has a small blast radius.
- Rotate keys, secrets and certificates on a schedule, and rehearse rotation so it is routine rather than risky.
- Monitor authentication failures: a spike can indicate an expired credential, a clock-drift problem breaking timestamp validation, or an attack.
- Revoke immediately on suspicion of compromise and follow your [payment incident response](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-incident-response) process.

## Common authentication failures and causes

- **401 or invalid token**: expired or wrongly scoped OAuth token, or wrong environment credentials.
- **TLS handshake failure**: expired or untrusted client certificate, or unsupported TLS version.
- **Signature mismatch**: body modified by middleware, wrong key version, or re-serialised payload.
- **Replay rejection**: server clock drift pushing timestamps outside the allowed window.

Back to the [Payment Operations hub](https://docs.switchtransact.com/faq/payment-operations).


# Payment Operations and Integrations

Practical answers for teams running and integrating payments, covering settlement and reconciliation, webhooks and callbacks, integration models and day-to-day operational hygiene.

## Topics in this section

- [Clearing, Settlement and Reconciliation Explained](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation)
- [How Does Merchant Settlement Work and What Are Reserves?](https://docs.switchtransact.com/faq/payment-operations/merchant-settlement-and-reserves)
- [Why Are Payment Statuses Asynchronous?](https://docs.switchtransact.com/faq/payment-operations/asynchronous-payment-statuses)
- [What Are Payment Webhooks and Callbacks?](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks)
- [What Is Idempotency and How Do You Prevent Duplicate Payments?](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates)
- [How Do You Handle Payment Retries and Stuck Payments?](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments)
- [Which Payment Integration Model Should You Choose?](https://docs.switchtransact.com/faq/payment-operations/payment-integration-models)
- [Batch Files vs APIs: Which Integration Is Right for You?](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis)
- [How Do API Authentication and Request Signatures Work?](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures)
- [Sandbox, UAT and Production Environments Explained](https://docs.switchtransact.com/faq/payment-operations/sandbox-uat-and-production)
- [How Do Payment Error and Reason Codes Work?](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes)
- [Logging, Data Masking and Audit Trails for Payments](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)
- [How Does API Versioning and Change Management Work?](https://docs.switchtransact.com/faq/payment-operations/api-versioning-and-change-management)


# How Do QR Code Payments Work?

A QR code payment lets a customer pay by scanning a printed or on-screen code with their phone instead of tapping a card or entering card details. The QR code carries the information the payment app needs, such as the merchant identifier and, in some cases, the amount, so the customer can confirm the payment in a few taps.

In South Africa, QR payments became familiar through apps such as SnapScan and Zapper, and most major banking apps now include a scan-to-pay feature. Interoperability initiatives in the local payments industry mean that many banking apps can scan third-party QR codes, so a single code at the till can often be paid from several different apps.

## How Does a QR Code Payment Work?

A typical QR payment follows these steps:

1. The merchant displays a QR code at the point of sale, on an invoice or on a checkout screen.
2. The customer scans the code with a payment app or their banking app.
3. The app reads the merchant details from the code and shows the payment to the customer.
4. The customer confirms the amount and authenticates in the app.
5. The merchant receives a payment notification and the transaction settles through the normal card or account rails behind the scenes.

The customer's card or account details are never handed to the merchant, which reduces the risk of card data being compromised at the point of sale.

## What Is the Difference Between Static and Dynamic QR Codes?

| Feature        | Static QR code                        | Dynamic QR code                        |
| -------------- | ------------------------------------- | -------------------------------------- |
| Content        | Fixed merchant identifier             | Generated per transaction              |
| Amount         | Customer usually types it in          | Embedded in the code                   |
| Display        | Printed sticker, table talker, poster | Screen, terminal or invoice            |
| Reconciliation | Harder to match to a sale             | Carries a unique reference             |
| Best for       | Small merchants, tips, donations      | Retail checkouts, invoices, e-commerce |

Static codes are cheap and simple: a printed sticker works indefinitely. Dynamic codes are generated for each sale, so the amount and a unique reference are baked in, which reduces keying errors and makes reconciliation far easier.

## Which QR Payment Apps Do South African Customers Use?

- **SnapScan** and **Zapper**, the well-known standalone scan-to-pay apps.
- **Banking app scan-to-pay** features built into the major banks' mobile apps.
- **Wallet apps** that include QR scanning alongside other payment features.

Because of interoperability work in the industry, a merchant no longer needs a separate code for every app. Many banking apps can scan and pay codes issued by third-party providers, and interoperable schemes take this further — see [What Is QR Plus?](https://docs.switchtransact.com/faq/other-payment-methods/qr-plus) for how one code can be paid across participating apps.

## Why Would a Merchant Accept QR Payments?

- No card machine is required — a printed code or a screen is enough.
- Setup is quick and hardware costs are low.
- The customer authenticates in their own app, so no card data touches the merchant.
- Dynamic codes carry references that simplify reconciliation.
- QR works in person, on invoices and in online checkouts alike.

QR payments suit market stalls, delivery drivers, restaurants and service businesses, and they complement card acceptance rather than replacing it. For a broader look at in-person options, see [How Do You Accept In-Person Payments?](https://docs.switchtransact.com/faq/accepting-payments/accept-in-person-payments).

## What Should Merchants Consider Before Adding QR?

- **Reconciliation.** Prefer dynamic codes with unique references where volumes justify it.
- **Coverage.** Check which apps can pay your provider's codes so customers are not turned away.
- **Settlement.** Confirm how and when QR transactions settle to your bank account.
- **Fees.** Understand the transaction fee structure before committing, as it differs by provider.
- **Display quality.** Damaged or poorly printed codes fail to scan; keep codes clean and well lit.

## Tips

- Place static codes where customers can scan them without reaching or queuing.
- Use dynamic QR codes at checkout so the amount and reference are embedded.
- Train staff to confirm the payment notification before releasing goods.
- Offer QR alongside cards and other methods rather than as the only option.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [What Is QR Plus?](https://docs.switchtransact.com/faq/other-payment-methods/qr-plus)
- [How Do You Accept In-Person Payments?](https://docs.switchtransact.com/faq/accepting-payments/accept-in-person-payments)
- [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)
- [What Are Digital Wallets?](https://docs.switchtransact.com/faq/card-payments/digital-wallets)


# What Is QR Plus?

QR Plus is an interoperable QR payments capability that allows a single merchant QR code to be paid by multiple participating banking and wallet apps. Instead of the merchant displaying a different code for every payment app, one code works across the participating ecosystem, and the transaction routes between the customer's app and the merchant's provider behind the scenes.

Interoperability solves the biggest practical problem with QR payments: fragmentation. In the early years of scan-to-pay in South Africa, each app used its own codes, so a merchant needed a cluttered row of stickers at the till. Interoperable QR consolidates this into a single code and a single settlement relationship for the merchant.

## How Does an Interoperable QR Payment Work?

1. The merchant displays one QR Plus-enabled code, either static or generated per transaction.
2. The customer scans it with any participating banking or wallet app.
3. The scheme routes the transaction from the customer's app or wallet to the merchant's acquiring provider.
4. The customer confirms and authenticates in their own app.
5. The merchant receives confirmation and settles through their existing provider relationship.

The customer does not need to know or care which provider issued the code, and the merchant does not need to know which app the customer used. Routing across participating wallets is handled by the scheme.

## How Is QR Plus Different from Ordinary QR Codes?

| Aspect                  | Single-app QR          | Interoperable QR (QR Plus)    |
| ----------------------- | ---------------------- | ----------------------------- |
| Codes displayed         | One per payment app    | One code for all participants |
| Customer apps supported | Only the issuing app   | Any participating app or bank |
| Merchant relationships  | Potentially several    | One provider, one settlement  |
| Reconciliation          | Split across providers | Consolidated                  |
| Counter space           | A row of stickers      | A single code                 |

For the underlying mechanics of QR payments — including static versus dynamic codes — see [How Do QR Code Payments Work?](https://docs.switchtransact.com/faq/other-payment-methods/qr-code-payments).

## Why Does Interoperability Matter for Merchants?

- **Fewer lost sales.** Customers are not turned away because their preferred app is not supported.
- **Simpler operations.** One code to display, one provider to reconcile with, one settlement flow.
- **Lower friction at the till.** Staff do not need to direct customers to the "right" sticker.
- **Future-proofing.** As more apps and banks join the scheme, coverage grows without the merchant changing anything.

Interoperable QR fits the broader direction of the South African payments industry, which is moving toward shared, interoperable rails — the same thinking behind [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) for instant account-to-account payments.

## Which Apps Can Pay a QR Plus Code?

Participation depends on which banks and wallet providers have joined the scheme at any given time, and coverage continues to expand. As a rule of thumb:

- Most major banking apps with scan-to-pay features participate in interoperable QR arrangements.
- Established scan-to-pay apps increasingly support codes issued by other providers.
- Your payments provider can confirm the current list of participating apps for the codes they issue.

Because participation changes over time, avoid printing marketing material that names specific apps; instead, describe the code as payable "with participating banking and payment apps".

## What Should Merchants Check Before Adopting Interoperable QR?

- **Settlement terms.** Confirm when funds from interoperable transactions reach your account.
- **References.** Use dynamic codes where possible so every payment carries a unique reference.
- **Refund handling.** Ask how refunds work when the customer paid from a different app than the one that issued the code.
- **Reporting.** Check that your provider's reporting shows which wallet or bank the payment came from, which helps with queries.

## Tips

- Replace multiple app-specific stickers with a single interoperable code where your provider supports it.
- Keep the code visible and undamaged; a failed scan usually means a switch to cash or card.
- Reconcile QR settlements daily using the payment references, just as you would card settlements.
- Review participating-app coverage with your provider periodically as the scheme grows.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [How Do QR Code Payments Work?](https://docs.switchtransact.com/faq/other-payment-methods/qr-code-payments)
- [What Is PayShap?](https://docs.switchtransact.com/faq/bank-transfers/payshap)
- [How Do You Accept In-Person Payments?](https://docs.switchtransact.com/faq/accepting-payments/accept-in-person-payments)


# What Is Instant EFT and Open Banking?

Instant EFT and open banking are both ways for a customer to pay a merchant directly from their bank account during checkout, without using a card. The customer selects "pay by bank", authenticates with their own bank, and the merchant receives near-immediate confirmation that the payment has been made.

The two terms describe different generations of the same idea. Instant EFT services grew up before South African banks offered payment APIs, so they worked by guiding the customer through their internet banking inside the checkout flow. Open banking replaces that approach with bank-supported APIs, and the industry — with the South African Reserve Bank's (SARB) support — is moving toward a regulated open banking framework.

## How Does Instant EFT Work?

A traditional instant EFT service works like this:

1. The customer chooses instant EFT at checkout and selects their bank.
2. The customer enters their internet banking credentials into the service's interface.
3. The service initiates an EFT from the customer's account with the payment details pre-filled.
4. The customer approves the payment, often with their bank's usual verification step.
5. The merchant receives confirmation and can release goods or services immediately, even though interbank settlement follows later.

This model has a screen-scraping heritage: the service effectively logs into the customer's internet banking on their behalf. It solved a real problem — merchants no longer had to wait days for a manual EFT and proof of payment — but it requires customers to share banking credentials with a third party, which banks have long cautioned against.

## How Is Open Banking Different?

Open banking, sometimes called pay-by-bank or API-based payment initiation, achieves the same outcome through official channels:

- The payment is initiated through APIs provided or sanctioned by the bank.
- The customer authenticates directly with their bank, typically in the banking app, and never shares credentials with a third party.
- Consent is explicit, scoped to the specific payment, and visible to the bank.

| Aspect               | Instant EFT (screen-scraping)                        | Open banking (API-based)                         |
| -------------------- | ---------------------------------------------------- | ------------------------------------------------ |
| Credential sharing   | Customer enters bank login into a third-party screen | Customer authenticates with their own bank       |
| Bank involvement     | Bank often unaware a third party is in the flow      | Bank participates via APIs                       |
| Consent model        | Implied by completing the flow                       | Explicit, per-payment consent                    |
| Regulatory direction | Being phased toward regulated models                 | Aligned with where SARB and industry are heading |

## Where Does PayShap Request to Pay Fit In?

PayShap Request to Pay is a bank-native alternative for collecting account-to-account payments. Instead of the customer pushing a payment from checkout, the merchant sends a payment request to the customer's bank, and the customer approves it in their banking app. It delivers a similar "pay from my bank account" experience over the PayShap instant rail, without any credential sharing.

See [What Is PayShap?](https://docs.switchtransact.com/faq/bank-transfers/payshap) and [What Are ShapIDs and Request to Pay?](https://docs.switchtransact.com/faq/bank-transfers/shapids-and-request-to-pay) for how these work.

## Why Offer Pay-by-Bank at Checkout?

- **Reaches customers without cards** or who prefer not to use them online.
- **Near-immediate confirmation**, unlike traditional EFT where merchants wait for proof of payment.
- **No card data** in the flow, which reduces card fraud exposure.
- **Push payments are hard to dispute**, since the customer actively authorises each one — there is no chargeback mechanism equivalent to cards.

The main trade-offs are checkout friction (the customer must authenticate with their bank) and the fact that refunds must be processed as separate payouts rather than reversals.

## What Should Merchants Consider?

- Prefer API-based or bank-native options (open banking, PayShap Request to Pay) over credential-sharing flows where available.
- Confirm how quickly confirmed payments settle to your account and how references are carried for reconciliation.
- Plan a refund process, since account-to-account payments cannot simply be voided.
- Treat pay-by-bank as one option in a broader mix — see [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods).

## Tips

- Label the option clearly at checkout so customers know they will authenticate with their bank.
- Show supported banks upfront to avoid abandoned payments.
- Reconcile using the payment reference rather than waiting for proof-of-payment emails.
- Watch industry developments: as regulated open banking matures in South Africa, API-based options will continue to displace screen-scraping.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [What Is PayShap?](https://docs.switchtransact.com/faq/bank-transfers/payshap)
- [What Are ShapIDs and Request to Pay?](https://docs.switchtransact.com/faq/bank-transfers/shapids-and-request-to-pay)
- [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)


# How Does Buy Now, Pay Later Work?

Buy now, pay later (BNPL) lets a customer take goods or services immediately and pay for them in a series of instalments, typically interest-free. The merchant is paid upfront by the BNPL provider, the customer repays the provider over the agreed schedule, and the provider earns its revenue mainly from merchant fees.

In South Africa, BNPL is offered at checkout by providers such as Payflex, PayJustNow and Happy Pay, among others. It has become a common option in online retail, particularly for fashion, homeware and electronics, and is increasingly available in-store as well.

## How Does a BNPL Purchase Work?

1. The customer selects the BNPL option at checkout.
2. The provider runs a quick affordability and risk check, usually in seconds.
3. If approved, the customer pays the first instalment immediately.
4. The merchant is paid the full purchase amount (less the provider's fee) and fulfils the order as normal.
5. The customer pays the remaining instalments to the provider on the agreed dates, typically collected from their card.

The exact split varies by provider — a common pattern is a purchase divided into a small number of equal, interest-free instalments over a few weeks or months.

## Who Carries the Risk and Who Pays?

| Party         | What they get                                                       | What they carry                                               |
| ------------- | ------------------------------------------------------------------- | ------------------------------------------------------------- |
| Customer      | Goods now, payment spread over instalments                          | Late or missed-payment fees if they default on the schedule   |
| Merchant      | Full payment upfront, potentially higher conversion and basket size | A merchant fee per transaction, usually higher than card fees |
| BNPL provider | Merchant fees and any customer default fees                         | The customer credit risk                                      |

Two points matter most for merchants:

- **You are paid upfront.** Once the provider approves the transaction, the customer's ability to pay future instalments is the provider's problem, not yours.
- **You pay for that certainty.** BNPL merchant fees are typically higher than standard card acquiring fees, because the provider is funding the instalments and absorbing defaults. Confirm the actual rate with each provider rather than assuming.

Ordinary returns and disputes still follow your normal policies — BNPL shifts credit risk, not product risk.

## Is BNPL Regulated in South Africa?

BNPL products are generally structured to fall outside the National Credit Act (NCA), most commonly by keeping instalment plans short and interest-free, since the NCA's definition of a credit agreement hinges on charging interest or fees for deferred payment. This structure is why providers can approve customers in seconds without full NCA credit assessments.

Merchants should be aware that:

- Regulatory treatment of BNPL is an active topic in South Africa and may evolve.
- Providers, not merchants, are responsible for how their product is structured relative to the NCA.
- Responsible presentation still matters — describe BNPL accurately at checkout and avoid implying it is free money.

## Should You Offer BNPL?

BNPL tends to make sense when:

- Your average order value is high enough that splitting payments meaningfully helps customers.
- Your margins can absorb a higher per-transaction fee in exchange for conversion gains.
- Your customer base skews toward shoppers who budget purchase-by-purchase rather than using credit cards.

It is less compelling for very low-value transactions, where the fee is hard to justify, or where your customers already convert well on other methods. Weigh it as part of your overall checkout mix — see [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods).

## Tips

- Compare at least two providers on fees, settlement timing and checkout experience before integrating.
- Display instalment amounts on product pages, not just at checkout, since that is where BNPL influences the buying decision.
- Reconcile BNPL settlements separately, as the provider pays you net of fees.
- Agree the refund process with the provider upfront: refunds usually flow back through the provider, which adjusts the customer's instalment plan.
- Monitor your blended cost of acceptance as BNPL volume grows.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)
- [How Do You Accept Payments Online?](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)
- [What Are Recurring Card Payments (CIT and MIT)?](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit)


# How Do Voucher and Cash Payments Work Online?

Voucher and cash payment methods let customers pay for online purchases using physical cash, bridging the gap between South Africa's large cash economy and digital commerce. A customer either buys a prepaid voucher with cash and redeems it online, or places an order online and pays for it in cash at a till.

For merchants, these methods unlock customers who have no card, do not trust entering card details online, or simply prefer transacting in cash. The merchant still receives a normal electronic settlement from the voucher or payment provider — the cash handling happens entirely on the retail side.

## How Do Prepaid Vouchers Work?

Prepaid vouchers such as 1Voucher, OTT and blu voucher follow a simple pattern:

1. The customer buys a voucher for cash at a participating retailer, spaza shop or ATM.
2. The voucher is a printed or digital PIN representing the amount paid.
3. At checkout, the customer selects the voucher option and enters the PIN.
4. The voucher provider validates the PIN and confirms the payment to the merchant.
5. The provider settles the funds to the merchant electronically.

Vouchers are effectively cash converted into a digital token. Key characteristics:

- **No bank account or card is needed** at any point.
- **Payment is prepaid and final** — the funds already exist, so there is no decline for insufficient funds and no chargeback mechanism like cards have.
- **Partial redemption** is supported by some voucher products, with the balance retained on the voucher.
- **PINs are bearer instruments**: whoever holds the PIN can spend it, so customers must guard them like cash.

## How Do Cash-at-Till Payments Work?

Cash-at-till (also called cash payment on order or pay-in-store) reverses the sequence — the order comes first, the cash later:

1. The customer completes checkout online and selects the cash payment option.
2. The system issues a payment reference, usually as a barcode or numeric code.
3. The customer takes the reference to a till at a participating major retailer, such as Pick n Pay, Shoprite and other national chains.
4. The cashier scans the code and accepts the cash.
5. The merchant receives real-time confirmation and fulfils the order.

| Aspect          | Prepaid voucher                         | Cash at till                                        |
| --------------- | --------------------------------------- | --------------------------------------------------- |
| Sequence        | Buy voucher first, then shop            | Order first, then pay                               |
| Customer needs  | A voucher PIN                           | The payment reference                               |
| Expiry pressure | Voucher holds value until used          | Order usually expires if unpaid within a set window |
| Best for        | Repeat online spenders, gaming, airtime | Once-off e-commerce orders                          |

## Why Offer Voucher and Cash Options?

- **Financial inclusion.** A meaningful portion of South African consumers transact primarily in cash; these methods make them addressable online.
- **No payment declines.** Funds are confirmed before the merchant fulfils.
- **Low fraud risk.** There are no card details to steal and no chargebacks to defend.
- **Trust bridge.** Cash-first customers can try online shopping without exposing banking details.

The trade-offs are conversion friction (an extra trip to a store for cash-at-till), unpaid-order expiry management, and refunds — since there is no card to reverse, refunds typically need an alternative payout channel.

## What Should Merchants Consider?

- Set a sensible expiry window for unpaid cash-at-till orders and release stock automatically when it lapses.
- Agree a refund mechanism with your provider upfront, such as a payout to a bank account or a replacement voucher.
- Reconcile provider settlements against confirmed orders daily using payment references.
- Present the option clearly at checkout with simple instructions, since the flow is unfamiliar to some customers.

## Tips

- Show the nearest participating retailers or a store list in the payment instructions.
- Send the payment reference by SMS or email so the customer has it at the till.
- Never fulfil before the provider confirms the cash has been received.
- Treat voucher PIN handling in your systems with the same care as card data — a leaked PIN is spendable cash.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)
- [How Do You Accept Payments Online?](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)
- [What Is Mobile Money and How Does It Work?](https://docs.switchtransact.com/faq/other-payment-methods/mobile-money)


# What Is Mobile Money and How Does It Work?

Mobile money is an electronic wallet linked to a mobile phone number. Customers deposit cash with an agent or receive money into the wallet, then use the balance to pay merchants, send money to other people, buy airtime and pay bills — all without a bank account. The phone number itself acts as the account identifier.

Mobile money is one of the most important payment stories in Africa. M-Pesa, launched in Kenya, became the dominant way to move money in much of East Africa and proved that a phone-based wallet could leapfrog traditional banking. In South Africa, MTN MoMo and Vodacom's wallet offerings bring the same model to the local market, with a particular focus on unbanked and underbanked consumers.

## How Does a Mobile Money Payment Work?

1. The customer loads value into their wallet — by depositing cash with an agent or retailer, or by receiving a transfer.
2. To pay a merchant, the customer authorises a payment from the wallet, typically via the provider's app, USSD menu or by approving a payment request.
3. The wallet provider moves the value from the customer's wallet to the merchant instantly.
4. The merchant either keeps the value in a business wallet or settles it out to a bank account.

Because USSD works on any phone, mobile money does not require a smartphone or data — one of the main reasons it reaches customers that card and app-based methods miss.

## Why Is Mobile Money So Significant in Africa?

- **It banks the unbanked.** A wallet requires a SIM card and identity verification, not a bank relationship, branch visit or minimum balance.
- **The agent network is the branch network.** Cash goes in and out through large networks of agents and retail points.
- **Person-to-person transfers drove adoption.** Sending money home cheaply and instantly made wallets ubiquitous in markets like Kenya and Tanzania, and merchant payments followed.
- **It runs on any handset.** USSD support means feature phones participate fully.

In South Africa, a well-developed banking system and card infrastructure meant mobile money took longer to gain traction than in East Africa, and early attempts were discontinued. Current offerings such as MTN MoMo target the segment that traditional banking still serves poorly.

## Mobile Money vs Other Wallets

| Aspect              | Mobile money                   | Card-based digital wallets        |
| ------------------- | ------------------------------ | --------------------------------- |
| Identifier          | Phone number                   | Card stored in the wallet         |
| Bank account needed | No                             | Underlying card requires one      |
| Value storage       | Held in the wallet itself      | Wallet passes through to the card |
| Device requirement  | Any phone (USSD) or smartphone | Smartphone                        |
| Typical user        | Unbanked and underbanked       | Banked, card-holding              |

For how card-based wallets like Apple Pay and Google Pay work, see [What Are Digital Wallets?](https://docs.switchtransact.com/faq/card-payments/digital-wallets). Note also that paying to a phone number is not unique to mobile money — [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) lets banked customers do the same between bank accounts using a ShapID.

## How Can a Business Accept Mobile Money?

- **Direct merchant integration** with the wallet provider, via API, payment links or an in-store QR/USSD flow.
- **Through a payments provider or gateway** that includes mobile money alongside cards and other methods in one integration and one settlement.
- **Payment requests**, where the merchant sends a request the customer approves in their wallet.

Points to confirm with the provider:

- How and when wallet balances settle to your bank account.
- Transaction fees and any wallet or settlement account charges.
- How refunds are processed back to a wallet.
- Reporting and references for reconciliation.

## When Does Mobile Money Make Sense for Your Business?

Mobile money is strongest where your customers are cash-first, informal-sector or without cards — and it pairs naturally with [voucher and cash payment methods](https://docs.switchtransact.com/faq/other-payment-methods/voucher-and-cash-payments) in an inclusion-focused checkout. If you trade into other African markets, wallet acceptance is often not optional but expected, since in several countries mobile money is the default way consumers pay.

## Tips

- Verify the customer-facing flow on a basic handset, not just the smartphone app.
- Reconcile wallet settlements daily using the provider's transaction references.
- Keep payment instructions simple and language-light for first-time users.
- Reassess coverage periodically — wallet participation and features change quickly in this space.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [What Are Digital Wallets?](https://docs.switchtransact.com/faq/card-payments/digital-wallets)
- [What Is PayShap?](https://docs.switchtransact.com/faq/bank-transfers/payshap)
- [How Do Voucher and Cash Payments Work Online?](https://docs.switchtransact.com/faq/other-payment-methods/voucher-and-cash-payments)


# Can You Accept Cryptocurrency and Stablecoin Payments?

Yes — South African businesses can accept cryptocurrency and stablecoin payments, but almost none do so by holding crypto directly. In practice, merchants use an intermediary payment provider that accepts the customer's crypto, converts it, and settles the merchant in rand. That structure sidesteps the two biggest obstacles: price volatility and the accounting complexity of holding crypto assets.

The regulatory picture in South Africa is clearer than in many countries. Crypto assets are regulated financial products, the providers that facilitate them require licensing, and tax obligations apply to crypto transactions. Accepting crypto is therefore a compliance decision as much as a payments decision.

## How Does a Crypto Payment to a Merchant Work?

A typical intermediary-based flow:

1. The customer selects the crypto option at checkout.
2. The payment provider quotes an amount in the chosen cryptocurrency, locked for a short window.
3. The customer sends the payment from their wallet or exchange account.
4. The provider confirms the transaction on the relevant blockchain.
5. The provider converts the crypto and settles the merchant in rand, so the merchant never holds the asset.

Crypto payments are push payments: the customer initiates them, and once confirmed on-chain they are irreversible. There is no chargeback mechanism, which removes card-style fraud disputes but also means refunds must be handled as separate transactions.

## What Is the Regulatory Position in South Africa?

- **Crypto assets are financial products.** The Financial Sector Conduct Authority (FSCA) declared crypto assets financial products under the FAIS Act in 2022.
- **Providers need licences.** Exchanges and other crypto asset service providers must be licensed by the FSCA, so merchants should only work with licensed intermediaries.
- **The SARB does not treat crypto as legal tender.** Crypto is not currency in the legal sense; the rand remains the unit in which the merchant prices, accounts and pays tax.
- **Tax applies.** SARS treats crypto transactions as taxable events; income or capital gains rules apply depending on the circumstances, and record-keeping is essential.

Regulation in this area continues to develop, so confirm the current position with your provider and advisers before launching.

## Cryptocurrency vs Stablecoins

| Aspect                  | Cryptocurrencies (e.g. Bitcoin)                | Stablecoins                                        |
| ----------------------- | ---------------------------------------------- | -------------------------------------------------- |
| Price behaviour         | Volatile                                       | Pegged to a reference asset, usually the US dollar |
| Payment suitability     | Amount can move between quote and confirmation | Value is broadly stable through the payment        |
| Main risk               | Volatility                                     | Quality of the issuer and its reserves             |
| Typical use in payments | Customer preference, store of value            | Remittances, cross-border settlement, e-commerce   |

Volatility is the core problem with using cryptocurrencies for everyday payments: neither party wants the value to shift while a payment is in flight. Stablecoins address this by pegging to a stable reference asset, which is why most practical crypto payment activity is moving toward them — particularly for cross-border payments, where they can be faster and cheaper than correspondent banking. For the traditional route, see [Cross-Border Payments and SWIFT](https://docs.switchtransact.com/faq/bank-transfers/cross-border-payments-and-swift).

## Should Your Business Accept Crypto?

It may be worth offering when:

- Your customer base includes crypto holders who ask to pay this way.
- You sell cross-border and want an additional settlement channel.
- Your provider settles you in rand, so you carry no crypto exposure.

It is harder to justify when your customers show no demand for it, or when the operational overhead (refund handling, reconciliation, tax records) outweighs the incremental sales. As with any method, weigh it against your overall mix — see [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods).

## What Should Merchants Check Before Accepting Crypto?

- **Licensing.** Confirm the intermediary is licensed by the FSCA.
- **Settlement.** Confirm you are settled in rand, on what timeline, and at what conversion rate or fee.
- **Refunds.** Agree how refunds are processed, since on-chain payments cannot be reversed.
- **Records.** Keep transaction records adequate for SARS and your auditors.
- **AML obligations.** Understand what customer and transaction screening the provider performs.

## Tips

- Start with an intermediary that settles in rand rather than holding crypto yourself.
- Prefer stablecoin support if your use case is payments rather than customer preference for a specific coin.
- Document your refund policy for crypto payments before you accept the first one.
- Get tax advice early — the treatment of crypto receipts affects your accounting from day one.

## Related Topics

- [Other Payment Methods](https://docs.switchtransact.com/faq/other-payment-methods)
- [How Do You Choose Payment Methods?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)
- [Cross-Border Payments and SWIFT](https://docs.switchtransact.com/faq/bank-transfers/cross-border-payments-and-swift)
- [How Do You Accept Payments Online?](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)


# Other Payment Methods

Beyond cards, debit orders and bank transfers, South Africans pay in many other ways. Learn how these alternative payment methods work and when to offer them.

## Topics in this section

- [How Do QR Code Payments Work?](https://docs.switchtransact.com/faq/other-payment-methods/qr-code-payments)
- [What Is QR Plus?](https://docs.switchtransact.com/faq/other-payment-methods/qr-plus)
- [What Is Instant EFT and Open Banking?](https://docs.switchtransact.com/faq/other-payment-methods/instant-eft-and-open-banking)
- [How Does Buy Now, Pay Later Work?](https://docs.switchtransact.com/faq/other-payment-methods/buy-now-pay-later)
- [How Do Voucher and Cash Payments Work Online?](https://docs.switchtransact.com/faq/other-payment-methods/voucher-and-cash-payments)
- [What Is Mobile Money and How Does It Work?](https://docs.switchtransact.com/faq/other-payment-methods/mobile-money)
- [Can You Accept Cryptocurrency and Stablecoin Payments?](https://docs.switchtransact.com/faq/other-payment-methods/cryptocurrency-and-stablecoin-payments)


# Payments Glossary: Key Terms Explained

This glossary defines the payment terms you are most likely to encounter when collecting debit orders, accepting card payments or making payouts in South Africa. Terms are listed alphabetically with short, practical definitions.

For acronyms and abbreviations, see the [acronym list](https://docs.switchtransact.com/faq/reference/acronyms). For more reference material, return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

## A

- **Abbreviated short name** — The short creditor name that appears on the payer's bank statement next to a debit order, so the payer can identify who debited their account. Also called the ABSN or statement descriptor.
- **Acquirer** — The bank or licensed institution that enables a merchant to accept card payments and receives the transaction on the merchant's behalf.
- **Action date** — The date on which a debit order payment instruction is due to be processed against the payer's account.
- **Authenticated collections** — The formal name for DebiCheck: debit orders where the payer electronically confirms the mandate with their bank before the first collection.
- **Authorisation** — The step where the payer's bank or card issuer approves a payment request, confirming the account or card is valid and funds are available.

## B

- **Batch processing** — Submitting many payment instructions together in a file for processing in a scheduled window, rather than one at a time in real time.
- **Beneficiary** — The party receiving a payment, for example the account holder receiving a payout or EFT credit.

## C

- **Card-not-present (CNP)** — A card transaction where the physical card is not presented, such as an online or telephone payment.
- **Chargeback** — A card dispute process where the cardholder's bank reverses a transaction and reclaims the funds from the merchant's acquirer.
- **Clearing** — The exchange of payment instructions and data between banks so that each bank knows what to debit and credit.
- **Collection** — A debit order payment instruction submitted against a payer's account under a mandate.
- **Cut-off time** — The deadline by which a payment or collection file must be submitted to be processed in a given cycle or on a given day.

## D

- **DebiCheck** — A South African debit order type where the payer electronically approves the mandate with their bank before collections start, giving the mandate protected dispute status. See [how DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works).
- **Debit order** — An instruction that lets a creditor collect money from a payer's bank account under an agreed mandate, on a recurring or once-off basis.
- **Dispute** — A payer's formal challenge to a payment, such as a debit order dispute at their bank or a card chargeback.

## E

- **Early processing window** — A processing slot ahead of the normal EFT run, historically associated with NAEDO and now with DebiCheck and registered mandate collections, which improves the chance of collecting when funds land in the account.
- **EFT** — Electronic funds transfer: the batch-based payment rails used for ordinary credit payments and EFT debit orders in South Africa.
- **Electronic mandate** — A mandate accepted through an electronic channel, such as a website, app or voice recording, rather than on paper.

## F

- **Finality** — The point at which a payment is settled and can no longer be recalled by the sender, as with RTC and RTGS payments.

## G

- **Gateway** — The technology service that securely captures payment details and passes transactions between the merchant and the acquirer or processor.

## H

- **Homing account** — The bank account against which a debit order or payment instruction is directed, identified by the branch code and account number in the instruction.

## I

- **Interchange** — The fee paid between banks on a card transaction, typically from the acquirer to the issuer, which forms part of the merchant's cost of acceptance.
- **Issuer** — The bank or institution that issued the payer's card or holds the payer's account.

## M

- **Mandate** — The payer's recorded authority allowing a creditor to collect debit orders from their account under agreed terms. See [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
- **Merchant account** — The facility, provided by an acquirer or payment provider, that allows a business to accept card payments and receive settlement.

## N

- **NAEDO** — Non-authenticated early debit order: a legacy early-window debit order type that was retired in 2021 and replaced by DebiCheck.
- **No-show / non-response** — In DebiCheck, when a payer does not respond to a mandate authentication request before it expires.

## P

- **Payer** — The party whose account is debited or who sends a payment.
- **Payment instruction** — The individual instruction submitted into a payment stream to debit or credit an account.
- **PayShap** — South Africa's low-value instant payment service, which supports paying to a bank account or a ShapID proxy. See [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap).
- **Payout** — A payment made by a business to a bank account, for example refunds, supplier payments or wage disbursements.

## R

- **Real-time clearing (RTC)** — The payment rail that clears once-off credit payments between banks within seconds rather than in batch cycles.
- **Reason code** — A code returned by a bank explaining why a payment failed, was unpaid or was declined. See the [reason code directory](https://docs.switchtransact.com/faq/reference/reason-code-directory).
- **Reconciliation** — Matching payment records against bank statements and settlement reports to confirm that expected money actually moved.
- **Registered mandate** — A debit order mandate registered with the payer's bank through the Registered Mandate Service, giving banks visibility of the mandate without requiring payer authentication. See [what is a registered mandate](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).
- **Reversal** — The return of a payment after processing, either by the payer's bank (for example a disputed debit order) or by the originator correcting an error.

## S

- **Settlement** — The actual movement of money between banks to discharge cleared obligations, typically across accounts held at the SARB.
- **ShapID** — A PayShap proxy, such as a cellphone number, that is linked to a bank account so payments can be addressed without sharing account details.
- **Sponsoring bank** — The bank that sponsors a non-bank participant, such as a TPPP or system operator, into the clearing system and takes responsibility for its entries.
- **Stop payment** — An instruction by the payer to their bank to block a specific debit order from being processed.
- **Switch** — Infrastructure that routes transactions between parties, for example between an ATM or POS device and the correct issuer.

## T

- **Tokenisation** — Replacing sensitive card details with a token so the real card number does not need to be stored or transmitted.
- **TPPP** — Third party payment provider: an entity that collects or pays out funds on behalf of others across its own bank account, under sponsorship and registration requirements.
- **Tracking** — Re-presenting a debit order over several days so it can collect as soon as sufficient funds arrive in the payer's account.
- **Transaction type (TT1, TT2, TT3)** — The three DebiCheck mandate authentication methods: real-time, delayed and card-and-PIN authentication. See [TT1, TT2 and TT3](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3).

## U

- **Unpaid** — A debit order returned by the payer's bank without payment, together with a reason such as insufficient funds. See [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).
- **User code** — The identifier assigned to a collecting party in the debit order system, used to link payment instructions to the responsible creditor.

## V

- **Value date** — The date on which funds become available in the receiving account, which can differ from the date the instruction was processed.

## W

- **Webhook** — An automated notification sent to your system when a payment event occurs, such as a status change on a collection.


# Payment Acronyms and Abbreviations Explained

The payments industry is full of acronyms, and South Africa adds a few of its own. This page expands the abbreviations you are most likely to see in bank specifications, payment reports and Kwik documentation, with a short explanation of what each one means in practice.

For fuller definitions of the underlying concepts, see the [glossary](https://docs.switchtransact.com/faq/reference/glossary) or return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

## Acronym reference table

| Acronym       | Full name                                                             | Meaning                                                                                                                                                 |
| ------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| AC            | Authenticated Collections                                             | The formal industry name for DebiCheck debit orders, where the payer confirms the mandate with their bank.                                              |
| AEDO          | Authenticated Early Debit Order                                       | A legacy early-window debit order authenticated with the payer's card and PIN; retired in 2021 in favour of DebiCheck.                                  |
| API           | Application Programming Interface                                     | The technical interface systems use to talk to each other, for example to create mandates or submit collections.                                        |
| AVS / AVS-R   | Account Verification Service (Real-time)                              | A bank service that checks whether an account exists, is open and matches the supplied ID or registration details; AVS-R is the real-time version.      |
| BNPL          | Buy Now, Pay Later                                                    | A payment method that splits a purchase into instalments, usually interest-free for the shopper.                                                        |
| CDV           | Check Digit Verification                                              | A mathematical check that a bank account number is validly formed for a given branch code; it does not confirm the account exists.                      |
| CIT           | Cardholder-Initiated Transaction                                      | A card payment actively initiated by the cardholder, such as a checkout payment.                                                                        |
| CNP           | Card Not Present                                                      | A card transaction where the physical card is not presented, such as an online payment.                                                                 |
| CVV           | Card Verification Value                                               | The 3-digit security code on a card used to verify card-not-present payments.                                                                           |
| DebiCheck TT1 | Transaction Type 1                                                    | Real-time DebiCheck mandate authentication, where the payer approves via banking app, USSD or similar within a short window.                            |
| DebiCheck TT2 | Transaction Type 2                                                    | Delayed DebiCheck authentication, where the payer has more time (typically up to two days) to respond to the bank's request.                            |
| DebiCheck TT3 | Transaction Type 3                                                    | Card-and-PIN DebiCheck authentication, performed on a device at the point of sale or in the field.                                                      |
| EFT           | Electronic Funds Transfer                                             | South Africa's batch-based payment rails for credit payments and EFT debit orders.                                                                      |
| EMV           | Europay, Mastercard and Visa                                          | The global chip card standard that secures card-present payments.                                                                                       |
| FICA          | Financial Intelligence Centre Act                                     | South African law requiring institutions to verify client identities and report suspicious activity.                                                    |
| FSCA          | Financial Sector Conduct Authority                                    | The South African regulator overseeing market conduct of financial institutions.                                                                        |
| ISO 20022     | International Organization for Standardization 20022                  | The international standard for rich, structured financial messaging that payment systems are adopting worldwide.                                        |
| KYC / AML     | Know Your Customer / Anti-Money Laundering                            | The processes for verifying customers and preventing the movement of criminal funds.                                                                    |
| MID           | Merchant Identification Number                                        | The unique number identifying a merchant to its acquirer for card acceptance and settlement.                                                            |
| MIT           | Merchant-Initiated Transaction                                        | A card payment initiated by the merchant under a prior agreement with the cardholder, such as a subscription charge.                                    |
| NAEDO         | Non-Authenticated Early Debit Order                                   | A legacy early-window debit order without payer authentication; retired in 2021 and replaced by DebiCheck.                                              |
| NCA           | National Credit Act                                                   | South African law regulating credit agreements, which affects how instalments may be collected.                                                         |
| PASA          | Payments Association of South Africa                                  | The industry body that has historically managed payment clearing rules; its functions are transitioning to a new payments industry body.                |
| PCI DSS       | Payment Card Industry Data Security Standard                          | The security standard for any organisation that stores, processes or transmits card data.                                                               |
| POPIA         | Protection of Personal Information Act                                | South Africa's data protection law governing how personal information, including payment data, is handled.                                              |
| POS           | Point of Sale                                                         | The place or device where an in-person payment is made.                                                                                                 |
| PSP           | Payment Service Provider                                              | A company that provides payment acceptance, collection or payout services to businesses.                                                                |
| RM / RMS      | Registered Mandate / Registered Mandate Service                       | A debit order mandate registered with the payer's bank, and the service used to register it; unlike DebiCheck it does not require payer authentication. |
| RTC           | Real-Time Clearing                                                    | The rail that clears once-off credit payments between banks within seconds.                                                                             |
| RTGS / SAMOS  | Real-Time Gross Settlement / South African Multiple Option Settlement | The SARB-operated system where high-value interbank payments settle individually, immediately and irrevocably.                                          |
| SARB          | South African Reserve Bank                                            | The central bank, which oversees and regulates the national payment system.                                                                             |
| SFTP          | Secure File Transfer Protocol                                         | A secure method for exchanging batch payment files between systems.                                                                                     |
| SWIFT         | Society for Worldwide Interbank Financial Telecommunication           | The messaging network banks use for cross-border payments.                                                                                              |
| TPPP          | Third Party Payment Provider                                          | An entity that collects or pays out funds on behalf of others across its own account, under bank sponsorship.                                           |
| 3DS           | 3-D Secure                                                            | The protocol that authenticates a cardholder during online payments, often via a bank app prompt or one-time PIN.                                       |

## Related reading

- [How DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) for TT1, TT2 and TT3 in context.
- [Payment participants](https://docs.switchtransact.com/faq/how-payments-work/payment-participants) for how issuers, acquirers and PSPs fit together.
- [The South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system) for SARB, SAMOS and BankservAfrica.


# Payment Status Directory

Every payment moves through a series of statuses between the moment it is created and the moment the money is finally settled or returned. Status names differ between providers and banks, but the underlying states are similar across the industry. This directory lists the generic statuses you will encounter for each payment method, what each one means, and what action (if any) to take.

Statuses describe where a payment is in its lifecycle; when a payment fails, the accompanying reason code explains why. See the [reason code directory](https://docs.switchtransact.com/faq/reference/reason-code-directory) for those, or return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

## Card payment statuses

| Status                | What it means                                                                                                     | What to do                                                                                                                                                                            |
| --------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pending               | The payment has been created but authorisation has not completed, for example the shopper is still in 3-D Secure. | Wait for the final result; do not release goods yet.                                                                                                                                  |
| Authorised            | The issuer approved the payment and funds are reserved on the card, but not yet captured.                         | Capture the payment to take the funds, or void it if you no longer need it.                                                                                                           |
| Captured / Paid       | The funds have been taken and will be settled to you.                                                             | Fulfil the order and reconcile against your settlement report.                                                                                                                        |
| Declined              | The issuer refused the payment.                                                                                   | Check the response code and ask the customer to retry or use another method. See [card declines](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes). |
| Expired               | The payment or authorisation was not completed in time and lapsed.                                                | Create a new payment if the customer still wants to pay.                                                                                                                              |
| Refunded              | Funds were returned to the cardholder after a successful payment.                                                 | Reconcile the refund; no further action needed.                                                                                                                                       |
| Disputed / Chargeback | The cardholder has disputed the payment with their bank.                                                          | Respond with evidence within the deadline. See [card chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks).                                 |

## Debit order collection statuses

| Status              | What it means                                                                                                   | What to do                                                                                                                                                                                             |
| ------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Pending / Scheduled | The collection has been created and is waiting for its action date or the next submission window.               | Nothing yet; it will be submitted automatically.                                                                                                                                                       |
| Submitted           | The payment instruction has been sent into the payment stream for processing.                                   | Wait for the outcome, usually available on or shortly after the action date.                                                                                                                           |
| Tracking            | The debit order was not immediately paid and is being re-presented over the tracking period, waiting for funds. | Wait for the tracking window to finish before treating it as failed.                                                                                                                                   |
| Paid / Successful   | The payer's account was debited and the funds will settle to you.                                               | Reconcile and mark the customer's account as paid.                                                                                                                                                     |
| Unpaid              | The payer's bank returned the collection without payment, with a reason such as insufficient funds.             | Check the reason and decide whether to resubmit or contact the customer. See [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions). |
| Disputed / Reversed | The payer disputed the debit order at their bank and the funds were returned to them.                           | Review the mandate, contact the customer, and do not simply re-collect a validly disputed amount.                                                                                                      |
| Cancelled           | The collection was withdrawn before processing.                                                                 | Recreate it if collection is still required.                                                                                                                                                           |

## DebiCheck mandate statuses

| Status                            | What it means                                                                              | What to do                                                                                  |
| --------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| Pending / Awaiting authentication | The mandate request has been sent to the payer's bank and the payer has not yet responded. | Ask the customer to look out for the bank's approval request and respond before it expires. |
| Authenticated / Approved          | The payer confirmed the mandate with their bank; collections can now be submitted.         | Begin collecting according to the mandate terms.                                            |
| Rejected                          | The payer declined the mandate request at their bank.                                      | Contact the customer to resolve the reason, then send a new request if appropriate.         |
| Expired                           | The authentication request lapsed before the payer responded.                              | Send a new mandate request and warn the customer that a bank prompt is coming.              |
| Suspended                         | The mandate is temporarily inactive and collections against it will not be paid.           | Resolve the suspension with the customer or their bank before collecting again.             |
| Cancelled                         | The mandate has been permanently ended by the payer, the creditor or the bank.             | Stop collections; a new mandate is required to collect again.                               |

For the full lifecycle, see [DebiCheck statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes) and the [mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle).

## Bank transfer and payout statuses

| Status                 | What it means                                                                                                    | What to do                                                                                                                                                          |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Pending / Queued       | The payment has been created and is waiting to be submitted, for example ahead of a cut-off time.                | Nothing yet; check cut-off times if it is urgent.                                                                                                                   |
| Submitted / Processing | The payment instruction has been sent to the bank or payment rail.                                               | Wait for confirmation; real-time payments confirm in seconds, EFT in batch cycles.                                                                                  |
| Paid / Completed       | The funds have been transferred to the beneficiary.                                                              | Reconcile against your statement.                                                                                                                                   |
| Failed / Returned      | The payment could not be applied, for example because the account is closed or invalid, and funds were returned. | Verify the beneficiary details and resubmit. See [failed and returned transfers](https://docs.switchtransact.com/faq/bank-transfers/failed-and-returned-transfers). |
| Cancelled              | The payment was withdrawn before it was processed.                                                               | Recreate it if the payment is still needed.                                                                                                                         |

## Tips for working with statuses

- Treat only the final statuses (paid, unpaid, declined, returned) as definitive; intermediate statuses can still change.
- Use webhooks or status polling rather than assuming an outcome from the absence of an error.
- Always read the status together with its reason code when a payment fails, so you take the right corrective action.


# Payment Reason Code Directory

When a payment fails, the bank or scheme returns a reason code explaining why. Each payment stream has its own code set: debit order unpaids use one set of return reasons, DebiCheck mandates another, and card payments use scheme response codes. The numeric or alphanumeric codes differ between streams and can differ between specifications, but the underlying reasons are consistent and predictable.

This directory describes the common reason categories for each stream and what to do about them. It deliberately avoids listing exact numeric codes, because those depend on the specification version your provider or bank uses. Always consult your provider or bank's current specification for the precise code values. For statuses rather than reasons, see the [status directory](https://docs.switchtransact.com/faq/reference/payment-status-directory), or return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

## How reason codes work

A reason code accompanies a failed or returned payment and tells you which party caused the failure and whether a retry is worthwhile. Broadly, reasons fall into three groups:

- **Funds-related** — the account is valid but could not pay right now. A retry on a better date often succeeds.
- **Account-related** — something is wrong with the account itself (closed, frozen, invalid). Retrying without fixing the details will fail again.
- **Authority-related** — the payer or their bank has withdrawn or refused authority (payment stopped, mandate cancelled, disputed). Do not simply retry; resolve the mandate or agreement with the customer first.

## Debit order unpaid reasons

Common reasons a debit order collection is returned unpaid:

| Reason                            | What it means                                                          | What to do                                                                                                                                                     |
| --------------------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Insufficient funds                | The account did not have enough money on the action date.              | Resubmit on a better date or use tracking; contact the customer if it repeats.                                                                                 |
| Account closed                    | The payer's account has been closed.                                   | Get new bank details and a new or updated mandate.                                                                                                             |
| Payment stopped                   | The payer instructed their bank to stop this debit order.              | Contact the customer; do not resubmit until the underlying issue is resolved.                                                                                  |
| Account frozen / blocked          | The account exists but is blocked, for example by a legal hold.        | Contact the customer for an alternative payment method.                                                                                                        |
| Account holder deceased           | The bank has flagged the account holder as deceased.                   | Stop collections and follow your estate/collections process.                                                                                                   |
| No such account / invalid account | The account number does not exist at that branch.                      | Verify the details, correct them and recollect. See [account validation and CDV](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv). |
| Authorisation cancelled           | The payer cancelled the underlying authority or mandate at their bank. | Treat the mandate as ended; obtain a new mandate before collecting again.                                                                                      |

For resubmission rules and strategy, see [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

## DebiCheck mandate decline reasons

Common reasons a DebiCheck mandate request fails:

| Reason                               | What it means                                                                                            | What to do                                                           |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Rejected by customer                 | The payer actively declined the mandate at their bank.                                                   | Contact the customer to understand why before sending a new request. |
| Authentication expired / no response | The payer did not respond before the request lapsed.                                                     | Warn the customer to expect the bank prompt, then resend.            |
| Account type not allowed             | The account cannot carry DebiCheck mandates, for example some savings or credit accounts.                | Ask the customer for a different account.                            |
| Mandate details mismatch             | The details in the request do not match the bank's records, for example the ID number or account holder. | Correct the customer details and resubmit.                           |
| Invalid or closed account            | The target account is invalid or closed.                                                                 | Verify the bank details before retrying.                             |

For the DebiCheck-specific view, see [DebiCheck statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

## Card decline reasons

Common categories of card response codes:

| Reason                             | What it means                                                                   | What to do                                                                                                                                            |
| ---------------------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| Do not honour                      | The issuer declined without a specific reason; the most common generic decline. | Ask the cardholder to retry, contact their bank or use another card.                                                                                  |
| Insufficient funds                 | The card's available balance or limit is too low.                               | Ask the cardholder to retry later or use another method.                                                                                              |
| Expired card                       | The card's expiry date has passed.                                              | Request updated card details.                                                                                                                         |
| Suspected fraud / security decline | The issuer's risk systems blocked the transaction.                              | The cardholder must contact their bank; do not repeatedly retry.                                                                                      |
| 3-D Secure failure                 | The cardholder did not complete or failed authentication.                       | Ask the cardholder to retry and complete the bank's verification step. See [3-D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure). |
| Invalid card details               | The card number, CVV or expiry was entered incorrectly.                         | Ask the cardholder to re-enter their details.                                                                                                         |

For a deeper treatment, see [card declines and response codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes).

## Bank transfer return reasons

Credit payments and payouts are returned for a narrower set of reasons: invalid or closed destination account, account unable to accept credits, or beneficiary details that do not match. Verify beneficiary details before paying, and see [failed and returned transfers](https://docs.switchtransact.com/faq/bank-transfers/failed-and-returned-transfers) for handling returns.

## Where to find exact codes

The authoritative source for exact code values is always the specification of the provider, bank or stream you integrate with. Code lists are versioned and occasionally change, so check that you are reading the version that matches your integration. If you receive a code you do not recognise, ask your provider rather than guessing, because acting on the wrong reason (for example retrying a stopped payment) can create disputes.


# Who Does What in the Payments Industry?

Every payment, whether a card purchase or a debit order collection, passes through several organisations that each play a defined role. Understanding who does what makes it much easier to follow where a payment is, who to contact when something fails, and why certain rules apply to your business.

This page summarises each role and how they fit together. For a fuller walkthrough, see [payment participants](https://docs.switchtransact.com/faq/how-payments-work/payment-participants), or return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

## The roles

### Issuer

The issuer is the bank or institution that gave the payer their card or holds their bank account. In a card payment the issuer decides whether to approve the transaction; in a debit order the payer's bank decides whether the collection is paid or returned unpaid. The issuer is the payer's point of contact for disputes and stop payments.

### Acquirer

The acquirer is the bank or licensed institution that enables a merchant to accept card payments. It receives transactions from the merchant, routes them to the schemes for authorisation, and settles the proceeds to the merchant. The acquirer also carries the risk of the merchant's chargebacks, which is why it vets merchants before onboarding them.

### Sponsoring bank

Non-bank participants cannot submit entries into the clearing system directly. A sponsoring bank sponsors them in, submits their payment instructions under its own participation, and takes responsibility for those entries. Debit order collectors, TPPPs and system operators all operate under bank sponsorship.

### Payment service provider (PSP) and third party payment provider (TPPP)

A PSP provides payment services to businesses: collecting debit orders, accepting cards, sending payouts and supplying the technology around them. When a provider receives money on behalf of other businesses across its own bank account before paying it over, it acts as a TPPP, a role subject to registration and sponsorship requirements. Kwik operates in this space, giving businesses access to collection and payment rails without each business needing its own bank sponsorship.

### System operator

A system operator provides the technical processing of payment instructions on behalf of other parties, for example preparing and delivering debit order files to a sponsoring bank, without itself handling the funds. Many providers are both a system operator (moving the data) and a TPPP (moving the money).

### Gateway

A gateway is the technology layer that captures payment details securely from a website, app or device and passes the transaction to the acquirer or processor. It handles encryption, 3-D Secure and formatting, but does not itself approve payments or hold funds. See [gateway, processor, switch and acquirer](https://docs.switchtransact.com/faq/accepting-payments/gateway-processor-switch-acquirer).

### Switch

A switch routes transactions between parties, for example carrying a card transaction from a POS device or ATM network to the correct issuer for authorisation. Switching is invisible to merchants and payers but essential to interoperability.

### Clearing house

The clearing house exchanges payment instructions between banks and calculates what each bank owes the others. In South Africa this is BankservAfrica, which operates the clearing infrastructure for EFT, debit orders, DebiCheck, real-time clearing and PayShap.

### Card schemes

Visa, Mastercard and other schemes set the rules, standards and interchange framework for card payments, and operate the networks that connect issuers and acquirers globally.

### Regulator

The South African Reserve Bank (SARB), through its National Payment System Department, oversees the whole system: who may participate, how settlement works and what standards apply. Interbank obligations ultimately settle across accounts held at the SARB.

## How they interact

Take a monthly DebiCheck collection as an example. Your business agrees a mandate with a customer. Kwik, acting as PSP/system operator, sends the mandate request through its sponsoring bank into the DebiCheck system, where BankservAfrica routes it to the customer's bank (the issuer side) for the customer to authenticate. On the action date, the collection instruction follows the same path; the customer's bank pays or returns it; BankservAfrica clears the results; and the banks settle with each other through the SARB's settlement system. Each organisation touches the payment, but each is responsible for a distinct step.

For card payments the chain is similar: merchant to gateway, gateway to acquirer, acquirer to scheme, scheme to issuer, and settlement flowing back along the same path.

## Related reading

- [Payment participants](https://docs.switchtransact.com/faq/how-payments-work/payment-participants)
- [The South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system)
- [Regulators and industry organisations](https://docs.switchtransact.com/faq/reference/regulators-and-industry-organisations)


# Payment Regulators and Industry Organisations in South Africa

South Africa's payment system is governed and operated by a small set of organisations, each with a distinct mandate: the central bank oversees the system, an industry body manages the operational rules, a clearing house runs the infrastructure, and several regulators and ombud schemes protect consumers and data. Knowing who does what helps you direct questions, complaints and compliance obligations to the right place.

This page introduces each organisation briefly. For how the system itself works, see [the South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system), or return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

## South African Reserve Bank (SARB)

The SARB is the central bank and the ultimate authority over the national payment system. Its National Payment System Department regulates and oversees payment systems under the National Payment System Act, decides who may participate in clearing and settlement, and operates the SAMOS real-time gross settlement system where interbank obligations are finally settled. Major payment reforms, such as DebiCheck and PayShap, happen under SARB direction.

## Payments Association of South Africa (PASA)

PASA has historically been the payment system management body recognised by the SARB, responsible for the operational rules of each payment stream: debit orders, EFT, cards, real-time payments and more. Collection rules such as mandate requirements and dispute processes originate here. As part of the SARB's broader payments reform, PASA's functions are transitioning to a new, more inclusive payments industry body that will represent non-bank participants alongside banks.

## BankservAfrica

BankservAfrica is South Africa's automated clearing house. It operates the interbank infrastructure for EFT credits and debits, debit order collections, DebiCheck, real-time clearing and PayShap, exchanging payment instructions between banks and calculating their positions for settlement at the SARB. When your debit order file is processed "at Bankserv", this is the organisation involved.

## Financial Sector Conduct Authority (FSCA)

The FSCA regulates the market conduct of financial institutions, focusing on fair treatment of customers. Businesses offering financial products or services may need FSCA licensing, and its conduct standards shape how payment-adjacent services are sold and administered.

## Financial Intelligence Centre (FIC)

The FIC administers the Financial Intelligence Centre Act (FICA), South Africa's anti-money laundering framework. Accountable institutions must verify customer identities, keep records and report suspicious transactions to the FIC. This is why payment providers ask for company documents and director IDs during onboarding. See [KYC, AML, sanctions and POPIA](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/kyc-aml-sanctions-and-popia).

## Information Regulator

The Information Regulator enforces the Protection of Personal Information Act (POPIA), which governs how personal information, including bank account details and payment records, is collected, stored and shared. Anyone processing payer data in South Africa must comply, and data breaches involving personal information must be reported to the Regulator.

## Ombudsman for Banking Services / National Financial Ombud

Consumers with unresolved complaints against their bank, including debit order disputes, can escalate to the ombud scheme at no cost. The Ombudsman for Banking Services has been consolidated into the National Financial Ombud Scheme, which now handles banking complaints alongside credit, insurance and other financial services complaints. Businesses should resolve customer payment complaints promptly, because unresolved disputes can end up here.

## Card schemes

Visa, Mastercard and other international card schemes are not South African regulators, but their rules bind every issuer, acquirer and merchant accepting their cards. Scheme rules govern chargebacks, interchange, security standards such as PCI DSS, and authentication requirements such as 3-D Secure.

## Consumer resources

For consumers wanting to understand or verify DebiCheck debit orders, the industry maintains [www.debicheck.co.za](https://www.debicheck.co.za){rel=""nofollow""} as a plain-language resource explaining how DebiCheck works and what payers' rights are. It is a useful link to share with customers who are unsure about a mandate request from their bank.

## Related reading

- [Who does what in the payments industry](https://docs.switchtransact.com/faq/reference/payment-industry-roles)
- [The South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system)
- [Debit order disputes and stop payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)


# South African Payments Change Log

South African payments have changed substantially over the past few years: legacy debit order types have been retired, DebiCheck and registered mandates have replaced them, and instant payments have arrived through PayShap. This page keeps a running, reverse-chronological log of the milestones that matter to businesses collecting and making payments.

Use it to understand why older articles or bank documents reference systems that no longer exist, and what is on the horizon. For background on the system itself, see [the South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system), or return to the [Reference hub](https://docs.switchtransact.com/faq/reference).

### 2024

- **PayShap Request to Pay** launched, allowing a business or person to send a payment request that the payer approves in their banking app, extending PayShap beyond simple push payments. See [ShapIDs and Request to Pay](https://docs.switchtransact.com/faq/bank-transfers/shapids-and-request-to-pay).
- **PayShap adoption continued to grow**, with more banks participating and transaction limits and use cases expanding.
- **ISO 20022 adoption** progressed across the industry, aligning South African high-value and cross-border payment messaging with the international standard as SWIFT and domestic systems migrate.

### 2023

- **PayShap launched in March 2023**, introducing low-value instant payments between participating banks, including payments addressed to a ShapID proxy such as a cellphone number. See [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap).
- **Debit order dispute rules continued to be refined**, strengthening the distinction between authenticated (DebiCheck) collections, registered mandates and ordinary EFT debit orders in how disputes are handled. See [debit order disputes and stop payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments).

### 2022

- **Registered Mandate Service (RMS) usage grew** as an alternative for collections where DebiCheck authentication is impractical, giving banks visibility of mandates without payer authentication. See [what is a registered mandate](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).
- **DebiCheck bedding-down period**, with banks and collectors refining authentication success rates, tracking behaviour and reason code handling after the full rollout.

### 2021

- **NAEDO and AEDO were retired at the end of October 2021.** The legacy early debit order types were switched off, completing the migration of early-window collections to DebiCheck. Existing NAEDO/AEDO mandates were migrated under industry rules. See [migrated NAEDO and AEDO mandates](https://docs.switchtransact.com/faq/debit-orders/migrated-naedo-and-aedo-mandates).
- **DebiCheck rollout completed**, making authenticated collections fully operational across participating banks after a phased implementation directed by the SARB. See [how DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works).

### Earlier

- **DebiCheck phased rollout** ran over several years before 2021, with banks progressively enabling mandate authentication and collectors migrating from NAEDO.
- **Real-time clearing (RTC) availability expanded** over time, from limited operating hours to broad daily availability, making once-off instant credits a practical option well before PayShap.
- **Screen-scraping "instant EFT" services came under industry scrutiny**, with the SARB and banks raising concerns about services that log into customers' bank accounts on their behalf; this scrutiny has encouraged a shift toward PayShap and safer, API-based alternatives. See [instant EFT and open banking](https://docs.switchtransact.com/faq/other-payment-methods/instant-eft-and-open-banking).

## Looking ahead

The SARB's payments modernisation agenda continues, including the transition of PASA's functions to a new payments industry body, broader non-bank participation in the payment system, and further ISO 20022 migration. Details and dates are confirmed by the SARB and industry bodies as programmes progress.

This change log is updated periodically as notable industry changes take effect. If a change affects how your collections or payments behave, we cover the practical detail in the relevant topic section of this Knowledge Centre.


# Payment Reference Centre

Look up payment terminology, statuses, reason codes and the organisations that keep South Africa's payment system running.

## Topics in this section

- [Payments Glossary: Key Terms Explained](https://docs.switchtransact.com/faq/reference/glossary)
- [Payment Acronyms and Abbreviations Explained](https://docs.switchtransact.com/faq/reference/acronyms)
- [Payment Status Directory](https://docs.switchtransact.com/faq/reference/payment-status-directory)
- [Payment Reason Code Directory](https://docs.switchtransact.com/faq/reference/reason-code-directory)
- [Who Does What in the Payments Industry?](https://docs.switchtransact.com/faq/reference/payment-industry-roles)
- [Payment Regulators and Industry Organisations in South Africa](https://docs.switchtransact.com/faq/reference/regulators-and-industry-organisations)
- [South African Payments Change Log](https://docs.switchtransact.com/faq/reference/payments-change-log)


# How Do I Accept Payments Online in South Africa?

Accepting payments online means giving your customers a secure way to pay you over the internet, whether that is on a website, in a mobile app, or through a link you send them directly. In South Africa this usually involves a payments provider that connects your business to the card networks and the local banking system.

You do not need to build any of this infrastructure yourself. A provider like Kwik supplies the checkout, handles the security requirements, and settles the money you collect into your business bank account.

## What do I need before I can accept online payments?

Most South African payment providers will ask for the following before activating your account:

- A registered business or a valid South African ID if you trade as a sole proprietor
- A business bank account at a South African bank such as Absa, FNB, Nedbank, Standard Bank or Capitec for settlement
- Basic FICA documents, for example proof of address and directors' ID documents
- A description of what you sell, since some industries need extra approval

Once your account is approved you receive access to a dashboard and, if you are integrating with a website or app, API credentials. See [what a merchant account and merchant ID are](https://docs.switchtransact.com/faq/accepting-payments/merchant-account-and-merchant-id) for more on how this works behind the scenes.

## Which online payment methods can I offer?

South African shoppers pay online in several ways, and offering more than one method generally reduces abandoned checkouts:

- **Card payments** – debit and credit cards remain the most common online payment method. Payments are verified with [3-D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure), which usually means an OTP or banking app approval.
- **Instant EFT and open banking payments** – the customer pays directly from their bank account and you get real-time confirmation. See [instant EFT and open banking](https://docs.switchtransact.com/faq/other-payment-methods/instant-eft-and-open-banking).
- **PayShap** – a real-time payment method that lets customers pay from their banking app, often using just a cellphone number. Read more about [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap).
- **Digital wallets** – options such as Apple Pay and Google Pay let customers pay with a card stored on their device. See [digital wallets](https://docs.switchtransact.com/faq/card-payments/digital-wallets).
- **Recurring debit orders** – for subscriptions and instalments, [debit orders](https://docs.switchtransact.com/faq/debit-orders) collect from the customer's bank account on a schedule they have authorised.

## How do customers actually check out?

There are three broad ways to present a checkout, and they differ mainly in how much development work is involved:

1. **A hosted payment page** – the customer is redirected to a secure page run by your provider. This is the fastest to set up.
2. **An embedded checkout** – payment fields appear inside your own website, but the sensitive card data still goes directly to the provider.
3. **A direct API integration** – you build the full experience yourself, which gives maximum control but carries the heaviest compliance burden.

The trade-offs are covered in detail in [hosted, embedded and API checkout](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout).

## Can I accept payments online without a website?

Yes. [Payment links](https://docs.switchtransact.com/faq/accepting-payments/payment-links) let you create a secure checkout URL and share it over WhatsApp, email, SMS or on an invoice. The customer taps the link, pays on a hosted page, and you are notified when the payment succeeds. This is a common starting point for small businesses, freelancers and anyone invoicing clients directly.

## How does the money reach my bank account?

When a customer pays, the funds do not land in your account instantly. The payment is authorised in real time, then cleared and settled through the banking system, typically within one to a few business days depending on the payment method. Your provider pays the collected funds into your nominated business bank account and gives you reporting to reconcile each settlement. For the full journey of a transaction, see [how payments work](https://docs.switchtransact.com/faq/how-payments-work).

## Where should I start?

If you already have a website or app, start by choosing an integration model that matches your technical capacity, then enable cards plus at least one bank-based method such as instant EFT or PayShap. If you do not have a website yet, payment links let you get paid today. For guidance on which methods suit your business, read [which payment methods should your business offer](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods), or return to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments) for the full topic list.


# How Do I Accept In-Person Payments?

In-person payments are payments taken face to face, whether at a till, a market stall, a restaurant table or a customer's front door. In South Africa the main options are card machines, tap-to-pay on a smartphone, and QR code payments, and many businesses use a combination.

The right choice depends on your transaction volumes, whether you trade from a fixed location or on the move, and how much hardware you want to manage. Kwik offers in-person card acceptance through point-of-sale (POS) devices alongside its online payment options, so card, online and debit order collections can be managed in one place.

## What is a card machine and how does it work?

A card machine, also called a POS terminal or speed point, reads the customer's card and sends the transaction for authorisation. Modern devices accept:

- **Tap (contactless)** – the customer taps a card, phone or smartwatch on the terminal. Most in-person card payments in South Africa are now contactless.
- **Insert (chip and PIN)** – the customer inserts the card and enters a PIN, typically required for higher amounts.
- **Digital wallets** – Apple Pay, Google Pay and Samsung Pay all work on contactless terminals. See [digital wallets](https://docs.switchtransact.com/faq/card-payments/digital-wallets).

Terminals come in two broad forms:

| Option                     | Best for                                                 | Considerations                      |
| -------------------------- | -------------------------------------------------------- | ----------------------------------- |
| Countertop terminal        | Fixed retail locations with mains power and connectivity | Reliable, but not portable          |
| Mobile / portable terminal | Restaurants, deliveries, markets, mobile services        | Uses a SIM or Wi-Fi; needs charging |

Providers price terminals differently — some rent the device monthly, some sell it outright, and transaction fees vary by provider and card type — so compare total cost rather than just the headline rate.

## Can I accept card payments on my phone without a machine?

Yes. **SoftPOS** (also called tap-to-pay on phone) turns an NFC-capable Android smartphone into a card terminal using only an app. The customer taps their card or phone against yours, and the payment is processed like any other contactless transaction.

SoftPOS suits sole traders, delivery drivers and low-volume sellers because there is no hardware to buy or rent. The trade-off is that it depends on your phone's battery, connectivity and NFC hardware, and PIN entry for larger amounts happens on the phone screen.

## What about QR code payments?

QR payments let the customer scan a code with their banking app or a wallet app such as SnapScan or Zapper and approve the payment on their own phone. You can display a static printed code at the till or generate a dynamic code per transaction with the amount included.

QR is popular where card machines are impractical — markets, events, parking, donations — and requires no hardware beyond the printed code or a screen. Read more in [QR code payments](https://docs.switchtransact.com/faq/other-payment-methods/qr-code-payments).

## How quickly do I receive the money?

In-person card payments are authorised in seconds, but settlement into your business bank account typically takes one or more business days, depending on your provider and agreement. Funds settle to your nominated account at any major bank, including Absa, FNB, Nedbank, Standard Bank and Capitec. The mechanics are the same as for online card payments; see [how payments work](https://docs.switchtransact.com/faq/how-payments-work).

## What do I need to get started?

Requirements are similar to accepting payments online:

- A registered business or valid South African ID for sole proprietors
- A business bank account for settlement
- FICA documentation for verification
- A [merchant account with a merchant ID](https://docs.switchtransact.com/faq/accepting-payments/merchant-account-and-merchant-id), which your payments provider arranges

## Which in-person option should I choose?

As a rule of thumb:

- **Fixed retail with steady volume** – a countertop or portable card terminal.
- **Mobile trading or occasional sales** – SoftPOS on a smartphone.
- **Very low cost, no hardware at all** – a static QR code, or [payment links](https://docs.switchtransact.com/faq/accepting-payments/payment-links) sent to the customer on the spot via WhatsApp.

Many businesses also accept in-person and online payments through the same provider so that reporting, settlement and reconciliation stay in one place. For help weighing up the broader mix of methods, see [which payment methods should your business offer](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods), or go back to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments).


# What Is a Merchant Account and Merchant ID?

A merchant account is a special type of account that allows a business to accept card payments. When a customer pays you by card, the funds are first authorised and processed through this account before being settled into your ordinary business bank account. A merchant ID, or MID, is the unique number that identifies your business within the card payment system.

You will encounter both terms when signing up with any payments provider in South Africa, so it helps to understand what each one does and who actually issues them.

## What does a merchant account actually do?

A merchant account sits between your customer's card payment and your business bank account. It exists because card payments are not instant transfers — they are authorised first, then cleared and settled later, and they can be reversed through refunds and chargebacks.

The merchant account:

- Receives the proceeds of your card transactions from the card networks
- Holds funds briefly while transactions clear
- Nets off refunds, chargebacks and fees
- Pays the balance into your nominated business bank account on the agreed settlement cycle

For the full transaction journey, see [how payments work](https://docs.switchtransact.com/faq/how-payments-work).

## How is a merchant account different from a business bank account?

They serve different purposes and you need both:

|                        | Merchant account                       | Business bank account                                     |
| ---------------------- | -------------------------------------- | --------------------------------------------------------- |
| Purpose                | Accepts and processes card payments    | Holds and manages your business funds                     |
| Opened with            | An acquiring bank or payments provider | Any bank, e.g. Absa, FNB, Nedbank, Standard Bank, Capitec |
| Can you spend from it? | No                                     | Yes                                                       |
| Where settlements land | Sends funds out                        | Receives funds in                                         |

Your business bank account is where the money ultimately arrives. The merchant account is the processing layer that makes card acceptance possible.

## What is a merchant ID (MID)?

A merchant ID is the unique identifier assigned to your business when your merchant account is created. Every card transaction you process carries your MID, which is how the card networks, the [acquirer](https://docs.switchtransact.com/faq/accepting-payments/gateway-processor-switch-acquirer) and the issuing banks know which business the payment belongs to.

Your MID matters in practice because it is used to:

- Route settlements to the correct business
- Identify your business on the customer's card statement, together with your trading name
- Track your chargeback and fraud ratios, which affect your standing with the card schemes
- Link transactions in disputes and investigations

A business can hold more than one MID — for example separate MIDs for online and in-person sales, or for different trading brands — which keeps reporting and statement descriptors clean.

## How do I get a merchant account in South Africa?

There are two routes:

1. **Directly from an acquiring bank.** You apply to a bank's merchant services division. This usually suits larger businesses with high volumes and involves a fuller application process.
2. **Through a payments provider.** Providers such as Kwik hold acquiring relationships and onboard you under their infrastructure, so you get a merchant facility as part of signing up. This is the quickest route for most small and medium businesses.

Either way, expect to provide company registration or ID documents, FICA verification, your settlement bank account details and a description of your business. Some industries are considered higher risk and may require additional review.

## Why do merchant accounts involve vetting?

Because card payments can be reversed, the acquirer carries financial risk on your transactions: if your business receives payments and then cannot honour refunds or chargebacks, the acquirer is liable to the card networks. Vetting, and sometimes rolling reserves or settlement delays, is how that risk is managed. Keeping disputes low protects your merchant account; see [disputes, risk and compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance) for how chargebacks work.

## Related reading

- [How do I accept payments online?](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)
- [Gateway vs processor vs switch vs acquirer](https://docs.switchtransact.com/faq/accepting-payments/gateway-processor-switch-acquirer)
- [Card payments](https://docs.switchtransact.com/faq/card-payments)
- Back to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments)


# Gateway vs Processor vs Switch vs Acquirer: What Is the Difference?

Gateway, processor, switch and acquirer are four terms that get used loosely — and sometimes interchangeably — in the payments industry, which makes them confusing when you are comparing providers. Each one describes a distinct role in moving a card payment from your customer to your bank account.

In practice a single company often performs more than one of these roles, which is where the confusion comes from. This page separates them out so you know what you are actually buying.

## The four roles at a glance

| Role      | What it does                                                                     | Who you deal with                           |
| --------- | -------------------------------------------------------------------------------- | ------------------------------------------- |
| Gateway   | Captures payment details securely at checkout and passes them on                 | Your payments provider                      |
| Processor | Handles the technical processing of the transaction between parties              | Usually behind the scenes                   |
| Switch    | Routes transactions between banks and card networks                              | Infrastructure layer, never customer-facing |
| Acquirer  | The licensed bank that accepts card payments on your behalf and carries the risk | Directly, or via your provider              |

## What is a payment gateway?

The gateway is the front door of a transaction. It is the technology that securely captures the customer's card details on your website, app or [payment link](https://docs.switchtransact.com/faq/accepting-payments/payment-links), encrypts them, and sends them onwards for authorisation. The gateway also returns the result — approved or declined — to your checkout.

Because the gateway handles raw card data, it carries most of the [PCI DSS](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss) security burden. Using a provider's gateway, rather than touching card data yourself, is what keeps your own compliance scope small. How much of that scope you take on depends on your integration choice; see [hosted, embedded and API checkout](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout).

## What is a payment processor?

The processor does the heavy lifting behind the gateway. It takes the transaction from the gateway, communicates with the card networks and the relevant banks, manages authorisation requests and responses, and handles clearing and settlement files afterwards. Processors also deal with operational events such as refunds and reversals.

Merchants rarely contract with a processor directly. Your payments provider either is the processor or has a processing relationship, and the distinction mostly matters when diagnosing where in the chain a payment failed. For what happens when a payment is declined, see [card declines and response codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes).

## What is a switch?

A switch is routing infrastructure. It receives a transaction and directs it to the correct destination — the right card network, the right issuing bank, or the national payment system. In South Africa, interbank transactions are cleared through national payments infrastructure, and switches are the plumbing that connects the participants.

You will never integrate with a switch as a merchant. The term appears in industry conversation because some companies market themselves as switches, meaning they specialise in that routing layer rather than in merchant-facing services.

## What is an acquirer?

The acquirer, or acquiring bank, is a licensed bank that is a member of the card schemes (such as Visa and Mastercard) and is authorised to accept card payments on behalf of merchants. The acquirer:

- Sponsors your [merchant account and merchant ID](https://docs.switchtransact.com/faq/accepting-payments/merchant-account-and-merchant-id)
- Receives settled funds from the card networks and pays them to you
- Carries the financial liability for your chargebacks and refunds
- Enforces scheme rules and risk requirements on your account

In South Africa the major acquiring banks include divisions of the big retail banks. Most small and medium businesses do not contract with an acquirer directly; instead, a payments provider aggregates merchants under its own acquiring relationships.

## How do the roles fit together in one transaction?

For a typical online card payment:

1. The customer enters card details at checkout — the **gateway** captures and encrypts them.
2. The **processor** sends an authorisation request via the card network, with the **switch** routing it to the customer's issuing bank.
3. The issuing bank approves or declines, often after [3-D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure) verification, and the response travels back the same way.
4. Later, cleared funds flow from the issuing bank through the network to the **acquirer**, which settles them to your bank account.

## Why does this matter when choosing a provider?

Full-service providers such as Kwik bundle the gateway, processing and acquiring relationships into one agreement, so you get one contract, one settlement and one support channel. When comparing providers, ask which roles they perform themselves and which they outsource — it affects support, reliability and how quickly issues get resolved. For the broader transaction flow, see [how payments work](https://docs.switchtransact.com/faq/how-payments-work), or return to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments).


# Hosted, Embedded and API Checkout: Which Should You Use?

When you integrate online payments into a website or app, you have to decide how much of the checkout experience you build yourself and how much your payments provider handles for you. The three common models are a hosted payment page, an embedded checkout, and a direct API integration.

The choice affects development effort, how much control you have over the customer experience, and — importantly — how much of the [PCI DSS](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss) security burden falls on your business. This page compares the three so you can pick the right starting point.

## The three models compared

|                            | Hosted checkout               | Embedded checkout                        | Direct API            |
| -------------------------- | ----------------------------- | ---------------------------------------- | --------------------- |
| Where the customer pays    | On the provider's secure page | On your page, inside provider components | Entirely on your page |
| Development effort         | Lowest                        | Moderate                                 | Highest               |
| Control over look and feel | Limited                       | Good                                     | Full                  |
| PCI DSS scope for you      | Smallest                      | Small                                    | Largest               |
| Who handles card data      | The provider                  | The provider, via its components         | Potentially you       |

## What is a hosted checkout?

With a hosted checkout, the customer is redirected from your website to a secure payment page operated by your provider. They complete the payment there — card details, [3-D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure) verification, alternative methods like instant EFT or PayShap — and are then returned to your site with the result.

**Advantages:**

- Fastest to integrate; often just a redirect and a return URL
- Card data never touches your servers, keeping your PCI scope minimal
- The provider maintains the page, so new payment methods and security updates arrive without work on your side

**Trade-offs:**

- The customer briefly leaves your site, which you have less control over
- Branding and layout options are limited to what the provider allows

Hosted checkout is the right default for most small and medium businesses, and it is the same model that powers [payment links](https://docs.switchtransact.com/faq/accepting-payments/payment-links) — a payment link is essentially a hosted checkout page reachable by URL.

## What is an embedded checkout?

Embedded checkout keeps the customer on your website while the sensitive fields — card number, expiry, CVV — are rendered inside secure components (often iframes) served by your provider. To the customer it looks like a seamless part of your page, but the card data flows directly to the provider and never passes through your systems.

**Advantages:**

- A seamless, on-brand experience with no redirect
- PCI scope stays small because you never handle raw card data
- You control the surrounding page: order summary, upsells, layout

**Trade-offs:**

- More development work than a redirect, including handling callbacks and error states
- You are responsible for the page around the components, so front-end quality matters

Embedded checkout suits businesses that care about conversion and brand consistency and have some development capacity.

## What is a direct API integration?

With a direct API integration you build the entire checkout yourself and communicate with the provider's API server-to-server. This gives full control — custom flows, saved cards, complex order logic — but if raw card details pass through your servers, your business falls into the most demanding PCI DSS compliance levels, which requires audits and significant security investment.

For this reason, pure direct-API card integrations are rare outside large enterprises. Most "API" integrations in practice combine server-side APIs for orders, refunds and reporting with tokenised or component-based capture of the card details, keeping compliance manageable. For a broader look at integration approaches, see [payment integration models](https://docs.switchtransact.com/faq/payment-operations/payment-integration-models).

## How do I get notified of payment results?

Whichever model you choose, do not rely only on the customer's browser returning to your success page — connections drop and customers close tabs. Use server-to-server notifications, called webhooks, as the source of truth for payment outcomes. See [webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks).

## Which one should you choose?

- **No developers, or you want to launch this week:** hosted checkout or payment links.
- **A development team and a conversion-focused website:** embedded checkout.
- **Complex, high-volume requirements and dedicated engineering:** API-led integration with tokenised card capture.

Kwik supports hosted checkout out of the box, so you can start simple and move to a deeper integration as your volumes grow. For the bigger picture of going live with online payments, read [how do I accept payments online](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online), or return to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments).


# What Are Payment Links and How Do They Work?

A payment link is a secure URL that opens a checkout page where your customer can pay you. Instead of building a website with an integrated checkout, you create the link — usually from a dashboard or an app — and send it to the customer over WhatsApp, email, SMS, or by adding it to an invoice or social media post.

Payment links are one of the simplest ways to accept digital payments in South Africa, and they are a core part of what Kwik offers. They need no development work, no card machine and no website.

## How does a payment link work?

The flow is straightforward:

1. You create a link, typically specifying the amount, a description and a reference.
2. You share the link with your customer through any channel — WhatsApp is the most common in South Africa.
3. The customer taps the link and lands on a secure, hosted checkout page.
4. They choose how to pay — card, instant EFT, PayShap or another enabled method — and complete the payment.
5. You are notified that the payment succeeded, and the funds settle to your business bank account on your normal settlement cycle.

The checkout page is hosted by the payments provider, so card details never pass through your hands and the [PCI DSS](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss) security requirements are handled for you. Under the hood, a payment link is the same technology as a [hosted checkout](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout), just reachable by URL instead of embedded in a website flow.

## What can customers pay with on a payment link?

That depends on which methods your provider supports and you have enabled. Typical options for South African customers include:

- **Debit and credit cards**, verified with [3-D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure)
- **Instant EFT**, paying directly from internet banking at Absa, FNB, Nedbank, Standard Bank, Capitec and others — see [instant EFT and open banking](https://docs.switchtransact.com/faq/other-payment-methods/instant-eft-and-open-banking)
- **PayShap**, for real-time account-to-account payments — see [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap)
- **Digital wallets** such as Apple Pay and Google Pay on supported devices

Offering more than one method on the link improves the chance the customer completes the payment.

## What types of payment links are there?

- **Once-off links** for a single payment of a fixed amount, such as an invoice or quote.
- **Reusable links** that can be paid multiple times, useful for a standard product, donation or event ticket.
- **Open-amount links** where the customer enters the amount, common for donations and account top-ups.
- **Links with expiry dates**, so a quote or offer cannot be paid after it lapses.

Availability of each type varies by provider.

## Who are payment links best for?

Payment links suit any business that invoices or bills customers directly rather than through an online store:

- Freelancers and consultants attaching a link to an invoice
- Trades and services collecting deposits or final payment on completion
- Sellers on Instagram, Facebook Marketplace or WhatsApp who have no website
- Businesses taking phone or email orders
- Schools, clubs and charities collecting fees and donations

They are also useful alongside a full website — for example, to recover a failed online payment or to charge a custom amount agreed with a specific customer.

## Are payment links safe?

Yes, when they come from a reputable provider. The checkout page is encrypted, card payments are verified with 3-D Secure, and the merchant never sees the customer's card details. Customers should still be cautious of links from unknown senders; as a business, sending links from a recognisable number or email address, with a clear description and reference, helps customers trust the request.

## Payment links vs other ways to get paid

|                 | Payment link                  | Online checkout  | Card machine              |
| --------------- | ----------------------------- | ---------------- | ------------------------- |
| Website needed  | No                            | Yes              | No                        |
| Hardware needed | No                            | No               | Yes                       |
| Setup effort    | Minutes                       | Development work | Device delivery and setup |
| Best for        | Remote, invoice-based billing | E-commerce       | Face-to-face sales        |

If your billing is recurring — subscriptions, memberships, instalments — a [debit order](https://docs.switchtransact.com/faq/debit-orders) collected against a mandate is usually a better fit than sending a link every month.

## Related reading

- [How do I accept payments online?](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)
- [Which payment methods should your business offer?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)
- Back to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments)


# Which Payment Methods Should Your Business Offer?

There is no single best payment method — there is only the best mix for your business. The right combination depends on who your customers are, how you sell, what each method costs you, how quickly you need the money, and whether your billing is once-off or recurring.

This page gives you a framework for choosing, using the payment methods available to South African businesses through providers like Kwik.

## What are the main options in South Africa?

| Method                                    | Best suited to                              | Settlement                                | Can it be reversed by the customer? |
| ----------------------------------------- | ------------------------------------------- | ----------------------------------------- | ----------------------------------- |
| Card (online and in-person)               | E-commerce, retail, services                | Typically 1+ business days                | Yes, via chargeback                 |
| Instant EFT / open banking                | Online checkout, higher-value payments      | Real-time confirmation; settlement varies | Generally no                        |
| PayShap                                   | Real-time account-to-account payments       | Real-time                                 | Generally no                        |
| Debit orders (EFT and DebiCheck)          | Subscriptions, instalments, memberships     | On scheduled collection dates             | Yes, disputes are possible          |
| Payment links                             | Invoicing, remote selling without a website | As per underlying method                  | As per underlying method            |
| QR codes (SnapScan, Zapper, banking apps) | In-person, events, donations                | Per provider                              | Rarely                              |

## What questions should guide the decision?

### Who are your customers and how do they prefer to pay?

Offer the methods your customers already use. Card is the baseline expectation for online and in-person retail. Bank-based methods like [instant EFT](https://docs.switchtransact.com/faq/other-payment-methods/instant-eft-and-open-banking) and [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) reach customers across all the major banks — Absa, FNB, Nedbank, Standard Bank and Capitec — including those who prefer not to use a card online. [Digital wallets](https://docs.switchtransact.com/faq/card-payments/digital-wallets) matter more if your customers skew towards smartphone-first shopping.

### Is your billing once-off or recurring?

For once-off sales, cards, instant EFT, PayShap and [payment links](https://docs.switchtransact.com/faq/accepting-payments/payment-links) all work well. For recurring billing — subscriptions, insurance premiums, school fees, loan instalments — [debit orders](https://docs.switchtransact.com/faq/debit-orders) are usually the strongest fit because collection happens automatically against a customer mandate, without the customer needing to act each month. [DebiCheck](https://docs.switchtransact.com/faq/debicheck) adds bank-confirmed mandates, which strengthens your position in disputes.

### How quickly do you need the money?

Real-time methods like PayShap and instant EFT confirm payment immediately, which matters if you release goods or services on the spot. Card payments authorise instantly but settle later. Debit orders collect on scheduled dates and can fail for insufficient funds, so build that into your cash flow planning. For the mechanics, see [how payments work](https://docs.switchtransact.com/faq/how-payments-work).

### What does each method cost?

Pricing differs by method and provider — typically a percentage per transaction for cards, and often lower or flat fees for bank-based methods and debit orders. Rather than chasing the cheapest headline rate, compare the total cost including settlement timing, failed-payment fees and any monthly charges, and weigh it against the revenue each method unlocks. A slightly costlier method that stops customers abandoning checkout usually pays for itself.

### What is your risk exposure?

Card payments can be reversed through chargebacks, so businesses in dispute-prone industries should pay attention to [3-D Secure](https://docs.switchtransact.com/faq/card-payments/3d-secure) and their dispute processes — see [disputes, risk and compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance). Bank-based push payments like instant EFT and PayShap are initiated by the customer and are far harder to reverse, which makes them attractive for high-value or high-risk sales. Debit orders can be disputed by the payer, which is where DebiCheck's bank-confirmed mandates help.

## Sensible starting combinations

- **Online store:** cards plus instant EFT or PayShap, with digital wallets if your provider supports them.
- **Service business invoicing clients:** payment links carrying card and bank-based options.
- **Subscription or membership business:** debit orders (DebiCheck where appropriate) for the recurring charge, plus a card or link option for sign-up and arrears.
- **Face-to-face selling:** a card terminal or SoftPOS, plus a QR code — see [in-person payments](https://docs.switchtransact.com/faq/accepting-payments/accept-in-person-payments) and [QR code payments](https://docs.switchtransact.com/faq/other-payment-methods/qr-code-payments).

## Start small and expand

You do not need every method on day one. Launch with one or two that match how you sell, watch where customers drop off or ask for alternatives, and add methods as the data justifies it. Using a single provider for multiple methods keeps settlement and reconciliation in one place as your mix grows.

For the fundamentals, start with [how do I accept payments online](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online), or return to the [accepting payments hub](https://docs.switchtransact.com/faq/accepting-payments).


# Accepting Payments

Learn what your business needs to accept payments, which providers and tools are involved, and how to choose the right mix of payment methods for your customers.

## Topics in this section

- [How Do I Accept Payments Online in South Africa?](https://docs.switchtransact.com/faq/accepting-payments/accept-payments-online)
- [How Do I Accept In-Person Payments?](https://docs.switchtransact.com/faq/accepting-payments/accept-in-person-payments)
- [What Is a Merchant Account and Merchant ID?](https://docs.switchtransact.com/faq/accepting-payments/merchant-account-and-merchant-id)
- [Gateway vs Processor vs Switch vs Acquirer: What Is the Difference?](https://docs.switchtransact.com/faq/accepting-payments/gateway-processor-switch-acquirer)
- [Hosted, Embedded and API Checkout: Which Should You Use?](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout)
- [What Are Payment Links and How Do They Work?](https://docs.switchtransact.com/faq/accepting-payments/payment-links)
- [Which Payment Methods Should Your Business Offer?](https://docs.switchtransact.com/faq/accepting-payments/choose-payment-methods)


# How Do Card Payments Work?

Every card payment, whether it is a tap at a till or a checkout on a website, follows the same basic journey. The transaction travels from the merchant to an acquiring bank, across a card network such as Visa or Mastercard, to the bank that issued the card, and back again with an approve or decline answer. This round trip usually takes a few seconds.

In South Africa, the vast majority of cards are Visa or Mastercard cards issued by banks such as Absa, FNB, Nedbank, Standard Bank, Capitec, TymeBank and Discovery Bank. Understanding the parties involved makes it much easier to follow topics like authorisation, declines, refunds and chargebacks.

## Who Is Involved in a Card Payment?

Four main parties, plus the network that connects them, take part in every card transaction:

- **Cardholder** – the customer paying with a debit, credit or prepaid card.
- **Merchant** – the business accepting the card payment, in person or online.
- **Acquirer** – the bank or payment institution that processes card transactions on behalf of the merchant and settles the money to the merchant.
- **Card network** – Visa or Mastercard (and others), which routes messages between the acquirer and the issuer and sets the scheme rules.
- **Issuer** – the cardholder's bank, which approves or declines the transaction and debits the cardholder's account.

A payment provider such as Kwik sits between the merchant and the acquirer, handling the checkout, card machine or payment link, securing the card details and passing the transaction into the card system.

## What Happens Step by Step?

A typical card payment follows this sequence:

1. **Initiation** – the cardholder taps, inserts or swipes a card at a terminal, or enters card details online.
2. **Authentication** – where required, the cardholder is verified with a PIN at the terminal or 3D Secure online.
3. **Authorisation request** – the transaction details travel from the merchant through the acquirer and card network to the issuer.
4. **Issuer decision** – the issuer checks that the card is valid, funds or credit are available and the transaction does not look fraudulent, then returns an approval or a decline.
5. **Response** – the answer travels back through the network to the merchant within seconds.
6. **Capture and clearing** – approved transactions are submitted for clearing, where the schemes exchange the transaction records between banks.
7. **Settlement** – the money moves from the issuer to the acquirer, and the acquirer pays the merchant, less any agreed fees.

Authorisation and settlement are separate steps. An approval reserves the funds on the cardholder's account, but the merchant is only paid once the transaction has been captured, cleared and settled. See [Authorisation, Capture and Pre-Authorisation](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation) for detail.

## Why Do Some Payments Fail?

The issuer can decline a transaction for many reasons, including insufficient funds, an expired card, incorrect details or suspected fraud. Some declines are temporary and can be retried, while others are final. [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes) explains the common decline categories.

## How Are Card Payments Kept Secure?

Several layers of security protect a card payment:

- **EMV chip and contactless** technology makes physical cards very difficult to clone.
- **PIN and 3D Secure** verify that the person paying is the genuine cardholder.
- **Tokenisation and encryption** protect card numbers in transit and in storage.
- **PCI DSS** sets the security standard that everyone handling card data must meet.

Read more in [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure) and [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [Gateways, Processors, Switches and Acquirers](https://docs.switchtransact.com/faq/accepting-payments/gateway-processor-switch-acquirer)
- [How Payments Work](https://docs.switchtransact.com/faq/how-payments-work)


# What Are Digital Wallets and How Do They Work?

A digital wallet lets a customer pay with a card stored on their phone, watch or browser instead of carrying the physical card or typing in card details. The best-known wallets in South Africa are Apple Pay, Google Pay and Samsung Pay, and most of the major issuing banks, including Absa, FNB, Nedbank, Standard Bank, Capitec, TymeBank and Discovery Bank, support adding their cards to at least some of these wallets.

Under the hood, a wallet payment is still a Visa or Mastercard transaction. What changes is how the card details are stored and presented: the wallet never uses the real card number, and every payment is approved with the device's own security, such as a fingerprint or face scan.

## How Does a Digital Wallet Work?

When a customer adds a card to a wallet:

1. The wallet sends the card details to the card network and the issuing bank for verification (the customer may need to approve the addition via their banking app or an OTP).
2. The network issues a **device token**, a substitute card number bound to that specific device, and the real card number is never stored on the phone.
3. From then on, every payment uses the device token plus a one-time cryptogram, authorised by the customer with biometrics or the device passcode.

This is network tokenisation applied to a device; see [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens) for how tokens work in general.

## Where Can Wallets Be Used?

- **In store** – the customer taps their phone or watch on any contactless-enabled terminal, including SoftPOS devices. To the terminal this looks like an ordinary contactless payment, so no special merchant setup is needed. See [Chip, Contactless and SoftPOS Payments](https://docs.switchtransact.com/faq/card-payments/chip-contactless-and-softpos).
- **Online and in-app** – the checkout shows an Apple Pay or Google Pay button. The customer confirms with a fingerprint or face scan instead of typing card details, which removes most of the checkout friction.

## Why Are Wallet Payments Secure?

- The **real card number is never shared** with the merchant or stored on the device; only the device token is used.
- Each payment carries a **unique cryptogram**, so intercepted data cannot be replayed.
- Every payment requires the **cardholder's biometric or passcode**, providing strong customer verification.
- If the phone is lost or stolen, the customer can disable the wallet remotely without cancelling the underlying card, and the physical card keeps working.

Because of this strong built-in authentication, wallet transactions carry a low fraud profile. In-store wallet taps are treated as card-present transactions, and online wallet payments carry stronger authentication data than a typed card number.

## What Do Merchants Need to Accept Wallets?

- **In person** – any contactless-capable card machine or SoftPOS app already accepts wallets. Nothing extra is required.
- **Online** – the payment provider must support the wallet, and the merchant enables the wallet button in their checkout. Hosted checkouts typically switch this on with minimal effort; see [Hosted, Embedded and API Checkouts](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout).
- Wallet transactions settle through the same acquiring relationship as ordinary card payments; there is no separate settlement stream to reconcile.

## Are Wallet Payments Different from Card Payments for Refunds and Disputes?

No. Because a wallet payment is a card payment underneath, refunds, reversals, chargebacks and settlement all work the same way. A refund on a wallet payment goes back to the underlying card account, even if the customer has since removed the card from the wallet. See [Card Refunds, Reversals and Voids](https://docs.switchtransact.com/faq/card-payments/card-refunds-reversals-and-voids).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens)
- [Card-Present vs Card-Not-Present](https://docs.switchtransact.com/faq/card-payments/card-present-vs-card-not-present)


# Recurring Card Payments: What Are CIT and MIT?

Recurring card payments let a business charge a customer's saved card on a schedule, for subscriptions, memberships, insurance premiums or instalments, without the customer being present for each charge. To make this safe and traceable, the card schemes divide transactions into two classes: customer-initiated transactions (CIT), where the cardholder actively takes part, and merchant-initiated transactions (MIT), where the merchant charges a stored card under a prior agreement.

Getting the CIT/MIT framework right matters. Correctly flagged transactions are approved more often, comply with Visa and Mastercard rules, and stand up better if a customer disputes a charge.

## What Is a Customer-Initiated Transaction (CIT)?

A CIT is any transaction where the cardholder actively participates at the time of payment, for example:

- Paying at an online checkout
- Tapping a card at a terminal
- Paying through a payment link
- The initial sign-up payment for a subscription, even a R0 or small card-verification charge

Because the customer is present, a CIT can be authenticated with 3D Secure. The first payment in any recurring relationship must be a CIT, and it is where the customer's agreement to future charges is established.

## What Is a Merchant-Initiated Transaction (MIT)?

An MIT is a transaction the merchant submits later using stored credentials, without the customer being present, based on the agreement made during the initial CIT. Common MIT types include:

- **Recurring** – fixed, scheduled charges such as a monthly subscription.
- **Instalment** – a fixed number of scheduled payments for a single purchase.
- **Unscheduled card-on-file** – charges triggered by an event rather than a schedule, such as an automatic top-up when a prepaid balance runs low.
- **Operational MITs** – amounts such as a no-show fee or delayed charge permitted under the original agreement.

MITs cannot be 3D Secure authenticated (nobody is there to approve a prompt), so the schemes require them to reference the original authenticated transaction, proving the chain of consent back to the initial CIT.

## CIT vs MIT at a Glance

| Aspect              | CIT                                         | MIT                                                   |
| ------------------- | ------------------------------------------- | ----------------------------------------------------- |
| Cardholder present? | Yes                                         | No                                                    |
| 3D Secure possible? | Yes, and usually applied                    | No; relies on the original CIT's authentication       |
| Triggered by        | The customer                                | The merchant, per prior agreement                     |
| Examples            | Checkout payment, first subscription charge | Monthly billing, instalments, auto top-ups            |
| Consent evidence    | Established at the time of payment          | Must reference the original agreement and transaction |

## What Does a Valid Recurring Setup Look Like?

1. **Clear consent** – during sign-up, the customer agrees to the amount (or how it is calculated), the frequency and the cancellation terms. Keep this evidence.
2. **Authenticated first payment** – the initial CIT is processed with 3D Secure, and the card is tokenised for storage. See [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure) and [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens).
3. **Correctly flagged MITs** – each subsequent charge is submitted as the correct MIT type, referencing the initial transaction.
4. **Easy cancellation** – scheme rules and good practice require that cancelling is straightforward; hard-to-cancel subscriptions drive chargebacks.

## Why Do Recurring Card Payments Fail, and What Helps?

Stored-card charges fail for the usual reasons, most commonly insufficient funds on debit cards and expired or reissued cards. Practical mitigations:

- **Retry soft declines** on a sensible schedule, for example aligned to common South African salary dates. See [Dunning and Payment Recovery](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery).
- **Keep credentials fresh** with network tokens and account updater services, so reissued cards keep working. See [Backup Cards and Account Updaters](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters).
- **Collect a backup card** where the business model justifies it.
- **Notify customers before billing**, especially after a price change, which reduces disputes and involuntary churn.

For a broader treatment of subscription billing strategy, see [Recurring Card Payments](https://docs.switchtransact.com/faq/billing/recurring-card-payments) in the Billing section.

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)
- [Recurring Card Payments (Billing)](https://docs.switchtransact.com/faq/billing/recurring-card-payments)
- [Card Chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks)


# Card Refunds, Reversals and Voids Explained

When money needs to go back to a cardholder, the right mechanism depends on how far the original transaction has progressed. A void or reversal cancels a transaction before it settles, so the customer's reserved funds are simply released. A refund is a new transaction that pushes money back to the card after settlement has already happened.

Choosing the right one matters for the customer experience: a released hold restores the customer's available balance without money ever having moved, while a refund has to travel back through the card networks and can take several business days to reflect.

## Refund vs Reversal vs Void

| Aspect          | Void                                                    | Reversal                                                             | Refund                                                     |
| --------------- | ------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------- |
| When it applies | After authorisation, before capture or batch settlement | Cancels an authorisation or an errored transaction before settlement | After the transaction has been captured and settled        |
| What happens    | The transaction is cancelled; it never settles          | The authorisation hold is released                                   | A new credit transaction sends money back to the card      |
| Money moved?    | No                                                      | No                                                                   | Yes                                                        |
| Customer sees   | Pending amount disappears                               | Pending amount disappears                                            | A separate credit on their statement                       |
| Typical timing  | Hold release depends on the issuer, often within days   | Hold release depends on the issuer, often within days                | Several business days to reflect on the customer's account |

Terminology varies between providers: "void" and "reversal" are often used interchangeably, and some platforms expose only a single "cancel" action that voids or reverses depending on the transaction state.

## When Should You Void or Reverse Instead of Refund?

Whenever the transaction has not yet settled. Typical situations:

- The customer cancels an order minutes after placing it.
- A duplicate transaction is spotted on the same day.
- A pre-authorisation hold is no longer needed, for example a rental deposit after the vehicle is returned. See [Authorisation, Capture and Pre-Authorisation](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation).

Voiding is better for everyone: no money moves, so there is nothing to reconcile, and the customer's funds are released rather than being debited and later re-credited. Note that the release of the pending amount is controlled by the issuing bank, so customers of different South African banks may see the hold disappear at different speeds.

## How Do Card Refunds Work?

A refund is a payment in the opposite direction. The merchant instructs the refund through their payment provider, the amount flows back through the acquirer and card network, and the issuing bank credits the cardholder's account.

Key points:

- **Refund to the original card only.** Scheme rules require refunds to go back to the card that paid. This protects against money-laundering and keeps the audit trail intact. If the card has been closed, the issuing bank still receives the refund and routes it to the customer.
- **Partial refunds are allowed.** You can refund any amount up to the original transaction value, and in most cases split it across multiple partial refunds.
- **Timing depends on the banks.** Refunds commonly take a few business days to show on the customer's statement, and timing differs between issuers. Tell customers this upfront to avoid "where is my refund?" queries.
- **Fees are not always returned.** Depending on your pricing agreement, the processing fees on the original transaction may not be reimbursed when you refund. Check your provider's terms rather than assuming.
- **Refunds are not disputes.** A refund is voluntary. If the cardholder instead disputes the transaction through their bank, that is a chargeback, a formal process with evidence requirements and additional cost. Refunding quickly when a customer has a valid claim is almost always cheaper than losing a chargeback. See [Card Chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks).

## Practical Tips for Merchants

- Prefer a void or reversal over a refund whenever the transaction has not settled.
- Publish a clear refund policy and set expectations about how long refunds take to reflect.
- Use idempotency controls so a refund cannot accidentally be submitted twice. See [Idempotency and Duplicate Payments](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates).
- Track refund events via webhooks so your order system and your payment records stay in sync. See [Webhooks and Callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks).
- Watch your refund rate; an unusually high one can indicate product, fulfilment or fraud problems.

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [Authorisation, Capture and Pre-Authorisation](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation)
- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [Card Chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks)


# Debit, Credit and Prepaid Cards: What Is the Difference?

Debit, credit and prepaid cards all look similar, carry a Visa or Mastercard logo and work at the same terminals and online checkouts. The difference lies in where the money comes from: a debit card draws directly from a bank account, a credit card draws from a credit facility, and a prepaid card draws from a balance loaded onto the card in advance.

For a merchant the acceptance experience is largely the same, but the card type can affect authorisation behaviour, decline rates, recurring billing reliability and refunds. South African banks such as Absa, FNB, Nedbank, Standard Bank, Capitec, TymeBank and Discovery Bank issue all three types, with debit cards being by far the most widely held.

## How Do the Three Card Types Compare?

| Feature                  | Debit card                                   | Credit card                            | Prepaid card                                      |
| ------------------------ | -------------------------------------------- | -------------------------------------- | ------------------------------------------------- |
| Source of funds          | Cardholder's bank account                    | Credit facility from the issuer        | Balance loaded onto the card                      |
| Approval check           | Available account balance                    | Available credit limit                 | Available loaded balance                          |
| Linked to a bank account | Yes                                          | Not directly                           | Usually not                                       |
| Typical holder           | Most banked South Africans                   | Customers who pass a credit assessment | Gift cards, youth cards, unbanked or budget users |
| Recurring payments       | Supported, but fails if the account is empty | Generally most reliable                | Often unreliable or blocked                       |
| Overspending possible    | No, limited to balance                       | Yes, up to the credit limit            | No, limited to loaded value                       |

## What Is a Debit Card?

A debit card is linked directly to a transactional bank account. When the cardholder pays, the issuer checks the available balance and reserves the amount immediately. If the balance is too low, the payment is declined with an insufficient funds response.

Modern South African debit cards are full scheme cards (Visa or Mastercard) with EMV chips and contactless capability, and most can be used online with 3D Secure. Older "electron" style cards that only worked at physical terminals have largely been phased out.

## What Is a Credit Card?

A credit card draws on a revolving credit facility rather than a bank balance. The issuer checks the available credit limit at authorisation and the cardholder repays the issuer later.

For merchants, credit cards tend to be the most dependable option for recurring and card-on-file billing, because a temporary lack of cash in a bank account does not cause the payment to fail in the way it does with a debit card. Credit cards are also commonly used for pre-authorisation holds by hotels and car rental companies.

## What Is a Prepaid Card?

A prepaid card carries a stored balance that is loaded before it can be spent. It is not linked to a bank account or credit facility, so spending is limited to the loaded value. Prepaid cards include gift cards, travel cards and budgeting cards, and they are often used by customers without a full bank account.

Points for merchants to note:

- Prepaid cards frequently fail on recurring payments because the balance may be empty when the charge is attempted.
- Some prepaid products are blocked for online, international or merchant-initiated transactions.
- Refunds to a prepaid card go back onto the card balance, which can be a problem if the card has expired or been discarded.

## Does the Card Type Matter for Merchants?

In most cases you accept all three types through the same terminal or checkout without doing anything different. The card type matters most when you:

- **Bill on a schedule** – expect more retries and failures on debit and prepaid cards. See [Recurring Card Payments: CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit) and [Dunning and Payment Recovery](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery).
- **Place holds** – pre-authorisations on debit cards lock up the customer's real cash, which can cause complaints. See [Authorisation, Capture and Pre-Authorisation](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation).
- **Process refunds** – a refund always goes back to the original card, whatever the type. See [Card Refunds, Reversals and Voids](https://docs.switchtransact.com/faq/card-payments/card-refunds-reversals-and-voids).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)
- [Backup Cards and Account Updaters](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters)


# Card-Present vs Card-Not-Present Transactions

Card payments are split into two broad categories. A card-present (CP) transaction happens when the physical card and the cardholder are at the point of sale, for example a tap or chip-and-PIN payment at a card machine. A card-not-present (CNP) transaction happens when the card details are provided remotely, for example on a website, in an app, via a payment link or over the phone.

The distinction matters because it changes how the cardholder is verified, how much fraud risk the transaction carries, who is liable if the transaction turns out to be fraudulent, and often what the transaction costs to process.

## What Counts as Card-Present?

A transaction is card-present when the card interacts directly with a payment terminal:

- Inserting a card and entering a PIN (EMV chip-and-PIN)
- Tapping a contactless card
- Tapping a phone or watch using a digital wallet such as Apple Pay or Google Pay
- Paying on a SoftPOS-enabled smartphone acting as a card machine

In each case the chip in the card (or the secure token in the device) generates a unique cryptogram for the transaction, which the issuer can verify. This makes counterfeiting extremely difficult. See [Chip, Contactless and SoftPOS Payments](https://docs.switchtransact.com/faq/card-payments/chip-contactless-and-softpos).

## What Counts as Card-Not-Present?

A transaction is card-not-present when the card details are captured without the physical card being read:

- E-commerce checkouts and in-app payments
- Payment links sent by email, SMS or WhatsApp
- Card-on-file and recurring subscription charges
- Mail order and telephone order (MOTO) payments
- Manually keyed transactions on a terminal

Because anyone who knows the card number, expiry date and CVV could attempt a CNP payment, additional controls are used, most importantly 3D Secure, which is standard on South African e-commerce. See [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure).

## How Do CP and CNP Compare?

| Aspect                    | Card-present                                  | Card-not-present                                                      |
| ------------------------- | --------------------------------------------- | --------------------------------------------------------------------- |
| Card verified by          | EMV chip cryptogram at the terminal           | Card number, expiry and CVV entered remotely                          |
| Cardholder verified by    | PIN (or device biometrics for wallets)        | 3D Secure (OTP or banking app approval)                               |
| Fraud risk                | Low                                           | Higher                                                                |
| Typical fraud liability   | Usually the issuer for chip transactions      | Usually the merchant, unless 3D Secure shifts liability to the issuer |
| Common chargeback reasons | Rare; mostly disputes about goods or services | Fraud, "transaction not recognised", non-delivery                     |
| Typical cost to process   | Generally lower                               | Generally higher, reflecting the higher risk                          |

## Why Does Liability Differ?

Card scheme rules broadly place fraud liability on the party that failed to use the strongest available security:

- In a **card-present** chip transaction, the chip and PIN prove the genuine card and cardholder were there, so fraud losses generally sit with the issuer.
- In a **card-not-present** transaction without authentication, the merchant carries the fraud risk and will usually lose a fraud chargeback.
- When a CNP transaction is successfully authenticated with **3D Secure**, liability for fraud chargebacks generally shifts from the merchant to the issuing bank.

This is why South African acquirers and gateways require or strongly encourage 3D Secure on e-commerce transactions. For what happens when a cardholder disputes a payment, see [Card Chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks).

## Which Should a Merchant Use?

Most businesses need both. A retail store, restaurant or delivery business takes card-present payments on a terminal or SoftPOS device, while an online store, subscription service or invoicing business takes card-not-present payments through a checkout or payment links. The practical rule is simple: whenever the physical card can be read, let it be read, because the transaction will be more secure and cheaper to process.

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [3D Secure and Fraud Prevention](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)


# What Happens During an Online Card Payment?

When a customer pays with a card on a South African website or app, a lot happens in the few seconds between clicking "Pay" and seeing the confirmation screen. The card details are captured securely, the cardholder is authenticated with 3D Secure, the issuing bank approves or declines the payment, and the merchant is notified of the result.

This page walks through each stage of the flow so you can understand where things can go wrong, why some payments take a detour through the customer's banking app, and when the money actually reaches the merchant.

## Step 1: The Customer Enters Card Details

At checkout the customer enters the card number (PAN), expiry date and CVV, or selects a saved card or digital wallet. How the details are captured depends on the integration:

- **Hosted checkout** – the customer is sent to a payment page hosted by the payment provider.
- **Embedded fields** – secure input fields from the provider are embedded in the merchant's own page.
- **API integration** – the merchant's certified systems pass the details to the provider directly.

In all cases the goal is that raw card numbers never touch the merchant's servers, which keeps the merchant's PCI DSS burden low. See [Hosted, Embedded and API Checkouts](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout).

## Step 2: The Card Details Are Tokenised

The gateway encrypts the card details and typically replaces them with a token, a reference that is useless to anyone who steals it. If the customer chose to save the card, the token is what gets stored for future payments. See [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens).

## Step 3: The Cardholder Is Authenticated with 3D Secure

On South African e-commerce transactions the cardholder is normally challenged with 3D Secure before the payment is authorised. Depending on the issuing bank, the customer approves the payment in their banking app or enters a one-time PIN (OTP) sent by SMS. Banks such as Absa, FNB, Nedbank, Standard Bank, Capitec, TymeBank and Discovery Bank each run their own challenge experience.

If authentication fails or the customer abandons the challenge, the payment stops here and no money moves. See [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure).

## Step 4: The Payment Is Authorised

The authorisation request travels from the gateway through the acquirer and the card network (Visa or Mastercard) to the issuing bank. The issuer checks:

- The card is valid, active and not reported lost or stolen
- Funds or credit are available
- The transaction passes the issuer's fraud screening

The issuer returns an approval or a decline with a response code, and the answer flows back to the checkout within seconds. Approved funds are reserved on the cardholder's account but not yet paid to the merchant. Declines are covered in [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes).

## Step 5: The Merchant Is Notified

The checkout shows the customer the result, and the merchant's systems are updated, usually via a webhook or callback, so the order can be released. Because customers can close browsers mid-payment, webhooks rather than the browser redirect should be treated as the source of truth. See [Webhooks and Callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks).

## Step 6: Capture, Clearing and Settlement

Authorised transactions are captured (finalised for billing), submitted into clearing where the schemes exchange transaction records between the banks, and then settled. The acquirer pays the merchant the settled amount less agreed fees, typically within a few business days depending on the provider and settlement schedule.

The gap between authorisation and capture is also what makes pre-authorisation holds possible. See [Authorisation, Capture and Pre-Authorisation](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [Card-Present vs Card-Not-Present](https://docs.switchtransact.com/faq/card-payments/card-present-vs-card-not-present)
- [Idempotency and Duplicate Payments](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates)


# Chip, Contactless and SoftPOS Payments Explained

In-person card payments in South Africa have moved through three generations of technology: the magnetic stripe (now largely retired), the EMV chip with a PIN, and contactless tap-to-pay. The newest development is SoftPOS, which turns an ordinary Android smartphone into a card machine with no extra hardware.

All three modern methods are built on the same EMV standard, which means every transaction is protected by a unique cryptogram that cannot be replayed or counterfeited. This page explains how each method works and what merchants should know when choosing how to accept in-person payments.

## How Does Chip-and-PIN Work?

An EMV chip card is a small computer. When the card is inserted into a terminal:

1. The terminal and the chip exchange data and agree on how to verify the cardholder.
2. The cardholder enters their PIN, which proves they are the genuine cardholder.
3. The chip generates a one-time cryptogram unique to that transaction.
4. The transaction is sent online to the issuer for approval.

Because the cryptogram changes every time, data skimmed from a chip transaction cannot be used to create a working counterfeit card. This is the main reason chip cards replaced magnetic stripe cards, which stored static data that was easy to clone.

## How Does Contactless (Tap-to-Pay) Work?

Contactless payments use NFC (near-field communication) to exchange the same EMV data over a very short range, typically a few centimetres, instead of through physical contact. The security model is the same as chip: a unique cryptogram per transaction.

Key points about contactless in South Africa:

- Taps below a bank-set limit usually do not require a PIN; above the limit the terminal prompts for a PIN.
- Issuers apply their own velocity controls, such as requiring a PIN after several consecutive taps.
- A card cannot be debited accidentally from a distance; the card must be effectively touching the reader, and a terminal processes only one transaction at a time.

Phones and watches using Apple Pay, Google Pay or Samsung Pay tap in exactly the same way, but replace the card number with a device token and the PIN with biometrics. See [What Are Digital Wallets?](https://docs.switchtransact.com/faq/card-payments/digital-wallets).

## What Is SoftPOS?

SoftPOS (software point of sale, also called tap-on-phone) is technology that lets a standard NFC-enabled Android smartphone accept contactless payments directly, with no card machine, dongle or card reader.

How it works:

- The merchant installs a certified SoftPOS app on their phone.
- The customer taps their card, phone or watch on the back of the merchant's phone.
- Where a PIN is required, the customer enters it securely on the merchant's phone screen.
- The transaction is processed online like any other contactless payment.

SoftPOS is certified against dedicated security standards that isolate and protect card data and PIN entry within the app, so the merchant's phone never sees usable card details.

### Why SoftPOS matters for South African businesses

- **Low barrier to entry** – no terminal hardware to buy or rent, which suits sole traders, market vendors, delivery drivers and mobile services.
- **Instant scale** – a business can equip an entire fleet of staff with payment acceptance using the phones they already carry.
- **Full card-present security** – SoftPOS transactions are genuine EMV contactless transactions, with the same low fraud profile as a traditional terminal.

The practical limitation is that SoftPOS only accepts contactless payments; a card without a working contactless function cannot be inserted or swiped.

## SoftPOS Security Standards: COTS, CPoC, SPoC and MPoC

SoftPOS solutions are certified against a family of PCI Security Standards Council standards. The names look similar, so it helps to understand what each one covers.

### What does COTS mean?

COTS stands for **commercial off-the-shelf** — an ordinary consumer device such as an Android smartphone or tablet, bought from any retailer, rather than purpose-built payment hardware. Because a COTS device was never designed as a secure payment terminal, the PCI standards below define how payment software must protect card data and PINs when running on it.

### What is SPoC (Software-based PIN Entry on COTS)?

SPoC was the first standard, published in 2018. Under SPoC:

- Card data is read by a small **hardware dongle** (a Secure Card Reader for PIN, or SCRP) attached to the phone.
- Only the **PIN is entered in software**, on the COTS device's screen.
- The PIN and card data travel through separate, encrypted channels and are only recombined at the processing host.

SPoC still requires a piece of dedicated hardware, so it is best thought of as a halfway step between a traditional terminal and true tap-on-phone.

### What is CPoC (Contactless Payments on COTS)?

CPoC, published in 2019, removed the hardware reader entirely:

- The phone's built-in **NFC interface reads the contactless card** or wallet directly.
- **No PIN entry is allowed** — transactions are limited to those that do not require cardholder verification, such as taps below the PIN limit.

CPoC made hardware-free acceptance possible, but the no-PIN restriction capped the transaction values a merchant could accept.

### What is MPoC (Mobile Payments on COTS)?

MPoC, published in 2022, is the newest and most complete standard, and it is where the industry is heading. It combines and extends the previous two:

- **Contactless acceptance on the phone's NFC interface** (like CPoC), and
- **Software-based PIN entry on the same device** (like SPoC, but without the hardware reader).

MPoC is modular, so vendors can certify different combinations of features, and it allows higher-value transactions because the customer can enter their PIN when prompted. A modern SoftPOS app accepting a tap and then a PIN on the merchant's phone is typically an MPoC-certified solution.

| Standard    | Card reading           | PIN entry           | Extra hardware needed |
| ----------- | ---------------------- | ------------------- | --------------------- |
| SPoC (2018) | Hardware dongle (SCRP) | On the phone screen | Yes — card reader     |
| CPoC (2019) | Phone's NFC            | Not permitted       | No                    |
| MPoC (2022) | Phone's NFC            | On the phone screen | No                    |

### What does HSM-backed mean?

An HSM (**hardware security module**) is a tamper-resistant physical device that generates, stores and uses cryptographic keys without ever exposing them, even to the systems that call it. SoftPOS is described as HSM-backed because the security that a traditional terminal provides in hardware is moved to HSMs in the processing back end:

- The PIN entered on the merchant's phone is **encrypted immediately on the device** and can only be decrypted inside an HSM at the processor or acquirer.
- **Payment keys are generated and managed inside HSMs**, never stored on the phone in usable form.
- Back-end **attestation and monitoring services** continuously check that the SoftPOS app and device have not been tampered with (for example rooted or running a modified app), and can block a compromised device from transacting.

The result is that even though the merchant's phone is an ordinary consumer device, card data and PINs are never available to the phone's operating system, other apps or the merchant — the sensitive cryptography always happens inside certified hardware on the processing side.

## Which Option Should a Merchant Choose?

- Choose a **traditional terminal** for high-volume fixed tills where inserting a card must remain possible.
- Choose **SoftPOS** for mobile, low-volume or many-user scenarios where carrying terminals is impractical.
- Both routes produce card-present transactions with the favourable risk and liability profile described in [Card-Present vs Card-Not-Present](https://docs.switchtransact.com/faq/card-payments/card-present-vs-card-not-present).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [What Are Digital Wallets?](https://docs.switchtransact.com/faq/card-payments/digital-wallets)
- [PCI DSS Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss)


# Authorisation, Capture and Pre-Authorisation Explained

A card payment is not a single event. It happens in two distinct steps: authorisation, where the issuing bank approves the transaction and reserves the funds, and capture, where the merchant confirms the amount to be taken and the transaction is submitted for settlement. Most everyday payments combine the two automatically, but keeping them separate unlocks useful patterns such as pre-authorisation holds.

Understanding the difference explains some things customers often ask about, such as why a "pending" amount appears on their statement before it becomes a final transaction, or why a cancelled hold takes days to disappear.

## What Is Authorisation?

Authorisation is the real-time approval of a transaction. The request travels from the merchant through the acquirer and card network to the issuing bank, which checks that the card is valid, funds or credit are available and the transaction passes fraud screening.

When the issuer approves:

- The amount is **reserved** against the cardholder's available balance or credit limit.
- The cardholder sees a **pending** transaction on their account.
- No money has moved yet; the merchant has an approval, not a payment.

## What Is Capture?

Capture is the merchant's instruction to finalise the authorised transaction. Captured transactions are submitted into clearing and settlement, after which the money is actually transferred to the acquirer and paid to the merchant.

- **Immediate (auto) capture** – authorisation and capture happen together. This is the default for retail purchases and most online checkouts.
- **Delayed capture** – the merchant authorises first and captures later, for example when goods are shipped. Capture can be for the full authorised amount or a smaller amount.

An authorisation that is never captured simply expires, and the issuer releases the reserved funds back to the cardholder.

## What Is a Pre-Authorisation?

A pre-authorisation (pre-auth) is an authorisation placed deliberately as a hold, with capture intended only later, often for a different amount. Common South African examples:

- **Hotels and guesthouses** – a hold at check-in to cover incidentals, with the final bill captured at check-out.
- **Car rental** – a deposit hold released after the vehicle is returned undamaged.
- **Fuel stations (automated pumps)** – a hold before pumping, captured for the actual fuel value.
- **E-commerce** – a hold at order time, captured only when stock is confirmed and shipped.

Points to remember:

- A pre-auth reduces the customer's available balance immediately, even though no money has moved. On a debit card this locks up real cash, which is why some customers prefer to present a credit card for holds.
- If the hold is cancelled (reversed) or expires without capture, the issuer releases the funds. Release is not always instant; depending on the issuing bank it can take several days for the pending amount to disappear from the customer's account.
- Card scheme rules limit how long an authorisation remains valid before it must be captured or released; the allowed window differs by merchant category.

## How Do Authorisation, Capture and Pre-Authorisation Fit Together?

| Step              | What happens                                 | Money moves?       | Customer sees                              |
| ----------------- | -------------------------------------------- | ------------------ | ------------------------------------------ |
| Authorisation     | Issuer approves and reserves the amount      | No                 | Pending transaction                        |
| Capture           | Merchant finalises the amount for settlement | Yes, at settlement | Final transaction                          |
| Pre-authorisation | Deliberate hold, captured later or released  | Only if captured   | Pending hold, then final amount or release |

## Practical Tips for Merchants

- Only capture what you are entitled to; capturing more than the authorised amount is generally not allowed.
- Release holds you no longer need rather than letting them expire, so customers get their funds back sooner.
- If you cancel an uncaptured authorisation, that is a **reversal or void**, not a refund; see [Card Refunds, Reversals and Voids](https://docs.switchtransact.com/faq/card-payments/card-refunds-reversals-and-voids).
- Reconcile captures against authorisations so unmatched holds are picked up quickly. Webhooks help here; see [Webhooks and Callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)
- [Debit, Credit and Prepaid Cards](https://docs.switchtransact.com/faq/card-payments/debit-credit-prepaid-cards)


# Why Do Card Payments Get Declined?

Every card authorisation comes back with a response code. An approval means the issuing bank has reserved the funds; a decline means the issuer, the network or the gateway has refused the transaction. Declines are a normal part of card processing, and the response code (or the decline category your payment provider maps it to) tells you whether the failure is worth retrying.

The most important distinction is between soft declines, which are temporary and may succeed on a later attempt, and hard declines, which are final and should never be retried on the same card.

## What Are the Common Decline Categories?

- **Insufficient funds** – the account balance or credit limit cannot cover the amount. Very common on debit cards, especially just before month-end salary dates. Widely returned as response code 51.
- **Do not honour** – a general refusal by the issuer without a specific reason, often driven by the issuer's internal risk rules. Widely returned as response code 05.
- **Expired card** – the card's expiry date has passed. The customer needs a replacement card, which their bank has usually already issued.
- **Suspected fraud** – the issuer's fraud systems flagged the transaction, or the card has been reported lost or stolen. These declines are final and must not be retried.
- **Incorrect details** – the card number, expiry date or CVV entered at checkout is wrong. The fix is simply for the customer to re-enter the details carefully.
- **3D Secure failure** – the cardholder failed or abandoned the authentication challenge (for example, never approved the prompt in their banking app), so the payment stopped before authorisation. See [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure).
- **Restricted card or transaction not permitted** – the card is blocked for this type of transaction, for example online or international payments disabled on the customer's banking app, common on South African cards.

## Soft Declines vs Hard Declines

| Aspect                  | Soft decline                                                                            | Hard decline                                                              |
| ----------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Nature                  | Temporary condition                                                                     | Permanent condition                                                       |
| Examples                | Insufficient funds, issuer unavailable, some do-not-honour responses, 3DS not completed | Stolen or lost card, closed account, invalid card number, confirmed fraud |
| Retry on the same card? | Yes, with sensible spacing and limits                                                   | No, never                                                                 |
| Best merchant action    | Retry later or ask the customer to try again                                            | Ask the customer for a different payment method                           |

Retrying hard declines wastes attempts, irritates issuers and can get a merchant flagged for excessive reattempts, as the card schemes monitor and penalise abusive retry behaviour.

## How Should Merchants Handle Declines?

- **Show the customer a helpful message.** "Insufficient funds" and "incorrect card details" have obvious customer fixes; a generic "payment failed" causes abandonment.
- **Let the customer retry or switch cards** immediately at checkout for soft declines and detail errors.
- **Check the customer's app settings.** Many South African banks (Capitec, FNB, Standard Bank and others) let customers toggle online and international payments per card. A "transaction not permitted" decline is often solved in the banking app in seconds.
- **Schedule smart retries for subscriptions.** For recurring billing, retry soft declines on a schedule, for example around common salary dates, and stop after a few attempts. See [Dunning and Payment Recovery](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery).
- **Keep saved card details fresh.** Expired-card failures on stored cards can be reduced with account updater services and network tokens. See [Backup Cards and Account Updaters](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters).
- **Never treat a decline as a payment.** Only release goods on an approval confirmed by your payment provider, ideally via webhook.

## Do Declines Cost the Merchant Money?

A declined authorisation does not move money, but declines still carry cost: lost sales, checkout abandonment and, for recurring merchants, involuntary churn. Improving approval rates through 3D Secure, tokenisation and sensible retry logic is usually one of the highest-value optimisations available to an online business. See [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [Recurring Card Payments: CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit)
- [3D Secure and Fraud Prevention](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)


# What Is 3D Secure and How Does It Work?

3D Secure (3DS) is the authentication step that appears during most South African online card payments: the moment where the customer approves the payment in their banking app or enters a one-time PIN (OTP) before the transaction goes through. It exists to prove that the person entering the card details is the genuine cardholder, not someone using stolen card numbers.

The "3D" stands for three domains: the issuer domain (the cardholder's bank), the acquirer domain (the merchant's side) and the interoperability domain (the card network connecting them). You may know it under its scheme brand names, Visa Secure (previously Verified by Visa) and Mastercard Identity Check (previously Mastercard SecureCode).

## How Does 3D Secure Work at Checkout?

1. The customer enters their card details and confirms payment.
2. The merchant's gateway sends an authentication request to the cardholder's issuing bank via the card network.
3. The issuer decides whether to challenge the customer.
4. If challenged, the customer proves their identity, typically by approving a prompt in their banking app or entering an OTP sent by SMS. Absa, FNB, Nedbank, Standard Bank, Capitec, TymeBank and Discovery Bank each run their own challenge experience.
5. On successful authentication, the payment continues to authorisation as normal. If authentication fails or is abandoned, the payment stops and no money moves.

## What Is 3D Secure 2?

The current version of the protocol, 3DS2 (EMV 3-D Secure), improved on the original in two important ways:

- **Richer data** – the merchant sends the issuer far more context about the transaction (device, address, transaction history), letting the issuer assess risk more accurately.
- **Frictionless flow** – if the issuer's risk assessment is comfortable, it can approve the authentication silently with no challenge at all. The customer sees nothing extra, but the transaction still counts as authenticated.

3DS2 also works properly inside mobile apps and supports modern challenge methods such as banking-app push approval and biometrics, rather than only static passwords.

## Why Does 3D Secure Matter for Merchants?

### Liability shift

The biggest commercial benefit is the fraud liability shift. On a card-not-present transaction without authentication, the merchant generally carries the loss if the payment turns out to be fraudulent. When a transaction is successfully authenticated with 3D Secure, liability for fraud-related chargebacks generally shifts to the issuing bank.

That does not make a merchant immune to all disputes. Chargebacks for non-delivery, defective goods or service disputes are unaffected by 3DS. See [Card Chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks).

### Fraud reduction

Stolen card numbers alone are not enough to complete a 3DS-challenged payment; the fraudster would also need control of the victim's phone or banking app. This blocks the bulk of basic card-testing and stolen-card fraud.

### Requirement in practice

In South Africa, acquirers and payment providers require 3D Secure on e-commerce card transactions as standard. Local shoppers are accustomed to the flow, so the friction cost is lower than merchants often fear, especially with 3DS2 frictionless approvals.

## What Can Go Wrong with 3D Secure?

- **Abandoned challenges** – the customer never receives or acts on the OTP or app prompt. This appears as a 3DS failure, not a bank decline. See [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes).
- **Outdated contact details** – OTPs go to an old cellphone number registered at the bank. The customer must update their details with their bank.
- **OTP fraud risk** – fraudsters phone victims pretending to be the bank and ask them to read out the OTP. Banks never ask for an OTP; merchants can help by reminding customers of this.

## Does 3D Secure Apply to Recurring Payments?

Usually only the first payment. The initial customer-initiated transaction is authenticated with 3DS, and subsequent merchant-initiated charges on the stored card run without a challenge, under the card scheme rules for recurring payments. See [Recurring Card Payments: CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [Card-Present vs Card-Not-Present](https://docs.switchtransact.com/faq/card-payments/card-present-vs-card-not-present)
- [3D Secure and Fraud Prevention](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)


# What Is Card Tokenisation and What Are Network Tokens?

Card tokenisation replaces a real card number (the PAN) with a substitute value called a token. The token can be stored and used to process payments, but it is useless to a criminal who steals it, because it cannot be used outside the system that issued it. Tokenisation is the reason a merchant can offer "save my card" without ever storing an actual card number.

There are two main kinds of token in everyday use: gateway (or provider) tokens, created by the payment provider, and network tokens, created by the card schemes themselves. They solve the same core security problem in different ways and are often used together.

## Why Tokenise Card Numbers at All?

A stored card number is a liability. If a database of real PANs leaks, every card in it can be abused anywhere. Storing raw card data also pulls the merchant deep into PCI DSS compliance obligations. Tokenisation addresses both problems:

- A stolen token cannot be used to make payments elsewhere, so a breach of tokens is far less damaging than a breach of card numbers.
- Because the merchant stores only tokens, most of the PCI DSS burden shifts to the payment provider. See [PCI DSS Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss).

Tokenisation is different from encryption (which is reversible with the right key) and hashing (which is one-way but not usable for payments). The distinctions are covered in [Tokenisation, Encryption and Hashing](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing).

## What Is a Gateway Token?

When a customer saves a card at checkout, the payment provider stores the real card details in its secure, PCI-compliant vault and gives the merchant a token in return. The merchant uses that token for future charges, refunds and subscription billing.

Characteristics of gateway tokens:

- They only work with the provider that issued them.
- The underlying card details are static; if the card expires or is replaced, the token can start failing unless the details are updated.
- They are simple and universal, working for any Visa or Mastercard card.

## What Is a Network Token?

A network token is issued by the card scheme itself (Visa Token Service or Mastercard's tokenisation platform) with the participation of the issuing bank. Instead of merely referencing the stored PAN, the scheme issues a distinct token PAN that stands in for the real card within the network.

Network tokens have properties that gateway tokens cannot match:

- **Automatic updates** – when the bank reissues or replaces the card, the network token stays valid and keeps working. This is a major benefit for subscription businesses fighting expired-card failures.
- **Merchant scoping** – a network token is bound to a specific merchant, so it cannot be replayed elsewhere if stolen.
- **Cryptograms** – network token transactions can carry a dynamic cryptogram, similar to an EMV chip transaction, giving issuers stronger assurance.
- **Better approval rates** – because issuers trust tokenised transactions more, network-tokenised payments tend to be approved more often than raw PAN transactions.

Digital wallets such as Apple Pay and Google Pay are built entirely on this technology: the card in the wallet is a device-bound network token. See [What Are Digital Wallets?](https://docs.switchtransact.com/faq/card-payments/digital-wallets).

## Gateway Tokens vs Network Tokens

| Aspect                 | Gateway token              | Network token                                 |
| ---------------------- | -------------------------- | --------------------------------------------- |
| Issued by              | Payment provider           | Card scheme (with the issuer)                 |
| Works with             | The issuing provider only  | The card network, for the enrolled merchant   |
| Card reissue or expiry | Token may start failing    | Token updated automatically                   |
| Security extras        | Vault storage              | Merchant scoping, dynamic cryptograms         |
| Typical use            | Saved cards, subscriptions | Wallets, subscriptions, card-on-file at scale |

In practice a merchant does not choose between them. The merchant integrates with a provider using gateway tokens, and the provider provisions network tokens underneath where supported, combining the simplicity of the first with the resilience of the second.

## Why Does Tokenisation Matter for Recurring Billing?

Stored-card billing lives or dies by whether the saved credentials still work months or years later. Network tokens and account updater services dramatically reduce failures caused by expired and reissued cards. See [Recurring Card Payments: CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit) and [Backup Cards and Account Updaters](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters).

## Related Topics

- [Card payments hub](https://docs.switchtransact.com/faq/card-payments)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)
- [Tokenisation, Encryption and Hashing](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing)


# Card Payments

Understand how debit and credit card payments work, what happens behind the scenes of every swipe, tap or online checkout, and how to handle declines and refunds.

## Topics in this section

- [How Do Card Payments Work?](https://docs.switchtransact.com/faq/card-payments/how-card-payments-work)
- [Debit, Credit and Prepaid Cards: What Is the Difference?](https://docs.switchtransact.com/faq/card-payments/debit-credit-prepaid-cards)
- [Card-Present vs Card-Not-Present Transactions](https://docs.switchtransact.com/faq/card-payments/card-present-vs-card-not-present)
- [What Happens During an Online Card Payment?](https://docs.switchtransact.com/faq/card-payments/online-card-payment-flow)
- [Chip, Contactless and SoftPOS Payments Explained](https://docs.switchtransact.com/faq/card-payments/chip-contactless-and-softpos)
- [Authorisation, Capture and Pre-Authorisation Explained](https://docs.switchtransact.com/faq/card-payments/authorisation-capture-and-preauthorisation)
- [Why Do Card Payments Get Declined?](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)
- [What Is 3D Secure and How Does It Work?](https://docs.switchtransact.com/faq/card-payments/3d-secure)
- [What Is Card Tokenisation and What Are Network Tokens?](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens)
- [What Are Digital Wallets and How Do They Work?](https://docs.switchtransact.com/faq/card-payments/digital-wallets)
- [Recurring Card Payments: What Are CIT and MIT?](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit)
- [Card Refunds, Reversals and Voids Explained](https://docs.switchtransact.com/faq/card-payments/card-refunds-reversals-and-voids)


# What Is a Debit Order and How Does It Work?

A debit order is an arrangement that allows a service provider to collect money directly from a consumer's bank account, after the consumer has given their approval. That approval is recorded in a mandate, which sets out the amount, the frequency and the collection date the consumer has agreed to.

Debit orders are one of the most widely used collection methods in South Africa. They are the standard way to collect insurance premiums, medical aid contributions, loan repayments, school fees, gym memberships and subscriptions, because the payment happens automatically on the agreed date without the customer having to do anything each month.

## How does a debit order work?

The process follows a consistent pattern, whichever debit order system is used:

1. The consumer and the service provider agree on a product or service and the payment terms.
2. The consumer gives the service provider a mandate authorising collections against their bank account.
3. The service provider submits a payment instruction to its bank before the agreed collection date, known as the action date.
4. On the action date, the consumer's bank debits the account and the funds are settled to the service provider.
5. If the collection cannot be completed, it is returned as an unpaid, for example because there were insufficient funds or the account was closed.

The key point is that the service provider pulls the money from the consumer's account. This is what distinguishes a debit order from a stop order, where the consumer instructs their own bank to push payments out. See [Debit Order vs Stop Order](https://docs.switchtransact.com/faq/debit-orders/debit-order-vs-stop-order) for a full comparison.

## What types of debit orders are there in South Africa?

South Africa runs two debit order systems side by side:

- **EFT debit orders** – the legacy electronic debit system. The mandate is held by the service provider and is not electronically confirmed with the consumer's bank. EFT debits are cost effective and widely used for reliable payers. Read more in [EFT Debit Orders](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders).
- **DebiCheck** – the modern ISO 20022-based system, introduced under the Authenticated Collections project. It covers authenticated transactions, where the consumer confirms the mandate with their bank before the first collection ([how DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)), and non-authenticated transactions collected through the Registered Mandate Service, where the mandate is registered with the banks but not confirmed by the consumer ([what is a registered mandate](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)).

The service provider chooses which system to use for a particular book of collections. Consumers cannot choose the system, but every system still requires a valid mandate.

## Why do businesses use debit orders?

Debit orders solve a practical problem: getting paid the same amount, on time, month after month, without chasing customers.

- Collections run automatically on the agreed action date.
- Cash flow becomes predictable, because the business controls when it collects.
- Failed collections are reported back with a return reason, so the business knows immediately which customers to follow up.
- On DebiCheck and registered mandates, tracking can re-present a failed collection when funds arrive in the account.

Kwik provides debit order collections across EFT, DebiCheck and registered mandates, so businesses can match the right collection method to each customer.

## What protects the consumer?

The mandate is the consumer's protection as much as the collector's. A service provider may only collect what the mandate allows, on the dates it allows. Consumers may dispute any collection they believe was incorrect, although not every dispute results in a reversal — the first step is to contact the service provider, and then the bank. See [Debit Order Disputes and Stop Payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments) for how this works.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [What Is a Debit Order Mandate?](https://docs.switchtransact.com/faq/debit-orders/debit-order-mandates)
- [What Is an EFT Debit Order?](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)


# Minimum Mandate Requirements

The Minimum Mandate Requirements section explains the information that must be included before an electronic debit order mandate can be accepted and used for collections.

A valid mandate records the payer's authority for the creditor to submit debit order payment instructions against the payer's bank account according to the agreed contract, amount, frequency and collection date.

## Example Mandate

Use the example mandate as a reference when reviewing or preparing your own mandate wording.

[View example mandate](https://docs.switchtransact.com/docs/mandate-example.pdf)

## Before Processing a Debit Order

Before any debit order payment instruction is submitted, the creditor must ensure that:

1. A valid mandate has been obtained from the payer.
2. The mandate was accepted before the first payment instruction is processed.
3. The payment instruction is only processed on or after the authorised action date.
4. The payment instruction matches the mandate terms.
5. The mandate has not been cancelled, withdrawn or stopped by the payer.
6. No mandate terms have been changed without the payer's authorisation or the required notice.

## Creditor Information

The mandate must clearly identify the party collecting the debit order.

Include:

- Full registered name of the creditor
- Trading name, where applicable
- Abbreviated short name / ABSN that will appear on the payer's bank statement
- Contact details for mandate queries
- Contract, agreement or customer reference number

The abbreviated short name must allow the payer to identify who debited their account.

## Payer Information

The mandate must clearly identify the payer and the account to be debited.

Include:

- Payer name and surname
- Identity number, passport number or temporary residence ID
- Bank name
- Branch code, where applicable
- Account number
- Account type, where applicable
- Confirmation that the payer has authority to authorise debits on the account

## Collection Details

The mandate must describe how and when the payer may be debited.

Include:

- First collection date, where applicable
- Collection day or agreed collection rule
- Frequency of collection, for example weekly, fortnightly, monthly, quarterly, annually or another agreed recurring rule
- Date adjustment rule, where the collection day may change, for example salary date or the previous business day when the normal collection date falls on a weekend or public holiday
- Initial amount, where applicable
- Instalment amount, where applicable
- Maximum collection amount, where applicable
- Whether the amount is fixed, variable or usage-based
- Any authorised adjustment category, amount or rate, where the amount may change over time

The mandate must either state the exact amount payable or clearly explain when and how the amount may vary.

## Authority to Debit

The mandate must contain explicit authority from the payer.

The authority wording should make it clear that:

- The payer authorises the creditor to issue payment instructions to the creditor's bank.
- The payer authorises the payer's bank to debit the payer's account.
- The payment instructions will be treated as if they were issued by the payer personally.
- The debit order will be processed according to the contract or agreement referenced in the mandate.

For an electronic mandate, the payer must give clear and unambiguous electronic acceptance of the mandate terms.

## Electronic Acceptance Evidence

For electronic mandates, the platform should retain evidence that the payer accepted the mandate.

Keep a record of:

- Date and time of acceptance
- Mandate version or wording accepted by the payer
- Payer details captured at acceptance
- Contract or agreement reference
- Amount, frequency and collection details accepted
- Electronic signature, acceptance action or consent record
- Device, browser, IP address or similar technical audit information, where available

This evidence should make it possible to prove which mandate terms the payer accepted if a dispute is raised.

## Credit Tracking Disclosure

Where credit tracking or account tracking is used, the mandate must disclose this to the payer.

The disclosure should explain that the debit order may be tracked and re-presented when sufficient funds become available, if this forms part of the collection process.

## Cession or Assignment

Where applicable, the mandate should include a cession or assignment clause.

This clause should state that the mandate may be ceded or assigned to a third party only if the related contract or agreement is also ceded or assigned to that third party.

## Confirmation to the Payer

For an electronic mandate, confirmation should be made available to the payer before payment instructions are processed.

The confirmation should include:

- Payer name and surname
- Contract or agreement reference
- Commencement or action date
- Amount or variable amount wording
- Abbreviated short name that will appear on the payer's bank statement
- Creditor contact details
- Date of confirmation

## Retention Requirements

Mandates and supporting records must be stored in a form that can be produced when requested by a bank, sponsor, auditor or dispute process.

Retain:

- The accepted mandate
- The contract or agreement linked to the mandate
- Any mandate amendments
- Any consent, confirmation or notification records
- Audit evidence supporting electronic acceptance

As a control, mandate records should be retained for at least 7 years after the last debit order transaction, unless a longer retention period applies.

## Common Reasons a Mandate May Fail Review

A mandate may be rejected or treated as deficient if:

- No mandate can be produced.
- The mandate does not identify the creditor.
- The abbreviated short name is missing or does not match the statement descriptor.
- The payer's bank account details are incomplete.
- The amount, frequency or collection date is unclear.
- The payer did not clearly authorise the debit.
- The mandate was accepted after the first payment instruction was processed.
- The payment instruction does not match the mandate.
- The mandate was changed without authorisation.
- The mandate was cancelled, withdrawn or stopped.

## Tips

- Keep mandate wording simple and specific.
- Make the amount, frequency and collection date easy for the payer to understand.
- Use the same abbreviated short name on the mandate and on payment instructions.
- Store a full copy of the mandate accepted by the payer, not only the captured form fields.
- Record the mandate version accepted by the payer.
- Do not process collections where the mandate is incomplete or disputed.
- Submit mandate templates for bank or sponsor review before using them in production.


# What Is the Difference Between a Debit Order and a Stop Order?

Debit orders and stop orders both move money out of a bank account on a recurring schedule, and the two terms are often used interchangeably in everyday conversation. They are, however, fundamentally different instruments — and the difference matters when a payment goes wrong, when you want to cancel, and when a business is deciding how to get paid.

The short version: with a **stop order**, you tell your bank to push money out of your account. With a **debit order**, you give a service provider permission to pull money from your account.

## What is a stop order?

A stop order is an instruction a consumer gives their own bank to make recurring, future-dated payments of a fixed amount to a beneficiary — for example, a monthly transfer to a savings account, rent to a landlord, or a donation to a charity.

Key characteristics:

- The **bank pushes** the money on the customer's instruction; the beneficiary does nothing.
- It is a **free-standing bank instruction** — no agreement with the beneficiary is required, and the beneficiary may not even know the payment is coming.
- The amount and date are fixed by the customer, who can amend or cancel the instruction directly at their bank at any time.

## What is a debit order?

A debit order is an instruction the consumer gives a **service provider** — not their bank — allowing that provider to collect money from the consumer's account. The authority is recorded in a mandate, which governs the amount, frequency and collection date. See [What Is a Debit Order?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order).

Key characteristics:

- The **collector pulls** the money by submitting a payment instruction through its own bank.
- It is governed by a **mandate between the consumer and the service provider**, linked to an underlying contract such as an insurance policy or loan agreement.
- The amount can be variable (for example usage-based billing), provided the mandate explains how it is determined.
- The consumer can dispute collections they believe were incorrect, and cancellation involves the service provider, not just the bank.

## Debit order vs stop order at a glance

|                           | Stop order                         | Debit order                                            |
| ------------------------- | ---------------------------------- | ------------------------------------------------------ |
| Who initiates the payment | The customer's bank (push)         | The service provider (pull)                            |
| Instruction given to      | The customer's own bank            | The service provider                                   |
| Governing document        | Free-standing bank instruction     | Mandate between customer and service provider          |
| Amount                    | Fixed                              | Fixed or variable per the mandate                      |
| Beneficiary involvement   | None required                      | Collector submits each collection                      |
| Cancellation              | At the bank, unilaterally          | Cancel the mandate with the service provider           |
| Typical uses              | Savings transfers, rent, donations | Insurance, medical aid, loan repayments, subscriptions |

## Which one should a business use to get paid?

For a business collecting recurring payments, the difference is control. With stop orders, payment depends on every customer setting up and maintaining an instruction at their own bank — the business cannot fix a wrong amount, a missed escalation or a cancelled instruction. With debit orders, the business submits the collection itself on the agreed action date, receives a return reason when a collection fails, and can use DebiCheck or registered mandates with tracking for harder-to-collect customers.

That is why virtually all commercial recurring collections in South Africa — across EFT, [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) and [registered mandates](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate) — run on debit orders. Kwik provides debit order collections across all three, backed by proper mandate management that meets the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

## A note on "stop payments"

Do not confuse a stop order with a **stop payment**: a stop payment is an instruction to your bank to block a specific expected debit order from going through. It relates to debit orders, not stop orders — see [Debit Order Disputes and Stop Payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments).

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [What Is a Debit Order?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order)
- [What Is a Debit Order Mandate?](https://docs.switchtransact.com/faq/debit-orders/debit-order-mandates)
- [Debit Order Disputes and Stop Payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)


# What Is an EFT Debit Order?

An EFT debit order is a collection processed through South Africa's legacy electronic funds transfer debit system. The service provider holds a mandate from the customer and submits payment instructions in batches to its bank, which routes them to the customer's bank for collection on the action date.

EFT is the older of the two debit order systems in South Africa, running alongside the modern ISO 20022-based DebiCheck system. It remains widely used because it is simple, cost effective and works well for customers who pay reliably.

## How do EFT debit orders work?

1. The customer signs or accepts a mandate authorising the service provider to debit their account. The mandate must meet the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
2. The service provider prepares a batch of payment instructions and submits it before the bank's cut-off for the chosen action date.
3. On the action date, each customer's bank attempts to debit the account.
4. Successful collections settle to the service provider. Failed collections come back as unpaids with a return reason, such as insufficient funds or account closed.

Unlike DebiCheck, the mandate behind an EFT debit order is not electronically registered or confirmed with the customer's bank. The bank processing the debit relies on the service provider's assurance that a valid mandate exists, and the service provider must be able to produce that mandate if the collection is ever queried or disputed.

## When should you use EFT debit orders?

Service providers choose the collection system; consumers cannot. EFT is generally the right choice when:

- The customer base pays reliably and dispute risk is low.
- Collection cost matters, for example on low-value recurring billing such as subscriptions or memberships.
- Mandates are already in place and collections have an established track record.

Where certainty of recovery matters more — for example credit agreements or high-risk books — DebiCheck's authenticated mandates or the Registered Mandate Service offer stronger protection. See [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) and [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).

## EFT vs DebiCheck vs registered mandates

|                                      | EFT debit order         | DebiCheck                          | Registered mandate (RMS)                   |
| ------------------------------------ | ----------------------- | ---------------------------------- | ------------------------------------------ |
| Mandate confirmed by customer's bank | No                      | Yes, authenticated by the customer | No, but registered with the banks          |
| Processing window                    | Standard EFT processing | Early window, first priority       | Early window, second priority to DebiCheck |
| Tracking of failed collections       | Not available           | Available                          | Available                                  |
| Dispute resistance                   | Lower                   | Highest                            | Higher than EFT                            |
| Relative cost                        | Lowest                  | Higher                             | Moderate                                   |

## What are the risks of EFT debit orders?

Because the mandate is not authenticated with the customer's bank, EFT collections carry more risk than DebiCheck or registered mandate collections:

- Customers can dispute collections more easily, and early disputes are typically reversed against the collector.
- There is no tracking, so a collection that fails on the action date is simply returned unpaid and must be resubmitted in a later cycle if the mandate allows.
- Invalid account details cause avoidable unpaids, which is why [account validation and CDV checking](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv) before submission is important.

Good mandate management and clean account data keep these risks manageable. Kwik supports EFT debit order collections alongside DebiCheck and registered mandates, so you can move individual customers to a stronger mandate type when their risk profile changes.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [Debit Order Action Dates and Processing Cycles](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles)
- [Why Do Debit Orders Get Returned Unpaid?](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)


# What Is a Debit Order Mandate?

A debit order mandate is the customer's recorded authority for a service provider to collect money from their bank account. It is the agreement that makes a debit order legitimate: without a valid mandate, a collection is unauthorised, no matter how genuine the underlying debt is.

Every debit order system in South Africa — EFT, DebiCheck and the Registered Mandate Service — is built on the mandate. The systems differ in how the mandate is captured, registered and confirmed, but the principle is the same: the customer must have agreed to be debited before the first collection runs.

## What must a mandate contain?

At minimum, a mandate records who is collecting, who is paying, and on what terms:

- The creditor's registered name, trading name and the abbreviated short name that will appear on the customer's bank statement
- The payer's name, identity number and bank account details
- The amount, or a clear explanation of how a variable amount is determined
- The frequency and the agreed collection date or collection rule
- The customer's explicit authority for the creditor to issue payment instructions and for the bank to debit the account

The full checklist, including electronic acceptance evidence and retention rules, is covered in [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

## Why is the mandate so important?

The mandate protects both sides of the relationship.

For the customer, it defines exactly what may be collected. A service provider may not debit a different amount, on a different date, or after the mandate has been cancelled, unless the mandate itself provides for it (for example a date adjustment rule for weekends and public holidays).

For the service provider, the mandate is the primary evidence in any dispute. When a customer disputes a debit order, the collector's ability to produce a valid, matching mandate largely determines the outcome. See [Debit Order Disputes](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/debit-order-disputes) for how disputes are handled.

## What happens if you collect without a valid mandate?

Collecting without a mandate, or outside the mandate's terms, has real consequences:

- Disputed collections are reversed, and the collector carries the loss and the return fees.
- High dispute ratios attract scrutiny from the sponsoring bank and can lead to suspension of collection facilities.
- Repeated unauthorised collections can amount to non-compliance with industry rules and expose the business to regulatory action.

The practical rule is simple: no mandate, no collection. Before every submission the payment instruction must match the mandate, the mandate must still be active, and the first collection may only run on or after the authorised action date.

## How do mandates differ between systems?

| System                     | How the mandate is handled                                                                                   |
| -------------------------- | ------------------------------------------------------------------------------------------------------------ |
| EFT debit order            | Mandate held by the service provider only; not confirmed with the customer's bank                            |
| DebiCheck                  | Mandate electronically confirmed (authenticated) by the customer with their bank before the first collection |
| Registered Mandate Service | Mandate registered with the banks but not authenticated by the customer                                      |

Stronger mandate types are harder to dispute successfully. The trade-offs are covered in [Types of Debit Order Mandates](https://docs.switchtransact.com/faq/debit-orders/types-of-debit-order-mandates).

## Can a mandate be cancelled?

Yes. A customer may cancel a mandate with the service provider, and no further collections may be processed once it has been cancelled, withdrawn or stopped. Cancelling the mandate does not cancel the underlying contract — the customer may still owe the money — but the service provider must recover it another way rather than continuing to debit.

Kwik captures, stores and manages mandates across EFT, DebiCheck and registered mandate collections, with the acceptance evidence needed to defend disputes.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [Types of Debit Order Mandates](https://docs.switchtransact.com/faq/debit-orders/types-of-debit-order-mandates)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)


# What Types of Debit Order Mandates Are There?

A debit order mandate can be captured and evidenced in several ways, and it can be processed through different collection systems. Both choices matter: how the mandate is captured determines what evidence you hold, and which system it runs on determines how resistant the collection is to disputes.

This page looks at the two dimensions separately — the form of the mandate, and the system the mandate is processed through — and then compares them.

## What forms can a mandate take?

- **Paper mandate** – the customer signs a physical form. Simple and familiar, but slow to capture, easy to lose and harder to match to electronic collections at scale.
- **Voice mandate** – the customer gives authority in a recorded telephone call. Common in outbound sales; the recording is the evidence, so call quality, script wording and storage matter.
- **Electronic mandate** – the customer accepts the mandate terms online or in an app. The platform records the acceptance with an audit trail: date and time, mandate wording, device and IP information. This is the most practical form for digital onboarding, provided the acceptance is clear and unambiguous.

Whatever the form, the mandate must meet the same content standard — see [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

## Which system processes the mandate?

- **EFT mandate** – the mandate is held by the service provider only. The customer's bank has no record of it and relies on the collector's assurance that it exists. See [EFT Debit Orders](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders).
- **DebiCheck mandate** – the mandate is electronically confirmed by the customer with their own bank before the first collection, using their banking app, USSD or ATM. Once authenticated, the bank holds a record of the approved terms. See [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works).
- **Registered mandate (RMS)** – the mandate is registered with the banks through the Registered Mandate Service but is not authenticated by the customer. It collects in the early processing window, at second priority to authenticated DebiCheck collections. See [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).

## How do the mandate types compare?

|                                   | EFT mandate                        | Registered mandate (RMS)                               | DebiCheck mandate                        |
| --------------------------------- | ---------------------------------- | ------------------------------------------------------ | ---------------------------------------- |
| Held at the customer's bank       | No                                 | Registered                                             | Registered and authenticated             |
| Customer confirms with their bank | No                                 | No                                                     | Yes                                      |
| Early processing window           | No                                 | Yes, second priority                                   | Yes, first priority                      |
| Tracking of failed collections    | No                                 | Yes                                                    | Yes                                      |
| Dispute resistance                | Lowest                             | Moderate                                               | Highest                                  |
| Relative cost                     | Lowest                             | Moderate                                               | Highest                                  |
| Typical use                       | Reliable payers, low-value billing | Books needing tracking without authentication friction | Credit agreements, high-risk collections |

## Which mandate type should you choose?

The service provider chooses the system — consumers cannot — so the decision comes down to the economics of your book:

- Use **EFT mandates** where customers pay reliably and cost per collection matters most.
- Use **registered mandates** where you want early-window collection and tracking, but authentication would add too much friction at onboarding.
- Use **DebiCheck mandates** where certainty of recovery matters, disputes are likely, or the collections relate to credit agreements.

Many businesses mix all three, moving customers between mandate types as their payment behaviour changes. Kwik supports EFT, DebiCheck and registered mandate collections on one platform, so a single customer relationship can move to a stronger mandate type without re-onboarding.

## What about NAEDO and AEDO mandates?

NAEDO and AEDO were the earlier tracking-based debit order services, replaced by DebiCheck and RMS under the Authenticated Collections project. Existing mandates were migrated rather than cancelled — see [What Happened to NAEDO and AEDO?](https://docs.switchtransact.com/faq/debit-orders/migrated-naedo-and-aedo-mandates).

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [What Is a Debit Order Mandate?](https://docs.switchtransact.com/faq/debit-orders/debit-order-mandates)
- [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)


# Debit Order Action Dates and Processing Cycles Explained

The action date is the date on which a debit order is due to be processed against the customer's bank account — the date the customer agreed to in the mandate. Getting action dates right is central to running a collections book: submit too late and you miss the cycle; collect on the wrong date and you are outside the mandate.

Debit orders are processed in cycles. The service provider submits payment instructions ahead of the action date, the banks process them on the action date, and the results — paid or unpaid — flow back to the collector.

## How does a processing cycle work?

1. **Preparation** – the collector builds the batch of payment instructions for a given action date, each matching an active mandate.
2. **Submission** – the batch is submitted to the sponsoring bank before its cut-off for that action date. Instructions submitted after cut-off roll to a later date.
3. **Processing** – on the action date, each paying bank attempts the debit against the customer's account.
4. **Results** – successful collections settle to the collector; failed collections return as unpaids with a reason, covered in [Unpaids, Returns and Resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

On DebiCheck and registered mandate collections, the early processing window applies: these collections are processed early in the cycle, with authenticated DebiCheck transactions taking first priority and registered (non-authenticated) mandates collecting at second priority. This ordering matters on high-pressure dates like month-end, when many collectors compete for the same funds.

## What happens when the action date is not a banking day?

Debit orders are only processed on banking days. When the agreed collection date falls on a weekend or a South African public holiday, the collection cannot run on that day, so a date adjustment rule applies: the service provider collects on either the previous or the next business day, depending on what the mandate provides.

This is one of the two legitimate reasons a debit order may go off on a different date than the customer expects. The other is tracking: if there are insufficient funds on the action date, a DebiCheck or registered mandate collection can be tracked and processed later, when funds reach the account. Both behaviours should be disclosed in the mandate — see [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

## How should you choose action dates?

The best action date is the one closest to when money arrives in the customer's account:

- **Salary-linked dates** – collecting on or immediately after payday dramatically improves success rates. Many mandates use a salary date rule rather than a fixed calendar day.
- **Month-end awareness** – the last business day of the month is the busiest collection date in South Africa. Early-window processing (DebiCheck first, registered mandates second) determines who gets paid first when funds are tight.
- **Consistent rules** – the mandate should state the collection day and the adjustment rule clearly, so the customer is never surprised by the date a debit appears on their statement.

## What are common action date mistakes?

- Submitting after the bank's cut-off and silently missing the agreed date.
- Collecting before the authorised first action date on a new mandate.
- Applying a weekend adjustment the mandate does not provide for.
- Ignoring public holidays when scheduling batches.

Kwik's collections platform handles cut-offs, banking-day adjustments and tracking automatically, so collections run on the correct date for every mandate.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [What Is an EFT Debit Order?](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders)
- [Why Do Debit Orders Get Returned Unpaid?](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)


# What Is Account Validation and CDV Checking?

Account validation is the process of checking a customer's bank account details before you try to collect against them. A debit order submitted against a mistyped account number is guaranteed to fail, and every avoidable failure costs a return fee, a delayed collection and a customer service conversation.

Two levels of validation are used in South African collections: check digit verification (CDV), which checks that account details are structurally valid, and account verification services (AVS), which check the account against the bank's actual records.

## What is check digit verification (CDV)?

CDV is a mathematical check of the branch code and account number combination. Each South African bank publishes rules describing which account number patterns are valid for which branch codes, including a check digit calculation — an algorithm that detects typing errors such as a swapped or mistyped digit.

A CDV check answers one question: **could this account number exist at this bank and branch?** It runs instantly, offline, and costs nothing per lookup, which makes it the natural first line of defence at the point of capture — in a signup form, a call-centre screen or a bulk file import.

What CDV cannot tell you:

- whether the account actually exists,
- whether it is open or closed,
- whether it belongs to your customer,
- whether it accepts debit orders.

An account number can pass CDV perfectly and still belong to nobody.

## What is real-time account verification (AVS-R)?

Account verification services close the gap CDV leaves. A real-time AVS request (AVS-R) is sent to the customer's bank, which checks the supplied details against its records and responds within seconds. Depending on the bank, an AVS-R result can confirm:

- the account exists and is open,
- the account accepts debit orders,
- the account holder's ID number or registration number matches the supplied details,
- the initials and surname match,
- how long the account has been open.

Because AVS-R confirms the account against live bank data, it also acts as a fraud control: it catches customers who supply someone else's account details, whether by mistake or deliberately.

## How do CDV and AVS-R fit together?

|                                     | CDV                             | AVS-R                                           |
| ----------------------------------- | ------------------------------- | ----------------------------------------------- |
| What it checks                      | Branch/account number structure | The account at the bank                         |
| Confirms account exists and is open | No                              | Yes                                             |
| Confirms ID/name match              | No                              | Yes                                             |
| Speed                               | Instant, offline                | Real time, seconds                              |
| Cost per check                      | None                            | Per-lookup fee                                  |
| Best used                           | At capture, on every entry      | Before first collection or mandate registration |

The practical pattern is: run CDV on every account number as it is captured, then run AVS-R once the details pass CDV — before the mandate is registered and the first collection is submitted.

## Why does validation reduce unpaids?

A meaningful share of debit order failures have nothing to do with the customer's willingness or ability to pay — they fail because the account details were wrong from the start: no such account, account closed, or an account that does not accept debits. These failures are entirely preventable.

Validating before submission means:

- fewer unpaids and lower return fees,
- the first collection succeeds, which sets the tone for the whole payment relationship,
- DebiCheck mandate registrations do not fail on bad account details,
- fraud using third-party account numbers is caught at onboarding rather than at dispute stage.

Kwik runs CDV and real-time account verification as part of its debit order onboarding flow, so collections are only ever submitted against accounts that exist, are open and belong to the customer.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [Why Do Debit Orders Get Returned Unpaid?](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions)
- [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)


# Why Do Debit Orders Get Returned Unpaid?

An unpaid debit order is a collection that could not be completed on the action date — the instruction reached the customer's bank, but the bank could not or would not process the debit. Every unpaid comes back to the collector with a return reason explaining what went wrong.

Unpaids are a normal part of running a collections book, but they are also its biggest cost driver. Understanding why collections fail, and what you may do next, is the difference between a book that recovers and one that leaks revenue.

## What are the common reasons debit orders are returned?

Return reasons fall into a few broad groups:

**Funds-related**

- **Insufficient funds** – the account did not hold enough money on the action date. This is by far the most common return reason, and the one most likely to succeed on a later attempt.

**Account-related**

- **Account closed** – the account no longer exists; further attempts against it are pointless.
- **Account frozen or blocked** – the bank has restricted the account, for example due to a legal hold.
- **No such account** – the account number does not exist at that bank, usually a capture error that [account validation](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv) would have caught.
- **Account holder deceased** – the account is in a deceased estate and debits are stopped.

**Customer-action-related**

- **Payment stopped** – the customer instructed their bank to stop this specific debit.
- **Authorisation cancelled** – the customer has cancelled the mandate or withdrawn the authority to debit.

The right response differs by group: funds-related failures are candidates for another attempt; account-related failures need corrected details or a different account; customer-action failures mean you must stop collecting and engage the customer directly — continuing to submit against a stopped or cancelled authority creates dispute and compliance risk. See [Debit Order Disputes and Stop Payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments).

## When may you resubmit an unpaid debit order?

Two rules govern re-presentment:

1. **The mandate must allow it.** An unpaid item may only be re-presented if the mandate permits re-presentment. If the mandate is silent or the customer has cancelled it, you may not simply try again.
2. **The resubmission must match the mandate.** The re-presented instruction must stay within the mandate's terms — the same agreed amount and the mandate's collection rules. You cannot add penalties to the collection amount or collect on dates the mandate does not provide for.

Resubmission also has a practical dimension: timing. Re-presenting an insufficient-funds failure the day after payday has a far better chance than re-presenting it mid-month. This is where system choice matters.

## How does tracking change the picture?

On the legacy EFT system there is no tracking — a failed collection is simply returned, and the collector must resubmit in a later cycle if the mandate allows.

DebiCheck and registered mandate (RMS) collections support **tracking**: instead of failing immediately when funds are short, the collection is monitored against the account for a period, and processes as soon as sufficient funds reach the account. Tracking recovers many collections that would be plain unpaids on EFT, which is a key reason collectors move higher-risk customers to DebiCheck or registered mandates. See [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) and [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate). Where tracking is used, the mandate must disclose it to the payer.

## How do you reduce unpaids?

- Validate account details with CDV and real-time verification before the first collection.
- Align action dates with salary dates, and apply banking-day adjustment rules correctly.
- Use DebiCheck or registered mandates with tracking for customers with irregular income.
- Respond to return reasons: retry funds failures, fix account failures, and stop on cancelled authorities.

Kwik reports every return reason back to you and applies tracking on DebiCheck and registered mandate collections automatically.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [What Is Account Validation and CDV Checking?](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv)
- [Debit Order Action Dates and Processing Cycles](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles)
- [Debit Order Disputes](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/debit-order-disputes)


# How Do Debit Order Disputes and Stop Payments Work?

A debit order dispute is a customer's formal challenge to a collection they believe was incorrect — wrong amount, wrong date, or not authorised at all. A stop payment is different: it is an instruction the customer gives their bank to prevent a specific future debit from being processed.

Consumers may dispute any collection they believe was incorrect. That right is fundamental to the debit order system, but it does not mean every dispute succeeds — not all disputes result in a reversal, and the outcome depends heavily on whether the collector can produce a valid mandate that matches the collection.

## How does a debit order dispute work?

The recommended path for a customer has two steps:

1. **Approach the service provider first.** Most "disputes" are really billing queries — a misread statement descriptor, a forgotten subscription, or a date that moved because of a weekend adjustment. The service provider can explain, correct or refund far faster than the formal dispute process.
2. **Then approach the bank.** If the service provider does not resolve the issue, the customer can dispute the debit at their bank, which processes the dispute through the interbank rules.

When a dispute is raised, the collector may be required to produce the mandate. If the mandate is valid and the collection matched its terms, the collector has a strong defence. If no mandate can be produced, or the collection deviated from it, the dispute will typically succeed and the funds are reversed.

## How do disputes differ by collection type?

The mandate type determines how exposed the collector is:

- **EFT debit orders** – the customer's bank holds no record of the mandate, so early disputes are generally processed in the customer's favour and reversed against the collector. The collector's recourse is to produce the mandate and pursue the matter with the customer.
- **DebiCheck** – the customer authenticated the mandate with their own bank, so a claim of "not authorised" is very difficult to sustain. Disputes within the approved mandate terms are resisted by the system itself.
- **Registered mandates (RMS)** – the mandate is registered with the banks, which gives the collector a stronger evidentiary position than EFT, though without the full protection of authentication.

This is why service providers choose DebiCheck where recovery certainty matters and dispute risk is high. See [Types of Debit Order Mandates](https://docs.switchtransact.com/faq/debit-orders/types-of-debit-order-mandates).

## What is a stop payment?

A stop payment is forward-looking: the customer instructs their bank to block a specific expected debit before it is processed. When the collection is subsequently submitted, it is returned unpaid with a payment-stopped reason.

A stop payment does not cancel the mandate or the underlying contract. The customer may still owe the money, and the right response from the collector is to contact the customer and resolve the account — not to keep resubmitting against a stopped instruction, which drives up return costs and dispute risk. See [Unpaids, Returns and Resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

## How do collectors protect themselves against disputes?

- Hold a complete, valid mandate for every collection, meeting the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements), with electronic acceptance evidence retained.
- Ensure every payment instruction matches the mandate — amount, frequency and action date.
- Use a clear abbreviated short name on bank statements so customers recognise the debit and phone you instead of their bank.
- Move high-dispute customers to DebiCheck, where the authenticated mandate itself resists disputes.
- Monitor dispute ratios: sustained high dispute rates attract sponsor bank scrutiny and can threaten your collection facility.

Kwik stores mandate and acceptance evidence for every collection and flags disputes and stop payments as they come back, so you can respond before small issues become account closures.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [Debit Order Disputes](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/debit-order-disputes)
- [What Is a Debit Order Mandate?](https://docs.switchtransact.com/faq/debit-orders/debit-order-mandates)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)


# What Happened to NAEDO and AEDO Debit Orders?

NAEDO and AEDO were South Africa's early debit order services designed for higher-risk collections. Both offered tracking — the ability to monitor an account and collect when funds arrived — and both have since been retired, replaced by DebiCheck and the Registered Mandate Service under the Authenticated Collections project driven by PASA and the South African Reserve Bank.

If you collected through NAEDO or AEDO, your mandates did not simply disappear: they were migrated onto the new systems so that existing collection relationships could continue.

## What were NAEDO and AEDO?

- **AEDO (Authenticated Early Debit Order)** – the customer authenticated the debit order at the point of sale using their bank card and PIN. The card-and-PIN authentication gave the collector strong proof of authority.
- **NAEDO (Non-Authenticated Early Debit Order)** – no electronic authentication; the collector held the mandate itself, much like EFT, but gained access to the early processing window and tracking.

Both services processed in the early window — ahead of ordinary EFT debits — which made them the tools of choice for credit providers and other collectors competing for funds on payday and month-end.

## Why were they replaced?

The Authenticated Collections project set out to modernise early debit orders and strengthen consumer protection. Its core idea was that the customer's own bank should hold an electronic record of what the customer agreed to, confirmed by the customer, rather than relying only on paperwork held by the collector.

The result was two successor services on the modern ISO 20022 messaging standard:

| Legacy service                       | Replaced by                      | What changed                                                                                                                      |
| ------------------------------------ | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| AEDO (card and PIN at point of sale) | DebiCheck                        | Authentication moved from card-and-PIN to the customer's own bank channels (app, USSD, ATM); the bank stores the approved mandate |
| NAEDO (non-authenticated, tracked)   | Registered Mandate Service (RMS) | The mandate is now registered with the banks, though still not authenticated by the customer                                      |

DebiCheck collections take first priority in the early processing window; registered mandate collections process at second priority. Tracking — NAEDO and AEDO's defining feature — carried over to both successors. See [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) and [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).

## What does a migrated mandate mean for collectors?

When the legacy services were switched off, active NAEDO and AEDO mandates were migrated onto the new rails rather than cancelled, so collections against existing customers continued without every customer having to re-authenticate.

Practical points for anyone still holding migrated mandates:

- **The original mandate still matters.** A migrated mandate is only as strong as the authority behind it. You must still be able to produce the original mandate if a collection is disputed — see [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
- **Collections must still match the mandate.** Migration did not change the agreed amount, frequency or collection date. Instructions outside those terms remain invalid.
- **New business cannot use the old services.** All new early debit order mandates are created as DebiCheck or registered mandates; NAEDO and AEDO are closed to new registrations.
- **Consider upgrading.** Migrated non-authenticated mandates can be replaced with authenticated DebiCheck mandates over time, which materially improves your position in disputes.

## What does this mean for consumers?

For consumers, the change is mostly invisible: debit orders continue on the agreed dates. The improvement is behind the scenes — with DebiCheck, your bank now holds a record of what you approved, and collections that do not match it can be rejected. The statement descriptor may have changed when the collector moved systems, so an unfamiliar entry is worth querying with the service provider first.

Kwik processes DebiCheck and registered mandate collections and can help collectors transition legacy books onto authenticated mandates.

## Related topics

- [Debit Orders hub](https://docs.switchtransact.com/faq/debit-orders)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)
- [Types of Debit Order Mandates](https://docs.switchtransact.com/faq/debit-orders/types-of-debit-order-mandates)


# Debit Orders

Learn how debit order collections work in South Africa, what makes a mandate valid, how processing cycles and action dates work, and how to handle unpaids and disputes.

## Topics in this section

- [What Is a Debit Order and How Does It Work?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order)
- [What Is an EFT Debit Order?](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders)
- [What Is a Debit Order Mandate?](https://docs.switchtransact.com/faq/debit-orders/debit-order-mandates)
- [What Types of Debit Order Mandates Are There?](https://docs.switchtransact.com/faq/debit-orders/types-of-debit-order-mandates)
- [Debit Order Action Dates and Processing Cycles Explained](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles)
- [What Is Account Validation and CDV Checking?](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv)
- [Why Do Debit Orders Get Returned Unpaid?](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions)
- [How Do Debit Order Disputes and Stop Payments Work?](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)
- [What Happened to NAEDO and AEDO Debit Orders?](https://docs.switchtransact.com/faq/debit-orders/migrated-naedo-and-aedo-mandates)
- [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [What Is the Difference Between a Debit Order and a Stop Order?](https://docs.switchtransact.com/faq/debit-orders/debit-order-vs-stop-order)


# What Is DebiCheck and How Does It Work?

DebiCheck is a debit order that the consumer approves, or authenticates, with their bank at the start of a new contract. Once approved, the consumer's bank stores an electronic copy of the mandate and will not allow any collection that falls outside the approved terms.

This makes DebiCheck fundamentally different from an ordinary [EFT debit order](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders), where the bank processes the collection without checking it against a mandate first. Kwik offers DebiCheck collections alongside EFT and Registered Mandate collections for South African businesses.

## Why was DebiCheck introduced?

The Payments Association of South Africa (PASA) introduced DebiCheck to stop two forms of abuse in the debit order system:

- **Rogue service providers** collecting from consumer accounts without valid approval.
- **Consumers unfairly disputing** debit orders that were, in fact, validly authorised.

DebiCheck addresses both problems at once. Because the consumer's bank holds an electronic copy of the approved mandate, collections that match the mandate cannot be unfairly disputed, and collections that do not match the mandate are simply not processed.

## How does DebiCheck work step by step?

1. The consumer signs up for a product or service that will be paid by debit order.
2. The service provider (or a payments provider like Kwik acting on its behalf) initiates a DebiCheck mandate request through the banking system.
3. The consumer receives a request from **their own bank** to electronically approve the debit order information — the amount, frequency, collection day and other terms.
4. The consumer approves the request through one of their bank's channels, such as a banking app, USSD, internet banking, an ATM or in branch.
5. The bank stores the approved mandate in its mandate register.
6. Every future collection is verified against the stored mandate. Collections that match are processed; collections that do not match are rejected.

The approval step is time-sensitive. An immediate, real-time request may need to be actioned within about 120 seconds, while a delayed request typically allows the consumer until the end of the day or the end of the next business day. See [mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication) for details per channel.

## How is DebiCheck different from a normal debit order?

| Feature             | DebiCheck                                                 | EFT debit order                           |
| ------------------- | --------------------------------------------------------- | ----------------------------------------- |
| Consumer approval   | Authenticated with the consumer's bank upfront            | Mandate held by the service provider only |
| Bank verification   | Every collection checked against the stored mandate       | No upfront mandate check by the bank      |
| Processing priority | First priority in the early morning window, after credits | Processed later in the processing cycle   |
| Disputes            | Matching collections cannot be unfairly disputed          | Easier for consumers to dispute           |
| Tracking            | Can track an account for funds for up to ten days         | Tracking not available in the same way    |

For a broader comparison that includes Registered Mandates, see [RM vs DebiCheck vs EFT](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-debicheck-vs-eft).

## What does DebiCheck mean for consumers?

- You approve each new debit order with your bank before the first collection, so you always know what you have agreed to.
- Your bank rejects any collection that does not match what you approved.
- You can suspend a DebiCheck mandate at your bank if something looks wrong — although suspending the mandate does not cancel the underlying contract with the service provider.
- Keeping your cellphone number up to date at your bank is important, because authentication requests are typically sent to your phone.

Consumers can learn more at [www.debicheck.co.za](https://www.debicheck.co.za){rel=""nofollow""}.

## What does DebiCheck mean for businesses?

For businesses that collect recurring payments, DebiCheck offers collection certainty, early processing priority, account tracking and strong protection against unfair disputes. See [DebiCheck for business](https://docs.switchtransact.com/faq/debicheck/debicheck-for-business) for the full picture, and the [transaction types TT1, TT2 and TT3](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3) to understand the different ways a mandate can be authenticated.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [What is a debit order?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order)
- [Mandates vs collections](https://docs.switchtransact.com/faq/debicheck/mandates-vs-collections)
- [Is DebiCheck safe?](https://docs.switchtransact.com/faq/debicheck/is-debicheck-safe)


# DebiCheck Troubleshooting: Common Problems and Fixes

Most DebiCheck problems fall into a handful of recurring patterns, and each has a known fix. The key is to work out which half of DebiCheck is failing — the **mandate** (permission) or the **collection** (payment) — and then read the reason code before retrying anything.

This page lists the most common issues we see, with practical steps to resolve each.

## The customer never received the authentication request

This is the single most common DebiCheck problem, and the cause is almost always the same: the authentication request is sent to the cellphone number **the bank has on record**, not the number you captured at sign-up.

Fixes:

- Ask the customer to confirm and, if necessary, update their cellphone number with their bank.
- Check that the customer banks with a [participating bank](https://docs.switchtransact.com/faq/debicheck/participating-banks).
- Re-initiate the request once the number is confirmed — a TT2 request gives the customer until the end of the next business day to respond through any of their bank's channels.

## The authentication request expired

A TT1 (real-time) request must be actioned within about 120 seconds; a TT2 request by end of the next business day. An expiry is not a rejection — the customer simply did not respond in time.

Fixes:

- For TT1 expiries, re-attempt while the customer is on the phone and ready, or fall back to TT2.
- Tell the customer exactly what to expect: who the request comes from, which channel it arrives on, and the details it will show.
- See [transaction types TT1, TT2 and TT3](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3) for the windows per type.

## The customer rejected the mandate

A rejection is a deliberate customer action, so do not simply re-initiate. Contact the customer first — common causes include not recognising the collecting party's name, being surprised by the amount, or accidental rejection. Resolve the concern, then send a new request. Making sure your abbreviated short name is recognisable on the authentication screen (and the bank statement) prevents many rejections — see [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

## Collections keep getting rejected on a mandate mismatch

If collections bounce before even reaching the account, the collection does not match the mandate stored at the customer's bank. Check for:

- An amount above the authenticated instalment or maximum collection amount.
- A frequency or collection date outside the approved terms.
- A mandate that has been suspended or cancelled since the last cycle.

Fix the data or [amend the mandate](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle) — retrying an unchanged mismatching collection will fail every time.

## Collections fail for insufficient funds

Use the tools DebiCheck gives you:

- Submit with a **tracking window** of up to ten days so the debit lands as soon as funds arrive.
- Align the collection date with the customer's salary date (amending the mandate if needed).
- Remember DebiCheck already processes first in the early morning window — if collections still fail, the issue is usually the date, not the priority.

See [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).

## The mandate was suspended

You will be notified at the time of suspension. Contact the customer promptly: suspension usually signals a service or billing concern, and the customer can lift the suspension at their bank once it is resolved. Remind them that suspension does not cancel the contract itself.

## An amendment was not accepted

Amendments that change authenticated terms may require the customer to re-authenticate. If an amendment fails or times out, the original mandate terms remain in force — keep collecting on the old terms until the amendment is confirmed, and re-engage the customer to approve the change.

## Quick reference

| Symptom                            | Likely cause                          | First action                                    |
| ---------------------------------- | ------------------------------------- | ----------------------------------------------- |
| No request received                | Outdated cellphone number at the bank | Customer updates number, re-initiate            |
| Request expired                    | Customer missed the window            | Re-initiate; prefer TT2 or prepare the customer |
| Mandate rejected                   | Customer concern or confusion         | Contact the customer before re-initiating       |
| Collection rejected pre-processing | Mandate mismatch                      | Correct data or amend the mandate               |
| Unpaid — insufficient funds        | Timing of funds                       | Tracking window, better collection date         |
| Suspended                          | Customer action at their bank         | Engage the customer to lift it                  |

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes)
- [Mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication)
- [Unpaids, returns and disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)


# DebiCheck API vs Host-to-Host: Which Integration Should You Use?

Banks expose DebiCheck through two kinds of technical interface: **real-time APIs** and **batch host-to-host file exchanges**. Both support the full set of operations — mandate initiation, amendment, cancellation and collections — but they behave very differently, and the right choice depends on how and where your customers sign up and how many collections you process.

Many businesses end up using both: API for the sign-up moment, host-to-host for the monthly collection run. A payments provider like Kwik can expose a single integration that routes to either channel behind the scenes.

## How does a DebiCheck API integration work?

With an API integration (for example Absa's CAPI), each operation is an individual real-time message:

1. Your system calls the API to initiate a mandate while the customer is signing up.
2. The bank pushes the authentication request to the customer — for TT1, a USSD prompt or app notification the customer actions within about 120 seconds.
3. The outcome (authenticated, rejected, expired) is returned to your system via the API response or a callback, per message.
4. Collections, amendments and cancellations follow the same request-and-response pattern.

The defining benefit is immediacy: a TT1 sign-up can go from "customer says yes" to "authenticated mandate" inside a single phone call or checkout session, and your sign-up flow can react to the result in real time.

## How does host-to-host integration work?

Host-to-host is a batch file interface: you assemble mandate requests, amendments, cancellations and collection instructions into structured files, transmit them to the bank over a secure connection, and receive response files with statuses and reason codes per record in return.

The defining benefit is throughput: tens or hundreds of thousands of records move in a single exchange, which suits scheduled monthly collection runs and bulk onboarding. The trade-off is latency — outcomes arrive when the response files do, not in the moment.

## API vs host-to-host at a glance

| Aspect               | Real-time API                            | Host-to-host (batch files)                            |
| -------------------- | ---------------------------------------- | ----------------------------------------------------- |
| Message model        | One request/response per operation       | Files containing many records                         |
| Result latency       | Seconds (per message)                    | Batch cycles                                          |
| Best for mandates    | TT1 real-time sign-ups                   | TT2 bulk initiation, migrations                       |
| Best for collections | Low volume or event-driven debits        | High-volume scheduled runs                            |
| Status delivery      | API responses and callbacks              | Response and reply files                              |
| Build effort         | REST-style integration, webhook handling | File generation, secure transfer, file reconciliation |

Statuses and reason codes are returned per message in both channels — the semantics are the same even though the transport differs. See [statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

## Which should your business choose?

- Choose **API** if your sign-ups happen in real time — call centres, in-app flows, point-of-sale — and you want TT1 authentication with an immediate answer.
- Choose **host-to-host** if you run large scheduled collection books, migrate existing mandate bases, or already operate bank file exchanges.
- Choose **both** if, like most collectors at scale, you need real-time sign-up and high-volume monthly collections.

Direct integration with a bank requires a sponsoring bank relationship, conformance to the bank's technical specifications and certification testing. Integrating through Kwik gives you one modern API for mandates and collections, with Kwik operating the underlying bank API and host-to-host connections, normalising statuses and reason codes across banks.

The same considerations apply to Registered Mandate integrations — see [RM API vs host-to-host](https://docs.switchtransact.com/faq/registered-mandates/api-vs-host-to-host). For the general integration trade-offs beyond DebiCheck, see [batch files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis).

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Transaction types TT1, TT2 and TT3](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3)
- [Batch files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis)
- [Webhooks and callbacks](https://docs.switchtransact.com/faq/payment-operations/webhooks-and-callbacks)


# Is DebiCheck Safe to Use?

Yes. DebiCheck was designed by the South African banking industry specifically to make debit orders **safer** — for consumers and for legitimate businesses. It was introduced by PASA to stop rogue service providers collecting from accounts without approval, and its entire design revolves around the consumer approving the debit order with their own bank before any money moves.

That said, any payment system that involves messages to consumers attracts imitators, so it is worth understanding both why DebiCheck itself is safe and how to recognise the phishing attempts that pretend to be DebiCheck.

## What makes DebiCheck safe by design?

- **You approve before anything is collected.** A new DebiCheck debit order cannot start collecting until you have electronically approved its terms with your bank.
- **Your bank stores the mandate.** An electronic copy of what you approved is held at your bank — not only at the service provider.
- **Every collection is verified.** Your bank checks each collection against the stored mandate. Collections that match are processed; anything outside the approved terms — a higher amount, a different frequency — is rejected automatically.
- **You stay in control.** You can suspend a DebiCheck mandate at your bank at any time, which blocks all future collections. (Remember to also cancel the underlying contract with the service provider, as suspension alone does not end the agreement.)
- **Approval happens inside bank channels.** Authentication takes place in your banking app, the bank's USSD service, internet banking, an ATM, a card-and-PIN device or in branch — channels your bank controls.

## How do I know an authentication request is genuine?

A genuine DebiCheck request:

- Arrives through your bank's own channels — an app notification, the bank's USSD prompt, or a pending item in internet banking.
- Shows you the debit order details — the collecting company, the amount and the frequency — for you to review before approving.
- Asks you only to **approve or reject** within your bank's own environment.

Banks **never** send links to click, and **never** ask for your PIN, password or one-time PIN by phone call, SMS or email to approve a DebiCheck mandate. Any message doing so is phishing, regardless of how official it looks — do not respond, and report it to your bank.

If a request is legitimate but unexpected, you can safely reject it. A real service provider will follow up, and a new request can always be sent once you understand what you are approving. See [mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication) for how the process works per channel.

## Is DebiCheck safer than an ordinary debit order?

| Protection                                      | DebiCheck | Ordinary EFT debit order  |
| ----------------------------------------------- | --------- | ------------------------- |
| Bank-side approval before first collection      | Yes       | No                        |
| Bank verifies each collection against a mandate | Yes       | No                        |
| Automatic rejection of out-of-terms collections | Yes       | No                        |
| Suspend at your bank with provider notified     | Yes       | Stop payment options vary |

The comparison is the core reason DebiCheck exists — see [how DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works) and [what is a debit order](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order).

## Is it safe for businesses too?

DebiCheck protects legitimate collectors as much as consumers. Because the consumer's bank holds the authenticated mandate, matching collections cannot be unfairly disputed — a persistent problem with ordinary debit orders. Businesses also receive notification when a payer suspends a mandate, allowing early engagement instead of silent failures. Kwik provides DebiCheck collections built on these protections.

Consumers wanting an independent reference can visit [www.debicheck.co.za](https://www.debicheck.co.za){rel=""nofollow""}.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication)
- [Unpaids, returns and disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)
- [What is a debit order?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order)


# Which Banks Support DebiCheck?

Most major South African banks participate in DebiCheck, including Absa, Capitec, FNB, Nedbank and Standard Bank, along with a number of other banks. However, not every bank in South Africa participates — some smaller banks and niche institutions do not — and not every service provider chooses to collect via DebiCheck.

Participation matters in both directions: a consumer can only authenticate a DebiCheck mandate if their bank participates, and a business can only collect via DebiCheck from payers whose banks are on the system.

## Which major banks participate in DebiCheck?

Participating banks include the major retail banks:

- Absa
- Capitec
- FNB (First National Bank)
- Nedbank
- Standard Bank
- Plus several other participating banks

Bank participation can change over time, so for a current list consumers and businesses can check [www.debicheck.co.za](https://www.debicheck.co.za){rel=""nofollow""} or confirm with the specific bank.

## Does every bank offer the same authentication channels?

No — the approval channels vary per bank. One bank may lean on app push notifications and USSD, another may emphasise ATM or internet banking approval. Common channels across the industry include:

- Banking app
- USSD
- Internet banking
- Cellphone banking
- ATM
- Card and PIN on a device
- In branch

Whatever the channel mix, every participating bank supports the core promise: the consumer approves the mandate, the bank stores it, and collections are verified against it. See [mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication) for how each channel works.

## What if the payer's bank does not participate?

If a payer banks with a non-participating institution, a DebiCheck mandate cannot be initiated against that account. Businesses then have alternatives on the same rails:

- **Registered Mandates (RM/RMS)** — the related non-authenticated route, where the mandate is registered with the bank without consumer authentication. See [what is a Registered Mandate](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).
- **EFT debit orders** — the traditional collection stream. See [EFT debit orders](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders).

A well-designed collections strategy routes each payer to the strongest available option. Kwik does this automatically, using DebiCheck where the payer's bank participates and falling back to the appropriate alternative where it does not.

## Do all service providers use DebiCheck?

No. DebiCheck is used at the discretion of the collecting business, and many still collect via EFT debit orders or Registered Mandates. As a consumer, this means not every new contract will trigger a DebiCheck authentication request — the absence of one does not necessarily mean anything is wrong. As a business, offering DebiCheck signals to customers that their bank will police your collections, which builds trust.

## What should businesses check before going live?

- **Payer bank coverage:** what share of your payer base banks with participating banks? That determines how much of your book can move to DebiCheck.
- **Channel behaviour per bank:** authentication user experience differs by bank; your sign-up scripts and customer messaging should reflect what each payer will actually see.
- **Transaction type support:** confirm that the [transaction types](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3) you plan to use (TT1, TT2, TT3) fit your sign-up channels.
- **Fallback strategy:** decide upfront how you will collect from payers whose banks do not participate.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [How DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [What is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)
- [DebiCheck for business](https://docs.switchtransact.com/faq/debicheck/debicheck-for-business)


# What Are the Benefits of DebiCheck for Business?

For any business that collects recurring payments in South Africa — insurers, lenders, gyms, schools, security companies, subscription services — DebiCheck changes the economics of collections. Because the payer authenticates the mandate with their bank upfront, and the bank verifies every collection against it, DebiCheck delivers stronger collection rates and dramatically better dispute protection than ordinary debit orders.

This page summarises the business case and how to get started.

## What are the main benefits of DebiCheck for a business?

- **Collection certainty.** The payer's bank holds an electronic copy of the authenticated mandate and processes every collection that matches it. You know before the first debit that the payer has approved the terms.
- **Early processing priority.** DebiCheck collections process first in the early morning window, after credits — your debit reaches the account just after salary deposits and ahead of later debit order streams.
- **Account tracking.** A collection can track the account for available funds for up to ten days, debiting the moment funds arrive. This converts many would-be unpaids into successful collections. See [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).
- **Dispute protection.** Collections that match the authenticated mandate cannot be unfairly disputed — the payer's own bank holds their electronic approval. This closes the biggest revenue leak in traditional debit order books. See [unpaids, returns and disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes).
- **Suspension notifications.** If a payer suspends the mandate at their bank, you are notified at the time of suspension — an early warning that lets you engage the customer before the next failed cycle, rather than discovering the problem in an unpaids file.

## How does DebiCheck compare commercially with EFT collections?

| Factor             | DebiCheck                        | EFT debit orders         |
| ------------------ | -------------------------------- | ------------------------ |
| Payer approval     | Bank-authenticated upfront       | Mandate held by you only |
| Processing slot    | First priority, early morning    | Later in the cycle       |
| Tracking for funds | Up to ten days                   | Not equivalent           |
| Unfair disputes    | Blocked for matching collections | A persistent cost        |
| Problem visibility | Suspension notified immediately  | Discovered at failure    |

The trade-off is an authentication step at sign-up, which requires well-designed onboarding — choosing the right [transaction type (TT1, TT2 or TT3)](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3) for each channel and preparing customers for the request from their bank.

## How does a business start collecting with DebiCheck?

Participation runs through the banking system:

1. **Engage a sponsoring bank** — or a payments provider like Kwik that operates through one. The sponsoring bank provides the technical specifications and the participation rules you must meet.
2. **Choose your integration**: real-time API for TT1 sign-up flows, host-to-host batch files for high-volume collection runs, or both. See [API vs host-to-host](https://docs.switchtransact.com/faq/debicheck/api-vs-host-to-host).
3. **Design compliant mandates** covering the required creditor, payer and collection details — see [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
4. **Build the operational processes**: handling authentication outcomes, statuses and reason codes, tracking windows, suspension notifications and amendments.
5. **Test and certify** against the bank's specifications before going live.

## Direct integration or through a provider?

Integrating directly gives you full control but means building and certifying against bank specifications, operating file exchanges or APIs per bank, and handling each bank's status and reason code variations yourself.

Collecting through Kwik gives you the same DebiCheck capabilities — TT1, TT2 and TT3 mandates, amendments, collections, tracking and notifications — through a single modern integration, with Kwik managing the sponsoring bank relationship, bank connectivity and code normalisation. For most businesses, this is the faster and cheaper route to a live DebiCheck book, and it can run alongside EFT and [Registered Mandate](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate) collections for payers whose banks do not participate in DebiCheck.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [How DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [Participating banks](https://docs.switchtransact.com/faq/debicheck/participating-banks)
- [Batch files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis)


# DebiCheck Mandates vs Collections: What Is the Difference?

DebiCheck has two distinct halves that are easy to confuse: the **mandate** and the **collection**. The mandate is the permission — the debit order terms the consumer approves with their bank at the start of a contract. The collection is the actual payment instruction that debits the consumer's account on a given day.

Understanding the split matters because each half has its own messages, statuses and failure modes. A mandate can be perfectly authenticated while a collection against it still fails, and a collection can only ever succeed if a valid mandate exists first.

## What is a DebiCheck mandate?

A DebiCheck mandate is the electronic record of the consumer's approval. When a new contract is signed, the consumer receives a request from their bank to approve the debit order information — typically the instalment amount, any maximum collection amount, the frequency, the collection day and the service provider's details.

Once the consumer authenticates the request, the bank stores an electronic copy of the mandate in its mandate register. From that point on, the bank will not allow a collection outside the approved terms.

A mandate is created once per contract and then lives on through amendments, suspensions and eventually cancellation. See the [mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle) for the full journey.

## What is a DebiCheck collection?

A collection is the payment instruction the service provider submits to actually debit the consumer's account — usually monthly, on the agreed collection day. Before processing a collection, the consumer's bank verifies it against the stored mandate:

- If the collection **matches** the mandate (right account, right amount within the approved limits, right frequency), it is processed.
- If the collection **does not match**, it is rejected and no money moves.

DebiCheck collections are processed as first priority in the early morning processing window, after credits, which improves the chance of collecting before other debit orders reach the account.

## How do mandates and collections compare?

| Aspect           | Mandate                                                                        | Collection                                            |
| ---------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------- |
| What it is       | The consumer's bank-authenticated permission                                   | The instruction that debits the account               |
| How often        | Once per contract, plus amendments                                             | Every collection cycle (e.g. monthly)                 |
| Who approves it  | The consumer, via their bank's channels                                        | No approval needed — verified against the mandate     |
| Typical statuses | Pending authentication, authenticated, rejected, expired, suspended, cancelled | Successful, unpaid/declined, tracking                 |
| Common failures  | Consumer does not respond in time, or rejects the request                      | Insufficient funds, account closed, mandate suspended |

## Why does the distinction matter in practice?

- **A failed authentication is not an unpaid.** If a consumer never approves the mandate, no collections can be submitted at all. Fix the mandate first — see [troubleshooting](https://docs.switchtransact.com/faq/debicheck/troubleshooting).
- **An unpaid collection does not invalidate the mandate.** If a collection fails for insufficient funds, the mandate remains authenticated and you can track or retry — see [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).
- **Amendments apply to the mandate, not the collection.** If the instalment amount changes beyond what the mandate allows, the mandate must be amended (and may require re-authentication) before collections at the new amount will pass verification.
- **Suspension blocks collections but not the contract.** A consumer can suspend a mandate at their bank, which stops future collections, but the underlying agreement must still be cancelled with the service provider.

Kwik's platform manages both halves — initiating and maintaining mandates, and submitting and reconciling collections — so businesses see one consistent view of each payer.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [How DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [Debit order mandates](https://docs.switchtransact.com/faq/debit-orders/debit-order-mandates)
- [Minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [Statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes)


# What Are DebiCheck Transaction Types TT1, TT2 and TT3?

DebiCheck supports three transaction types — TT1, TT2 and TT3 — which describe **how and when the consumer authenticates the mandate** with their bank. The mandate terms are the same in each case; what differs is the authentication channel and the time the consumer has to respond.

Choosing the right transaction type has a real impact on sign-up conversion. A consumer sitting in front of a sales agent can approve a TT1 request in seconds, while a consumer signing up online after hours may be better served by a TT2 request they can action later through their bank.

## What is TT1 (real-time authentication)?

TT1 is an immediate, real-time authentication. The consumer's bank sends an authentication request straight to the consumer — typically a USSD prompt or a banking app push notification — and the consumer must respond within roughly **120 seconds**.

TT1 works best when the consumer is present and expecting the request, for example during a telephonic or in-person sign-up. Because the response comes back in real time, the service provider knows immediately whether the mandate was authenticated, which suits API-driven sign-up flows — see [API vs host-to-host](https://docs.switchtransact.com/faq/debicheck/api-vs-host-to-host).

## What is TT2 (delayed or batch authentication)?

TT2 is a delayed authentication. The mandate request is lodged with the consumer's bank, and the consumer then authenticates it through one of their bank's channels — banking app, USSD, internet banking, cellphone banking, ATM or in branch — by the **end of the next business day**.

TT2 suits situations where the consumer cannot respond immediately: online sign-ups, batch onboarding of existing customers, or cases where a TT1 request timed out. The trade-off is that the outcome is not known immediately, so sign-up flows must handle a pending state.

## What is TT3 (card-and-PIN authentication)?

TT3 authenticates the mandate using the consumer's **bank card and PIN on a device**, typically a card machine at the point of sale (or an ATM). The consumer confirms the mandate terms and enters their PIN, which serves as the authentication.

TT3 suits face-to-face environments such as retail stores and branch networks, where a card device is available and the consumer can approve on the spot without relying on their cellphone.

## TT1 vs TT2 vs TT3 at a glance

|                          | TT1                                       | TT2                                              | TT3                               |
| ------------------------ | ----------------------------------------- | ------------------------------------------------ | --------------------------------- |
| Authentication method    | Real-time USSD or app push from the bank  | Consumer authenticates via their bank's channels | Card and PIN on a device          |
| Time to respond          | About 120 seconds                         | Until end of next business day                   | Immediate, at the device          |
| Consumer must be present | Yes, with their phone                     | No                                               | Yes, with their bank card         |
| Result known             | Immediately                               | Delayed                                          | Immediately                       |
| Typical use case         | Call centre and assisted digital sign-ups | Online sign-ups, batch onboarding                | Retail and point-of-sale sign-ups |

## Which transaction type should a business use?

- Use **TT1** when the consumer is engaged in real time and has their phone with them — it gives the fastest confirmation and the cleanest sign-up flow.
- Use **TT2** as the default for online or asynchronous journeys, and as a fallback when a TT1 request expires without a response.
- Use **TT3** where you have physical card devices and want to authenticate at the point of sale.

Many businesses combine them: attempt TT1 first, then fall back to TT2 if the consumer does not respond in time. Kwik supports this pattern as part of its DebiCheck collections service.

Note that Registered Mandates (RM/RMS) are the related **non-authenticated** route, where the mandate is registered with the bank without consumer authentication — see [what is a Registered Mandate](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate).

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication)
- [How DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [RM vs DebiCheck vs EFT](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-debicheck-vs-eft)


# How Do Customers Authenticate a DebiCheck Mandate?

Authentication is the step that makes DebiCheck different from every other debit order: the consumer approves the mandate **with their own bank** before the first collection. The bank then stores an electronic copy of the mandate and verifies every future collection against it.

The authentication request always comes from the consumer's bank, not from the service provider. It presents the debit order information — amount, frequency, collection day and the collecting party — and asks the consumer to approve or reject it.

## Which channels can be used to authenticate?

The exact channels vary per bank, but across the major South African banks consumers can typically authenticate through:

- **Banking app** — approve a push notification or an item in the app's inbox
- **USSD** — respond to a USSD prompt on any cellphone, no smartphone needed
- **Internet banking** — approve the pending mandate online
- **Cellphone banking** — approve via the bank's mobile banking menu
- **ATM** — approve at the bank's ATM
- **Card and PIN on a device** — approve at a point-of-sale device (the TT3 route)
- **In branch** — approve with a consultant

Which channel applies depends partly on the [transaction type (TT1, TT2 or TT3)](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3) used to initiate the mandate.

## How long does the customer have to respond?

| Request type               | Typical window                                                          |
| -------------------------- | ----------------------------------------------------------------------- |
| Immediate (real-time, TT1) | About 120 seconds                                                       |
| Delayed (TT2)              | Until end of day or end of the next business day, depending on the bank |
| Card and PIN (TT3)         | Approved on the spot at the device                                      |

If the window passes without a response, the authentication request **expires**. An expired request is not a rejection — the service provider can usually initiate a new request, often falling back from TT1 to TT2.

## Why does the cellphone number at the bank matter so much?

Authentication requests are typically sent to the cellphone number the **bank** has on record for the consumer — not the number the service provider captured at sign-up. If the bank has an old number, the request never reaches the consumer and the authentication expires.

Consumers should keep their contact details up to date with their bank. Businesses seeing high expiry rates should prompt payers to confirm that their bank has their current number — this is one of the most common issues covered in [troubleshooting](https://docs.switchtransact.com/faq/debicheck/troubleshooting).

## What happens after the customer responds?

- **Approved:** the bank stores the mandate in its mandate register and the mandate becomes authenticated. Collections that match it will be processed.
- **Rejected:** the consumer declined the request. No collections can be submitted. The service provider should contact the customer to resolve the reason before re-initiating.
- **Expired:** no response was received in time. The service provider can re-initiate, typically via TT2 or after contacting the customer.

These outcomes flow back to the service provider as statuses — see [statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

## How can customers tell a genuine request from phishing?

A genuine DebiCheck authentication request:

- Comes through the bank's own channels — the banking app, the bank's USSD service, internet banking or an ATM.
- Displays the debit order details for the consumer to review.
- **Never** contains a link to click, and **never** asks for a PIN, password or one-time PIN over the phone, by SMS link or by email.

Banks never send links or ask for PINs or passwords to approve a DebiCheck mandate. Any such request is phishing and should be reported to the bank. See [is DebiCheck safe?](https://docs.switchtransact.com/faq/debicheck/is-debicheck-safe) for more on security.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Transaction types TT1, TT2 and TT3](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3)
- [Mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle)
- [Minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)


# The DebiCheck Mandate Lifecycle Explained

A DebiCheck mandate is not a once-off event — it is a living record that moves through defined stages from the moment it is initiated until it is finally cancelled. Because the consumer's bank stores an electronic copy of the mandate and verifies every collection against it, keeping the mandate's state accurate matters for every collection you submit.

This page walks through each stage of the lifecycle and what triggers the moves between them.

## Stage 1: Initiation

The service provider (or a payments provider like Kwik acting through a sponsoring bank) submits a mandate initiation request containing the debit order terms: payer details, instalment amount, any maximum collection amount, frequency, collection day and the collecting party's details.

The request is routed to the consumer's bank, which sends the consumer an authentication request. The mandate is now **pending authentication**.

## Stage 2: Authentication

The consumer approves or rejects the request through their bank's channels — app, USSD, internet banking, ATM, card-and-PIN device or in branch. Depending on the [transaction type](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3), they have from about 120 seconds (TT1) up to the end of the next business day (TT2) to respond.

Three outcomes are possible:

- **Authenticated** — the bank stores the mandate in its mandate register; collections may begin.
- **Rejected** — the consumer declined; the mandate cannot be used.
- **Expired** — no response in time; the request can be re-initiated.

See [mandate authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication) for channel details.

## Stage 3: Active collections

While the mandate is authenticated, the service provider submits collections against it each cycle. The consumer's bank verifies every collection against the stored mandate — matching collections are processed as first priority in the early morning window; non-matching collections are rejected. See [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).

## Stage 4: Amendments

Contracts change: instalments increase at an annual escalation, collection days move to match a new salary date, or account details change. Amendments are submitted as mandate amendment requests. Depending on what changes and the rules of the consumer's bank, an amendment may:

- Be registered without new consumer action (for example, a change already provided for in the mandate), or
- Require the consumer to **re-authenticate** the amended terms.

Until an amendment is accepted, collections must still match the existing mandate terms. Changes to [amounts and frequencies](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments) are the most common amendments.

## Stage 5: Suspension

A consumer can suspend a DebiCheck mandate at their bank. Suspension blocks all future collections against the mandate, and the service provider is **notified at the time of suspension** — a significant advantage over ordinary debit orders, where you often only learn of a problem when a collection bounces.

Two points are important:

- Suspension does **not** cancel the underlying contract. The consumer must still cancel the agreement with the service provider, and the debt continues to accrue in the meantime.
- The service provider can engage the consumer to resolve the issue and have the suspension lifted.

## Stage 6: Cancellation

Cancellation ends the mandate permanently. It can be initiated by the service provider (for example when a contract ends or is settled) or by the consumer through their bank. Once cancelled, no further collections can be processed against the mandate; a new contract would need a new mandate.

## Lifecycle statuses at a glance

| Status                 | Meaning                                    | Collections allowed? |
| ---------------------- | ------------------------------------------ | -------------------- |
| Pending authentication | Awaiting the consumer's response           | No                   |
| Authenticated          | Approved and stored at the bank            | Yes                  |
| Rejected               | Consumer declined the request              | No                   |
| Expired                | Authentication window lapsed               | No — re-initiate     |
| Suspended              | Consumer blocked collections at their bank | No — until lifted    |
| Cancelled              | Mandate permanently ended                  | No                   |

For how these statuses and their reason codes reach your systems, see [statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Mandates vs collections](https://docs.switchtransact.com/faq/debicheck/mandates-vs-collections)
- [Statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes)
- [Minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)


# DebiCheck Statuses and Reason Codes Explained

Every DebiCheck message — a mandate initiation, an amendment, a collection — comes back with a status, and most negative outcomes carry a reason code explaining why. Reading these correctly is the difference between fixing a problem quickly and resubmitting requests that were always going to fail.

Statuses split naturally into two groups, mirroring the two halves of DebiCheck: **mandate statuses** and **collection outcomes**. If the distinction is new to you, start with [mandates vs collections](https://docs.switchtransact.com/faq/debicheck/mandates-vs-collections).

## What are the DebiCheck mandate statuses?

| Status                 | What it means                                                 | What to do                                                                           |
| ---------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Pending authentication | The consumer's bank has sent the request; awaiting a response | Wait, or prompt the customer to check their bank's channels                          |
| Authenticated          | The consumer approved; the bank stored the mandate            | Begin collections per the mandate terms                                              |
| Rejected               | The consumer declined the request                             | Contact the customer before re-initiating                                            |
| Expired                | The authentication window lapsed with no response             | Re-initiate, often via TT2, or confirm the customer's cellphone number at their bank |
| Suspended              | The consumer blocked collections at their bank                | Engage the customer; the suspension can be lifted                                    |
| Cancelled              | The mandate has been permanently ended                        | Stop collections; a new contract needs a new mandate                                 |

These statuses map onto the stages described in the [mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle).

## What are the common collection outcomes?

Once a mandate is authenticated, each collection returns its own outcome:

- **Successful** — funds were debited from the payer's account.
- **Unpaid / declined** — the collection failed, with a reason code such as insufficient funds, account closed, account frozen, or payment stopped.
- **Rejected before processing** — the collection did not match the stored mandate (wrong amount, wrong frequency, suspended or cancelled mandate) and was never presented to the account.
- **In tracking** — the collection is monitoring the account for available funds for a specified period of up to ten days; it will debit as soon as funds are available.

See [unpaids, returns and disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes) for how to respond to each.

## How do reason codes work?

Banks return a reason code with each negative status, identifying the cause per message. The exact code sets are defined in the banks' technical specifications and can differ slightly between real-time API and host-to-host file interfaces, but the causes fall into consistent categories:

- **Consumer action** — rejected, suspended or cancelled by the payer.
- **Timing** — the authentication request or mandate action expired.
- **Account issues** — insufficient funds, account closed, account dormant or frozen, invalid account details.
- **Mandate mismatch** — the collection did not match the registered mandate's amount, frequency or timing.
- **Technical** — malformed messages, duplicate references or invalid fields in the request itself.

Kwik normalises the raw bank codes into consistent statuses across banks and interfaces, so your reconciliation does not need to handle each bank's variations. For the industry-wide view of reason codes across payment types, see the [reason code directory](https://docs.switchtransact.com/faq/reference/reason-code-directory).

## How should a business respond to each category?

- **Consumer action codes** are conversations, not retries. Contact the payer to understand why they rejected or suspended the mandate.
- **Timing codes** usually mean the payer never saw the request — confirm their cellphone number is current at their bank and re-initiate.
- **Account issue codes** may resolve with tracking or a retry on a better date — see [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries). Codes like "account closed" will not resolve; get new account details instead.
- **Mandate mismatch codes** mean your collection data has drifted from the registered mandate. Amend the mandate before collecting at the new terms.
- **Technical codes** point to integration issues — validate your messages against the bank's specification, or let your payments provider handle this layer.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle)
- [Unpaids, returns and disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)
- [Error and reason codes in payment operations](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes)


# DebiCheck Amounts, Frequencies and Adjustments Explained

Because the consumer's bank verifies every DebiCheck collection against the stored mandate, the amounts and frequency captured in the mandate are not just paperwork — they are hard limits. A collection that exceeds the approved amount, or arrives on a frequency the mandate does not allow, is rejected before it ever reaches the account.

Getting the amount fields right at initiation therefore prevents most collection rejections later. This page explains each field and how changes are handled over the life of the mandate.

## What amounts appear in a DebiCheck mandate?

- **Instalment amount** — the regular amount collected each cycle. For a fixed contract this is simply the monthly premium or repayment.
- **Maximum collection amount** — the ceiling on what may be collected in any cycle. This is only presented for **usage-based or variable mandates** (for example utilities or metered services), where the amount changes month to month. It caps what may be collected, and it must be clearly explained to the consumer before authentication so they understand what they are approving.
- **First collection amount** — where the first debit differs from the regular instalment, for example a pro-rata amount or an initiation fee combined with the first instalment.

For variable mandates, the maximum collection amount is often set as a multiple of the instalment amount — commonly in the region of one and a half times the instalment — but the exact multiple is agreed in the mandate and subject to each bank's rules, not a fixed universal figure.

## What frequencies does DebiCheck support?

DebiCheck mandates support the recurring frequencies used in South African collections, including:

- Weekly
- Fortnightly
- Monthly (the most common)
- Quarterly
- Every six months
- Annually
- Once-off, for single collections

The frequency is authenticated as part of the mandate, so a mandate approved as monthly cannot suddenly be collected weekly. The collection day (or day rule, such as "last business day") is also part of the approved terms.

## How do date adjustments work?

Salaries do not always land on the same calendar day, and collection days can fall on weekends or public holidays. Mandates can therefore include date adjustment rules agreed with the consumer, for example:

- Collecting on the previous business day when the normal collection day falls on a weekend or public holiday.
- Aligning the collection day with the payer's salary date.

These rules must be captured in the mandate so that adjusted collections still pass the bank's verification. The general principles are the same as for ordinary debit orders — see [action dates and processing cycles](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles).

## How are amount changes and escalations handled?

Contracts often include annual escalations or rate-linked changes. DebiCheck accommodates this in two ways:

1. **Authorised adjustments captured upfront.** The mandate can record an adjustment category, amount or rate — for example an agreed annual percentage increase. Because the consumer authenticated these terms, collections that follow the agreed adjustment remain within the mandate.
2. **Mandate amendments.** Changes not provided for in the original mandate must be submitted as amendments, and depending on the change and the bank's rules the consumer may need to re-authenticate the new terms. See the [mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle).

Either way, the golden rule holds: collections are verified against the mandate register, so the mandate must always reflect what you intend to collect **before** you collect it.

## What happens if a collection exceeds the approved amount?

It is rejected. The consumer's bank compares each collection against the stored mandate, and an amount above the instalment (or above the maximum collection amount on a variable mandate) does not match the approved terms. The rejection comes back with a mandate mismatch reason — see [statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

Kwik validates collection amounts against the registered mandate before submission, catching mismatches before they become bank rejections.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [Collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries)
- [Mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle)


# How Do DebiCheck Collections, Tracking and Retries Work?

Once a DebiCheck mandate is authenticated, the real work begins: submitting collections each cycle and getting them paid. DebiCheck gives collectors two structural advantages here — priority processing in the early morning window, and the ability to track an account for funds — which together materially improve collection rates compared with ordinary debit orders.

This page covers how a collection moves through the system, how tracking works, and what your options are when a collection fails.

## How is a DebiCheck collection processed?

1. The service provider submits the collection instruction (via API or host-to-host file, directly or through a payments provider like Kwik).
2. The consumer's bank **verifies the collection against the stored mandate** — account, amount within the approved limits, frequency and timing.
3. Matching collections are queued for processing; non-matching collections are rejected without touching the account.
4. DebiCheck collections process as **first priority in the early morning processing window, after credits**. This means the collection hits the account just after salaries and other credits land, and before later debit order streams — a significant advantage when an account holds limited funds.
5. The outcome — successful or unpaid with a reason code — is returned to the service provider.

## What is DebiCheck tracking?

Tracking instructs the bank to monitor the payer's account for available funds for a specified period of **up to ten days**. If the account has insufficient funds when the collection is first presented, the bank keeps watching; as soon as sufficient funds become available, the account is debited.

Key points about tracking:

- It turns a single collection attempt into a continuous window of opportunity, catching irregular salary dates and mid-month deposits.
- The tracking period is specified per collection, up to the ten-day maximum.
- Where tracking is used, the mandate should disclose it to the payer — see [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
- Registered Mandate (RMS) collections support tracking in the same way — see [RMS collections, tracking and settlement](https://docs.switchtransact.com/faq/registered-mandates/collections-tracking-and-settlement).

## How do retries work when a collection fails?

If a collection is unpaid and its tracking window closes without funds becoming available, the collection has failed for that cycle. Options then include:

- **Re-presenting** the collection on a later date within the current cycle, still within the mandate's terms.
- **Adjusting the collection date** going forward (for example to the payer's actual salary date) via a mandate amendment where needed.
- **Engaging the payer** to settle the arrears by another method.

Two constraints matter:

- Every retry is still verified against the mandate, so retries must stay within the authenticated amount, frequency and timing terms.
- Retrying a collection that failed for a structural reason — account closed, mandate suspended — will fail again. Check the reason code first; see [statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes).

## DebiCheck collections vs ordinary EFT collections

| Aspect               | DebiCheck                                        | EFT debit order                        |
| -------------------- | ------------------------------------------------ | -------------------------------------- |
| Pre-processing check | Verified against the bank's mandate register     | No mandate verification                |
| Processing priority  | First priority, early morning after credits      | Later in the processing cycle          |
| Tracking             | Up to ten days per collection                    | Not available in the same form         |
| Failed collections   | Reason-coded; retry within mandate terms         | Reason-coded; resubmission rules apply |
| Dispute exposure     | Matching collections cannot be unfairly disputed | Easier for payers to dispute           |

For the EFT side of this comparison, see [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

## How does this look in practice with Kwik?

Kwik submits DebiCheck collections with the tracking window you choose, monitors outcomes across banks, normalises reason codes, and gives you a single view of successful, tracking and unpaid collections so your team can act on genuine exceptions rather than raw bank files.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Amounts, frequencies and adjustments](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments)
- [Unpaids, returns and disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)
- [Action dates and processing cycles](https://docs.switchtransact.com/faq/debit-orders/action-dates-and-processing-cycles)


# Why Do DebiCheck Collections Get Returned or Disputed?

Even with an authenticated mandate, DebiCheck collections can still come back unpaid — most commonly because the account simply does not have the funds. What DebiCheck changes fundamentally is the **dispute** picture: because the consumer's bank holds an electronic copy of the approved mandate, collections that match the mandate cannot be unfairly disputed and reversed the way ordinary debit orders can.

This page separates the two concepts — unpaids (the money was never collected) and disputes (the payer challenges a collection) — and explains how to handle each.

## Why do DebiCheck collections come back unpaid?

Common unpaid and rejection reasons include:

- **Insufficient funds** — the most frequent reason; the account could not cover the collection, and any tracking window closed without funds arriving.
- **Account closed, dormant or frozen** — the account can no longer be debited; new account details are needed.
- **Payment stopped** — the payer instructed their bank to stop the payment.
- **Mandate suspended or cancelled** — the payer acted on the mandate at their bank, blocking collections.
- **Mandate mismatch** — the collection did not match the registered mandate's amount, frequency or timing, and was rejected before reaching the account.

Each failure carries a reason code that tells you whether to retry, track, amend the mandate or contact the payer — see [statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes) and [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).

## How do disputes work on DebiCheck collections?

With ordinary EFT debit orders, a payer can dispute a debit at their bank and often have it reversed, even when the underlying mandate was valid. DebiCheck was designed specifically to close this gap:

- The bank verified the collection against the mandate the consumer personally authenticated, so a matching collection is treated as authorised.
- As a result, **not all DebiCheck transactions can be reversed on dispute**. A payer cannot simply claim the debit was unauthorised when their own bank holds their electronic approval.

Consumers who believe a DebiCheck debit is wrong should **first approach the service provider** to resolve the issue, and then their bank if it cannot be resolved. This ordering matters: most issues (a contract already cancelled, an amount queried) are contractual questions that the service provider can fix directly, often faster than a formal dispute.

## What can a payer still do at their bank?

A payer who wants to stop DebiCheck collections can **suspend the mandate** at their bank. This blocks all future collections, and the service provider is notified at the time of suspension so it can engage the payer. Two important caveats for consumers:

- Suspension does not reverse past collections.
- Suspension does not cancel the underlying contract — the agreement must be cancelled with the service provider, and amounts owed remain owing.

For the broader dispute landscape across debit order types, see [debit order disputes and stop payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments).

## Unpaids vs disputes at a glance

|                             | Unpaid                                                  | Dispute                                          |
| --------------------------- | ------------------------------------------------------- | ------------------------------------------------ |
| What happened               | The collection failed; no money moved                   | The payer challenges a processed collection      |
| Typical cause               | Insufficient funds, account issues                      | Payer believes the debit was wrong               |
| DebiCheck effect            | Tracking and priority processing reduce unpaids         | Matching collections cannot be unfairly disputed |
| First step for the business | Read the reason code; track, retry or contact the payer | Engage the payer and produce the mandate         |

## How should businesses manage unpaids and disputes?

- Use tracking windows to convert insufficient-funds failures into successful collections.
- Keep mandate data accurate so collections never fail on a mismatch.
- Respond quickly to suspension notifications — early contact usually resolves the payer's concern.
- Keep clean records of contracts and mandates; in the rare dispute that does proceed, the authenticated mandate is your evidence.

Kwik handles unpaid processing, tracking and suspension notifications as part of its DebiCheck collections service, surfacing exceptions with clear next actions.

## Related topics

- [DebiCheck hub](https://docs.switchtransact.com/faq/debicheck)
- [Collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries)
- [Statuses and reason codes](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes)
- [Debit order disputes and stop payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)


# DebiCheck

DebiCheck is South Africa's bank-authenticated debit order system. Learn how mandates are authenticated, how collections and tracking work, and how to resolve declines and disputes.

## Topics in this section

- [What Is DebiCheck and How Does It Work?](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [DebiCheck Mandates vs Collections: What Is the Difference?](https://docs.switchtransact.com/faq/debicheck/mandates-vs-collections)
- [What Are DebiCheck Transaction Types TT1, TT2 and TT3?](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3)
- [How Do Customers Authenticate a DebiCheck Mandate?](https://docs.switchtransact.com/faq/debicheck/mandate-authentication)
- [The DebiCheck Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle)
- [DebiCheck Statuses and Reason Codes Explained](https://docs.switchtransact.com/faq/debicheck/statuses-and-reason-codes)
- [DebiCheck Amounts, Frequencies and Adjustments Explained](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments)
- [How Do DebiCheck Collections, Tracking and Retries Work?](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries)
- [Why Do DebiCheck Collections Get Returned or Disputed?](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)
- [DebiCheck Troubleshooting: Common Problems and Fixes](https://docs.switchtransact.com/faq/debicheck/troubleshooting)
- [DebiCheck API vs Host-to-Host: Which Integration Should You Use?](https://docs.switchtransact.com/faq/debicheck/api-vs-host-to-host)
- [Is DebiCheck Safe to Use?](https://docs.switchtransact.com/faq/debicheck/is-debicheck-safe)
- [Which Banks Support DebiCheck?](https://docs.switchtransact.com/faq/debicheck/participating-banks)
- [What Are the Benefits of DebiCheck for Business?](https://docs.switchtransact.com/faq/debicheck/debicheck-for-business)


# What Is a Registered Mandate?

A registered mandate (RM) is a debit order mandate whose details are registered at the payer's bank through the Registered Mandate Service (RMS), without the payer having to electronically approve the mandate. It forms part of South Africa's modern ISO 20022 collections system — the same generation of payment rails that powers [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works).

Registered mandates were introduced because real-time authentication is not always possible. Some payers hold company accounts, some accounts require multiple signatories, and some payers simply cannot complete a DebiCheck authentication on their phone. RMS gives collectors a way to place the mandate on record at the payer's bank in these situations.

## How does a registered mandate work?

When you register a mandate through RMS, the following happens:

1. You capture the mandate details — payer, account, amount, frequency and collection date — as agreed in your contract with the payer.
2. Your sponsoring bank sends the mandate details to the payer's bank using ISO 20022 messages.
3. The payer's bank records the mandate against the payer's account and notifies the payer, typically by SMS or an app message.
4. The payer does not approve the mandate, but can query or dispute it with their bank.
5. You can then submit collections against the registered mandate.

The key difference from DebiCheck is step 3: the payer is informed, not asked. With DebiCheck, the payer must actively [authenticate the mandate](https://docs.switchtransact.com/faq/debicheck/mandate-authentication) before collections can begin.

## Why register a mandate instead of using an ordinary EFT debit order?

An ordinary [EFT debit order](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders) relies entirely on the mandate you hold on file. The payer's bank has no record of the agreement, so disputes usually go the payer's way unless you can produce strong evidence.

Registering the mandate changes that position:

- The payer's bank holds the mandate details on record.
- The payer is notified when the mandate is registered, so a later claim of "I never knew about this debit order" is harder to sustain.
- Collections against registered mandates process in the early processing window, ahead of ordinary EFT debit orders.
- Collections can be tracked for available funds for up to ten days, in the same way as DebiCheck collections.

Registered mandates therefore sit between plain EFT and DebiCheck: stronger dispute evidence than EFT, but without the payer authentication that gives DebiCheck its full protection.

## When should you use a registered mandate?

Registered mandates are most useful when DebiCheck authentication is impossible or impractical:

- The payer's account belongs to a company or other juristic entity.
- The account requires multiple signatories to approve transactions.
- The payer does not have a cellphone or cannot receive authentication requests.
- DebiCheck authentication attempts repeatedly fail or expire.

For these scenarios, see [Registered Mandates for Juristic and Multi-Signatory Accounts](https://docs.switchtransact.com/faq/registered-mandates/juristic-and-multisignatory-accounts).

Where the payer can authenticate, DebiCheck remains the stronger option. The industry direction in South Africa is to move collections off legacy EFT and onto DebiCheck and registered mandate rails.

## What do you still need to hold yourself?

Registration does not replace your obligation to obtain a valid mandate from the payer. You must still meet the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements), keep the signed or electronically accepted mandate on file, and ensure every collection matches the mandate terms. If a dispute arises, the registered record and your underlying mandate together form your evidence.

## Does Kwik support registered mandates?

Yes. Kwik offers registered mandate collections alongside DebiCheck and EFT debit orders, so you can register mandates, submit collections and track outcomes from a single platform.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [RM vs RMS: What Is the Difference?](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-rms)
- [Registered Mandates vs DebiCheck vs EFT Debit Orders](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-debicheck-vs-eft)
- [How Are Registered Mandates Registered and Payers Notified?](https://docs.switchtransact.com/faq/registered-mandates/registration-and-payer-notification)


# RM vs RMS: What Is the Difference?

The terms RM and RMS appear throughout South African collections documentation, bank specifications and industry FAQs, and they are often used as if they mean the same thing. Strictly speaking they do not: RM refers to the mandate itself, while RMS refers to the industry service that registers it.

Understanding the distinction helps when you read bank documentation, interpret statuses, or discuss integration options with your sponsoring bank or payment provider.

## What is a registered mandate (RM)?

A registered mandate (RM) is the mandate record itself — the agreement between you and your payer that has been registered at the payer's bank. It contains the mandate details you captured: the payer's account, the collection amount or maximum amount, the frequency and the collection date.

Once registered, the RM exists as a record at the payer's bank. Collections you submit reference that record, and the mandate moves through a lifecycle of statuses such as registered, amended, suspended or cancelled. See [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle) for the full picture.

## What is the Registered Mandate Service (RMS)?

The Registered Mandate Service (RMS) is the industry service — part of South Africa's ISO 20022 DebiCheck-era collections system — that carries mandate registrations between banks. It is the rail, not the record.

RMS handles non-authenticated mandates: the mandate details are registered at the payer's bank without the payer electronically approving them. The payer's bank notifies the payer of the registration, and the payer can query or dispute it, but no authentication step takes place. This is what distinguishes RMS from DebiCheck, where the payer must actively [authenticate the mandate](https://docs.switchtransact.com/faq/debicheck/mandate-authentication).

RMS covers the full set of mandate operations:

- Initiation (registering a new mandate)
- Amendments to an existing registered mandate
- Suspension of a mandate
- Cancellation of a mandate

All of these are communicated as ISO 20022 messages between your sponsoring bank and the payer's bank, over either an API or a host-to-host file integration. See [API vs Host-to-Host Integration](https://docs.switchtransact.com/faq/registered-mandates/api-vs-host-to-host).

## Why are RM and RMS used interchangeably?

In practice, most people say "RM" or "registered mandate" to mean the whole capability — registering mandates and collecting against them — and "RMS" when quoting bank or industry documentation. Because every registered mandate exists only through the Registered Mandate Service, the two terms point at the same process from different angles:

| Term | Refers to                                                | Example usage                                         |
| ---- | -------------------------------------------------------- | ----------------------------------------------------- |
| RM   | The mandate record registered at the payer's bank        | "The RM was cancelled by the payer's bank."           |
| RMS  | The industry service that registers and manages mandates | "We submit RMS registrations via host-to-host files." |

You will see both in bank specifications — for example, Absa publishes a Registered Mandate host-to-host file specification and a Registered Mandate API. Both describe the same underlying RMS capability.

## Does the distinction matter operationally?

Rarely. What matters operationally is:

- Whether the mandate registered successfully at the payer's bank.
- What status the mandate currently holds (registered, amended, suspended, cancelled or rejected).
- Whether your collections reference a valid, active registered mandate.

If a bank or provider tells you "the RM was rejected", they mean the mandate record; if they say "RMS is unavailable", they mean the service. Kwik supports registered mandate collections through RMS, so you can register and manage mandates without needing to work with the bank messaging directly.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)
- [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)


# Registered Mandates vs DebiCheck vs EFT Debit Orders

South African collectors have three main debit order rails to choose from: DebiCheck, registered mandates (RM) and ordinary EFT debit orders. They differ in how the mandate is established at the payer's bank, how early collections process, and how much protection you have when a payer disputes a debit.

Choosing the right rail for each payer segment directly affects your unpaid rates, dispute losses and operational cost. This page compares the three side by side.

## How do the three collection types compare?

| Feature                | DebiCheck                                               | Registered mandate (RM)                                          | EFT debit order                                    |
| ---------------------- | ------------------------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------- |
| Payer approval         | Payer actively authenticates the mandate electronically | No approval — mandate registered at payer's bank, payer notified | None — mandate held only by the collector          |
| Bank record of mandate | Yes, authenticated                                      | Yes, registered but not authenticated                            | No                                                 |
| Payer notification     | Authentication request                                  | Notification of registration (e.g. SMS or app message)           | None                                               |
| Processing window      | Early window, first priority                            | Early window, second priority behind DebiCheck                   | Later than the early window                        |
| Tracking for funds     | Yes, up to ten days                                     | Yes, up to ten days                                              | Limited or none, depending on service              |
| Dispute protection     | Strongest — payer authenticated the mandate             | Stronger than EFT — registered details as evidence               | Weakest — collector's mandate is the only evidence |
| Typical use            | Consumers who can authenticate                          | Juristic, multi-signatory and non-authenticatable payers         | Legacy books not yet migrated                      |

## What makes DebiCheck the strongest option?

With [DebiCheck](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works), the payer must electronically confirm the mandate — usually via USSD, banking app or ATM — before you can collect. The authenticated mandate is stored at the payer's bank, which gives you the strongest possible dispute position: the payer approved the exact terms on record.

DebiCheck collections process first in the early morning processing window, giving you the best chance of reaching funds before other debits. Different [transaction types (TT1, TT2, TT3)](https://docs.switchtransact.com/faq/debicheck/transaction-types-tt1-tt2-tt3) determine how the authentication is requested.

## Where do registered mandates fit in?

Registered mandates exist because authentication is not always possible. Company accounts, multi-signatory accounts and payers without cellphones cannot complete DebiCheck authentication, and some authentications simply fail or expire repeatedly.

With an RM, the mandate details are registered at the payer's bank without approval. The payer is notified of the registration and can query or dispute it, but no authentication happens. In exchange:

- RM collections process in the early window, but as second priority behind authenticated DebiCheck collections.
- RM collections support tracking for available funds for up to ten days, like DebiCheck.
- In a dispute, the registered record is stronger evidence than a plain EFT mandate, but weaker than DebiCheck's payer authentication.

See [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate) for the fundamentals.

## Why do EFT debit orders still exist?

[EFT debit orders](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders) are the legacy rail. The mandate lives only in your records; the payer's bank processes the debit without any knowledge of the underlying agreement. That makes EFT simple and cheap to run, but it also means:

- Collections process later than DebiCheck and RM collections.
- Payers can dispute debits relatively easily, and without a bank-side mandate record the dispute usually succeeds.
- There is no built-in tracking comparable to the DebiCheck and RM services.

The industry direction is to migrate collections off EFT and onto DebiCheck and registered mandate rails, so new collection books should generally start on the modern rails.

## Which one should you use?

A practical rule of thumb:

- **Consumer payers who can authenticate:** use DebiCheck.
- **Juristic, multi-signatory or non-authenticatable payers:** use a registered mandate. See [Juristic and Multi-Signatory Accounts](https://docs.switchtransact.com/faq/registered-mandates/juristic-and-multisignatory-accounts).
- **Existing legacy books:** continue on EFT while planning migration to DebiCheck or RM.

Many collectors run all three in parallel, routing each payer to the strongest rail available for their account type. Kwik supports DebiCheck, registered mandate and EFT collections on one platform, which makes this kind of routing straightforward.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [How DebiCheck Works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works)
- [EFT Debit Orders](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders)
- [Registered Mandate Returns and Disputes](https://docs.switchtransact.com/faq/registered-mandates/returns-and-disputes)


# How Are Registered Mandates Registered and Payers Notified?

Registering a mandate places your debit order agreement on record at the payer's bank without asking the payer to approve it. The payer's bank then notifies the payer that the mandate has been registered. This notification step is what separates registered mandates from both ordinary EFT debit orders (where the bank knows nothing) and DebiCheck (where the payer must actively authenticate).

This page walks through the registration flow, what the payer sees, and what happens if the payer objects.

## How does mandate registration work?

Registration follows a bank-to-bank message flow using ISO 20022 messages:

1. **You capture the mandate.** The payer agrees to the debit order in your contract, and you record the mandate details — payer name, account, amount or maximum amount, frequency and collection date. The underlying mandate must still meet the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).
2. **The registration request is submitted.** Your sponsoring bank (or your payment provider, such as Kwik, on your behalf) sends the mandate details to the payer's bank via the Registered Mandate Service, over API or host-to-host file integration.
3. **The payer's bank validates the request.** It checks the account details and either accepts or rejects the registration.
4. **The mandate is registered.** On acceptance, the mandate record is stored against the payer's account and the mandate status becomes registered.
5. **The payer is notified.** The payer's bank informs the payer of the new registered mandate.

Once registered, you can submit collections against the mandate. See [Collections, Tracking and Settlement](https://docs.switchtransact.com/faq/registered-mandates/collections-tracking-and-settlement).

## How is the payer notified?

The payer's bank sends the notification through its own channels — typically an SMS or a message in the banking app. The notification tells the payer that a mandate has been registered against their account, usually including the collector's name and key mandate details.

Two things are important about this notification:

- **It is informational, not a request.** The payer is not asked to approve or reject anything. This is the fundamental difference from [DebiCheck authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication), where collections cannot start until the payer approves.
- **It creates awareness.** Because the payer was told about the mandate at registration, a later claim that they knew nothing about the debit order carries less weight in a dispute.

## What if the payer objects to the registration?

The payer cannot decline the registration the way they can decline a DebiCheck request, but they are not powerless. A payer who does not recognise or does not accept the mandate can:

- Query the mandate with their bank.
- Dispute the mandate or any collections made against it.
- Ask their bank to act on the mandate, which can lead to suspension or cancellation of the registered record.

If a payer raises a query with their bank, expect the bank or the payer to contact you. It is good practice to resolve the underlying contractual question directly with the payer quickly — an unresolved objection tends to become a formal dispute. See [Returns and Disputes](https://docs.switchtransact.com/faq/registered-mandates/returns-and-disputes) for how disputes are handled.

## Can a registration be rejected?

Yes. The payer's bank can reject a registration request, for example where the account details are invalid, the account cannot accept debit orders, or the request fails the bank's validation rules. A rejected registration means no mandate record exists, and you should not collect against it. Correct the details and resubmit, or fall back to another collection type if registration is not possible for that account.

Statuses across the mandate's life — registered, amended, suspended, cancelled and rejected — are covered in [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle).

## What should you tell the payer before registering?

Even though the bank sends its own notification, you should set expectations when the payer signs your contract:

- Tell the payer their bank will notify them that a mandate has been registered.
- Confirm the statement name they will see when collections start.
- Give the payer a contact channel for queries, so questions come to you rather than becoming bank disputes.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)
- [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle)
- [Registered Mandate Returns and Disputes](https://docs.switchtransact.com/faq/registered-mandates/returns-and-disputes)


# Registered Mandates for Juristic and Multi-Signatory Accounts

DebiCheck was designed around a single account holder approving a mandate on their phone or at an ATM. That model breaks down for business accounts: a company account has no single natural person who can authenticate, and a multi-signatory account requires more than one person to approve any instruction. Registered mandates exist largely to solve this problem.

If you collect from businesses — insurance premiums, rentals, subscriptions, trade accounts — registered mandates are usually the strongest rail available for those payers.

## Why can't DebiCheck authenticate juristic accounts?

DebiCheck authentication is a real-time interaction between the payer's bank and the account holder, typically via USSD, banking app or ATM. For that to work, the bank needs one identifiable person with authority to approve the mandate on the spot. Juristic and multi-signatory accounts fail this requirement:

- **Juristic (company) accounts** belong to a legal entity, not a person. There is no single cellphone number that represents the company's authority.
- **Multi-signatory accounts** require two or more signatories to approve transactions. A single real-time authentication cannot capture multiple approvals.
- **Some individual payers** also cannot authenticate — they may not have a cellphone, or authentication attempts may repeatedly fail or expire.

For the DebiCheck authentication flow itself, see [Mandate Authentication](https://docs.switchtransact.com/faq/debicheck/mandate-authentication).

## How do registered mandates solve this?

The Registered Mandate Service registers the mandate details at the payer's bank without requiring electronic approval. The bank records the mandate and notifies the account holder of the registration, but no authentication takes place.

For a juristic account, this means:

1. The company signs your contract and debit order mandate through its normal internal approval process — resolutions, authorised signatories, procurement sign-off, whatever the entity requires.
2. You register the mandate at the company's bank through RMS.
3. The bank notifies the account holder that the mandate has been registered.
4. You collect against the registered mandate, with early-window processing and tracking for available funds for up to ten days.

The authority question is answered by your underlying mandate document, not by a real-time bank interaction. That makes it essential that the mandate is properly executed by people with authority to bind the entity.

## What should a juristic mandate include?

Everything in the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements) applies, with extra care on authority:

- The registered name and registration number of the entity being debited.
- The names and capacities of the signatories accepting the mandate.
- Confirmation that the signatories have authority to authorise debits on the account — supported by a resolution or signing authority where appropriate.
- The account details of the business account to be debited.
- Clear amount, frequency and collection date terms, exactly as you will collect.

If a dispute is ever raised, your evidence is the registered record at the bank plus this underlying mandate. A well-executed juristic mandate with proof of signing authority is difficult to repudiate.

## Are there limits or bank-specific rules?

Banks apply their own validation when registering mandates, and treatment of certain account types can differ between banks. Some accounts may not accept mandate registration at all, in which case the registration request is rejected and you would need to agree an alternative with the payer — for example an [EFT debit order](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders) or a credit-push arrangement. Confirm specifics with your sponsoring bank or payment provider rather than assuming uniform behaviour across banks.

## How does Kwik handle business collections?

Kwik supports registered mandate collections, so you can register mandates against juristic and multi-signatory accounts, collect in the early processing window and track collections for available funds — all alongside your DebiCheck and EFT collections for individual payers. See [RM vs DebiCheck vs EFT](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-debicheck-vs-eft) for guidance on routing each payer type to the right rail.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)
- [How Are Registered Mandates Registered and Payers Notified?](https://docs.switchtransact.com/faq/registered-mandates/registration-and-payer-notification)
- [DebiCheck for Business](https://docs.switchtransact.com/faq/debicheck/debicheck-for-business)


# The Registered Mandate Lifecycle Explained

A registered mandate is not a once-off event. From the moment it is registered at the payer's bank, the mandate is a living record that can be amended when contract terms change, suspended when collections must pause, and cancelled when the agreement ends. Each of these operations is communicated between your sponsoring bank and the payer's bank using ISO 20022 messages.

Understanding the lifecycle helps you keep your own records in sync with the bank-side record — mismatches between the two are a common cause of failed collections and avoidable disputes.

## What are the stages of the registered mandate lifecycle?

| Stage        | What happens                                                                              | Resulting status         |
| ------------ | ----------------------------------------------------------------------------------------- | ------------------------ |
| Initiation   | Mandate details are registered at the payer's bank; payer is notified                     | Registered (or rejected) |
| Amendment    | Changed terms — such as amount, frequency or collection date — are submitted and recorded | Amended (or rejected)    |
| Suspension   | Collections against the mandate are paused without ending the mandate                     | Suspended                |
| Cancellation | The mandate is ended; no further collections may be submitted                             | Cancelled                |

Statuses are described generically here; the exact codes and message formats depend on your bank's API or host-to-host file specification. See [API vs Host-to-Host Integration](https://docs.switchtransact.com/faq/registered-mandates/api-vs-host-to-host).

## How is a mandate initiated?

Initiation is the registration step: you submit the mandate details, the payer's bank validates and records them, and the payer is notified of the registration. A successful initiation returns a registered status; a failed one returns a rejection, for example where account details are invalid or the account cannot accept mandate registration. The full flow is covered in [Registration and Payer Notification](https://docs.switchtransact.com/faq/registered-mandates/registration-and-payer-notification).

Only collect against mandates in a registered (or validly amended) state. Collecting against a rejected or cancelled mandate exposes you to unpaids and disputes.

## When and how do you amend a mandate?

Amend the registered mandate whenever the collection terms change — a new instalment amount, a different collection day, a changed frequency. The amendment is sent to the payer's bank, which updates the registered record.

Keep two principles in mind:

- **The bank record must match what you collect.** If you increase the instalment in your billing system but never amend the registered mandate, the bank-side record no longer supports your collections, weakening your position in any dispute.
- **The payer must have agreed to the change.** An amendment message updates the bank record, but your authority still comes from the underlying contract. Changes the payer never agreed to remain disputable regardless of the registered record.

## What does suspension do?

Suspension pauses the mandate without ending it. The registered record remains at the payer's bank, but collections should not be submitted while the mandate is suspended. Typical uses include payment holidays, account queries under investigation, or a payer instruction routed through their bank.

A suspended mandate can later be reactivated or cancelled, depending on how the situation resolves. Track suspended mandates carefully so collections resume only when the mandate is active again.

## How is a mandate cancelled?

Cancellation ends the mandate permanently. It can originate from your side — the contract has ended or been settled — or from the payer's side via their bank, for example after a dispute or a payer instruction. Once cancelled:

- No further collections may be submitted against the mandate.
- A new agreement with the payer requires a new mandate and a new registration.

If the payer cancels the registered mandate but your underlying contract is still in force, the contractual debt does not disappear — but you no longer have a mandate to collect it by debit order. Resolve the contractual position with the payer before attempting any further collection.

## How do you keep lifecycle state in sync?

- Process every response and status message from the bank, not just successes.
- Reconcile your mandate register against bank responses regularly.
- Block collection submission automatically for suspended, cancelled or rejected mandates.
- Keep an audit trail of every lifecycle event alongside the underlying contract.

Kwik manages this synchronisation for you when you run registered mandate collections through the Kwik platform, exposing current mandate status so your billing only collects against active mandates.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [How Are Registered Mandates Registered and Payers Notified?](https://docs.switchtransact.com/faq/registered-mandates/registration-and-payer-notification)
- [Registered Mandate Collections, Tracking and Settlement](https://docs.switchtransact.com/faq/registered-mandates/collections-tracking-and-settlement)
- [DebiCheck Mandate Lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle)


# Registered Mandate Collections, Tracking and Settlement

Registering a mandate is only the first half of the process — the value comes from collecting against it. Registered mandate collections run on the same modern ISO 20022 rails as DebiCheck, which means early-window processing and tracking for available funds, two features that ordinary EFT debit orders do not enjoy.

This page explains how collections against registered mandates are submitted, how the tracking mechanism works, and how settlement reaches your account.

## How do you submit a collection against a registered mandate?

Each collection is a payment instruction that references the registered mandate at the payer's bank:

1. You (or your payment provider) submit the collection for the agreed action date, with an amount and terms that match the registered mandate.
2. The instruction flows via your sponsoring bank to the payer's bank.
3. On the action date, the payer's bank attempts to debit the payer's account.
4. The outcome — paid, unpaid or in tracking — is reported back to you.

The collection must stay within the registered mandate's terms. If the contract terms have changed, amend the mandate first; see [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle).

## When do registered mandate collections process?

Registered mandate collections process in the early processing window each day — the window in which the modern collection streams debit accounts before other payment activity. Within that window they run as second priority: authenticated DebiCheck collections process first, then registered mandate collections.

This still puts you well ahead of ordinary [EFT debit orders](https://docs.switchtransact.com/faq/debit-orders/eft-debit-orders), which process later. When a payer's account holds limited funds, position in the processing order often decides which debit gets paid, so the early window materially improves your success rates.

## How does tracking work?

Tracking is the feature that re-presents a collection when the account has insufficient funds at the first attempt. Registered mandate collections support tracking for available funds for a period of up to ten days, the same as DebiCheck.

In practice:

- If the first debit attempt fails for insufficient funds, the collection enters tracking rather than immediately returning unpaid.
- The payer's bank monitors the account and debits it when sufficient funds become available within the tracking period.
- If the tracking period ends without funds becoming available, the collection is returned unpaid.

Tracking should be disclosed to the payer in your mandate — see the credit tracking disclosure in [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements). Choose a tracking period that suits your book: longer tracking captures more late salary deposits, but delays certainty about the outcome.

## When do you receive settlement?

Once a collection is successfully debited, the funds settle through the interbank clearing and settlement process into the collections account operated by your sponsoring bank or payment provider, and from there are paid over to you according to your settlement arrangement.

Timing depends on your setup, but the general pattern is:

- Successful collections settle after the interbank settlement cycle for the action date.
- Collections paid out of tracking settle when the tracked debit succeeds, which can be any day within the tracking window.
- Your provider then pays the settled funds to your nominated account per your agreed settlement schedule.

Reconcile settlements against your submitted collections rather than assuming totals — some collections will be unpaid, some will still be in tracking, and some may later be disputed. For the mechanics, see [Clearing, Settlement and Reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

## What can you do to maximise collection success?

- Align action dates with payers' salary dates where possible.
- Use tracking on collections where payers' cashflow is unpredictable.
- Keep registered mandate terms up to date so collections are never rejected for mismatching an amended contract.
- Monitor unpaid reasons and adjust strategy per payer; see [Returns and Disputes](https://docs.switchtransact.com/faq/registered-mandates/returns-and-disputes).

Kwik submits registered mandate collections, manages tracking and reconciles settlement for you, reporting each collection's status so your billing system always reflects the true outcome.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [Registered Mandate Returns and Disputes](https://docs.switchtransact.com/faq/registered-mandates/returns-and-disputes)
- [DebiCheck Collections, Tracking and Retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries)
- [Clearing, Settlement and Reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation)


# Registered Mandate Returns and Disputes Explained

Even with a mandate registered at the payer's bank, not every collection succeeds and not every payer accepts every debit. Returns (unpaid collections) and disputes are a normal part of running a collections book — what changes with registered mandates is the strength of your position when they happen.

This page covers why registered mandate collections come back unpaid, how disputes work, and where registration does and does not protect you.

## Why are registered mandate collections returned unpaid?

Common reasons a collection is returned include:

- **Insufficient funds** — the account did not hold enough money, and either tracking was not used or the tracking period expired without funds becoming available.
- **Account issues** — the account is closed, frozen or otherwise unable to accept debits.
- **Mandate issues** — the referenced mandate is suspended, cancelled or does not match the collection terms.
- **Payer instructions** — the payer has instructed their bank to stop or block the debit.

Banks report the reason with each return. Reason codes vary by bank and integration, so treat them generically in your processes and map your bank's specific codes during implementation. For handling strategies common to all debit orders, see [Unpaids, Returns and Resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

## Can a payer dispute a registered mandate collection?

Yes. Registration does not remove the payer's right to dispute. A payer who does not recognise or does not accept a debit can approach their bank, and the dispute is then handled between the payer, the banks and you as the collector.

What registration changes is the evidence. When a dispute is raised:

- The payer's bank holds the registered mandate details on record.
- The payer was notified when the mandate was registered, so they were aware of it before collections began.
- You hold the underlying signed or electronically accepted mandate.

Together, this makes a "I never authorised this" claim much harder to sustain than against a plain EFT debit order, where the bank has no record at all.

## How does dispute protection compare across collection types?

| Collection type    | Bank-side record           | Payer approval            | Dispute position for the collector       |
| ------------------ | -------------------------- | ------------------------- | ---------------------------------------- |
| DebiCheck          | Authenticated mandate      | Yes — payer authenticated | Strongest                                |
| Registered mandate | Registered mandate details | No — payer notified only  | Stronger than EFT, weaker than DebiCheck |
| EFT debit order    | None                       | No                        | Weakest — collector's records only       |

The gap between RM and DebiCheck matters: because the payer never approved the registered mandate, a dispute cannot be answered with "the payer authenticated these exact terms". Your defence rests on the registered record plus the quality of your underlying mandate. See [RM vs DebiCheck vs EFT](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-debicheck-vs-eft) for the full comparison.

## What should you do when a dispute is raised?

1. **Retrieve your evidence** — the underlying mandate, proof of the payer's acceptance, the registration record and the collection history.
2. **Respond within the required timeframe.** Dispute processes run on deadlines; a strong mandate produced late is worth little.
3. **Contact the payer.** Many disputes are recognition or affordability problems that a conversation resolves faster than the formal process.
4. **Check the mandate status afterwards.** A dispute can result in the registered mandate being suspended or cancelled — do not keep collecting against it until the position is clear.
5. **Track dispute rates.** Persistent disputes on a segment of your book usually signal a sales, communication or affordability problem worth fixing at the source.

## How do you keep returns and disputes low?

- Meet the [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements) on every mandate, with clear amount and date terms.
- Use a statement name payers recognise.
- Tell payers at sign-up that their bank will notify them of the registration, so the notification confirms rather than surprises.
- Amend the registered mandate whenever contract terms change, so collections always match the bank-side record.
- Use tracking to convert insufficient-funds returns into successful collections.

Kwik reports returns and dispute outcomes against each registered mandate collection, so you can act on them quickly and keep your book healthy.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [Registered Mandate Collections, Tracking and Settlement](https://docs.switchtransact.com/faq/registered-mandates/collections-tracking-and-settlement)
- [Debit Order Disputes and Stop Payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)
- [DebiCheck Unpaids, Returns and Disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)


# Registered Mandates: API vs Host-to-Host Integration

Every registered mandate operation — registration, amendment, suspension, cancellation and the collections that follow — is ultimately an ISO 20022 message exchanged between your sponsoring bank and the payer's bank. What you choose is how those messages reach your bank: through a real-time API or through host-to-host (H2H) file exchange.

Banks typically publish both options — for example, Absa offers a Registered Mandate host-to-host file specification alongside its Registered Mandate API. Both carry the same operations; they differ in interaction style, latency and operational model.

## What is the API integration model?

With an API integration, your system calls the bank's registered mandate API for each operation and receives responses over the same channel:

- You send a registration, amendment, suspension or cancellation request as an individual API call.
- Validation failures surface immediately, so errors can be fixed while the customer interaction is still live.
- Status updates and outcomes are returned as API responses or asynchronous notifications.

APIs suit event-driven flows: a customer signs up on your website, and you register the mandate as part of the onboarding journey, confirming success before the session ends.

## What is the host-to-host integration model?

With host-to-host integration, you exchange batch files with the bank over a secure managed connection:

- You compile mandate instructions and collections into files in the bank's specified format and transmit them on an agreed schedule.
- The bank processes the file and returns response files with the outcome of each instruction.
- Your systems import the response files and update mandate and collection statuses.

H2H suits scheduled, high-volume processing: a monthly billing run that registers, amends and collects against thousands of mandates in one batch.

## How do the two models compare?

| Aspect          | API                                                               | Host-to-host                                                  |
| --------------- | ----------------------------------------------------------------- | ------------------------------------------------------------- |
| Interaction     | Per-mandate, real-time requests                                   | Batched files on a schedule                                   |
| Feedback        | Immediate validation and responses                                | Response files after processing                               |
| Best for        | Onboarding journeys, event-driven registration                    | Bulk billing runs, large books                                |
| Volume handling | One call per operation; high volumes need throughput planning     | Thousands of instructions per file                            |
| Error handling  | Fix and retry in-session                                          | Correct and resubmit in the next file cycle                   |
| Build effort    | REST/JSON style development, authentication, retries, idempotency | File generation, transfer scheduling, response reconciliation |

The general trade-offs between these styles apply across all payment types — see [Batch Files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis) for the broader discussion.

## Which should you choose?

Consider your operating pattern:

- **Choose API** when mandates are created one at a time as customers sign up, and you want immediate confirmation that the registration succeeded before proceeding.
- **Choose host-to-host** when you run scheduled bulk cycles against a large existing book and per-mandate latency does not matter.
- **Combine both** where it fits: many collectors register new mandates via API during onboarding and run monthly collections via files.

Whichever channel you choose, the lifecycle rules are identical — the same statuses (registered, amended, suspended, cancelled, rejected) come back, just packaged as API responses or file records. See [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle).

## Do you need to build the bank integration yourself?

Not necessarily. Integrating directly with a bank's RM API or H2H specification means handling ISO 20022 message structures, bank onboarding, security requirements and per-bank differences yourself. A payment provider abstracts this away: Kwik offers registered mandate collections through a single integration, handling the bank messaging, response processing and reconciliation on your behalf — the same way it does for DebiCheck, where an equivalent choice exists (see [DebiCheck: API vs Host-to-Host](https://docs.switchtransact.com/faq/debicheck/api-vs-host-to-host)).

That lets you work with one modern API regardless of which underlying channel and sponsoring bank carries the messages.

## Related topics

- [Registered Mandates hub](https://docs.switchtransact.com/faq/registered-mandates)
- [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle)
- [Batch Files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis)
- [API Authentication and Signatures](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures)


# Registered Mandates

Registered mandates give EFT debit orders many of the protections of DebiCheck without real-time payer authentication. Learn how registration, notification and collections work.

## Topics in this section

- [What Is a Registered Mandate?](https://docs.switchtransact.com/faq/registered-mandates/what-is-a-registered-mandate)
- [RM vs RMS: What Is the Difference?](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-rms)
- [Registered Mandates vs DebiCheck vs EFT Debit Orders](https://docs.switchtransact.com/faq/registered-mandates/rm-vs-debicheck-vs-eft)
- [How Are Registered Mandates Registered and Payers Notified?](https://docs.switchtransact.com/faq/registered-mandates/registration-and-payer-notification)
- [Registered Mandates for Juristic and Multi-Signatory Accounts](https://docs.switchtransact.com/faq/registered-mandates/juristic-and-multisignatory-accounts)
- [The Registered Mandate Lifecycle Explained](https://docs.switchtransact.com/faq/registered-mandates/mandate-lifecycle)
- [Registered Mandate Collections, Tracking and Settlement](https://docs.switchtransact.com/faq/registered-mandates/collections-tracking-and-settlement)
- [Registered Mandate Returns and Disputes Explained](https://docs.switchtransact.com/faq/registered-mandates/returns-and-disputes)
- [Registered Mandates: API vs Host-to-Host Integration](https://docs.switchtransact.com/faq/registered-mandates/api-vs-host-to-host)


# What Is an EFT Credit Payment?

An EFT credit payment is an electronic funds transfer where the payer instructs their own bank to push money into another bank account. It is the everyday "bank transfer" most South Africans use to pay rent, suppliers, invoices and friends from internet banking or a banking app.

Because the payer initiates the payment, an EFT credit is a push payment. This makes it fundamentally different from a [debit order](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order), where the receiving business pulls money from the payer's account under a mandate.

## How does an EFT credit payment work?

When you capture an EFT payment, your bank validates the instruction, debits your account and sends the payment into the interbank clearing system.

The typical flow is:

1. The payer captures the beneficiary's bank, branch code, account number and a payment reference.
2. The payer's bank validates the instruction and debits the payer's account.
3. The payment is submitted to BankservAfrica, the national automated clearing house, in a batch.
4. BankservAfrica sorts the batch and delivers the payment to the beneficiary's bank.
5. Interbank settlement takes place through the South African Reserve Bank's settlement system.
6. The beneficiary's bank credits the beneficiary's account.

For more detail on each stage, see [what happens when you make a bank transfer](https://docs.switchtransact.com/faq/bank-transfers/bank-transfer-lifecycle).

## How long does an EFT take to reflect?

EFT credits are batch-cleared, not real-time. Payments are collected into batches and exchanged between banks at scheduled processing windows during the day.

As a general rule:

- **Same bank:** transfers between accounts at the same bank are usually immediate, because no interbank clearing is needed.
- **Different banks:** payments typically reflect in one to two banking days, depending on when the payment was captured relative to the bank's cut-off times.
- **Weekends and public holidays:** payments captured after the last cut-off, or on non-banking days, are processed in the next banking day's cycles.

Cut-off times differ between banks and channels, which is why two payments captured minutes apart can reflect on different days. See [cut-off times and value dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates) for how this works.

## Why is EFT still so widely used?

Despite being slower than instant rails, EFT remains the workhorse of South African payments because it is:

- **Cheap:** batch processing keeps per-transaction costs low.
- **Universal:** every bank account in the country can receive an EFT credit.
- **Suited to bulk:** salaries, supplier runs and refunds are processed efficiently in large batches.
- **Well understood:** businesses and consumers know how to make and reconcile EFT payments.

When speed matters more than cost, [real-time clearing](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) or [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) move money in seconds rather than days.

## What are the risks with EFT payments?

EFT credits carry a few practical risks worth managing:

- **Wrong account details:** banks generally do not match the beneficiary name to the account number, so a payment to a mistyped account number may be paid away. [Account verification](https://docs.switchtransact.com/faq/bank-transfers/beneficiary-and-account-verification) before paying reduces this risk.
- **Proof of payment fraud:** a payment notification or POP document is not the same as cleared funds. Only release goods once the money reflects in your account — see [proof of payment and reconciliation](https://docs.switchtransact.com/faq/bank-transfers/proof-of-payment-and-reconciliation).
- **Limited recallability:** an EFT can sometimes be recalled before settlement if fraud is reported quickly, but recovery is never guaranteed. Read more under [final and irrevocable payments](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments).

## Tips

- Always use a clear, unique payment reference so the beneficiary can reconcile your payment.
- Check your bank's cut-off times before promising a supplier same-day payment.
- Verify new beneficiary account details before the first payment.
- Do not treat an emailed proof of payment as confirmation — wait for cleared funds.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# Proof of Payment and Reconciliation Explained

A proof of payment (POP) is the notification or document a payer sends to show that a payment has been made — a bank-generated payment notification, a screenshot from a banking app, or a PDF confirmation. South African businesses ask for POPs constantly, and fraudsters exploit that habit constantly too.

The uncomfortable truth is that a POP proves very little. The only reliable confirmation that you have been paid is cleared funds reflecting in your own bank account.

## Why is a proof of payment not proof of payment?

A POP can be misleading for legitimate and fraudulent reasons:

- **The payment may not have cleared yet.** An interbank [EFT credit](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments) can take one to two banking days to reflect. A genuine POP today does not mean money in your account today.
- **The payment can still fail.** A payment can be rejected or returned after the POP was generated — for example if the account details were wrong. See [failed and returned transfers](https://docs.switchtransact.com/faq/bank-transfers/failed-and-returned-transfers).
- **The document can be fake.** PDF confirmations and app screenshots are trivially forged or edited. Fake POPs are one of the most common fraud methods used against South African businesses, especially for goods collected in person.
- **The payment can be manipulated.** A fraudster can make a real payment and recall or dispute it, or pay from a compromised account.

If a "buyer" pressures you to release goods on the strength of a POP — especially with urgency, or outside business hours — treat it as a red flag.

## How should a business confirm payment safely?

- **Wait for cleared funds.** Check your own bank account or statement feed; only funds reflecting there count.
- **Prefer instant rails for on-the-spot transactions.** A [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) payment or Request to Pay confirms in seconds and is [final and irrevocable](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments), which removes the waiting problem entirely.
- **Understand your bank's notifications.** A "payment received" notification from your own bank is far stronger evidence than any document a payer sends you — but even then, check whether the funds are cleared or provisional.
- **Never release high-value goods against an emailed POP alone.**

## What is reconciliation?

Reconciliation is the process of matching the credits on your bank statement to what you expected to receive — invoices, customer accounts, orders or payout instructions — so that every rand is accounted for. It is the operational counterpart to confirmation: confirmation tells you money arrived; reconciliation tells you what it was for.

Good reconciliation depends on three things:

1. **Unique references:** every invoice or customer gets a unique payment reference, so statement lines match records automatically. Vague references like a customer's first name create manual work and errors.
2. **Timely statement data:** daily statement downloads, or automated bank statement feeds, so credits are matched as they arrive rather than at month-end.
3. **Exception handling:** a defined process for unmatched credits, short payments, overpayments and duplicates.

The wider discipline, including how clearing and settlement timing affects reconciliation, is covered in [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

## How can reconciliation be automated?

Manual reconciliation does not scale past a few dozen payments a day. Automation options include:

- Bank statement feeds or aggregation services that pull statement lines into your systems automatically.
- Reference-based auto-matching, with fuzzy matching for imperfect references.
- Choosing payment methods that reconcile themselves — payment links, PayShap Request to Pay and [debit orders](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order) all tie each payment to a known customer and amount, unlike free-form EFTs.

## Tips

- Publish an exact payment reference on every invoice and insist customers use it.
- Train staff that no goods leave on the strength of a POP document.
- Reconcile daily, and investigate unmatched credits promptly — unclaimed money creates its own problems.
- For collect-on-payment sales, use an instant, irrevocable rail instead of EFT plus POP.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# Why Do Bank Transfers Fail or Get Returned?

Most bank transfers complete without incident, but a meaningful percentage fail or come back. A transfer can be rejected upfront before it ever leaves the payer's bank, or it can be returned later when the receiving bank cannot apply the credit. Knowing the difference — and the common reasons — makes it much easier to fix problems and manage expectations on both sides of a payment.

Failures behave differently depending on the rail: an instant [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) or [RTC](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) payment either succeeds or fails within seconds, while a batch [EFT credit](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments) can be returned a day or more after the payer was debited.

## What is the difference between a rejected and a returned transfer?

- **Rejected (failed upfront):** the payment never enters clearing. The payer's bank blocks it during validation, and the payer's account is either not debited or immediately re-credited. The payer usually sees an error at capture time.
- **Returned (failed after clearing):** the payment cleared to the receiving bank, but that bank could not credit the beneficiary. The funds are sent back through the clearing system with a reason code, and the payer's account is re-credited — often one or more banking days after the original payment.

The stages where each failure can occur are described in the [bank transfer lifecycle](https://docs.switchtransact.com/faq/bank-transfers/bank-transfer-lifecycle).

## Why do transfers get rejected upfront?

Common validation failures at the payer's bank include:

- Insufficient funds or exceeding a daily/per-transaction limit.
- Invalid account number format for the branch code (CDV failure).
- Payments blocked by fraud screening rules.
- Instructions captured outside an allowed processing window or with an invalid future date.

## Why do transfers get returned by the receiving bank?

Typical return reasons include:

- **Account closed:** the beneficiary account no longer exists.
- **No such account / unable to locate:** the account number does not exist at that bank or branch, usually because of a capture error.
- **Account frozen or blocked:** legal holds, deceased estates or compliance blocks prevent the credit from being applied.
- **Account type cannot accept the credit:** some products cannot receive certain payment types.
- **Recalled by the payer's bank:** in limited cases — usually reported fraud — an EFT can be recalled before settlement. Recovery is never guaranteed; see [final and irrevocable payments](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments).

Each return carries a reason code that identifies the cause. Interpreting these systematically is covered in [error and reason codes](https://docs.switchtransact.com/faq/payment-operations/error-and-reason-codes).

## How long do returned funds take to come back?

For batch EFT, a return typically arrives one to two banking days after the original payment, following the same batch windows and [cut-off times](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates) as any other payment. This creates an awkward gap: the payer has been debited, the beneficiary has received nothing, and neither side can see where the money is. It is sitting in the interbank process and will be re-credited to the payer once the return is processed.

Instant payments avoid this gap — if a PayShap or RTC payment cannot be applied, it fails immediately and the payer is not debited.

## How should businesses handle failed and returned payouts?

For a business running [payouts and bulk payments](https://docs.switchtransact.com/faq/bank-transfers/payouts-and-bulk-payments), returns are an operational fact of life:

- Monitor return files or API notifications daily and match every returned item to its original payment.
- Park returned funds in a suspense process so they are re-paid or refunded deliberately, not forgotten.
- Correct the root cause — usually bad account details — before re-paying, ideally with [account verification](https://docs.switchtransact.com/faq/bank-transfers/beneficiary-and-account-verification).
- Track return rates; a rising rate usually points to a data-capture problem upstream.

## Tips

- If a payment has not reflected after two banking days, ask the payer for the date, amount and reference so the banks can trace it.
- Verify account details before first payment — most returns are preventable capture errors.
- Never re-send a payment until you have confirmed the first one failed, or you risk paying twice.
- Report suspected fraud to your bank immediately; recall attempts only work within a narrow window.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# How Do Cross-Border Payments and SWIFT Work?

A cross-border payment moves money from a bank account in one country to a bank account in another. Unlike domestic transfers, there is no single clearing house connecting all the world's banks, so international payments from South Africa travel through SWIFT messaging and chains of correspondent banks — and are subject to South African Reserve Bank exchange control rules along the way.

The result is that cross-border payments are slower, more expensive and less predictable than domestic rails like [EFT](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments) or [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap), and they involve paperwork that domestic payments never require.

## How does a SWIFT payment actually work?

SWIFT itself does not move money. It is a secure messaging network that banks use to send standardised payment instructions to each other. The money moves through correspondent banking: banks hold accounts with one another, and a payment is executed by debiting and crediting those accounts along a chain.

A typical outbound payment from South Africa:

1. You give your bank the beneficiary's details — name, account number or IBAN, and the receiving bank's SWIFT/BIC code — plus the purpose of the payment.
2. Your bank converts rand to the foreign currency (or sends rand for conversion abroad) and sends a SWIFT instruction.
3. If your bank has no direct relationship with the beneficiary's bank, one or more correspondent (intermediary) banks pass the payment along the chain.
4. The beneficiary's bank receives the funds and credits the beneficiary.

Each hop adds time, cost and a compliance check, which is why international payments typically take anywhere from a day to several days, and occasionally stall for additional screening.

## What does a cross-border payment cost?

Three layers of cost apply, and only the first is always visible upfront:

- **Your bank's SWIFT/commission fees:** the charge your bank quotes for sending the payment.
- **Correspondent bank deductions:** intermediary banks in the chain may deduct their own fees from the amount in transit, so the beneficiary can receive less than you sent (depending on whether charges are set as OUR, SHA or BEN).
- **FX margin:** the exchange rate applied usually includes a spread over the interbank rate, which is often the largest cost of all.

Fees and margins vary widely between banks and providers, so compare the total amount the beneficiary will receive, not just the upfront fee.

## What are South Africa's exchange control requirements?

Cross-border payments from South Africa fall under SARB exchange control, administered through authorised dealers (the banks). In practice this means:

- Every payment needs a **balance of payments (BoP) category** describing its purpose — imports, services, gifts, investment and so on.
- **Supporting documentation** may be required, such as invoices or contracts, depending on the payment category and amount.
- **FICA documentation** — proof of identity and address — must be in place with your bank.
- Individuals have annual allowances for transfers abroad, with SARS tax compliance requirements applying above certain thresholds.
- Businesses may need supporting documents for each trade payment.

Your bank will not process the payment until the exchange control and FICA requirements are met, and incomplete paperwork is a leading cause of delay.

## What about payments within the SADC region?

For payments within the Southern African Development Community, regional rails exist alongside SWIFT. TCIB (Transactions Cleared on an Immediate Basis) is a regional low-value payment scheme operated by BankservAfrica that enables faster, cheaper cross-border payments between participating institutions in SADC countries — an alternative to routing a payment to a neighbouring country through the full SWIFT correspondent chain. Availability depends on whether both institutions participate.

## How do cross-border payments compare with domestic ones?

|              | Domestic (EFT/RTC/PayShap)  | Cross-border (SWIFT)                               |
| ------------ | --------------------------- | -------------------------------------------------- |
| Speed        | Seconds to two banking days | One to several days                                |
| Cost         | Low, known upfront          | SWIFT fees, correspondent deductions and FX margin |
| Paperwork    | None                        | BoP category, FICA, possible supporting documents  |
| Traceability | High                        | Depends on the correspondent chain                 |

For the domestic picture, see [EFT vs RTC vs PayShap vs RTGS](https://docs.switchtransact.com/faq/bank-transfers/eft-vs-rtc-vs-payshap-vs-rtgs) and the [South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system).

## Tips

- Get the beneficiary's SWIFT/BIC and account details in writing, and verify changes independently — invoice redirection fraud is common on international payments.
- Ask your bank what the beneficiary will actually receive after all deductions.
- Have your FICA and supporting documents ready before initiating the payment.
- For recurring international payments, compare specialist FX providers against your bank's rates.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# EFT vs RTC vs PayShap vs RTGS: What Is the Difference?

South Africa has several interbank payment rails, and each one makes a different trade-off between speed, cost and transaction size. Choosing the right rail matters: paying a supplier by ordinary EFT on a Friday afternoon can mean the money only reflects on Tuesday, while the same payment over PayShap or RTC arrives in seconds at a higher fee.

This page compares the four rails you will encounter most often: batch EFT, Real-Time Clearing (RTC), PayShap and RTGS. All four ultimately settle between banks through the national payment system — see [the South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system) for the bigger picture.

## How do the four rails compare?

|                  | EFT credit                                                                    | RTC                                                      | PayShap                                                           | RTGS (SAMOS)                                  |
| ---------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------------------- |
| **What it is**   | Batch bank transfer cleared through BankservAfrica                            | Real-time interbank transfer between participating banks | Low-value instant rapid payments programme launched in March 2023 | The SARB's real-time gross settlement system  |
| **Speed**        | One to two banking days between banks; usually immediate within the same bank | About 60 seconds                                         | Seconds                                                           | Real time, during SAMOS operating hours       |
| **Typical use**  | Invoices, salaries, bulk payouts, everyday transfers                          | Urgent payments where the recipient banks elsewhere      | Person-to-person and low-value business payments, pay-by-proxy    | High-value corporate and interbank settlement |
| **Cost**         | Low                                                                           | Higher per-transaction fees, set by each bank            | Low to moderate, set by each bank                                 | Highest, priced for high-value payments       |
| **Limits**       | Bank and profile dependent                                                    | Per-transaction limits set by banks                      | Bank-dependent low-value caps                                     | Designed for high values                      |
| **Reversible?**  | Recall sometimes possible before settlement, not guaranteed                   | Final and irrevocable                                    | Final and irrevocable                                             | Final and irrevocable                         |
| **Availability** | Banking-day processing windows                                                | Typically extended hours, bank dependent                 | 24/7/365                                                          | SAMOS operating window                        |

Exact fees and limits differ by bank and change over time, so always confirm with your own bank rather than relying on published figures.

## When should you use ordinary EFT?

Use [EFT credit payments](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments) when cost matters more than speed: bulk payouts, salary runs, supplier payments on agreed terms and any payment where a one to two day clearing window is acceptable. Batch EFT is by far the cheapest way to move money between banks, but you must plan around [cut-off times and value dates](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates).

## When should you use RTC?

Use [Real-Time Clearing](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) when a specific payment must reflect at another bank within about 60 seconds — releasing a vehicle, settling a property-related payment, or paying a supplier who will not release stock without cleared funds. Banks charge a premium for RTC and apply their own per-transaction limits.

## When should you use PayShap?

Use [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) for low-value payments that need to be instant, especially where you only have the recipient's cellphone number rather than their account details. PayShap runs around the clock, clears in seconds and supports Request to Pay, which lets a business request an instant payment from a customer.

## When should you use RTGS?

RTGS payments settle individually and immediately across accounts at the South African Reserve Bank through SAMOS. In practice, RTGS is used for high-value corporate transactions and for the interbank settlement that sits behind the retail rails. Most businesses never initiate an RTGS payment directly; their bank does so on their behalf when the value justifies it.

## Which rail should a business default to?

A practical rule of thumb:

- **Bulk and scheduled payments:** batch EFT.
- **Urgent one-off payments:** RTC or PayShap, depending on value and whether the amount fits within PayShap's bank-dependent limits.
- **Collections from customers:** consider [debit orders](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order) instead, since transfers depend on the customer remembering to pay.
- **Very high values:** ask your bank about RTGS.

Remember that instant payments cannot be recalled — see [final and irrevocable payments](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments) before choosing a real-time rail for large amounts.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# What Happens When You Make a Bank Transfer?

When you press "Pay" in your banking app, a chain of events starts that involves your bank, the national clearing house, the South African Reserve Bank and the beneficiary's bank. Understanding this lifecycle explains why some payments reflect instantly, why others take a day or two, and where a payment can fail along the way.

The stages below describe an ordinary interbank EFT credit. Instant rails like [RTC](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) and [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) compress the same steps into seconds, and same-bank transfers skip interbank clearing entirely.

## Stage 1: Capture and validation

The payment starts when the payer captures the instruction — beneficiary bank, branch code, account number, amount and reference — through internet banking, a banking app, a batch file or an API.

The payer's bank then validates the instruction:

- Checks the account number format against the branch code (check-digit validation).
- Confirms the payer has sufficient funds or an available limit.
- Applies fraud screening and daily or per-transaction limits.
- Confirms the payment falls within an allowed processing window.

If validation fails, the payment is rejected immediately and never enters clearing.

## Stage 2: The payer's account is debited

Once validated, the payer's bank debits the payer's account and takes on the obligation to deliver the payment. From the payer's perspective the money is gone, but the beneficiary has not received anything yet — the payment still has to clear and settle.

## Stage 3: Clearing through BankservAfrica

For interbank payments, the payer's bank submits the payment to BankservAfrica, South Africa's automated clearing house. EFT credits are cleared in batches:

- Payments are accumulated into batches during the day.
- Batches are exchanged at scheduled processing windows, which is why [cut-off times](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates) matter.
- BankservAfrica sorts each batch and delivers every payment to the correct receiving bank.

Clearing is the exchange of payment instructions and the calculation of what each bank owes the others. No money has actually moved between the banks yet.

## Stage 4: Settlement at the Reserve Bank

Settlement is where value actually moves between banks. The banks' obligations from clearing are settled across their accounts at the South African Reserve Bank through SAMOS, the real-time gross settlement system. Batch EFT obligations are typically settled on a netted basis at set settlement windows, while RTGS payments settle individually in real time.

The distinction between clearing and settlement trips up many people — see [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation) for a deeper explanation.

## Stage 5: The beneficiary's account is credited

The beneficiary's bank receives the payment from clearing, validates the account number, and credits the beneficiary's account with the payment reference the payer captured. Only at this point does the money reflect for the beneficiary.

If the account number is invalid, closed or blocked, the beneficiary's bank cannot apply the credit and returns the payment — see [failed and returned transfers](https://docs.switchtransact.com/faq/bank-transfers/failed-and-returned-transfers).

## Why do the timelines differ so much?

| Scenario                                     | Typical time to reflect |
| -------------------------------------------- | ----------------------- |
| Same bank, both accounts                     | Usually immediate       |
| Interbank EFT, before cut-off                | Often next banking day  |
| Interbank EFT, after cut-off or on a weekend | One to two banking days |
| RTC                                          | About 60 seconds        |
| PayShap                                      | Seconds, 24/7           |

The batch windows and settlement cycles are the reason ordinary EFT is cheap but slow, while real-time rails cost more per transaction.

## Tips

- Capture payments well before your bank's cut-off if the beneficiary needs the funds the next day.
- Use a unique reference so the beneficiary can match the credit to your invoice or account.
- Remember that a debit on your statement does not mean the beneficiary has been paid yet.
- For time-critical payments, use RTC or PayShap rather than hoping a batch EFT clears in time.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# What Is Real-Time Clearing (RTC)?

Real-Time Clearing (RTC) is South Africa's original fast payment rail. Where an ordinary EFT credit can take one to two banking days to reflect at another bank, an RTC payment clears between participating banks in about 60 seconds. Banks usually present it to customers as an "immediate payment", "instant payment" or "pay and clear now" option.

RTC has been the go-to option for urgent interbank payments for years, and it remains widely used even though [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) now offers instant payments for lower values around the clock.

## How does RTC work?

RTC follows the same logical steps as any bank transfer — capture, validation, clearing, settlement and crediting — but the clearing leg happens as a single real-time message rather than a batch:

1. The payer selects the immediate payment option and captures the beneficiary's details.
2. The payer's bank validates the payment and debits the payer's account.
3. The payment is cleared to the beneficiary's bank in real time through BankservAfrica.
4. The beneficiary's bank confirms acceptance and credits the beneficiary within about 60 seconds.

Because the receiving bank confirms the payment before it completes, the payer gets near-immediate certainty that the money has been delivered. Compare this to the batch process described in the [bank transfer lifecycle](https://docs.switchtransact.com/faq/bank-transfers/bank-transfer-lifecycle).

## How much does RTC cost, and what are the limits?

RTC is priced at a premium compared with batch EFT. Each bank sets its own fee, and the difference can be significant — instant payments cost the banks more to process, and pricing reflects that.

Limits are also set by each bank:

- Banks apply their own per-transaction limits for RTC payments.
- Your profile's daily payment limits still apply on top of any RTC-specific limit.
- Limits differ between personal and business banking and between channels.

Because fees and limits are bank-dependent and change over time, confirm the current figures with your own bank before relying on RTC for a specific payment.

## Can an RTC payment be reversed?

No. RTC payments are final and irrevocable once processed. The receiving bank credits the beneficiary immediately, so there is no settlement delay during which the payment could be recalled.

This makes RTC excellent for legitimate urgent payments and equally attractive to fraudsters. Before making a large immediate payment:

- Verify the beneficiary's account details independently, not from an emailed invoice alone.
- Consider [account verification](https://docs.switchtransact.com/faq/bank-transfers/beneficiary-and-account-verification) to confirm the account belongs to the person or business you intend to pay.
- Understand the implications of [final and irrevocable payments](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments) before you press pay.

## When should you use RTC instead of EFT or PayShap?

Use RTC when:

- The payment must reflect at another bank within a minute or two.
- The amount exceeds PayShap's bank-dependent low-value limits.
- The beneficiary will only act — releasing goods, a vehicle or documents — once funds have cleared.

Use ordinary [EFT](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments) when cost matters more than speed, and PayShap for low-value instant payments, especially outside banking hours. The full comparison is in [EFT vs RTC vs PayShap vs RTGS](https://docs.switchtransact.com/faq/bank-transfers/eft-vs-rtc-vs-payshap-vs-rtgs).

## Tips

- Double-check the account number before confirming — there is no undo on RTC.
- Check your bank's RTC operating hours; some banks restrict immediate payments late at night or apply different rules after hours.
- Do not pay a fee premium unnecessarily: if the beneficiary only needs funds tomorrow, a normal EFT before [cut-off](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates) is usually enough.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# What Is PayShap and How Does It Work?

PayShap is South Africa's low-value instant payment service. Launched in March 2023 as the industry's rapid payments programme, it was built by BankservAfrica together with the major banks to make instant payments cheap and accessible enough for everyday use. A PayShap payment clears in seconds, works around the clock every day of the year, and can be addressed to a cellphone number instead of a bank account.

PayShap is part of a broader modernisation of the [South African national payment system](https://docs.switchtransact.com/faq/how-payments-work/south-african-national-payment-system), aimed at reducing the economy's reliance on cash and slow batch EFT.

## How does a PayShap payment work?

PayShap supports two ways of addressing a payment:

- **Pay-by-account:** the payer captures the beneficiary's bank account details, as with a normal transfer, and the payment clears instantly.
- **Pay-by-proxy:** the payer enters the beneficiary's ShapID — a proxy, typically a cellphone number, that the beneficiary has registered against their bank account. The payer never needs to know the account number.

In both cases the payment is cleared between the banks in seconds and the beneficiary can use the funds immediately. A third capability, Request to Pay, was added later and lets a payee send a payment request that the payer approves in their banking app — see [ShapIDs and Request to Pay](https://docs.switchtransact.com/faq/bank-transfers/shapids-and-request-to-pay).

## How is PayShap different from RTC and EFT?

|              | PayShap                        | RTC                            | EFT credit                                |
| ------------ | ------------------------------ | ------------------------------ | ----------------------------------------- |
| Speed        | Seconds                        | About 60 seconds               | One to two banking days                   |
| Availability | 24/7/365                       | Extended hours, bank dependent | Banking-day batch windows                 |
| Addressing   | Account or ShapID proxy        | Account details only           | Account details only                      |
| Value range  | Low-value, bank-dependent caps | Higher, bank-set limits        | Bank and profile limits                   |
| Reversible   | No — final and irrevocable     | No — final and irrevocable     | Recall sometimes possible, not guaranteed |

The full four-rail comparison, including RTGS, is at [EFT vs RTC vs PayShap vs RTGS](https://docs.switchtransact.com/faq/bank-transfers/eft-vs-rtc-vs-payshap-vs-rtgs).

## What are the PayShap limits?

PayShap is designed for low-value payments, and each bank sets its own transaction and daily limits within the industry framework. The industry transaction cap has been increased over time as adoption has grown, so treat any specific number you read as potentially outdated — check with your bank for the limits that apply to your account today.

## Can a PayShap payment be reversed?

No. PayShap payments are final and irrevocable. The beneficiary's bank credits the account in seconds, so there is no window in which the payment can be recalled. If you pay the wrong ShapID or account, recovery depends entirely on the recipient's cooperation and your bank's ability to request the funds back.

Practical safeguards:

- Confirm the beneficiary name your bank displays before approving the payment.
- Start with a small test payment for a new beneficiary if the amount is significant.
- Read [final and irrevocable payments](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments) to understand your options if something goes wrong.

## What does PayShap mean for businesses?

For businesses, PayShap offers instant, confirmed payments without card fees and without waiting for EFT batches to clear:

- Customers can pay invoices or make purchases with immediate confirmation, even at night or on weekends.
- Request to Pay gives businesses a way to prompt payment rather than waiting for the customer to capture an EFT.
- Instant payouts — refunds, claims, winnings, wage advances — become practical.

Kwik supports PayShap alongside its debit order, card and payout services, so businesses can collect and disburse funds over the rail that best fits each use case.

## Tips

- Register a ShapID with your bank so people can pay you using just your cellphone number.
- Treat PayShap like cash: verify who you are paying before you confirm.
- For amounts above your bank's PayShap limit, use [RTC](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) instead.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# What Are ShapIDs and Request to Pay?

Two features set [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) apart from older bank transfer rails: proxy payments using a ShapID, and Request to Pay. Together they remove the two biggest points of friction in bank transfers — needing the recipient's full account details, and waiting for the payer to remember to pay.

Both features run on PayShap's instant rails, so payments clear in seconds, around the clock, and are final once processed.

## What is a ShapID?

A ShapID is a proxy — an easy-to-share identifier that stands in for a bank account. It is typically a cellphone number, registered with your bank and linked to one of your accounts. When someone pays your ShapID, their bank looks up the linked account behind the scenes and delivers the payment there.

Key points about ShapIDs:

- You register a ShapID through your own bank's app or channels.
- A ShapID links to one account at a time; you can move it to a different account or bank if you switch.
- The payer never sees your account number, which reduces the risk of your details being harvested or misused.
- Banks typically display the registered account holder's name to the payer before the payment is confirmed, giving a valuable check that you are paying the right person.

## Why are proxy payments useful?

Paying a proxy instead of an account number solves practical problems:

- **No account details needed:** you can pay someone knowing only their cellphone number.
- **Fewer capture errors:** a familiar phone number is harder to mistype than an 11-digit account number, and the name check catches most mistakes.
- **Privacy:** account numbers stay private, which matters for informal traders, landlords and anyone sharing payment details publicly.

Proxy payments do not remove the need for care entirely — PayShap payments are [final and irrevocable](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments), so always confirm the displayed name before approving.

## What is Request to Pay?

Request to Pay (RTP) was added to PayShap after its March 2023 launch. It reverses the direction of the conversation: instead of waiting for the payer to capture a payment, the payee sends a payment request and the payer simply approves or declines it in their banking app.

A typical Request to Pay flow:

1. The payee (a business or individual) sends a request specifying the amount and a reference, addressed to the payer's ShapID or account.
2. The payer receives the request in their banking app.
3. The payer reviews the details and approves or declines.
4. On approval, an instant PayShap payment is made and both parties get confirmation in seconds.

The payer stays in control throughout — nothing leaves their account without an explicit approval. This is what distinguishes Request to Pay from a [debit order](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order), where a standing mandate lets the business pull funds without per-transaction approval.

## How can businesses use Request to Pay?

Request to Pay suits situations where a business wants payment now but a card machine or checkout is impractical:

- Requesting payment for an invoice, quote or booking deposit.
- Collecting from customers who prefer bank transfers but forget to pay.
- On-the-spot payments for deliveries, trades and services.
- Replacing "please send proof of payment" with a confirmed, instant credit — removing the [POP fraud risk](https://docs.switchtransact.com/faq/bank-transfers/proof-of-payment-and-reconciliation) entirely.

Because the payment is confirmed and irrevocable within seconds, a business can release goods or services immediately, which batch EFT never allowed. Kwik offers PayShap as part of its payment toolkit for South African businesses.

## Tips

- Register your cellphone number as a ShapID so customers and friends can pay you effortlessly.
- Always check the account holder name displayed before approving a payment or a request.
- Treat unexpected payment requests with suspicion — decline anything you were not expecting.
- Use a clear reference on every request so reconciliation stays simple.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# What Makes a Payment Final and Irrevocable?

A payment is final and irrevocable when it can no longer be recalled, reversed or unwound by the payer or the payer's bank. Finality is a deliberate design feature of payment systems: the beneficiary — and the beneficiary's bank — must be able to treat received funds as theirs, otherwise no one could safely release goods against a payment.

Different South African payment rails reach finality at very different points, and misunderstanding this is behind a large share of payment fraud losses and failed recovery attempts.

## When does each payment type become final?

| Payment type            | When is it final?                 | Can it be recalled?                                     |
| ----------------------- | --------------------------------- | ------------------------------------------------------- |
| PayShap                 | Seconds after initiation          | No                                                      |
| RTC (immediate payment) | About 60 seconds after initiation | No                                                      |
| RTGS                    | On settlement, in real time       | No                                                      |
| EFT credit              | At interbank settlement           | Sometimes, before settlement only, and never guaranteed |
| Debit order             | Never truly final for the payer   | Yes — disputable by the payer                           |

## Why can't instant payments be recalled?

Instant rails like [RTC](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing) and [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) credit the beneficiary's account within seconds, and the beneficiary can immediately withdraw or move the funds. There is no in-flight window in which a recall could operate.

Once an instant payment is processed:

- Your bank cannot pull the money back.
- Recovery depends on the recipient agreeing to return the funds, or on legal action.
- If the recipient account belongs to a fraudster, the money is usually moved on within minutes.

This is why banks display the account holder's name before you confirm a PayShap payment, and why verifying details before paying matters so much — see [beneficiary and account verification](https://docs.switchtransact.com/faq/bank-transfers/beneficiary-and-account-verification).

## Can an ordinary EFT be recalled?

Sometimes, but do not rely on it. Because EFT credits are batch-cleared and settle later, there can be a short window before settlement in which the payer's bank can attempt a recall — most commonly where fraud is reported very quickly.

Important caveats:

- A recall is a request, not a right. The receiving bank and account holder's position matter.
- Once the beneficiary has been credited and settlement has occurred, the payment is final.
- Even a successful fraud report does not guarantee recovery if the funds have already been withdrawn.

If you have paid the wrong account or been defrauded, contact your bank immediately — minutes matter. The mechanics of clearing and settlement timing are covered in the [bank transfer lifecycle](https://docs.switchtransact.com/faq/bank-transfers/bank-transfer-lifecycle) and in [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

## How are debit orders different?

Credit transfers are push payments: the payer initiates them, so the system holds the payer responsible for getting the details right, and finality protects the receiver.

A [debit order](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order) is a pull payment: the business initiates the debit against the payer's account under a mandate. Because the payer did not initiate the specific transaction, the system protects the payer instead — debit orders can be disputed, and unauthorised debits can be reversed. From a business's perspective, money received by debit order is never as final as money received by PayShap or RTC.

## What does finality mean in practice?

For payers:

- Treat instant payments like handing over cash. Verify before you confirm.
- For large first-time payments, verify the account, or send a small test payment first.
- Report mistakes and fraud to your bank immediately.

For businesses receiving payments:

- Funds received via PayShap, RTC or RTGS are safe to act on once they reflect.
- Funds received by EFT are safe once cleared and settled — but a proof-of-payment document is not the same thing. See [proof of payment and reconciliation](https://docs.switchtransact.com/faq/bank-transfers/proof-of-payment-and-reconciliation).
- Revenue collected by debit order remains exposed to disputes and reversals.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# How Do Payouts and Bulk Payments Work?

A payout is a payment a business makes out to a bank account — a salary, a supplier invoice, a refund, an insurance claim, a customer withdrawal. When a business needs to make many payouts at once, they are processed as bulk payments: a single batch containing hundreds or thousands of individual credits, submitted to the bank or a payment provider in one go.

Bulk payments run on the same rails as ordinary transfers — usually batch [EFT credits](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments), with instant rails like [PayShap](https://docs.switchtransact.com/faq/bank-transfers/payshap) increasingly used where individual payouts need to arrive immediately.

## How does a bulk payment run work?

A typical bulk payment cycle looks like this:

1. **Prepare:** the business compiles beneficiary details, amounts and references — from a payroll system, accounts payable, or a platform's withdrawal queue.
2. **Validate:** account numbers are checked against branch codes (CDV checks), and ideally verified through an [account verification service](https://docs.switchtransact.com/faq/bank-transfers/beneficiary-and-account-verification) before first payment.
3. **Submit:** the batch is uploaded as a file to the bank, or submitted through a payout API.
4. **Fund:** the total value of the batch is debited from the business's account, or must be pre-funded, depending on the arrangement.
5. **Process:** the batch is cleared through BankservAfrica in the scheduled processing windows and settled between banks.
6. **Report:** the business receives results per item — paid, rejected or returned — and reconciles them against the original batch.

Because batches are cleared in windows, submission [cut-off times](https://docs.switchtransact.com/faq/how-payments-work/cut-off-times-and-value-dates) determine when beneficiaries are paid. A payroll batch submitted after cut-off pays staff a day late.

## Files or APIs — which should you use?

Businesses submit bulk payments in two main ways:

- **Batch files:** a formatted file uploaded to the bank's business banking channel or delivered host-to-host. Well suited to scheduled, high-volume runs like monthly payroll.
- **Payout APIs:** individual or batched payment instructions sent programmatically, with statuses returned via API or webhooks. Better for event-driven payouts such as marketplace withdrawals, refunds and claims.

The trade-offs between the two models are covered in [batch files vs APIs](https://docs.switchtransact.com/faq/payment-operations/batch-files-vs-apis). Kwik offers EFT payouts and PayShap payments through its platform, so businesses can automate disbursements without building bank file integrations themselves.

## What can go wrong in a bulk run?

Individual items in a batch can fail even when the batch as a whole is accepted:

- **Invalid account numbers** fail CDV validation and are rejected before processing.
- **Closed, frozen or unlocatable accounts** cause the receiving bank to return the credit, often a day or more later.
- **Duplicate submissions** happen when a file is uploaded twice — idempotency controls and batch references prevent this.
- **Insufficient funding** can cause the whole batch to be rejected.

Returned items come back with reason codes and must be investigated, corrected and re-paid. See [failed and returned transfers](https://docs.switchtransact.com/faq/bank-transfers/failed-and-returned-transfers) for the common return reasons.

## How should payouts be controlled and reconciled?

Bulk payments move significant money quickly, so controls matter:

- **Verify before you pay:** run new beneficiaries through account verification to confirm the account exists and matches the ID or registration number.
- **Dual authorisation:** require a second approver to release batches above a threshold.
- **Unique references:** give every item a unique reference so bank statement entries match back to source records automatically.
- **Reconcile every run:** match submitted items against processed results and the bank statement, and chase every exception. The discipline is described in [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).
- **Protect the process:** payout systems are prime fraud targets — restrict who can edit beneficiary details and audit changes.

## Tips

- Schedule payroll submission at least one processing window before payday.
- Keep a suspense process for returned items so beneficiaries are re-paid quickly.
- Use instant rails for one-off urgent payouts rather than re-running a batch.
- Never edit beneficiary bank details based on an emailed request without independent verification.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# What Is Beneficiary and Bank Account Verification?

Account verification answers a simple but critical question before money moves: does this bank account exist, and does it belong to the person or business I think it does? In South Africa this is done through Account Verification Services — commonly referred to as AVS, with AVS-R being the real-time version — which query the account-holding bank and return a set of yes/no results in near real time.

Verification matters because banks generally do not check that a beneficiary name matches the account number when a payment is made. If you pay the wrong account — through a typo or a fraudster's swapped banking details — the money goes where the number points, and instant payments [cannot be recalled](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments).

## What does an AVS check confirm?

An AVS request submits the account details you hold, together with the customer's identity information, to the account-holding bank. The response typically confirms whether:

- The account number exists at the bank and branch specified.
- The account is open, and how long it has been open.
- The account accepts debits.
- The account accepts credits.
- The ID number or company registration number matches the account holder.
- The initials and surname, or business name, match the account holder.
- The cellphone number or email on record matches, where supported.

The result is a series of match/no-match flags, not the account holder's actual details — verification confirms what you were given without exposing anyone's banking information.

## What is the difference between AVS and CDV?

These two checks are often confused:

- **CDV (check digit verification)** is a mathematical test that an account number is validly formatted for a given branch code. It runs offline and instantly, but it cannot tell you whether the account actually exists or who owns it. See [account validation and CDV](https://docs.switchtransact.com/faq/debit-orders/account-validation-and-cdv).
- **AVS** queries the actual bank and confirms the account's existence, status and ownership in near real time.

CDV is a cheap first filter; AVS is the real assurance. Sensible systems run CDV at capture and AVS before the first payment or debit.

## When should you verify an account?

Verification is worth the small cost and delay whenever the risk of paying or debiting the wrong account is material:

- **Before payouts:** verify supplier, employee and customer withdrawal accounts before the first payment — see [payouts and bulk payments](https://docs.switchtransact.com/faq/bank-transfers/payouts-and-bulk-payments).
- **Before debit orders:** verify that the account exists, accepts debits and belongs to the mandate signer before the first collection — this reduces unpaids and [disputes](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments).
- **When details change:** treat any request to change banking details as high-risk and re-verify. Invoice redirection fraud relies on businesses skipping this step.
- **During onboarding:** confirming that an account belongs to the customer supports FICA and fraud controls.

## What are the limits of account verification?

AVS is powerful but not a complete defence:

- A match confirms the account belongs to the named person — it does not confirm that person is trustworthy or that the invoice is genuine.
- Results reflect the account's status at the time of the check; accounts can close afterwards.
- Coverage and response times vary by bank, and some account types cannot be fully verified.

Pair verification with process controls: independent confirmation of banking-detail changes, dual authorisation on payouts, and healthy suspicion of urgency. And remember that verification protects the sending side — receiving businesses still need cleared funds, not a [proof of payment document](https://docs.switchtransact.com/faq/bank-transfers/proof-of-payment-and-reconciliation), before releasing goods.

## Tips

- Verify every new beneficiary before the first payment, not after.
- Re-verify whenever banking details change, and confirm the change with the beneficiary on a known contact number.
- Log verification results as part of your audit trail.
- Combine CDV at capture with AVS before payment for the best cost/assurance balance.

Back to the [Bank Transfers, Payouts and PayShap](https://docs.switchtransact.com/faq/bank-transfers) hub.


# Bank Transfers, Payouts and PayShap

Learn how money moves between South African bank accounts, from ordinary EFT credits to instant PayShap payments, and how businesses run payouts and reconcile incoming funds.

## Topics in this section

- [What Is an EFT Credit Payment?](https://docs.switchtransact.com/faq/bank-transfers/eft-credit-payments)
- [EFT vs RTC vs PayShap vs RTGS: What Is the Difference?](https://docs.switchtransact.com/faq/bank-transfers/eft-vs-rtc-vs-payshap-vs-rtgs)
- [What Happens When You Make a Bank Transfer?](https://docs.switchtransact.com/faq/bank-transfers/bank-transfer-lifecycle)
- [What Is Real-Time Clearing (RTC)?](https://docs.switchtransact.com/faq/bank-transfers/real-time-clearing)
- [What Is PayShap and How Does It Work?](https://docs.switchtransact.com/faq/bank-transfers/payshap)
- [What Are ShapIDs and Request to Pay?](https://docs.switchtransact.com/faq/bank-transfers/shapids-and-request-to-pay)
- [What Makes a Payment Final and Irrevocable?](https://docs.switchtransact.com/faq/bank-transfers/final-and-irrevocable-payments)
- [How Do Payouts and Bulk Payments Work?](https://docs.switchtransact.com/faq/bank-transfers/payouts-and-bulk-payments)
- [What Is Beneficiary and Bank Account Verification?](https://docs.switchtransact.com/faq/bank-transfers/beneficiary-and-account-verification)
- [Proof of Payment and Reconciliation Explained](https://docs.switchtransact.com/faq/bank-transfers/proof-of-payment-and-reconciliation)
- [Why Do Bank Transfers Fail or Get Returned?](https://docs.switchtransact.com/faq/bank-transfers/failed-and-returned-transfers)
- [How Do Cross-Border Payments and SWIFT Work?](https://docs.switchtransact.com/faq/bank-transfers/cross-border-payments-and-swift)


# How Do Invoice Payments Work?

Invoice payments are payments a customer makes against a bill you have issued, rather than at a checkout. The invoice states what is owed, by when, and how the customer can pay.

In South Africa, invoices are most commonly settled by EFT, but businesses increasingly add payment links, card payments and debit orders to get paid faster and reduce manual reconciliation.

## How does the invoice payment cycle work?

A typical invoice payment cycle looks like this:

1. You issue an invoice with an amount, due date and payment reference.
2. The customer pays using one of the payment methods offered on the invoice.
3. The payment is received and matched to the invoice using the reference.
4. The invoice is marked as paid and the customer receives confirmation.
5. Unpaid invoices are followed up before or after the due date.

The weakest points in this cycle are usually steps 2 and 3: customers delay paying because it takes effort, and payments arrive without a usable reference.

## Which payment methods work for invoices?

| Method       | How the customer pays                                          | Best suited to                        |
| ------------ | -------------------------------------------------------------- | ------------------------------------- |
| EFT          | Manual transfer from their banking app using your bank details | Business customers, larger amounts    |
| Payment link | Clicks a link on the invoice and pays online                   | Fast collection with minimal friction |
| Card payment | Pays by card via a link or hosted page                         | Consumers, immediate confirmation     |
| Debit order  | You collect on the due date under a mandate                    | Repeat customers billed regularly     |

A [payment link](https://docs.switchtransact.com/faq/accepting-payments/payment-links) on the invoice is one of the simplest upgrades: the customer pays in a few taps, the amount is fixed, and the payment is automatically tied to the invoice it belongs to.

For customers you invoice every month, a debit order mandate lets you collect the invoiced amount on the due date instead of waiting for the customer to act. See [what is a debit order](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order) for how mandates and collections work.

## How are payments matched to invoices?

Matching, or reconciliation, is the process of linking money received to the invoice it settles. It works best when:

- Every invoice carries a unique payment reference.
- The reference is short and easy to type correctly.
- Online methods, such as payment links and debit orders, carry the reference automatically.
- Incoming payments are checked against open invoices as they arrive.

Manual EFT is the hardest to reconcile because customers type their own reference, or none at all. Payments collected through a platform such as Kwik arrive with the invoice reference attached, so they can be matched automatically. For the mechanics of settlement and matching, see [clearing, settlement and reconciliation](https://docs.switchtransact.com/faq/payment-operations/clearing-settlement-and-reconciliation).

## What happens when an invoice is not paid?

Unpaid invoices need a follow-up process:

- Send a reminder shortly before the due date and again after it.
- Make it easy to pay from the reminder itself, for example by repeating the payment link.
- For debit order customers, a failed collection can be resubmitted or tracked in line with the mandate. See [unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).
- Escalate consistently overdue accounts to a defined collections process.

## Invoice payments vs subscription billing

Invoicing suits work that varies from month to month, or once-off sales. If you bill the same customers a predictable amount on a schedule, subscription billing automates the whole cycle, including collection and failed payment handling. See [how subscription payments work](https://docs.switchtransact.com/faq/billing/subscription-payments).

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [How do payment links work?](https://docs.switchtransact.com/faq/accepting-payments/payment-links)
- [What is a debit order?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order)
- [Payment statuses and references](https://docs.switchtransact.com/faq/how-payments-work/payment-statuses-and-references)


# How Do Subscription Payments Work?

Subscription payments are recurring payments a customer makes for ongoing access to a product or service — insurance premiums, gym memberships, software, security services, medical aid contributions and streaming are common South African examples.

The defining feature of a subscription is that the customer authorises payment once, at sign-up, and the business then collects each billing period without the customer having to act again.

## What happens when a customer signs up?

A subscription starts with capturing the customer's payment authority:

1. The customer chooses a plan with an amount and billing frequency.
2. They provide a payment method: a bank account for a debit order, or a card.
3. For a debit order, a mandate is created recording the amount, frequency and collection date. DebiCheck mandates are also confirmed with the customer's bank. See [how DebiCheck works](https://docs.switchtransact.com/faq/debicheck/how-debicheck-works).
4. For a card, the card is tokenised and stored for future merchant-initiated charges. See [card tokenisation and network tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens).
5. The first payment is taken, either immediately or on the first billing date.

## Debit order billing vs card billing

South African subscription businesses typically bill by debit order, card-on-file, or both.

|                    | Debit order (EFT / DebiCheck)                                 | Card-on-file                                        |
| ------------------ | ------------------------------------------------------------- | --------------------------------------------------- |
| Customer authority | Mandate against a bank account                                | Tokenised card with consent for recurring charges   |
| Collection         | You submit a payment instruction for the action date          | You initiate a merchant-initiated transaction (MIT) |
| Variable amounts   | Governed by mandate terms and, for DebiCheck, maximum amounts | Charge what was agreed with the customer            |
| Common failure     | Insufficient funds on the action date                         | Declines, expired or reissued cards                 |
| Recovery options   | Resubmission, and tracking for DebiCheck                      | Retries and account updater services                |

Debit orders suit essential services collected near salary dates; cards suit digital products and customers without a preference for bank debits. Kwik supports both, so a subscription can run on whichever method the customer provides. For the card side in detail, see [recurring card payments](https://docs.switchtransact.com/faq/billing/recurring-card-payments).

## How does each billing cycle run?

On every billing date, the billing system:

1. Calculates the amount due for the period, including any proration or usage charges.
2. Checks that the amount is allowed — for DebiCheck, that it does not exceed the mandate's maximum collection amount.
3. Submits the collection: a debit order payment instruction or a card MIT.
4. Records the outcome and updates the subscription status.
5. Routes failed payments into a recovery process. See [dunning and payment recovery](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery).

Debit order timing matters in South Africa. Most consumers are paid between the 25th and the 1st, so collecting on or just after salary date significantly improves success rates. Mandates should record the agreed collection day and any date adjustment rule, such as moving to the previous business day when the date falls on a weekend or public holiday.

## What happens when a subscription payment fails?

Failed payments are normal and most are recoverable:

- Debit orders returned unpaid can be resubmitted according to the mandate, and DebiCheck collections can be tracked, where the bank re-attempts the collection for a period as funds become available. See [collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).
- Card declines can be retried on a schedule, ideally timed around salary dates.
- The customer should be notified and given an easy way to pay or update their details.

## How do cancellations work?

When a customer cancels, stop billing from the agreed end date, cancel or suspend the debit order mandate, and stop initiating card charges. Collecting after a customer has cancelled or withdrawn a mandate leads to disputes and reversals, so cancellation must flow through to the payment method immediately.

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [How do recurring card payments work?](https://docs.switchtransact.com/faq/billing/recurring-card-payments)
- [What is a debit order?](https://docs.switchtransact.com/faq/debit-orders/what-is-a-debit-order)
- [DebiCheck amounts, frequencies and adjustments](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments)


# How Do Recurring Card Payments Work?

Recurring card payments let a business charge a customer's stored card on a schedule — monthly for a subscription, per instalment for a payment plan, or whenever a usage bill falls due — without the customer entering their card details each time.

They are the card-rail equivalent of a debit order: the customer authorises future charges once, and the business initiates each subsequent payment. The mechanics, however, are quite different, and getting them right affects approval rates and dispute outcomes.

## How is the card stored?

Card numbers are never stored as-is. When the customer first pays or saves their card:

- The card is tokenised: the card number is replaced with a token that can only be used by the merchant or platform that created it.
- The token, not the card number, is stored and used for future charges.
- Network tokens, issued by the card schemes, can update automatically when a card is reissued, which reduces failures over time.

See [card tokenisation and network tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens) for how this works in detail.

## What is the difference between CIT and MIT?

Card scheme rules distinguish who initiates a payment:

|               | Customer-initiated (CIT)                     | Merchant-initiated (MIT)                                   |
| ------------- | -------------------------------------------- | ---------------------------------------------------------- |
| Who starts it | The cardholder, in session                   | The merchant, without the cardholder present               |
| 3-D Secure    | Applied, and used to establish the agreement | Not required; the charge references the original agreement |
| Example       | First payment at sign-up                     | Each monthly billing charge                                |

The first payment in a recurring series is a CIT, usually authenticated with 3-D Secure, and it establishes the recurring agreement. Every later charge is an MIT that references that agreement. Flagging recurring charges correctly as MITs matters: issuers approve properly flagged recurring transactions more readily, and the reference to the original consent supports you if a charge is disputed. See [recurring card payments, CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit).

## What does the customer agree to?

Before storing a card for recurring billing, the customer should explicitly agree to:

- The amount, or how a variable amount will be calculated
- The billing frequency and the date charges will be made
- How they can cancel, and how much notice is required
- The name that will appear on their card statement

Keep a record of this consent. It is the card equivalent of a debit order mandate and is central to defending disputes.

## Why do recurring card payments fail?

Common causes of failed recurring charges:

- **Insufficient funds** — the most common cause, and often temporary.
- **Expired or reissued cards** — the stored details no longer match a valid card.
- **Lost or stolen cards** — the card has been blocked and replaced.
- **Issuer declines** — risk rules or account status at the customer's bank.

Insufficient-funds declines are usually recovered by retrying at a better time — in South Africa that means around salary dates, typically the 25th to the 1st. Expired and reissued cards are better solved by account updater services and backup cards than by retrying. See [dunning and payment recovery](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery) and [backup cards and account updaters](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters).

## Recurring cards or debit orders — which should you use?

Cards give immediate authorisation responses and work well for digital services. Debit orders, especially DebiCheck, are widely used for essential services in South Africa and offer bank-confirmed mandates and built-in tracking as a recovery mechanism. Many businesses offer both and let the customer choose; Kwik supports card-on-file billing alongside EFT and DebiCheck debit orders on the same subscription. For the comparison, see [how subscription payments work](https://docs.switchtransact.com/faq/billing/subscription-payments).

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [Recurring card payments, CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit)
- [Card tokenisation and network tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens)
- [Card declines and response codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)


# Instalment and Usage-Based Billing Explained

Not all recurring billing is a fixed amount every month. Instalment billing splits a known total into scheduled payments, while usage-based billing charges for what the customer actually consumed in a period. Both are common in South Africa — instalments for lay-by, school fees, insurance and financed purchases; usage billing for utilities, airtime top-ups, metered services and per-transaction pricing.

The key difference from flat subscriptions is that the amount can vary, and on debit order rails the amount you collect must always match what the mandate allows.

## How does instalment billing work?

An instalment plan takes a known total and collects it over an agreed schedule:

1. The total, number of instalments, amount per instalment and collection dates are agreed upfront.
2. A mandate or card agreement is captured covering the full schedule.
3. Each instalment is collected on its date.
4. The plan ends when the final instalment is paid — billing must stop at that point.

Instalment plans have a defined end, so the billing system needs to track how many instalments remain and never collect past the last one.

## How does usage-based billing work?

Usage billing charges in arrears for consumption:

1. Usage is metered during the billing period.
2. At period end, usage is rated into an amount, often with a fixed base fee added.
3. The customer is notified of the amount before or when it is collected.
4. The amount is collected by debit order or card MIT.

Because the amount differs every period, customer notification matters more than with fixed billing: an unexpected debit is far more likely to be disputed. Tell the customer the amount before the collection date wherever possible.

## How do variable amounts work with debit order mandates?

A debit order mandate must either state the exact amount or clearly explain when and how the amount may vary. For variable billing this means the mandate should record:

- Whether the amount is fixed, variable or usage-based
- The instalment amount, where applicable
- The maximum collection amount, where applicable
- Any authorised adjustment category, amount or rate for amounts that change over time

DebiCheck makes this explicit: the bank-confirmed mandate carries an instalment amount and a maximum collection amount, and the customer authorises these at their bank. You cannot collect more than the authorised maximum, and changes beyond the authorised adjustment rates require a mandate amendment confirmed by the customer. When designing a usage-billed product on DebiCheck, set the maximum high enough to cover realistic peak usage, but not so high that customers refuse to authorise it. See [DebiCheck amounts, frequencies and adjustments](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments) and [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

Every payment instruction must match the mandate terms. Collecting an amount the mandate does not authorise is a common cause of disputes and reversals.

## How do variable amounts work with cards?

Card billing is more flexible on amounts — there is no bank-registered maximum — but the same principle applies: charge only what the customer agreed to. The recurring agreement should describe how variable amounts are calculated, and each charge is submitted as a merchant-initiated transaction referencing that agreement. See [recurring card payments](https://docs.switchtransact.com/faq/billing/recurring-card-payments).

## Instalments vs usage billing at a glance

|              | Instalment billing                          | Usage-based billing                         |
| ------------ | ------------------------------------------- | ------------------------------------------- |
| Amount       | Known upfront, usually fixed per instalment | Calculated each period from usage           |
| Duration     | Fixed number of collections                 | Ongoing while the service is active         |
| Mandate fit  | Instalment amount and end date in mandate   | Variable amount wording plus maximum amount |
| Notification | Schedule agreed at sign-up                  | Amount communicated each period             |

Kwik supports fixed, variable and usage-based collection amounts across EFT and DebiCheck debit orders and card billing, with mandate terms captured at sign-up.

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [DebiCheck amounts, frequencies and adjustments](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments)
- [Minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [How do subscription plan changes and proration work?](https://docs.switchtransact.com/faq/billing/subscription-plan-changes)


# What Is Dunning and How Does Payment Recovery Work?

Dunning is the process of recovering a failed recurring payment: retrying the collection, notifying the customer, and deciding what happens to the subscription while the payment is outstanding.

Most failed subscription payments are not customers choosing to leave — they are insufficient funds on the collection date, an expired card, or a temporary bank issue. Losing these customers is called involuntary churn, and a good dunning process recovers a large share of it.

## Why do recurring payments fail?

- **Insufficient funds** — the account or card had no funds on the day. Usually temporary and the most recoverable failure.
- **Expired, lost or reissued cards** — the stored card details are no longer valid.
- **Closed or blocked accounts** — the bank account can no longer be debited.
- **Disputes and stops** — the customer has stopped or disputed the collection, which is a cancellation signal, not a retry candidate.

The reason code matters: retrying a closed account wastes attempts and fees, while retrying insufficient funds at the right time often succeeds. See [card declines and response codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes) and [debit order unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions).

## What does smart retry timing look like in South Africa?

Retrying a failed payment the next day at the same time usually fails again for the same reason. Retries succeed when they land when money is in the account, and in South Africa that is driven by salary dates: most consumers are paid between the 25th and the 1st of the month.

A practical retry approach:

- Retry insufficient-funds failures on or just after the customer's likely salary date rather than on a fixed short interval.
- Space retries out rather than exhausting them in the first few days.
- Cap the number of attempts and stop retrying hard failures such as closed accounts immediately.

## How does debit order tracking help?

Debit orders come with a recovery mechanism built into the rails. With DebiCheck, a collection can be submitted with tracking: the customer's bank monitors the account for a specified period — up to ten days — and completes the collection as soon as sufficient funds arrive. This turns a single collection attempt into a continuous one, without you scheduling retries yourself.

Tracking must be disclosed in the mandate, and it works particularly well combined with salary-date collection: a debit submitted just before payday with tracking catches the salary deposit as it lands. See [DebiCheck collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries).

## What should customer communication look like?

Retries recover funds; communication retains customers. A dunning sequence typically includes:

1. Immediate notice that the payment failed, with the reason in plain language.
2. A self-service way to fix it — pay now via a [payment link](https://docs.switchtransact.com/faq/accepting-payments/payment-links), or update card or bank details.
3. Reminders before each retry, so the customer is not surprised by another attempt.
4. A final notice before suspension or cancellation.

Keep the tone factual and helpful. Most customers want to keep the service and simply need an easy way to pay.

## What is a grace period?

A grace period keeps the subscription active for a defined time after a failed payment while recovery runs. Cutting access immediately converts a recoverable payment failure into a cancellation; a short grace period gives retries, tracking and reminders time to work. Define when access is suspended, when the subscription is cancelled, and whether recovered payments restore access automatically.

## What does a complete recovery flow look like?

1. Payment fails and the reason code is classified.
2. Hard failures skip retries and go straight to customer contact.
3. Soft failures are retried on a salary-aware schedule, or tracked on the debit order rails.
4. The customer is notified with a self-service payment or update option.
5. The subscription moves through grace, suspension and cancellation states on a defined timeline.

Kwik's collection tools support tracked DebiCheck collections, resubmissions and payment links for once-off catch-up payments, which covers the recovery mechanics of this flow.

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [DebiCheck collections, tracking and retries](https://docs.switchtransact.com/faq/debicheck/collections-tracking-and-retries)
- [Debit order unpaids, returns and resubmissions](https://docs.switchtransact.com/faq/debit-orders/unpaids-returns-and-resubmissions)
- [What are backup cards and account updaters?](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters)


# How Do Subscription Plan Changes and Proration Work?

Subscriptions rarely stay the same for their whole life. Customers upgrade, downgrade, pause, and cancel, and each change has a billing consequence: what is charged for the current period, what the next collection amount will be, and whether the underlying mandate or card agreement still covers it.

Handled well, plan changes are invisible to the customer. Handled badly — a debit for an amount the customer did not expect, or a collection after cancellation — they become disputes.

## What is proration?

Proration adjusts a billing period's charge when a plan changes partway through it, so the customer pays for what they actually had. If a customer upgrades halfway through a month, they have used half a month of the old plan and will use half a month of the new one.

Common approaches:

- **Immediate proration** — charge or credit the difference for the remainder of the period at the time of the change.
- **Adjust the next bill** — apply the prorated difference to the next scheduled collection.
- **Change at period end** — the new plan and price only take effect from the next billing period, with no mid-cycle adjustment.

For debit order billing, adjusting the next bill or changing at period end is usually simpler than raising an extra mid-cycle debit, because every collection must match the mandate terms.

## What happens on an upgrade or downgrade?

| Change    | Current period                                 | Next period           | Mandate impact                                              |
| --------- | ---------------------------------------------- | --------------------- | ----------------------------------------------------------- |
| Upgrade   | Prorated charge or credit, or none if deferred | New, higher amount    | Amendment if the new amount exceeds what the mandate allows |
| Downgrade | Usually takes effect at period end             | New, lower amount     | Usually none — lower amounts fit within existing terms      |
| Pause     | No further charges                             | Collections suspended | Suspend, do not cancel, the mandate                         |
| Cancel    | Service until period end, per your terms       | No collection         | Cancel the mandate and stop card charges                    |

## When does a plan change require a mandate amendment?

On card billing, changing the amount is straightforward as long as the customer agreed to the new price — each merchant-initiated charge simply reflects the current plan. See [recurring card payments](https://docs.switchtransact.com/faq/billing/recurring-card-payments).

On debit orders the mandate is the constraint:

- An EFT debit order mandate must describe the amount or how it varies. If the new plan amount falls outside that wording, the mandate must be amended with the customer's authorisation and the required notice.
- A DebiCheck mandate carries a bank-confirmed instalment amount and maximum collection amount, plus any authorised adjustment category or rate. Increases within the authorised adjustment terms can be applied; increases beyond them, such as a large upgrade, require a mandate amendment that the customer confirms with their bank.

See [DebiCheck amounts, frequencies and adjustments](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments) and the [DebiCheck mandate lifecycle](https://docs.switchtransact.com/faq/debicheck/mandate-lifecycle) for how amendments work.

A practical design choice is to authorise a maximum collection amount with sensible headroom at sign-up, so routine upgrades and annual price adjustments fit without a new bank confirmation.

## How should pauses and cancellations be handled?

- **Pauses**: stop collections for the pause period but keep the mandate or card token in place, so billing can resume without a new sign-up. Confirm the resume date to the customer.
- **Cancellations**: apply your notice terms, stop future collections, cancel the mandate and stop initiating card charges. Any collection after a customer has cancelled or withdrawn their mandate is likely to be disputed and reversed. See [debit order disputes and stop payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments).

## What should you communicate to the customer?

For every plan change, confirm in writing: the new amount, when it takes effect, any prorated charge or credit, and the date of the next collection. Unexpected debit amounts are one of the most common causes of debit order disputes, and a short confirmation message prevents most of them.

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [DebiCheck amounts, frequencies and adjustments](https://docs.switchtransact.com/faq/debicheck/amounts-frequencies-and-adjustments)
- [Instalment and usage-based billing explained](https://docs.switchtransact.com/faq/billing/instalment-and-usage-based-billing)
- [Debit order disputes and stop payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)


# What Are Backup Cards and Account Updaters?

Stored cards do not last forever. Cards expire, banks reissue them after fraud or loss, and account numbers change — and every one of those events silently breaks a recurring billing agreement that depends on the stored details. Backup cards and account updater services exist to keep subscriptions running through these changes without asking the customer to re-enter their details.

For subscription businesses, stale card details are one of the biggest sources of involuntary churn, alongside insufficient funds. Unlike insufficient funds, retrying does not help: a charge against an expired card will fail every time until the stored details are fixed.

## Why do stored card details go stale?

- **Expiry** — every card has an expiry date, and charges after it decline.
- **Reissue** — banks replace cards after fraud, loss or a scheme migration, often changing the card number.
- **Account changes** — the customer switches banks or closes the account.

The customer usually does not think of their subscriptions when this happens, so the first sign of trouble is a failed billing charge.

## What is a card account updater?

Account updater services are run by the card schemes. When an issuing bank replaces or renews a card, the scheme records the link between the old and new details. Merchants and platforms that bill stored cards can then receive updated card numbers and expiry dates for their stored credentials, so recurring charges continue against the new card without the customer doing anything.

Network tokens achieve a similar outcome by design: because the token is maintained by the card scheme rather than being a copy of the card number, it can stay valid when the underlying card is reissued. See [card tokenisation and network tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens).

Coverage is not universal — it depends on the issuing bank and scheme participating and on the type of change — so updaters reduce stale-card failures rather than eliminating them.

## What is a backup payment method?

A backup payment method is a second stored method the billing system can fall back to when the primary one fails:

- A second card on file, charged when the primary card declines.
- A different method entirely — for example, a debit order mandate as a fallback for card billing, or the reverse.

Fallbacks should be part of the agreed billing terms: the customer should know at sign-up that the backup method may be charged if the primary fails, and each method needs its own valid authority — a card consent for cards, a mandate for debit orders. See [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements).

## How do these fit into a recovery strategy?

Account updaters, backup methods and retries solve different failure types:

| Failure                      | Best response                                                          |
| ---------------------------- | ---------------------------------------------------------------------- |
| Insufficient funds           | Salary-aware retries, or debit order tracking                          |
| Expired or reissued card     | Account updater or network token; otherwise ask the customer to update |
| Hard decline on primary card | Charge the backup method, then contact the customer                    |
| Closed bank account          | Ask the customer for a new account and capture a new mandate           |

Debit orders are naturally less exposed to this problem: bank accounts change far less often than cards, and a DebiCheck mandate stays valid until it is cancelled or amended. This is one reason many South African subscription businesses use debit orders as the primary rail and cards as the secondary. See [dunning and payment recovery](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery) for the full recovery picture.

## What should you ask customers to do?

Even with updaters and backups, some failures need the customer:

- Make it easy to update card or bank details from any failed-payment notice.
- Prompt for updated details when a stored card is approaching expiry.
- Offer a once-off [payment link](https://docs.switchtransact.com/faq/accepting-payments/payment-links) to settle the missed amount while the stored method is being fixed.

## Related topics

- [Billing and recurring payments hub](https://docs.switchtransact.com/faq/billing)
- [Card tokenisation and network tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens)
- [How do recurring card payments work?](https://docs.switchtransact.com/faq/billing/recurring-card-payments)
- [What is dunning and how does payment recovery work?](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery)


# Billing and Recurring Payments

Learn how businesses bill customers on a recurring basis, keep subscriptions paid and recover failed payments without losing customers.

## Topics in this section

- [How Do Invoice Payments Work?](https://docs.switchtransact.com/faq/billing/invoice-payments)
- [How Do Subscription Payments Work?](https://docs.switchtransact.com/faq/billing/subscription-payments)
- [How Do Recurring Card Payments Work?](https://docs.switchtransact.com/faq/billing/recurring-card-payments)
- [Instalment and Usage-Based Billing Explained](https://docs.switchtransact.com/faq/billing/instalment-and-usage-based-billing)
- [What Is Dunning and How Does Payment Recovery Work?](https://docs.switchtransact.com/faq/billing/dunning-and-payment-recovery)
- [How Do Subscription Plan Changes and Proration Work?](https://docs.switchtransact.com/faq/billing/subscription-plan-changes)
- [What Are Backup Cards and Account Updaters?](https://docs.switchtransact.com/faq/billing/backup-cards-and-account-updaters)


# Refund vs Reversal vs Dispute vs Chargeback

Refunds, reversals, disputes and chargebacks all describe money moving back from a business to a customer, but they follow very different processes and have very different consequences. Knowing which one applies helps you respond correctly and avoid unnecessary costs.

The simplest way to think about it: a refund is voluntary, a reversal undoes a payment before or shortly after it completes, a dispute is a formal complaint, and a chargeback is a forced return of funds decided through the customer's bank or card scheme.

## What is the difference at a glance?

|                              | Refund                  | Reversal                                       | Dispute                                    | Chargeback                                        |
| ---------------------------- | ----------------------- | ---------------------------------------------- | ------------------------------------------ | ------------------------------------------------- |
| Who initiates it             | The business            | The business or the bank                       | The customer                               | The customer, via their issuing bank              |
| When it happens              | After a payment settles | Before settlement, or shortly after processing | Any time within the allowed dispute window | Within scheme-defined timeframes                  |
| Who decides the outcome      | The business            | Largely automatic                              | The bank, based on rules and evidence      | The card scheme process                           |
| Typical cost to the business | The refunded amount     | Usually minimal                                | The disputed amount, plus admin effort     | The amount, fees, and impact on chargeback ratios |

## What is a refund?

A refund is a voluntary return of funds that the business initiates, usually because goods were returned, a service was cancelled, or an error was made. Refunds are processed through the same payment method as the original transaction where possible.

Refunds are the cheapest way to resolve a problem. A customer who receives a prompt refund has no reason to raise a dispute or chargeback, both of which cost the business more. See [card refunds, reversals and voids](https://docs.switchtransact.com/faq/card-payments/card-refunds-reversals-and-voids) for how this works on card payments specifically.

## What is a reversal?

A reversal undoes a payment before it fully completes, or corrects it shortly afterwards. Common examples include:

- Voiding a card authorisation before it is captured
- An automatic reversal when a transaction times out or fails mid-processing
- A bank reversing a recent unauthorised debit order at the account holder's request

Reversals are usually faster than refunds because the funds have not yet settled to the business, or the correction happens within the banking system itself.

## What is a dispute?

A dispute is a formal complaint by a customer that a payment was wrong, unauthorised or not what they agreed to. The dispute process depends on the payment method:

- **Debit orders** are disputed through the customer's bank, with the mandate deciding the outcome. See [debit order disputes](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/debit-order-disputes).
- **Card payments** are disputed through the issuing bank and may escalate into a chargeback. See [card chargebacks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks).

A dispute does not always mean the customer wins. If the business can show valid authorisation — a signed mandate, a 3D Secure result or proof of delivery — the dispute may be rejected.

## What is a chargeback?

A chargeback is the card-scheme version of a dispute: the issuing bank forcibly returns the funds to the cardholder, and the business must either accept the loss or fight it with evidence through a process called representment.

Chargebacks are the most expensive outcome for a business because they involve:

- Loss of the transaction amount
- Chargeback fees
- Administrative effort to gather evidence
- Damage to the business's chargeback ratio, which schemes and acquirers monitor

## Which one should you use to fix a problem?

- If the customer is right, refund them promptly. A refund closes the matter; a chargeback keeps it open and costs more.
- If a payment was duplicated or failed mid-flight, ask your payment provider about a reversal before refunding.
- If a customer threatens a dispute, resolve it directly first. Banks and schemes generally expect customers to approach the business before escalating.
- Never refund a transaction that already has an open chargeback — you risk paying twice.

## Related topics

- [What Is a Card Chargeback and How Does It Work?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks)
- [How Do Debit Order Disputes Work?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/debit-order-disputes)
- [Card Refunds, Reversals and Voids](https://docs.switchtransact.com/faq/card-payments/card-refunds-reversals-and-voids)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# What Is PCI DSS and Who Must Comply?

PCI DSS — the Payment Card Industry Data Security Standard — is the global security standard for protecting card data. It is set by the PCI Security Standards Council, founded by the major card schemes, and applies to every organisation that stores, processes or transmits cardholder data, from the largest processor down to a small online shop.

PCI DSS is not South African legislation; it is a contractual requirement enforced through the card schemes and your acquiring bank. But the practical effect is the same: if you accept card payments, some level of PCI DSS compliance applies to you.

## What does PCI DSS require?

The standard is organised around a set of core security goals:

- Build and maintain secure networks and systems (firewalls, no vendor default passwords)
- Protect stored cardholder data and encrypt it in transit
- Maintain vulnerability management (anti-malware, secure development, patching)
- Implement strong access control (need-to-know access, unique IDs, physical security)
- Monitor and test networks (logging, monitoring, security testing)
- Maintain an information security policy

The recurring theme is simple: card data must be protected everywhere it exists, and the fewer places it exists, the easier that is.

## Who must comply, and at what level?

Everyone who handles card data must comply, but the **validation** burden scales with transaction volume. The schemes define merchant levels — from Level 1 for the highest-volume merchants down to Level 4 for the smallest — where higher levels require formal on-site assessments by a Qualified Security Assessor, and lower levels can self-assess.

Self-assessment is done through a **Self-Assessment Questionnaire (SAQ)**, and the SAQ type depends on *how* you accept cards:

| SAQ type     | Typical scenario                                                                                   | Relative burden   |
| ------------ | -------------------------------------------------------------------------------------------------- | ----------------- |
| SAQ A        | Card entry fully outsourced to a hosted payment page or redirect; you never touch card data        | Lightest          |
| SAQ A-EP     | E-commerce where your website affects how card data is captured (e.g. embedded fields you control) | Moderate          |
| SAQ B / B-IP | Standalone card terminals, no electronic storage                                                   | Light to moderate |
| SAQ D        | You store, process or transmit card data in your own systems                                       | Heaviest          |

## How do you reduce your PCI scope?

The most effective compliance strategy is to keep card data out of your systems entirely:

- **Use a hosted checkout or redirect.** When your payment provider's hosted page captures the card, your website never sees the number, and your validation typically reduces to SAQ A — the lightest option.
- **Use tokenisation for repeat billing.** Store your provider's token, never the card number. See [tokenisation, encryption and hashing](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing).
- **Never let card numbers into logs, emails, spreadsheets or support tickets.** A single stored card number pulls that system into scope. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
- **Never record CVV numbers anywhere** — storing them after authorisation is prohibited outright.

Your payment provider carries the heavy end of PCI compliance for its own platform, but outsourcing does not remove your obligations entirely: you remain responsible for the parts you control, such as your website's integrity and how your staff handle card details.

## What happens if you don't comply?

Non-compliance exposes a business to consequences through its acquiring bank and the card schemes: fines passed down contractually, increased transaction costs, mandatory forensic investigations after a breach, and ultimately loss of the ability to accept cards. After a data breach, the difference between "compliant and breached" and "non-compliant and breached" is significant — and breaches of personal information also trigger South African obligations under POPIA. See [KYC, AML, sanctions and POPIA](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/kyc-aml-sanctions-and-popia).

## Related topics

- [Tokenisation, Encryption and Hashing Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing)
- [Hosted, Embedded and API Checkouts](https://docs.switchtransact.com/faq/accepting-payments/hosted-embedded-api-checkout)
- [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens)
- [Logging, Masking and Audit Trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# KYC, AML, Sanctions Screening and POPIA Explained

Behind every payment relationship in South Africa sits a set of compliance obligations. When a payment provider asks a new business for company documents, director IDs and proof of bank account, it is not bureaucracy for its own sake — it is the law. The two frameworks that matter most are FICA, which targets money laundering and terrorist financing, and POPIA, which protects personal information.

Understanding what each framework requires helps businesses prepare for onboarding, know what information they must protect, and recognise why certain checks and questions are non-negotiable.

## What is KYC and why is it required?

KYC — Know Your Customer — is the process of verifying who a customer actually is before doing business with them. In South Africa it is required by the **Financial Intelligence Centre Act (FICA)**, which obliges accountable institutions, including banks and payment providers, to perform **customer due diligence**. In practice that means:

- Verifying the identity of individuals (ID document, proof of address where required)
- Verifying businesses: registration documents, and identifying the directors and **beneficial owners** — the natural persons who ultimately own or control the entity
- Understanding the nature of the customer's business and the expected use of the account
- Applying **enhanced due diligence** to higher-risk customers, such as politically exposed persons

KYC is not once-off. Institutions must keep customer information current and re-verify when circumstances change.

## What does AML involve beyond KYC?

Anti-money laundering (AML) is the broader programme that KYC feeds into. Under FICA, accountable institutions must also:

- **Monitor transactions** for patterns inconsistent with the customer's profile
- **Report suspicious and unusual transactions** to the **Financial Intelligence Centre (FIC)**
- **Report cash transactions** above the prescribed threshold
- **Keep records** of customer identities and transactions for the prescribed retention period, so that money flows can be reconstructed if investigated
- Maintain a risk management and compliance programme, with trained staff and an appointed compliance function

For businesses using a payment provider, this is why unusual activity — sudden volume spikes, transactions inconsistent with the stated business — can trigger questions or holds. The provider is legally obliged to ask.

## What is sanctions screening?

Sanctions screening checks customers and transactions against lists of sanctioned persons, entities and countries — including the United Nations sanctions lists that South Africa applies through FICA's targeted financial sanctions provisions. Institutions must screen at onboarding and on an ongoing basis, and must not process transactions for sanctioned parties. Screening also flags politically exposed persons for enhanced due diligence rather than automatic refusal.

## What does POPIA require?

The **Protection of Personal Information Act (POPIA)** governs how personal information — names, ID numbers, contact details, bank account numbers and more — is collected, used, stored and shared. It is enforced by the **Information Regulator**. Core requirements include:

- Collect personal information for a specific, lawful purpose and don't use it beyond that purpose
- Collect only what is needed, keep it accurate, and don't retain it longer than necessary
- Secure it with appropriate technical and organisational measures
- Notify the Information Regulator and affected people of security compromises involving personal information
- Respect data subjects' rights to access and correct their information

There is a natural tension with FICA: FICA compels institutions to collect and retain identity data, while POPIA demands minimalism. The resolution is that FICA processing is lawful under POPIA — but the data collected for compliance must still be protected, access-controlled and used only for its purpose. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails) for how this plays out in payment systems.

## What does this mean for a business accepting payments?

- Expect KYC at onboarding and have documents ready: registration papers, director IDs, proof of banking details.
- Answer compliance questions honestly and promptly; delays usually mean missing information.
- Protect the personal information of your own customers — POPIA applies to you too, not only to banks.
- If you suspect your platform is being used to move criminal funds — for example, mule activity — raise it with your provider. See [payment fraud](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-fraud).

## Related topics

- [What Are the Most Common Types of Payment Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-fraud)
- [What Is PCI DSS and Who Must Comply?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss)
- [Logging, Masking and Audit Trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# How Should You Respond to a Payment Incident?

A payment incident is any event that disrupts payments or puts money or data at risk: a batch of duplicate debit orders, a card testing attack, a suspected data breach, a processor outage, or compromised account credentials. Incidents involving money are unforgiving — every hour of delay can mean more failed collections, more fraudulent transactions or more customers double-charged — so having a response approach ready matters more than in almost any other part of the business.

The good news is that most payment incidents follow the same response structure, regardless of the cause. What differs is who you notify and how you remediate.

## What are the phases of incident response?

1. **Detect and confirm.** An alert, a customer complaint or a reconciliation mismatch raises the flag. Confirm it is real before acting — a signal that pattern-matches a known failure can have a different cause.
2. **Contain.** Stop the damage from growing: pause a collection batch, disable a compromised API key, enable emergency fraud rules, or take an exploited endpoint offline. Containment usually has to happen before the root cause is fully understood.
3. **Assess impact.** Establish which transactions, customers and amounts are affected, over what period. Reconciliation data and audit logs are your primary tools here.
4. **Remediate.** Fix the root cause and correct the money: refund duplicates, reverse erroneous collections, or reprocess failed payments.
5. **Communicate.** Notify affected customers, your payment provider and bank, and — where legally required — regulators.
6. **Review.** Once resolved, run a blameless post-incident review: what happened, why, how detection and response could be faster, and what prevents recurrence.

## What do common payment incidents look like?

- **Duplicate collections or charges** — usually a batch submitted twice or a retry bug. Contain by halting the batch process, then refund or reverse proactively before disputes start arriving. Idempotency controls prevent recurrence; see [idempotency and duplicates](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates).
- **Fraud attack** — such as card testing against your checkout. Contain with velocity rules and blocking, refund fraudulent successes, and review the attack surface. See [card testing and velocity checks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks).
- **Compromised credentials or account takeover** — revoke keys and sessions immediately, freeze payouts, re-verify banking details. See [account takeover and social engineering](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/account-takeover-and-social-engineering).
- **Data breach involving personal information** — contain the exposure, then remember that POPIA requires notifying the Information Regulator and affected data subjects when personal information is compromised. If card data may be involved, your acquirer and the card schemes have their own notification and investigation requirements under PCI DSS.
- **Provider or bank outage** — mostly about communication and recovery: queue or retry payments safely once service resumes, and reconcile carefully afterwards to catch payments stuck in unknown states. See [retries and stuck payments](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments).

## Who needs to be notified, and when?

| Incident type                                 | Notify                                                       |
| --------------------------------------------- | ------------------------------------------------------------ |
| Duplicate or erroneous collections            | Affected customers, your payment provider                    |
| Fraud attack                                  | Your payment provider; bank fraud line if funds moved        |
| Personal information breach                   | Information Regulator and affected data subjects (POPIA)     |
| Card data compromise                          | Your payment provider and acquirer (PCI DSS obligations)     |
| Any incident affecting collections or payouts | Your finance team, so reconciliation expects the corrections |

Communicate with customers early and plainly. A customer who hears about a duplicate debit from you, with a refund already in progress, rarely disputes; a customer who discovers it on their bank statement goes straight to the bank.

## What should you prepare before an incident?

- **Alerting** on failure rates, decline spikes, duplicate patterns and reconciliation breaks, so you detect problems in minutes.
- **Audit trails and logs** that let you reconstruct exactly which transactions were affected. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
- **Emergency contacts** for your payment provider and bank, known before you need them at 2 a.m.
- **The ability to stop things** — a way to pause batches, disable keys and halt payouts quickly.
- **A simple written runbook** covering the phases above, because decision-making under pressure is when structure helps most.

## Related topics

- [Account Takeover and Social Engineering Fraud Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/account-takeover-and-social-engineering)
- [Idempotency and Duplicate Payments](https://docs.switchtransact.com/faq/payment-operations/idempotency-and-duplicates)
- [Retries and Stuck Payments](https://docs.switchtransact.com/faq/payment-operations/retries-and-stuck-payments)
- [Logging, Masking and Audit Trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# What Is a Card Chargeback and How Does It Work?

A chargeback is a forced reversal of a card payment, initiated by the cardholder through their issuing bank. It exists to protect cardholders from fraud and from merchants who fail to deliver, but it is also open to abuse — and every chargeback costs the merchant money, time and reputation with the card schemes.

Chargebacks follow processes defined by Visa and Mastercard, not by the merchant or the payment provider. Understanding the process helps you respond within the deadlines and decide which chargebacks are worth fighting.

## How does the chargeback process work?

1. **The cardholder raises a dispute** with their issuing bank, claiming the transaction was fraudulent, incorrect or that goods or services were not received.
2. **The issuer assigns a reason code** that classifies the dispute under the card scheme's rules, and returns the funds to the cardholder provisionally.
3. **The chargeback reaches the merchant** through the acquirer and payment provider, with a deadline to respond.
4. **The merchant accepts or fights it.** Accepting means the loss stands. Fighting it — called representment — means submitting evidence that the transaction was valid.
5. **The issuer reviews the evidence** and either reverses the chargeback or upholds it.
6. **Arbitration** is the final stage if the parties still disagree; the card scheme rules on the case, and the losing side typically bears additional costs.

## What are the common chargeback reason codes?

Reason codes vary slightly between Visa and Mastercard, but they group into four broad categories:

- **Fraud** — the cardholder claims they did not authorise the transaction, common in card-not-present payments.
- **Consumer disputes** — goods or services not received, not as described, defective, or a cancelled subscription still being billed.
- **Processing errors** — duplicate processing, incorrect amount, or currency errors.
- **Authorisation issues** — the transaction was processed without valid authorisation.

The reason code determines what evidence is relevant, so always check it before preparing a response.

## What are the timeframes?

Timeframes are scheme-defined. Cardholders generally have up to around 120 days from the transaction date — or from the expected delivery date for goods and services — to raise a dispute. Merchants then have a much shorter, scheme-defined window to respond with evidence, often measured in days rather than weeks. Missing the response deadline means the chargeback stands by default, so treat every chargeback notification as urgent.

## What does a chargeback cost the merchant?

- The transaction amount is returned to the cardholder.
- A chargeback fee is charged regardless of the outcome.
- Staff time is spent gathering evidence and responding.
- The merchant's **chargeback ratio** worsens. Schemes monitor the ratio of chargebacks to transactions, and merchants who exceed thresholds can face remediation programmes, higher costs or ultimately loss of card acquiring.

## How do you reduce chargebacks?

- **Use 3D Secure** on online payments. Successfully authenticated transactions generally shift fraud liability to the issuer. See [3D Secure and fraud prevention](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention).
- **Use a clear billing descriptor** so customers recognise the charge on their statement.
- **Make refunds and cancellations easy.** A refund is always cheaper than a chargeback.
- **Deliver on time and keep proof** of delivery or service fulfilment.
- **Respond quickly to customer complaints** before they escalate to the bank.
- **Screen for fraud** with velocity checks and risk rules. See [card testing and velocity checks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks).

## Should you fight every chargeback?

No. Fight chargebacks where you have strong evidence — a 3D Secure authentication result, proof of delivery, or clear acceptance of your terms. For low-value transactions with weak evidence, accepting the chargeback is often cheaper than the effort of representment. What matters most is fixing the root cause so the same type of chargeback does not recur.

## Related topics

- [What Evidence Do You Need to Fight a Chargeback?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/chargeback-evidence)
- [Refund vs Reversal vs Dispute vs Chargeback](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/refund-reversal-dispute-chargeback)
- [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure)
- [Card Declines and Response Codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# What Evidence Do You Need to Fight a Chargeback?

Winning a chargeback comes down to evidence. When you fight a chargeback — a process the card schemes call representment — you are asking the issuing bank to overturn its cardholder's claim, and the bank will only do that if your documentation clearly answers the specific reason code raised.

The best time to gather evidence is before a chargeback ever happens. Businesses that log authentication results, delivery confirmations and customer communications as a matter of routine can respond to any chargeback within the deadline; businesses that scramble to reconstruct records afterwards usually lose.

## What evidence do issuers actually look at?

- **Proof of delivery or fulfilment** — courier tracking with a delivery confirmation, a signed proof of delivery, or for digital goods, download and access logs tied to the customer.
- **Authentication results** — the 3D Secure authentication outcome, AVS (address verification) results and CVV match results from the original transaction.
- **Signed agreements and mandates** — contracts, subscription terms or order confirmations showing what the customer agreed to.
- **Communication logs** — emails, support tickets, chat transcripts or call records showing the customer engaged with you about the order.
- **Refund and cancellation policy acceptance** — evidence the customer saw and accepted your terms at checkout, such as a ticked checkbox with a timestamp.
- **IP address and device data** — showing the transaction came from a device, location or account the customer had used before.
- **Transaction history** — prior undisputed purchases from the same customer, which undermines a claim that the card was stolen.

## How should evidence match the reason code?

Evidence only helps if it addresses the claim being made. Match your response to the dispute category:

| Dispute claim                      | Strongest evidence                                                                                           |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| "I did not authorise this" (fraud) | 3D Secure result, AVS/CVV match, matching IP/device history, prior purchases                                 |
| "I never received it"              | Proof of delivery, tracking data, delivery address matching the cardholder                                   |
| "Not as described / defective"     | Product listing, terms accepted, communication showing the customer's actual complaint                       |
| "I cancelled the subscription"     | Cancellation policy acceptance, absence of a cancellation request, usage logs after the alleged cancellation |
| "I was charged twice"              | Transaction records showing two distinct orders, or proof a refund was already issued                        |

Submitting a large bundle of irrelevant documents weakens a response. A short, focused submission that directly refutes the specific claim performs far better.

## Why does 3D Secure matter so much?

When a transaction is successfully authenticated with 3D Secure, liability for fraud-type chargebacks generally shifts from the merchant to the issuing bank. That means the most common and hardest-to-fight category of chargeback — "I did not authorise this" — is largely closed off. Keep the authentication result and related identifiers from every 3D Secure transaction, because they are your primary evidence. See [How Does 3D Secure Help Prevent Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention) for detail.

## How should you store evidence?

- Log authentication and verification results with every transaction record automatically, rather than relying on manual capture.
- Keep delivery confirmations linked to the order reference.
- Retain records for at least as long as the dispute window allows — cardholders can typically dispute up to around 120 days after the transaction or expected delivery, and arbitration can extend the timeline further.
- Mask card numbers in your own records; you need the transaction reference, not the full card number. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).

## Practical tips for representment

- Respond well before the deadline. Late responses lose by default.
- Open with a one-paragraph summary of why the chargeback is invalid, then attach supporting documents in a logical order.
- Reference the reason code explicitly and address it directly.
- If the customer already received a refund, lead with that — it usually ends the dispute immediately.

## Related topics

- [What Is a Card Chargeback and How Does It Work?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks)
- [How Does 3D Secure Help Prevent Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)
- [Logging, Masking and Audit Trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# How Do Debit Order Disputes Work?

South African bank account holders have the right to dispute debit orders they believe are unauthorised or incorrect. The dispute is lodged with the account holder's own bank — at a branch, through the call centre, or in most cases directly in the banking app — and the outcome depends on how recent the debit is and whether a valid mandate exists.

For businesses that collect by debit order, disputes are an operational reality. The mandate is your defence: a collection that matches a valid, provable mandate can be defended, while a collection without one will be reversed.

## What happens when a customer disputes a debit order?

The process depends on how long ago the debit was processed:

- **Recent debits** are typically reversed immediately on the account holder's request, without the bank first asking the business for proof. The account holder gets their money back quickly, and the reversal flows through to the business as an unpaid or dispute item.
- **Older debits** require more scrutiny. The bank requests the mandate from the business (via its sponsoring bank), and the outcome depends on whether a valid mandate covering the disputed collection can be produced.

This is why mandate record-keeping matters so much: if you cannot produce the mandate, you lose the dispute regardless of what the customer actually agreed to. See [minimum mandate requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements) for what a mandate must contain.

## How does DebiCheck change disputes?

DebiCheck exists largely to solve the dispute problem. Because the customer electronically confirms the mandate with their own bank before collections begin, the bank holds independent proof of authorisation.

- A DebiCheck collection that **matches the approved mandate** — correct amount, frequency and timing — cannot be unfairly disputed and immediately reversed the way an ordinary EFT debit can.
- A DebiCheck collection that **does not match the mandate** (for example, a higher amount than authorised) can still be disputed successfully.

This makes DebiCheck significantly safer for businesses collecting recurring payments. See [unpaids, returns and disputes under DebiCheck](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes) for the DebiCheck-specific process.

## What should a customer do about a wrong debit order?

The recommended order is:

1. **Contact the service provider first.** If the debit is a billing error, the business can refund it and fix the underlying mandate or billing issue — usually faster and cleaner than a bank dispute.
2. **Dispute with the bank** if the business does not resolve it, or if the debit is genuinely unknown or unauthorised.
3. **Consider a stop payment** to block future collections while the underlying contract issue is sorted out — noting that a stop payment does not cancel the contract itself.

Disputing a debit that was legitimately authorised does not make the underlying debt go away; the business can still pursue the amount owed.

## What does a dispute mean for the business?

- The disputed amount is reversed out of your collections.
- Dispute items usually carry fees and are tracked as part of your dispute ratio, which sponsoring banks monitor.
- High dispute ratios can lead to review, remediation requirements or loss of collection facilities.

To keep disputes low:

- Only collect against valid, provable mandates that match the collection amount and date.
- Use a recognisable abbreviated short name on bank statements so customers know who debited them.
- Notify customers before amounts change.
- Resolve billing complaints quickly, before the customer goes to their bank.
- Use DebiCheck for new recurring collections where dispute risk is a concern.

## Related topics

- [Debit Order Disputes and Stop Payments](https://docs.switchtransact.com/faq/debit-orders/debit-order-disputes-and-stop-payments)
- [DebiCheck Unpaids, Returns and Disputes](https://docs.switchtransact.com/faq/debicheck/unpaids-returns-and-disputes)
- [Minimum Mandate Requirements](https://docs.switchtransact.com/faq/debit-orders/minimum-mandate-requirements)
- [Refund vs Reversal vs Dispute vs Chargeback](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/refund-reversal-dispute-chargeback)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# What Are the Most Common Types of Payment Fraud?

Payment fraud takes many forms, and the controls that stop one type often do nothing against another. A business that has locked down its online checkout can still lose money to a fake invoice emailed to its finance team, and a business with strong internal controls can still absorb chargebacks from stolen cards.

Understanding the main fraud types helps you match controls to the risks your business actually faces, rather than treating fraud as a single problem.

## What are the main types of payment fraud?

### Stolen card and card-not-present fraud

A fraudster uses stolen card details to pay online, where no physical card or PIN is needed. The genuine cardholder later disputes the transaction and the merchant absorbs the chargeback. The strongest defence is [3D Secure authentication](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention), which verifies the cardholder with their bank and generally shifts fraud liability to the issuer.

### Friendly fraud

A genuine customer makes a purchase and then disputes it dishonestly — claiming they never received it, or that they did not authorise it — to get the goods and their money back. It is one of the hardest types to prevent because the transaction itself looks completely legitimate. Good [chargeback evidence](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/chargeback-evidence) is the main defence.

### Card testing

Fraudsters run large volumes of small transactions through a checkout to find out which stolen card numbers still work. The merchant suffers fees, declines and scheme scrutiny even though the individual amounts are tiny. See [card testing and velocity checks](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks).

### Phishing and vishing

Fraudsters impersonate a bank or payment provider by email, SMS or phone call to trick victims into revealing card numbers, PINs, passwords or one-time PINs. A simple rule protects against most of it: **banks and legitimate payment providers never ask for your PIN, password or full card details by phone, SMS or email.** Any such request is phishing.

### Invoice and business email compromise (BEC) fraud

A fraudster intercepts or imitates business email and sends a fake invoice, or a "change of banking details" notice, so that a legitimate payment is made to the fraudster's account. The defence is procedural: always verify banking detail changes through a known, independent channel — a phone number you already have, not one on the suspicious email.

### Proof of payment (POP) fraud

A fraudster sends a forged proof of payment — a doctored EFT notification or fake SMS — and pressures the seller to release goods before the money reflects. Never release goods on a proof of payment alone; wait for cleared funds in the account.

### Refund abuse

Customers exploit refund policies — claiming non-delivery of items that arrived, returning used or swapped goods, or systematically abusing goodwill refunds. Delivery confirmation and per-customer refund tracking limit the damage.

### Money mule activity

Fraudsters recruit account holders to receive and forward stolen funds, disguising the money trail. Businesses can be exposed when paying out to mule accounts. This is one of the risks that [KYC and AML controls](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/kyc-aml-sanctions-and-popia) are designed to catch.

## How do you match controls to fraud types?

| Fraud type          | Primary control                                          |
| ------------------- | -------------------------------------------------------- |
| Stolen card / CNP   | 3D Secure, AVS/CVV checks                                |
| Friendly fraud      | Evidence retention, clear descriptors, proof of delivery |
| Card testing        | Velocity checks, CAPTCHA, risk rules                     |
| Phishing / vishing  | Customer and staff awareness, never sharing credentials  |
| Invoice / BEC fraud | Out-of-band verification of banking details              |
| POP fraud           | Release goods only on cleared funds                      |
| Refund abuse        | Delivery tracking, refund limits per customer            |
| Money mules         | KYC, transaction monitoring                              |

No single control covers everything, so layered defences matter: authentication at checkout, monitoring behind it, and trained people around it.

## Related topics

- [What Is Card Testing and How Do Velocity Checks Stop It?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks)
- [Account Takeover and Social Engineering Fraud Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/account-takeover-and-social-engineering)
- [How Does 3D Secure Help Prevent Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)
- [KYC, AML, Sanctions Screening and POPIA Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/kyc-aml-sanctions-and-popia)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# What Is Card Testing and How Do Velocity Checks Stop It?

Card testing is an automated attack where fraudsters push large volumes of transactions through an online checkout to find out which stolen card numbers are still valid. The individual amounts are usually tiny — sometimes just an authorisation with no capture — because the goal is not to buy anything, but to sort a stolen card list into "working" and "dead" cards that can then be used or resold.

Any publicly reachable payment form can become a target, and businesses often discover an attack only when they see thousands of declined transactions overnight. Even though most attempts decline, the attack still hurts.

## Why is card testing a problem if the transactions decline?

- **Fees.** Authorisation attempts can carry costs even when declined, and a large attack means a large volume of attempts.
- **Decline ratios.** Issuers and card schemes monitor merchants with abnormally high decline rates, which can trigger scrutiny or penalties.
- **Chargebacks.** The small percentage of successful test transactions become fraud chargebacks when the real cardholders notice.
- **Infrastructure load.** Bot traffic can degrade your checkout for genuine customers.
- **Downstream fraud.** Cards validated on your checkout are used for larger fraud elsewhere, and your business becomes known to attackers as a useful testing ground.

## What are velocity checks?

Velocity checks are rules that limit how many payment attempts are allowed within a time window, based on shared attributes. Instead of judging each transaction alone, they spot patterns across transactions, for example:

- More than a set number of attempts from the same **IP address** in a few minutes
- Many different **card numbers** used from the same device or session
- Repeated attempts on the same **card number** with varying details
- A spike in attempts against a single **merchant account** far above its normal baseline
- Many attempts sharing the same **email address, delivery address or fingerprinted device**

When a threshold is breached, the rule can block further attempts, add friction such as a CAPTCHA or 3D Secure challenge, or flag the traffic for review. Genuine customers rarely hit these limits, so well-tuned velocity rules stop attacks with little impact on real sales.

## What other controls stop card testing?

- **CAPTCHA or bot detection** on the payment form, ideally triggered only when traffic looks automated so genuine customers are not inconvenienced.
- **3D Secure**, which forces cardholder authentication that bots cannot complete. See [3D Secure and fraud prevention](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention).
- **Requiring CVV and running AVS checks**, which raise the bar for stolen card lists that lack full details.
- **Rate limiting at the API layer**, so scripted attacks are throttled before they reach the payment provider. This matters especially for payment APIs and payment links that can be called without a browser.
- **Disposable or single-use payment links** rather than long-lived open payment pages.
- **Monitoring and alerting** on decline rates and attempt volumes, so an attack is spotted in minutes rather than discovered on the next invoice.

## What should you do during an active attack?

1. Enable or tighten velocity rules and CAPTCHA immediately — your payment provider can usually help apply emergency limits.
2. Block the offending IP ranges, device fingerprints or attack patterns where identifiable.
3. Review any transactions that succeeded during the attack and refund them proactively before they become chargebacks.
4. Keep logs of the attack for your provider and for any scheme queries. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
5. Afterwards, review why the attack was possible — an unauthenticated payment endpoint or missing rate limits — and fix the gap.

Card testing is one of the clearest examples of why fraud prevention needs to be layered: no single control stops it, but velocity checks, bot detection and authentication together make your checkout an unattractive target.

## Related topics

- [What Are the Most Common Types of Payment Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-fraud)
- [How Does 3D Secure Help Prevent Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)
- [Card Declines and Response Codes](https://docs.switchtransact.com/faq/card-payments/card-declines-and-response-codes)
- [Logging, Masking and Audit Trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# Account Takeover and Social Engineering Fraud Explained

Not all payment fraud starts with stolen card numbers. In account takeover and social engineering attacks, the fraudster targets people — customers, staff or account holders — and tricks or hacks their way into legitimate accounts, then uses those accounts to move money or make payments that look entirely genuine to the payment system.

These attacks are dangerous precisely because they pass technical checks: the payment comes from the real account, on the real device profile, sometimes even authenticated by the real (deceived) account holder. Preventing them requires securing accounts and educating people, not just screening transactions.

## What is account takeover?

Account takeover (ATO) is when a fraudster gains control of someone else's account — internet banking, an e-commerce profile with saved cards, a merchant dashboard or an email account — and uses it for fraud. Common entry routes include:

- **Credential stuffing** — trying username and password combinations leaked from other breaches, which works whenever people reuse passwords.
- **Phishing** — fake login pages that harvest credentials.
- **SIM swap fraud** — the attacker fraudulently ports the victim's mobile number so that one-time PINs sent by SMS arrive on the attacker's device.
- **Malware** — keyloggers or remote access tools on the victim's device.

Once inside, the attacker can pay with saved cards, change payout banking details, redirect settlements, or approve transactions the victim never intended.

## What is social engineering?

Social engineering manipulates people into doing the fraudster's work for them. Typical patterns in South Africa include:

- **Phishing emails and smishing (SMS phishing)** impersonating banks, SARS, courier companies or payment providers, with links to fake login or "verify your card" pages.
- **Vishing** — phone calls from someone claiming to be the bank's fraud department, creating urgency ("your account is being drained right now") to extract an OTP or PIN, or to get the victim to approve a transaction in their banking app.
- **Refund and support scams** — the "agent" needs your card details to process a refund.
- **Business email compromise** — impersonating a supplier or executive to redirect legitimate payments to a fraudster's account.

The single most important fact to remember: **banks and legitimate payment providers never ask for your PIN, password, OTP or full card details by phone, SMS or email.** Any such request — no matter how convincing the caller or how official the message looks — is fraud.

## How do you protect customer and business accounts?

- **Enforce multi-factor authentication (MFA)**, preferring app-based authentication over SMS, which is vulnerable to SIM swaps.
- **Never reuse passwords**; use a password manager and unique passwords per system.
- **Monitor for anomalies** — logins from new devices or locations, changes to banking or contact details, and unusual payout instructions should trigger verification.
- **Add friction to sensitive changes.** Changing settlement banking details or adding a new payout beneficiary should require re-authentication and, ideally, a delay or second approver.
- **Verify changes out-of-band.** If a "supplier" emails new banking details, confirm on a phone number you already have on file — never the number in the email.
- **Train staff** to recognise urgency, secrecy and authority pressure as red flags, and to feel safe pausing a payment to verify.

## What should you do if an account is compromised?

1. Lock the account and revoke active sessions and API keys immediately.
2. Contact your bank or payment provider to freeze pending payouts or reverse in-flight payments where possible — speed matters enormously.
3. Reset credentials and re-verify contact and banking details on the account.
4. Review the audit trail to establish what the attacker accessed and changed. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
5. Report the incident to your bank's fraud line and, where applicable, the South African Police Service. Treat it as a payment incident with a structured response — see [payment incident response](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-incident-response).

## Related topics

- [What Are the Most Common Types of Payment Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-fraud)
- [How Should You Respond to a Payment Incident?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-incident-response)
- [API Authentication and Signatures](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# How Does 3D Secure Help Prevent Fraud?

3D Secure (3DS) is the card industry's authentication protocol for online payments. When a customer pays online, 3DS lets their issuing bank verify that the person entering the card details is actually the cardholder — typically through the banking app, a one-time PIN or a biometric prompt. Visa markets it as Visa Secure and Mastercard as Identity Check.

For fraud prevention, 3DS does two things at once: it stops many fraudulent transactions from completing at all, and for transactions that are successfully authenticated, it generally moves fraud chargeback liability from the merchant to the issuing bank.

## How does 3D Secure stop fraud?

Stolen card details alone are not enough to complete a 3DS-authenticated payment. The fraudster would also need access to the cardholder's banking app or phone. When the issuer challenges a suspicious transaction, the genuine cardholder receives an authentication prompt for a purchase they did not make — and declines it. The fraud fails before any money moves and before any chargeback can occur.

Modern 3DS (version 2) also works silently in the background. The merchant's checkout sends the issuer contextual data — device information, transaction details and history — and the issuer can approve low-risk transactions with a **frictionless flow** that the customer never sees, reserving the visible **challenge flow** for riskier transactions. This keeps checkout smooth for most genuine customers while still screening every payment.

## What is the liability shift?

The liability shift is the commercial reason merchants use 3DS. Under card scheme rules:

- If a transaction is **successfully authenticated** with 3DS and later disputed as fraud ("I did not authorise this"), the chargeback liability generally sits with the **issuing bank**, not the merchant.
- If the merchant processes **without 3DS** and the transaction turns out to be fraudulent, the **merchant** absorbs the chargeback.

The shift applies to fraud-type disputes. It does not protect against service disputes — a customer claiming goods were not delivered or not as described can still charge back an authenticated transaction. For those, you still need [chargeback evidence](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/chargeback-evidence).

## What are the limits of 3D Secure?

3DS is powerful but not a complete fraud strategy:

- **Friendly fraud** is largely unaffected — the genuine cardholder authenticated the payment and disputes it anyway, usually on non-fraud grounds.
- **Social engineering** can defeat it: a fraudster who talks the victim into approving the authentication prompt gets a fully authenticated fraudulent payment. See [account takeover and social engineering](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/account-takeover-and-social-engineering).
- **Checkout friction** is a real cost. Challenge flows add a step, and failed or abandoned authentications lose genuine sales. Poorly configured 3DS can cost more in lost conversions than it saves in fraud.
- **Not everything supports it.** Merchant-initiated recurring charges, for example, are handled under separate rules, with the initial customer-initiated transaction authenticated instead.

## How should you use 3DS in practice?

- Enable 3DS on customer-initiated online payments, and keep the authentication results with your transaction records — they are your primary chargeback evidence.
- Pass rich, accurate data in the 3DS request; better data means more frictionless approvals for genuine customers.
- Combine 3DS with [velocity checks and bot controls](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks) — authentication stops stolen-card fraud, while velocity rules stop automated attacks from hammering the checkout in the first place.
- For recurring billing, authenticate the first transaction and tokenise the card for subsequent merchant-initiated charges. See [recurring card payments, CIT and MIT](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit).

Used this way, 3DS removes most of the stolen-card chargeback risk from online trading while keeping the checkout experience acceptable for genuine customers.

## Related topics

- [What Is 3D Secure?](https://docs.switchtransact.com/faq/card-payments/3d-secure)
- [What Is a Card Chargeback and How Does It Work?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks)
- [What Evidence Do You Need to Fight a Chargeback?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/chargeback-evidence)
- [What Is Card Testing and How Do Velocity Checks Stop It?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# Tokenisation, Encryption and Hashing Explained

Tokenisation, encryption and hashing are the three core techniques used to protect payment data, and they are often confused with one another. All three transform sensitive data into something safer to store or transmit, but they work differently, protect against different threats, and are used at different points in the payment flow.

Understanding the difference matters practically: it determines your PCI DSS scope, what you are allowed to store, and how you should log and reference payment data in your own systems.

## What is the difference?

|                                 | Tokenisation                                                                          | Encryption                                    | Hashing                                                        |
| ------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------------- |
| What it does                    | Replaces the data with a substitute token; the real value is stored in a secure vault | Scrambles the data mathematically using a key | Produces a fixed-length fingerprint of the data                |
| Reversible?                     | Only by the token vault                                                               | Yes, with the key                             | No — one-way by design                                         |
| Typical use in payments         | Storing cards for repeat billing                                                      | Protecting data in transit (TLS) and at rest  | Verifying passwords, integrity checks, matching records        |
| If stolen, is the data exposed? | No — a token is useless outside the system that issued it                             | Only if the key is also compromised           | No original data to recover, though weak inputs can be guessed |

## How does tokenisation work in payments?

When a customer saves a card, the payment provider stores the real card number in its secure vault and gives the merchant a **token** — a reference that only works with that provider (and often only for that merchant). The merchant charges the token for future payments without ever holding the card number. If the merchant's database is breached, the tokens are worthless to the attacker.

There are two layers of card tokenisation:

- **Provider (vault) tokens** issued by the payment gateway or processor.
- **Network tokens** issued by Visa and Mastercard themselves, which replace the card number at scheme level and can be automatically updated when a card is reissued.

See [card tokenisation and network tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens) for the details, and [recurring card payments](https://docs.switchtransact.com/faq/card-payments/recurring-card-payments-cit-mit) for how tokens enable subscription billing.

## How is encryption used in payments?

Encryption protects data while it moves and while it rests:

- **In transit:** every payment page, API call and webhook should use TLS, so card numbers and bank details cannot be read on the network.
- **At rest:** databases, backups and files containing sensitive data are encrypted so a stolen disk or dump is unreadable without the keys.
- **In hardware:** card terminals and payment processors use dedicated cryptographic hardware to protect PINs and keys.

Encryption is reversible by design — systems that need the real value can decrypt it. That makes **key management** the critical discipline: encrypted data is only as safe as the keys, which must be stored separately from the data, rotated, and tightly access-controlled.

## Where does hashing fit in?

Hashing is one-way: you can compute the hash of a value, but you cannot recover the value from the hash. In payment systems it is used for:

- **Password storage** — systems store the hash, never the password itself.
- **Integrity and signatures** — webhook signatures and API request signing use hashes to prove a message was not tampered with. See [API authentication and signatures](https://docs.switchtransact.com/faq/payment-operations/api-authentication-and-signatures).
- **Matching without storing** — comparing whether two records refer to the same underlying value without keeping that value.

Hashing is not a substitute for tokenisation or encryption when you need the original value back — and hashing predictable data (like card numbers, which have known structure) provides weaker protection than it appears to.

## What does this mean for your systems?

- Never store raw card numbers; use your provider's tokens instead.
- Mask sensitive values in logs and interfaces — show at most the first six and last four digits of a card. See [logging, masking and audit trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails).
- Keeping card data out of your systems entirely, via a hosted checkout and tokenisation, is also the single biggest reducer of [PCI DSS scope](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss).

## Related topics

- [Card Tokenisation and Network Tokens](https://docs.switchtransact.com/faq/card-payments/card-tokenisation-and-network-tokens)
- [What Is PCI DSS and Who Must Comply?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss)
- [Logging, Masking and Audit Trails](https://docs.switchtransact.com/faq/payment-operations/logging-masking-and-audit-trails)

Back to [Refunds, Disputes, Fraud and Compliance](https://docs.switchtransact.com/faq/disputes-risk-and-compliance).


# Refunds, Disputes, Fraud and Compliance

Understand what happens when payments go wrong: refunds and reversals, chargebacks and disputes, fraud attacks, and the compliance rules every business handling payments must meet.

## Topics in this section

- [Refund vs Reversal vs Dispute vs Chargeback](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/refund-reversal-dispute-chargeback)
- [What Is a Card Chargeback and How Does It Work?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-chargebacks)
- [What Evidence Do You Need to Fight a Chargeback?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/chargeback-evidence)
- [How Do Debit Order Disputes Work?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/debit-order-disputes)
- [What Are the Most Common Types of Payment Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-fraud)
- [What Is Card Testing and How Do Velocity Checks Stop It?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/card-testing-and-velocity-checks)
- [Account Takeover and Social Engineering Fraud Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/account-takeover-and-social-engineering)
- [How Does 3D Secure Help Prevent Fraud?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/3ds-and-fraud-prevention)
- [Tokenisation, Encryption and Hashing Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/tokenisation-encryption-and-hashing)
- [What Is PCI DSS and Who Must Comply?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/pci-dss)
- [KYC, AML, Sanctions Screening and POPIA Explained](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/kyc-aml-sanctions-and-popia)
- [How Should You Respond to a Payment Incident?](https://docs.switchtransact.com/faq/disputes-risk-and-compliance/payment-incident-response)