How money works

Money moves differently for delivery than for the Safe catalog, because they're different kinds of transaction. Both are explained here truthfully, based on how the platform actually works today — not aspirational numbers.

Delivery: prepaid wallet

Delivery is billed from a delivery wallet balance held against your partner account:

1. You top up the wallet via the API (Wallet top-up) or Partner Hub.
2. Deliveries billed to your account draw down that balance (or, if you have a credit limit, can run a balance up to that limit before being blocked).
3. You check the balance and top up programmatically at any time — there's no separate invoicing relationship to manage.

This is straightforward: you're prepaying for a service and drawing it down.

Who pays the delivery fee

You choose per order, via payment.payer on orders.create:

• recipient (default) — cash on delivery. The rider collects the fee from the recipient on arrival; your wallet is not touched. Good for marketplaces where the buyer covers delivery.
• partner — the fee is debited from your delivery wallet at order creation (or drawn against your credit limit). Use this when you (the vendor) absorb or pre-collect delivery. This path moves money, so the key must carry the delivery:wallet:spend scope, and the order must include pickup + delivery coordinates so Dawurobo prices the fee — a wallet-funded order is never billed against a client-supplied amount.

Either way the fee itself is computed by Dawurobo from the pickup → delivery distance; you can preview it before creating an order with orders.estimate.

Safe catalog: buyer pays, split at settlement

Syndicated orders work differently, because three parties are involved — the buyer, the vendor whose product it is, and you (the reseller):

1. The buyer pays online through the platform's payment gateway when you call orders.create — you never touch their card or mobile money details directly; the gateway returns a checkout_url you redirect them to.
2. Once payment clears (orders.verify), the platform records a settlement decomposition to its ledger: a share for the vendor (their merchandise price), a share for fulfillment (the delivery fee), and a share for you, the reseller (your markup, if you set one via reseller_markup_ghs).
3. Payouts to vendors and partners are made by Dawurobo based on the ledger — this isn't an automated real-time transfer in the API today; it's a recorded entitlement that Dawurobo pays out.

When things go wrong

Delivery and orders both have failure states that the platform tracks and reports, rather than silently retrying forever:

• Delivery: order.rejected, order.cancelled, order.returned, order.rescheduled are real webhook events (see Webhooks) — build your app to handle them, not just the happy path.
• Syndicated orders: orders.verify can come back with state: "failed" if the gateway payment didn't succeed — the stock reservation is released automatically, and you should let the buyer retry with a fresh external_reference rather than reusing the failed one.

Refund & dispute policy

Refunds are not automated — the system records status; it doesn't move money back on its own. This is the default policy; specific terms may be adjusted in your partner agreement.

Wallet-funded deliveries (payment.payer: "partner"):

• Cancelled before dispatch — if you cancel (or Dawurobo cancels) an order before a rider is dispatched, the delivery fee is refunded to your wallet. orders.cancel returns refund_status: "pending" for a wallet-paid order; the credit lands back on your balance once the cancellation is confirmed.
• Failed or returned after dispatch (order.rejected / order.returned) — reviewed case by case, because a rider's time and travel may already be committed. Partial or full refunds are issued at Dawurobo's discretion after review; open a ticket with the order id.
• Recipient-pays (cash on delivery) — nothing was charged to your wallet, so there's nothing to refund; a failed delivery simply means the recipient wasn't billed.

Syndicated Safe orders (buyer pays online):

• Payment never cleared (orders.verify → state: "failed") — no money was captured and the stock reservation is released automatically. Nothing to refund; have the buyer retry with a fresh external_reference.
• Paid but undelivered, wrong, or disputed — the buyer's payment sits in the settlement ledger as party shares that Dawurobo has not yet paid out. If a dispute is raised before payout, Dawurobo can reverse the relevant shares and refund the buyer. If it's raised after payout, resolution runs through the vendor. Report disputes promptly with the sale_id.

How to initiate: you (the partner) raise it via support with the order id / sale_id; Dawurobo verifies against delivery and payment records. Target first response is one business day, with most clear-cut cases resolved within 3–5 business days. Dawurobo initiates the actual money movement — the API never moves money back on its own.

Related pages

• Wallet top-up — the delivery wallet endpoints.
• Safe catalog — orders.create / orders.verify / orders.get.
• Getting started — which of these operations need a production key.
• Get help — for pricing, payout, and dispute questions.