Skip to main content
POST

Intro

Requests a payout of a sub-merchant’s available balance — the first step in a three-stage approval flow that ends with Khaime settling funds to their bank or Stripe account.

Context

This is called with the sub-merchant’s own Partner API key, not the marketplace operator’s — it’s the merchant asking to be paid, not the operator paying them. It only creates a staged request; nothing moves until the marketplace operator calls Approve Merchant Payout (or Reject Merchant Payout to release it back). After operator approval, Khaime’s own admin settlement step is what actually sends money. Before calling this, the merchant needs KYC approved and payout configured (Setup Merchant Payout), and enough available balance — check with Get Merchant Balance.
Funds can live in two different places depending on how the merchant gets paid: a Khaime wallet balance (built up from settled charges), or — for merchants on Stripe direct-charge marketplace payments — directly in their Stripe connected account. This endpoint checks whichever source applies and reserves against it.

Hows

Path parameters

string
required
The ID of the sub-merchant whose balance should be paid out.

Request body

number
required
Amount to withdraw, in the smallest currency unit (e.g. 50000 = ₦500.00 for NGN, or $500.00 for USD). Must be a positive whole number — no fractional smallest-unit amounts.
string
required
Currency to withdraw, e.g. NGN, USD, GBP. Must be one of Khaime’s supported collection currencies.
string
Optional internal note for the payout request.
Each currency has a minimum payout amount (roughly the local equivalent of $10 — e.g. 500,000 kobo for NGN, 1,000 cents for USD). Requests below the minimum are rejected before anything is reserved.

Response

For merchants settling via a connected Stripe account (payout_method: "payout"), the response instead includes stripe_account_id and withdrawal_source: "stripe_subaccount" in place of bank_details.

Response fields

Requirements

  • The sub-merchant must have an active marketplace relationship.
  • The sub-merchant must have completed KYC and payout setup — for non-NGN/wallet settlement, a connected Stripe account with approved KYC is required.
  • The requested amount must clear the per-currency minimum and be a whole number in the smallest unit.
  • The currency must be one Khaime supports for collection.
  • The sub-merchant must have enough available balance (wallet or Stripe connected-account balance, depending on settlement path) after subtracting anything already reserved by a pending request.
  • Only one pending request is allowed per merchant, per currency, per environment (sandbox/live) at a time.

Error cases

Whys

A staged request instead of an immediate withdrawal. Marketplace payouts move real money out of a merchant’s balance, and letting a merchant unilaterally trigger settlement would remove the operator’s ability to catch mistakes, fraud, or disputes before funds leave. Staging the request — reserve now, settle only after two more approvals — buys review time without blocking the merchant from queuing the request the moment they want to. Balance is reserved immediately, before approval. If the reservation waited until the operator approved, a merchant could file several requests for more than their balance covers and race the approval step. Reserving on request keeps remaining_balance accurate and prevents overcommitment. Different settlement paths for wallet vs. Stripe-direct-charge merchants. Not every merchant’s funds land in the same place — it depends on how their charges were processed. Rather than forcing every payout through one channel, the endpoint detects where the merchant’s money actually is and reserves against that source.

Why nots

  • Doesn’t move money. This only stages a request — it takes an Approve Merchant Payout from the marketplace operator, and settlement from Khaime admin, before funds actually go anywhere.
  • Not a substitute for checking balance first. Call Get Merchant Balance before requesting — this endpoint validates balance server-side, but you’ll get a cleaner UX by not letting a merchant submit a request you already know will fail.
  • No partial payouts or queued requests. You can’t have more than one pending request per merchant/currency/environment — a second request while one is pending is rejected outright rather than queued.
  • Doesn’t let a merchant choose the settlement rail. Which gateway handles the payout (gravv, paystack, stripe_direct, etc.) is determined by the merchant’s currency and existing payout configuration, not a parameter you can set on the request.