--- title: "Mamo Integration" description: "Mamo Business is a UAE payments platform for links, invoices, and payouts. Agents create payment links and invoices, initiate, capture, and refund payments, run subscriptions, send local and international payouts, and act on webhook events." url: https://flowrunner.ai/integrations/mamo date_modified: 2026-09-04T14:51:36-07:00 --- # Mamo [Payments](https://flowrunner.ai/integrations/category/finance-accounting) Mamo Business is a UAE payments platform for links, invoices, and payouts. Agents create payment links and invoices, initiate, capture, and refund payments, run subscriptions, send local and international payouts, and act on webhook events. 1 trigger · 47 actions · API key · available [Mamo website](https://mamopay.com/) · [Platform Documentation](https://mamopay.readme.io/) · Capability data verified 2026-08-25 1. A customer writes in asking to cancel their subscription 2. Agent identifies the customer and the schedule they sit on 3. List Subscribers reports how many other customers are billed by that same schedule 4. Agent matches the request against the two cancellation operations 5. Unsubscribe Subscriber runs unattended when the schedule bills only this customer 6. An ambiguous request posts to the support channel with the subscriber count attached 7. The support owner names the scope, and the matching operation runs ## What This Integration Enables Mamo Business is a UAE payments account that runs in both directions. Money comes in through hosted payment links, emailed invoices, saved cards charged without the customer present, and subscription schedules. Money goes out through bulk disbursements, international payouts to saved recipients, and virtual partner cards with spending limits. Very few connectors in this category cover both halves, and the ones that do usually treat the outbound side as an afterthought. Mamo does not. Its outbound surface carries regulatory shape: a saved recipient requires a relationship and a reason, which are classifications UAE payout rules turn on rather than notes, and an international payout will not accept raw bank details at all. FlowRunner agents run the collection side end to end, reconcile card spend against expense receipts, and assemble payouts against saved and validated recipients. The operations that move money in bulk or change who gets paid are exactly where the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate belongs. ### Without FlowRunner **Cancellations done in the dashboard**: An agent clicks cancel without seeing how many other customers sit on the same schedule **Payout details retyped**: An IBAN is copied into each disbursement rather than saved, checked, and reused **Card spend without receipts**: Transactions land in the ledger and the documents that justify them arrive separately ### With FlowRunner **Scope confirmed before canceling**: The subscriber count is read first, and an ambiguous request reaches a person **Recipients saved and validated**: Bank details are checked once, stored, and named by identifier on every later payout **Spend matched to its document**: Card transactions and expense receipts are read together and the classification written back ## Use Case Scenarios ### A card saved once, charged when the flow decides A customer completes a first payment through a link created with card saving required, and Mamo stores the card. From then on the agent charges it without the customer present using Initiate Payment, taking the stored card identifier from that first payment's details. For a booking where the amount is not final, it holds rather than charges, then Capture Payment for the settled figure once the service is delivered, or Reverse Payment if the booking falls through. A hold that nobody captures lapses and the customer is never charged, so a sweep reads open holds and warns the operations owner before they expire. ### Card spend that closes its own loop On a schedule, the agent reads List Card Transactions, which is the business-wide spend feed rather than one card at a time. For each transaction it looks for a matching entry in List Expense Receipts, pulls the document link, and writes the category and accounting classification back with Update Expense. Matched spend flows into [Xero](https://flowrunner.ai/integrations/xero) with its receipt attached. Anything without a document becomes an exception posted to the cardholder in [Slack](https://flowrunner.ai/integrations/slack), asking for the receipt rather than chasing it a month later at close. ### Payouts against recipients that were checked before they were saved A supplier is onboarded. The agent runs Validate IBAN first and reads the answer properly, because the route returns a success status either way and reports an invalid IBAN as a validity flag set false with the bank name simply absent. Only a genuinely valid result proceeds to Create Recipient with the relationship and reason classifications the vendor requires. Later disbursements name the saved identifier rather than repeating bank details, Get Account Balances is read before Issue Payouts so a bulk run is not refused partway, and international payments carry an idempotency key so a retried request cannot pay somebody twice. ## Human-in-Loop Highlight Mamo has two cancellation operations and they are not versions of each other. Unsubscribe Subscriber removes one customer from a schedule and leaves the schedule and everyone else on it untouched. Cancel Subscription cancels the schedule itself, which stops billing for every subscriber on it, and nothing in this action list re-enrolls them. A support agent reading "please cancel my subscription" is one word away from ending revenue for a whole cohort. So the agent resolves the scope before it writes: it calls List Subscribers on the schedule, and if the count is greater than one it stops and posts, "Fatima on the Studio Monthly schedule asked to cancel. That schedule bills 214 other subscribers. Remove her only, or cancel the schedule?" The support owner answers. The per-customer path runs unattended; the one that reaches 214 other people never does. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 47 actions ### Payment Links and Invoices 6 - **Create Payment Link** Creates a hosted checkout you send a customer. It is also how a subscription is actually billed, since a subscription on its own charges nobody and its identifier has to be attached here. An amount of zero with card saving required is the platform's card-verification pattern, storing a card without charging for it. - **List Payment Links** Lists the payment links on your business. - **Get Payment Link** Reads one payment link with its settings, URL, and usage. - **Update Payment Link** Updates a payment link. This is also where a subscription is attached to an existing link, and where a link is deactivated without being deleted. - **Delete Payment Link** Deletes a payment link. Switching it inactive with an update is the reversible alternative, and it keeps the link's payment history addressable. - **Create Invoice** Creates an invoice and emails it to the customer. Unlike a payment link, this sends something the moment it succeeds, since there is no draft state. Enabling VAT adds and displays UAE VAT, which is what makes it a valid tax document rather than a request for money. ### Payments 6 - **Initiate Payment** Charges a card the platform already holds, without the customer present. The card must have been saved through a link created with card saving on, and the identifier comes from that first payment's details. A hold-and-charge-later option authorizes without taking money. - **List Payments** Lists the payments taken on your business. - **Get Payment** Reads one payment in full: its status, the card used, the settlement amount and date, and the error code if it failed. This is the authoritative check, since the browser redirect and the webhook are both claims and the settlement figures appear only here. - **Capture Payment** Takes the money on a payment that was placed on hold. The amount must be at most the amount held, and a hold nobody captures eventually lapses with the customer never charged. - **Reverse Payment** Cancels a payment that is on hold, releasing the customer's funds. Only a held payment can be reversed; a captured one is refunded instead. - **Refund Payment** Refunds a captured payment in whole or in part. The vendor supports dirham transfers only for refunds, so a payment taken in another currency cannot be refunded this way, and the refund is asynchronous with separate initiated, completed, and failed events. ### Subscriptions 6 - **Create Subscription** Creates a subscription, which is a billing schedule and nothing more. It bills nobody on its own: the returned identifier must be attached to a payment link before anything is charged. Daily and test frequencies exist only in sandbox, and an end date takes precedence over a payment quantity. - **Cancel Subscription** Cancels a subscription schedule so it stops billing. It cancels the schedule, which affects every subscriber on it, so the per-customer removal is a different operation. - **List Subscribers** Lists the customers signed up to one subscription schedule. - **List Subscription Payments** Lists the payments taken under one subscription schedule, across all its subscribers. - **Unsubscribe Subscriber** Removes one customer from a subscription, leaving the schedule and everyone else on it untouched. This is the per-customer cancellation. - **Change Customer Subscription** Moves one subscriber from their current schedule to a different one. This is the upgrade and downgrade path, and the customer's stored card carries over so they are not asked to pay again. ### Payouts and Recipients 11 - **Issue Payouts** Sends money out of your balance to one or more destinations in a single call. Each disbursement may name a saved recipient, in which case the stored bank details are used, or carry raw bank details directly. The saved form is safer, since an IBAN typed once and validated beats one repeated per payout. - **Create International Payout** Sends money from your balance to a recipient outside the UAE. It requires a saved recipient, since the destination currency and corridor come from their stored details. Supply exactly one of the source amount or the destination amount, and use an idempotency key so a retry cannot pay somebody twice. - **List Payouts** Lists the payouts your business has issued. - **Get Payout** Reads one payout with its status, destination, and amounts. - **Create Recipient** Saves someone you pay regularly with their bank details, so later payouts name an identifier instead of repeating an IBAN. The relationship and reason fields are both required and are regulatory classifications rather than notes. - **List Recipients** Lists the recipients saved on your business. - **Get Recipient** Reads one saved recipient with their bank details and classification. - **Update Recipient** Updates a saved recipient's details. Changing bank details changes where future payouts go, so validate the new IBAN first. - **Delete Recipient** Removes a saved recipient. Any flow that pays them by identifier stops working, though payouts already issued are unaffected. - **Get Recipient Balance** Reads the balance held for one recipient. - **Validate IBAN** Checks a UAE IBAN and reports which bank it belongs to. It always answers with a success status: an invalid IBAN comes back as a validity flag set false with an error list and no bank name, so a status-only reader treats a bad IBAN as a good one. ### Cards and Expenses 12 - **Create Partner Card** Issues a virtual card with a spending limit, for a partner or a booking. The cardholder must have completed identity verification already, and the surface is enabled per business by arrangement. A transaction limit alongside the amount makes a single-use card possible. - **List Partner Cards** Lists the partner cards issued by your business, with their status and spend. - **Get Partner Card** Reads one partner card: its limit, its spend so far, and its status. - **Update Partner Card** Changes a partner card's limits. Lowering the amount below what has already been spent is refused, so read the total spend first. - **Cancel Partner Card** Cancels a partner card so it stops working. Transactions already authorized may still settle afterwards. - **List Partner Card Transactions** Lists the transactions made on one partner card. - **Get Partner Card Transaction** Reads one transaction on a partner card in detail. - **List Card Transactions** Lists card transactions across every card on the business rather than one card at a time. This is the spend feed a bookkeeping flow should poll. - **Get Card Transaction** Reads one card transaction by identifier, from the business-wide feed. - **List Expense Receipts** Lists the receipts attached to card expenses. Together with the transaction feed this closes the bookkeeping loop: the spend and the document that justifies it. - **Get Expense Receipt** Reads one expense receipt, including the link to the document itself. - **Update Expense** Updates an expense: its category, its note, its accounting classification. This is where an automated bookkeeping flow writes back what it worked out about a card transaction. ### Account and Webhooks 6 - **Get Business Info** Reads the business your API key belongs to. The cheapest way to confirm a key works and which environment it points at. - **Get Account Balances** Reads the balances held for your business. Check it before a bulk disbursement, since a run larger than the balance fails partway rather than being refused up front. - **Create Webhook** Creates a webhook. The auth header is the whole security model, since the platform sends whatever string you set back on every delivery and there is no signature. The event trigger manages this plumbing for you. - **List Webhooks** Lists the webhooks registered on your business, with their URLs and subscribed events. - **Update Webhook** Updates a webhook. The URL and the enabled events are both required on every update, and the event list replaces the stored one rather than adding to it. - **Delete Webhook** Removes a webhook. Do not delete one the event trigger created, or that trigger goes quiet with no error. ## Triggers 1 triggers ### Event Triggers 1 - **On Mamo Event** Fires when Mamo reports a payment succeeding, failing, being authorized or voided, a card verified, or a refund initiated, completed, or failed. It also covers a subscription payment succeeding or failing, a payment link created, a payout processed or failed, an expense created or updated, and a card transaction created or updated. Because the delivery carries no signature, treat it as notice that something changed and read the record back before acting on the values. ## Frequently Asked Questions ### What can FlowRunner do with Mamo? FlowRunner agents can run Create Payment Link, List Payment Links, and Get Payment Link in Mamo, plus 44 more actions. ### Does connecting Mamo to FlowRunner require OAuth? No. Mamo connects to FlowRunner with an API key, no OAuth flow required. ### Can Mamo trigger a FlowRunner workflow automatically? Yes. Mamo supports 1 trigger that can start a FlowRunner workflow automatically. **Work at Mamo?** This integration exposes Mamo to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/mamo. Site index: https://flowrunner.ai/llms.txt