A South African business can offer a supported crypto-funded payment method while receiving settlement in rands. Before enabling it, establish who processes the payment, who owes you settlement, what your fees are and how refunds reconcile. The customer's asset choice does not remove ordinary bookkeeping responsibilities.
MoneyBadger describes a partner-based rand-settlement model. Treat that as one documented operating model, not a claim that every crypto payment gateway works the same way. If you instead accept tokens directly into your own wallet, you take on a different custody and accounting workflow.
Choose the operating model deliberately
| Decision | Rand-settlement provider | Direct receipt into your wallet |
|---|---|---|
| What reaches your business | Rand settlement under provider terms | Crypto asset under your control |
| Who arranges conversion | Provider or payment partner | Your business, if and when needed |
| Reconciliation source | Order, payment and settlement reports | Wallet records plus sale and conversion records |
| Key operational dependency | Provider availability and settlement contract | Keys, network support, custody and conversion access |
This article concentrates on the first column. It does not recommend that a business switch to holding crypto reserves or promise extra sales from adding a payment button.
Ask these questions before onboarding
Obtain the legal entity, merchant agreement, current pricing and settlement schedule from the provider. Confirm whether your business type and product categories qualify. Ask which payment methods will appear at your actual checkout and which require activation.
For an existing payment-service-provider account, ask whether the crypto-funded method is an additional integration or a setting within the current service. MoneyBadger lists partner routes and direct API integration; the existence of an API does not tell you what development work your own checkout needs.
| Contract question | Evidence to save |
|---|---|
| What fees apply? | Signed rate schedule, VAT treatment and refund charges |
| When are funds settled? | Cut-offs, weekends, reserves and exception rules |
| Who handles a failed payment? | Merchant support channel and incident procedure |
| What triggers fulfilment? | Authenticated completed-payment event |
| How are refunds authorised? | Role permissions, references and settlement deductions |
| Can service be suspended? | Relevant contract clause and notice process |
A headline such as “next business day” should not replace those terms. MoneyBadger describes settlement as typically following the payment partner's cycle. Verify what that means for your merchant account, including public holidays and any reserve arrangement.
Test the order lifecycle
In a permitted test environment, create a sale, let a quote expire, simulate a failed attempt, complete a payment and process a refund. Confirm that an unpaid order is never marked fulfilled merely because a customer reached the payment page.
Your integration should associate one merchant order with its payment references and handle repeated notifications without creating duplicate fulfilment. Validate callbacks using the provider's documented security mechanism. An emailed screenshot from a customer is not the system's settlement record.
Ask the provider for its testing process before making a live transaction. No test purchases or merchant onboarding were performed for this guide.
Reconcile a day's takings
Use this hypothetical example to check your report fields, not as a quoted fee schedule. Assume completed sales of R8,000, approved refunds of R500 and an illustrative fee of R120, with no other adjustments.
Expected settlement = R8,000 - R500 - R120 = R7,380
If the bank credit is R7,280, the R100 difference remains an exception until explained. It might relate to timing, another adjustment or an error; do not invent a fee category to force the reconciliation to balance.
Store gross sales, refunds, fees, batch ID, expected settlement date and actual bank credit separately. Ask your accountant how VAT, revenue recognition and provider fees should be recorded for your business. A payment provider's broad tax statement is not an individual tax opinion.
Plan support and customer communication
Tell customers which payment methods are accepted and what to do when an app debit is uncertain. Train staff to check the merchant system before asking for a second payment. Use normal refund authorisation controls and retain the original payment reference.
Review the provider's current regulatory disclosure without converting an application number into a claim of completed authorisation. Keep the operational settlement comparison separate from your business's tax classification and any provider authorisation checks. Begin with the spending hub, consult the SARS guide, and request an official merchant proposal appropriate to your actual checkout.
Sources and verification
Primary sources checked on 20 September 2026. Prices, availability and processing arrangements can change.