Ozow Hub

Refund a payment

Everything needed to refund a completed payment through One API, in full or in part, and to handle the statuses a refund moves through.

On this page4 sections
Markdown, linkedMarkdown, everything inlined

A refund is its own transaction with its own lifecycle, not a reversal of the original one. It is submitted against a completed payment, it can be for less than the full amount, and it settles on its own schedule.

Refunds reuse status names that also appear on 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 mean something different there. A system that reads a refund's status as though it were a payin's reports the wrong outcome to a customer. Handle every refund status the statuses page lists.

What this was built from

Implement against these

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

  • Refund a payment: Issue a refund with One API. Refunds are merchant-initiated backend operations with no customer-facing step, so the whole flow is in your backend.
  • Verify a webhook signature: The signature on a One API 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., the five steps that check it, and a working implementation in four languages.

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, 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. 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.
  • Refunds: Returning money to a customer through Ozow.
  • Float top-up guide: Payouts and refunds are funded from your 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. 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, webhook 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.