Ozow Hub

Send a payout

Everything needed to pay money out to a customer's bank account or voucher with the Payouts API, including how to exercise the failure paths before going live.

On this page4 sections
Markdown, linkedMarkdown, everything inlined

Paying out is not a payinPayin 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. in reverse. The money leaves a 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. balance you have topped up in advance, a request above that balance fails validation rather than queueing, and the outcome arrives on a notification rather than in the response to your call.

Decide first whether you are paying to a bank account or a voucher: the fields differ. Then work through the mock test cases, which are the only way to exercise a decryption failure or an insufficient float before a real one happens.

PayoutPayout 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. statuses reuse names that mean something different from payin statuses. Handle every payout status the statuses page lists.

What this was built from

Implement against these

Every field name, order and format on these pages is exact.

  • Send a payout: Transfer funds to a recipient's bank account with the Payouts API. There is no customer-facing step, so the whole integration lives in your backend.
  • Payout test cases: The mandatory tests for a payout integration, for bulk payouts from the Dashboard and for the Payouts API. You must pass these before going live.

Background

Context for the above. Nothing here is implemented against.

  • How Ozow works: How Ozow connects you to South African banks and payment methods, and the two directions money moves: payins from customers, payouts to recipients.
  • Prerequisites and onboarding: What to have in place before you write any code: a merchant account, Dashboard access, your credentials, and payout eligibility if you need it.
  • Payout to bank: Paying money out from your Ozow float to a bank account.
  • Payout to voucher: Paying money out from your Ozow float as a voucher.
  • Float top-up guide: Payouts and refunds are funded from your float balance. Set up your static top-up reference once, then load funds whenever your float runs low.
  • Transaction and settlement statuses: Every payin, payout, refund and settlementSettlement Ozow paying the money you have collected into your bank account. Payins arrive at Ozow first and are settled to you on a schedule, so what a customer paid you today and what has been settled to you today are different amounts. status, which are final, and what to do about each.
  • Building a secure integration: Where Ozow's security responsibility ends and yours begins: credentials, webhookWebhook A URL of yours that Ozow calls when something happens, rather than you polling to find out. The call carries no credential of yours and arrives at a public URL, so authenticate it before acting on it: a hash field on the Payments API, a Svix signature on One API. endpoints, verifying notifications, and validating amounts.

The contract

Fetch the OpenAPI document named above to generate a client, or to check a field name or an enum against the schema.