A handful of terms recur across the Business API with specific meanings. This page defines them once so the rest of the docs can assume you know them.
Charge vs. payment
They're the same object under two names. Mamo's API originally used charge.* for routes, webhooks, and IDs (MPB-CHRG-...). The product was later renamed to "payment" — payment.* is the current naming, charge.* is kept as a legacy alias.
- Endpoints:
/payments/*is canonical;/charges/*is a deprecated alias for the same routes. - Webhooks:
payment.*events (payment.succeeded,payment.failed, ...) are canonical;charge.*equivalents fire for the same underlying event. You get one delivery per event even if you're subscribed to both names — see Webhook delivery & retries. - Object: described on the Payment Object page (named for the legacy term since that's the existing published slug).
New integrations should use payment.* throughout. There is no behavioral difference — this is a naming migration, not two separate features.
Recipient vs. seller vs. sub-merchant
A recipient is a payout destination registered via POST /recipients — a UAE IBAN, a name, and a reason. It is not a sub-merchant: there's no trade license, MOA, KYC review, or separate dashboard/login for the seller. Registration is immediate because the IBAN itself is treated as sufficient verification.
"Seller" or "provider" are the business terms for whoever a recipient represents in your marketplace (a vendor, a driver, a host). In the API they're just a recipient — the API doesn't model a distinct "seller" entity with its own merchant-of-record status. Mamo remains the merchant of record for every transaction, recipients included. See Marketplace & Split Payments for the full flow.
payouts_share
payouts_shareA field on Create Payment Link that splits a payment at capture time: a percentage or fixed amount of the payment routes to a recipient's balance, with the rest staying in yours. It is not a delayed or escrowed split — the recipient's share is credited as soon as the payment captures, and reaches their bank account on the next scheduled payout run (see Marketplace & Split Payments for timing and hold-pattern options).
Rolling reserve
A percentage of each captured payment withheld and held for a period before being released, used by payment processors to cover potential future chargebacks/refunds. Mamo applies this case-by-case based on industry and risk profile, not universally. Where it applies: 10–25% of each transaction (before fees) is deducted as soon as the payment processes, and is released back to you roughly 26 weeks after that payment settles — continuously, as each transaction clears its hold period. See the Commercial FAQ for the full figures and your Mamo contact to confirm whether it applies to your account.
Settlement vs. payout
These describe two different money-movement flows — conflating them is a common mistake.
Settlement is what pays out your own captured revenue to your own bank account. It's a single combined event: Mamo clears the captured amount and transfers it to the bank account on file, which is what produces the settlement_amount, settlement_fee, and settlement_date you see on the Payment Object. On automatic settlement (the default) this happens on your configured schedule (immediate, weekly, or monthly) with no API call on your part. On manual settlement, there is no public API to trigger it yourself either — it's a Mamo-side action; talk to your Mamo contact about your account's specific behavior.
Payout (the Payouts API) is a distinct, narrower action: it moves funds out of a recipient's accrued balance (from payouts_share) to that recipient's bank account. It requires a recipient_id — there is no way to target your own account through this API, so it's not a mechanism for receiving your own revenue under any settlement configuration.
See also
Commercial FAQ for Developers answers the commercial questions that come up most against the definitions above — rolling reserves, UAE vs. international card fees, refund fee handling, and hold-period limits.