MONEI
Status of the MONEI integration — not released yet, what already exists behind the flag, why it has no mandates resource, and the exact v1 and MCP surface that appears on release.
MONEI is not available yet. Its v1 endpoints and MCP tools are not
registered, so calling them today returns 404 route_not_found. This page
documents the status of the integration and the surface that will appear
when it is released — it is not a usage guide.
MONEI is a Spanish payment gateway that collects by card and Bizum. Money moves at the moment of capture, like a card gateway and unlike SEPA Direct Debit — which is the reason its integration is shaped slightly differently from GoCardless.
What "not released" means
The single source of truth is the backend's list of released payment gateways
(integrations.released_providers), which today contains Stripe only. It is
configuration, not code, so a gateway is switched on without a code deploy. While
MONEI is outside that list:
- Its v1 route block is not registered. The
/v1/monei-autoinvoicing/*endpoints do not exist — they are absent from the route registry, from the OpenAPI spec and from the API reference of this site. - Its MCP tools are filtered out of the public server.
- The gateway shows as "Próximamente" (coming soon) in the integrations marketplace of the dashboard, and the connect flow is blocked at the command handler as well.
- The gateway-agnostic connected-accounts endpoint filters its results to released gateways, so no MONEI account surfaces through it either.
The classes are asleep, not absent. The release flips one list.
No mandates resource, and that is not an omission
GoCardless collects by SEPA Direct Debit, so a mandate — the customer's standing authorisation to pull money from their bank account — is a first-class object with its own life cycle, and it gets its own endpoint and its own MCP tool.
MONEI does not use SEPA Direct Debit. There is no standing authorisation to
model, so there is no mandates resource, no mandate states to keep in sync and
no mandate webhooks. If you are porting an integration written against
GoCardless, that whole branch disappears; there is nothing to map it onto.
What already exists behind the flag
| Piece | State |
|---|---|
| Connect flow | Built. MONEI authenticates with an API key, not OAuth 2 |
| Webhook signature verification | Built |
| Event normaliser | Built — maps MONEI payment statuses onto the same internal payment events the Stripe pipeline uses |
| Per-gateway connected accounts | Built — list, retrieve, update and disconnect, mirroring the Stripe multi-store model |
| Auto-invoiced charges and correctives | Built — same decision rules, same VeriFactu registration as Stripe |
| Mandates | Not applicable — see above |
Which statuses invoice, and which deliberately do not
MONEI reports the state of a payment as a status on the payment object, and the normaliser keys on it:
| MONEI status | What it produces |
|---|---|
SUCCEEDED | Treated as paid → the auto-invoicing flow runs |
REFUNDED, PARTIALLY_REFUNDED | Treated as a refund → corrective invoice flow, total or partial |
FAILED, CANCELED | Recorded as a failed charge; nothing is issued |
AUTHORIZED | Deliberately ignored — an authorisation without capture is not money collected, and invoicing it would invoice a charge that may never be captured |
| Anything else | Recorded as an unknown event |
A payment without an identifier is dropped before anything else: with no id there is no canonical identity and no idempotency key, so it could neither be deduplicated nor safely replayed.
The surface that appears on release
v1 endpoints
| Endpoint | Scope |
|---|---|
GET /v1/monei-autoinvoicing/connected-accounts | monei_autoinvoicing:read |
GET /v1/monei-autoinvoicing/connected-accounts/{account} | monei_autoinvoicing:read |
PUT /v1/monei-autoinvoicing/connected-accounts/{account} | monei_autoinvoicing:write |
DELETE /v1/monei-autoinvoicing/connected-accounts/{account} | monei_autoinvoicing:write |
GET /v1/monei-autoinvoicing/payments | monei_autoinvoicing:read |
GET /v1/monei-autoinvoicing/correctives | monei_autoinvoicing:read |
The charges listing carries an origin filter (subscription / oneshot) for
symmetry with the other gateways. If MONEI has no subscription charges for you,
origin=subscription returns an empty page rather than an error.
MCP tools
list_monei_connected_accounts, get_monei_connected_account,
update_monei_connected_account, disconnect_monei_connected_account,
list_monei_autoinvoiced_payments and list_monei_autoinvoiced_correctives —
one per endpoint above, with the same scopes.
Plan requirement
The MONEI integration is a module of the Empresario and Enterprise plans, like the Stripe and GoCardless integrations. Being on the right plan will not be enough on its own while the gateway is unreleased — both conditions have to hold.
Mapping against the Stripe flow
The gateway-specific part ends at the normaliser: from there on, every gateway shares the same invoicing pipeline, the same fiscal decisions and the same VeriFactu registration described in Stripe auto-invoicing.
| Concept | Stripe | MONEI |
|---|---|---|
| Authentication | OAuth 2 (Stripe Connect) | API key |
| Multi-store | connected-accounts per account | Same model, under monei-autoinvoicing/connected-accounts |
| "Charge succeeded" signal | charge.succeeded / invoice.paid | Payment status SUCCEEDED |
| Refunds | charge.refunded → corrective invoice | REFUNDED / PARTIALLY_REFUNDED → corrective invoice |
| Uncaptured authorisation | Not invoiced | AUTHORIZED, not invoiced |
| Mandates | Not applicable | Not applicable |
| Subscription cycles | invoice.paid with a subscription billing_reason | No equivalent branch in the normaliser |
| Payout reconciliation | Supported | Not covered today |
What works today regardless
The integration event inbox is
gateway-agnostic and is registered unconditionally, so provider=monei is a
valid filter value there on day one — including for historical events, which is
precisely why those rows are not hidden.