Marketplace & Split Payments

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.

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 splits the payment at capture time — the recipient's share moves into their recipient balance immediately when the payment succeeds.
Payouts disburse on a schedule from the recipient's balance to their bank account. See "Payouts: fees, timing, failures" below.

Mamo 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 splits funds at payment time, not at fulfillment. 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.

Recipients: onboarding & KYC posture

A recipient is not a sub-merchant — there's no trade license, MOA, or identity document requirement, and no separate consent or sign-up flow for the seller. Required fields are a UAE IBAN (or account number), recipient name, relationship, and reason — 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.
Recipients currently must hold a UAE bank account. Payouts to other GCC countries (for example Saudi Arabia) are on the roadmap but not available yet, with no committed date — check with your Mamo contact for current status before committing a launch date around it.

Payouts: fees, timing, failures

Fee: AED 5 per payout, per recipient. Whether you or the recipient absorbs it is set by recipient_pays_fees on the split. 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 (for example an invalid IBAN): the funds return to the recipient's balance. Resending after correcting the IBAN is a new payout and incurs the AED 5 fee again — so a failed-then-resent payout costs two fees in total.
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

Mamo is the merchant of record for every transaction — 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 behavior, and how to authenticate incoming webhook requests, see Webhook delivery & retries — in short, deliveries aren't HMAC-signed; authenticate via the auth_header value you set at registration, and make your handler idempotent on the event ID since the same event can be delivered more than once.

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].