How to integrate with Ozow
Choose how to integrate with Ozow: no code, a plugin, or building against our APIs.
On this page7 sections
Build with AI 2 packages
A build package is every page for one task, with the API operations they use. Copy the prompt into a coding assistant, or hand it the package itself: slim links to each page, full inlines all of them in one document.
- Migrate a payin from the Payments API to One APIEverything needed to move an existing redirect payin onto One API, with the legacy guide and its One API counterpart side by side.
- Migrate refunds from the Payments API to One APIEverything needed to move an existing refunds integration onto One API, with the legacy guide and its One API counterpart side by side.
There are three ways to integrate with Ozow, and the right one depends on how much you want to build. This page helps you choose, then points you at the guide.
You integrate once.
Pay by BankPay by Bank The payer authorises the payment inside their own banking app or online banking, and the funds move from their bank account. No card is involved and no card details are entered. is enabled by default, and any other payment methods you opt into are enabled by Ozow on your account; they then appear on the Ozow payment page with no further development work. See One integration, every payment method.
Three ways to integrate
All three are supported, and you can combine them; a plugin on your online store, say, plus payment links for invoicing.
| No code | Plugins and platforms | APIs | |
|---|---|---|---|
| What it is | Create and send payment requests from the Ozow Dashboard | Install an Ozow extension on your ecommerce platform | Call our APIs from your own application |
| Best for | Invoicing, ad-hoc requests, occasional payoutsPayout Money sent from a merchant to a bank account. Unlike a refund, a payout is not tied to a payment anyone made you, so you can pay anyone with a bank account. Payouts draw on your float rather than on your incoming payments, and they are not self-service: they need approval from Ozow and testing in staging first. | Standard online stores on a supported platform | Custom checkout, full control, flows a plugin can't handle |
| You need | Dashboard access | A supported platform and admin access to it | A developer |
No code
Everything happens in the Ozow Dashboard. No developer, no deployment needed.
- Payment requests: generate a single link or upload a batch, then send them by email, SMS or WhatsApp
- Refunds: refund a completed transaction. Single transactions only; needs a funded float
- Bulk payouts: upload a CSV of payouts for approval. Needs Ozow approval and a funded floatFloat The balance held with Ozow that payouts and refunds are paid out of. Both draw on it, and neither will process while it is empty. Payins do not need one, so if you only take payments you never meet it.
Plugins and platforms
If your store runs on one of these, install the plugin and configure it with your Ozow credentials. Nothing to build.
Shopify · Magento · WooCommerce · OpenCart · WHMCS · Xero · PrestaShop · nopCommerce · VirtueMart · Drupal
Plugins cover accepting payments. Refund support varies by platform: check your platform's page. Some platforms have additional plugins for specific payment methods, such as Capitec PayCapitec Pay Capitec's own payment method. The payer gives a cellphone, account or ID number rather than card details, and approves the payment in the Capitec app, so no card number and no banking login is ever entered at checkout. It gets its own button rather than sitting inside the bank list, and it requires Customer Identity Verification.Capitec or voucher redemption.
APIs
Build it yourself, for full control over the experience. This is the only route to recurring payments and API-driven payouts.
New integrations use the One API. Payouts use the Payouts API. If you built your integration before the One API, see Already integrated with Ozow? below.
| You want to | Start here |
|---|---|
| Accept payments from your customers | Choosing a checkout experience |
| Pay money out to bank accounts | Send a payout: needs Ozow approval, staging testing and sign-off |
| Return money for a payment you've received | Refund a payment: needs a funded float |
| Charge a customer on a repeating schedule | Set up recurring payments: limited availability, by approval only |
PayinsPayin A payment made by a consumer to a merchant. The direction most of this site is about: money coming in. Its counterpart is a payout, which sends money out and is not tied to any payment anyone made you. and payouts are separate integrations, with different APIs, different credentials and different approval processes. If you need both, treat them as two pieces of work.
Choosing a checkout experience
If you're accepting payments through our APIs, you then choose where the customer pays: redirectRedirect Sending the payer to the Ozow payment page to complete the payment, and returning them to your site afterwards. The alternative is embedding the checkout in your own page, where the payer never leaves it. to an Ozow-hosted page, embed the checkout in your own page, or, when it's available, collect the details yourself.
Redirect is the recommended starting point. It's the fastest to build, it supports every payment method enabled on your account, and Ozow carries the PCI DSSPCI DSS The security standard that applies to anyone who stores, processes or transmits card data. Its reach is the reason most integrations avoid touching card numbers at all.PCI Security Standards Council scope. You can move to an embedded experience later without changing how you create payment requests.
→ Choosing a checkout experience compares all three, including the embedded variants, Apple Pay and Google Pay, and standalone payment buttons for individual banks and methods.
Before you go live
| Testing | Sign-off | |
|---|---|---|
| Payin | Payin test cases: recommended, no evidence required | Not required |
| Payout | Payout test cases: mandatory, in staging | Required before production |
| Refunds | Test in staging | Funded float required |
| Recurring payments | Test in staging | See the go-live checklist in Set up recurring payments |
Payin testing is guidance: we recommend working through the test cases, but you don't need to submit anything.
Payout testing is a gate, not guidance. Payouts and bulk payouts need explicit approval from Ozow, mandatory staging testing, and formal sign-off before they're enabled in production. There are no exceptions.
Already integrated with Ozow?
If your integration posts to api.ozow.com and builds a SHA512SHA-512 A hashing algorithm. Ozow uses it to sign the values in a request or a notification so you can tell that they arrived unaltered and came from us. Hashing is one-way: the hash cannot be turned back into what produced it.Wikipedia hash, you're on the Payments API,
which is deprecated. It remains supported and your integration keeps working, but new payment
methods and features are released on the One API only, and no new merchants are onboarded onto it.
We recommend moving when you next have development capacity. Migrating to One API walks through the differences.
Last updated