Platform-led marketplace

For every payment collected, you tell Mamo which seller it belongs to and what share they get. When the buyer pays, Mamo splits the money and records each seller's share against them; the rest stays with you as your platform fee.

If your platform collects payments on behalf of other sellers or providers — a marketplace, a booking platform, a reseller network — you don't need a separate payout integration. payouts_share on a payment link routes part of each payment to a recipient automatically. This page covers how the pieces fit together and the questions that come up most when integrating it.

If your sellers have their own Mamo accounts and should own their payments, with you taking a commission, see Seller-led marketplace instead.

How it works

Register each seller once via POST /recipients — this is a lightweight payout destination, not a full sub-merchant account. See "Recipients: onboarding & KYC posture" below for what's required.
Create payment links with payouts_share set, referencing the recipient. See the payouts_share field on Create payment link for the exact schema (recipient_id, recipient_pays_fees, and one of percentage_to_recipient / amount_to_recipient).
Mamo credits the recipient's share on the payment's settlement date, together with your own share of that payment, in the first hourly run that day. If your account settles same-day (settlement period 0), it is credited at capture.
Payouts disburse on a schedule from the recipient's balance to their bank account. See "Payouts: fees, timing, failures" below.

Your business (the marketplace) is the merchant of record throughout — recipients are payout destinations, not sub-merchants, and don't go through their own onboarding, KYC, or dashboard.

Controlling when funds move

payouts_share fixes the split when the payment is made and credits the recipient's share at settlement, not at fulfilment. If your model needs to hold the recipient's share until some condition is met (for example, a delivery-confirmation or buyer-review window), you have two options:

Use payouts_share and let the schedule handle timing — funds sit in the recipient's balance (not yet paid out) until the next scheduled disbursement, so a weekly or monthly schedule naturally gives you a hold window. Refunding the buyer after capture is not automatically reversed against the recipient's share — reconcile this yourself if you refund after a split has been applied.
Skip payouts_share and hold funds in your own balance instead. Collect the full payment with no split, confirm your own condition (delivery, review period, dispute window), then trigger a payout to the recipient yourself via the Payouts API once you're ready. This gives you full control over timing but means you're managing the payout call per order instead of letting it run automatically.

There's no API option to delay the initial split itself — if your model needs the hold, use the second pattern.

Release date

Payment link responses include payouts_share.release_date, a date-only string (YYYY-MM-DD) or null. It does not delay a recipient's share: the share is credited to the recipient's balance on the payment's settlement date (at capture if your account settles same-day), and paid out on the payout schedule.

For links you create with Create payment link, release_date is always null. The endpoint accepts a release_date inside payouts_share without error but ignores it, so sending one has no effect.
It is set only on links a marketplace creates with Create marketplace payment link, where the seller is the merchant and the marketplace takes a commission. There it is the earliest day (UAE calendar day) Mamo moves the marketplace's commission out of the seller's balance. See Seller-led marketplace.

Recipients: onboarding & KYC posture

A recipient is not a sub-merchant — there's no trade licence, MOA, or identity document requirement, and no separate consent or sign-up flow for the seller. Required fields are recipient_type, a name, relationship, and bank (an IBAN or account number) — see Create recipient for the full schema.

The IBAN itself is treated as sufficient verification — there's no KYC review cycle, so registration is immediate.
There's no limit on the number of recipients you can register.
Split payouts (payouts_share) and Issue payouts go to UAE bank accounts. Recipients banked abroad can be paid with Create international payout once Mamo enables it for your account.

Payouts: fees, timing, failures

Fee: the payout fee on your plan, plus VAT, charged per payout and per recipient. You pay it by default. Mamo can switch your account so the recipient bears the fee (deducted from their payout, while the VAT on it is still charged to you); ask your Mamo contact, because it isn't an API setting. recipient_pays_fees on the split is different: when true, Mamo's processing fee and its VAT on each payment are deducted from the recipient's share instead of yours. Minimum payout amount is AED 10.
Schedule: configured per account (for example weekly or monthly) — this isn't a per-payout API parameter. Talk to your Mamo contact to set up or change the schedule. payouts_share itself is API-only; there's no dashboard toggle for it.
Timing: payouts initiated before roughly 7pm UAE time are typically received by the recipient's bank the same day; after that, the next day.
Failed payouts: a payout that Mamo cancels or rejects returns its amount, fee and VAT to your business wallet, not to the recipient's balance. The next scheduled payout won't include that money, so pay the recipient yourself (for example with Issue payouts); that new payout is charged its own fee. If you absorb the fee (the default), you pay one fee in total. If the recipient bears it (recipient_pays_fees), the fee was taken from the recipient's balance; on failure the fee and VAT are still credited to your wallet and the recipient's balance is not restored. A payout rejected by the recipient's bank is held instead: Mamo's team corrects the bank details and re-sends the same payout, with no refund to your wallet and no new fee.
Virtual cards as a payout alternative: instead of a bank payout, you can fund a virtual debit card for a recipient via the Partner cards API — issued to the business name (no identity checks on the individual holder), funded from your balance up to a spend limit you set, valid up to 3 years, with unused funds returning to your balance on cancellation or expiry.

Liability, disputes & reserves

Your business (the marketplace) is the merchant of record for every transaction and carries chargeback, refund, and VAT liability — recipients are payout destinations, not merchants of record. Practically:

Disputes, chargebacks and refunds run through your (the marketplace's) Mamo account, not the recipient's. If you need to recover a chargeback or refund from the recipient, that's managed on your side — directly with them, or by deducting it from a future payout.
A rolling reserve is not applied by default. Mamo reserves the right to introduce one based on account signals such as an elevated dispute rate — this isn't something you can opt out of contractually, but it isn't the default posture.
Refunds don't carry a separate fee, but the original processing fee on the refunded payment is not returned, including on partial refunds.

Currency & FX

Settlement defaults to AED. A payment made in USD is converted directly to AED at settlement; the FX fee on non-AED payments is borne by the merchant (you), not the customer or recipient.
Settling in USD instead is possible, but requires a UAE bank account that accepts USD and carries a flat USD 7.15 fee per settlement.
There's no conversion applied during the payment itself — a customer is charged in the currency you set on the payment link. If they pay with a card in a different currency, their own card issuer handles the conversion, not Mamo.

Webhooks & reconciliation

Use payment.succeeded, payment.failed, and payout.processed to track a split payment end to end — poll GET /payments/{id} if you'd rather not rely on webhooks for the payment side. For delivery guarantees, retry behaviour, and how to authenticate incoming webhook requests, see Webhook delivery — in short, verify the Mamo-Signature HMAC header with the signing_secret returned when you created the webhook (or check the auth_header value you set at registration), and make your handler idempotent: payloads have no event ID, so never deduplicate on id alone. See Webhook delivery → Idempotency for how to apply state safely when deliveries are repeated, retried or out of order.

Testing in sandbox

Sandbox behaves like live except for settlement timing, which defaults to a multi-day delay so test payments won't be immediately available for a payout. If that's blocking your testing, ask your Mamo contact to switch your sandbox settlement period to immediate. See Sandbox testing for the full checklist, including test card numbers.

Getting help

For anything this page doesn't cover, or to set up/change a payout schedule, request Saudi payout access, or ask about your specific split-payment model, reach out to [email protected].