GoCardless
Status of the GoCardless integration — not released yet, what already exists behind the flag, and the exact v1 and MCP surface that appears the day it is switched on.
GoCardless 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, and nothing below should be read
as "you can call this now".
GoCardless collects by SEPA Direct Debit: instead of charging a card, your customer signs a mandate authorising you to pull money from their bank account, and every collection afterwards runs against that mandate. That model changes two things compared with a card gateway — money moves on a deferred schedule with a guarantee window, and the mandate has a life of its own that starts, activates, and can be cancelled or expire independently of any single charge.
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
GoCardless is outside that list:
- Its v1 route block is not registered.
GET /v1/gocardless/mandatesand the/v1/gocardless-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, so an agent cannot discover or call them.
- 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 too — even for a super-admin who bypasses module middleware.
- The gateway-agnostic connected-accounts endpoint filters its results to released gateways, so no GoCardless account can surface through it either.
Nothing is missing or half-built: the classes are asleep, not absent. The release flips one list.
What already exists behind the flag
| Piece | State |
|---|---|
| OAuth 2 connect flow | Built. GoCardless authenticates with OAuth 2, unlike MONEI |
| Webhook signature verification | Built |
| Event normaliser | Built — maps GoCardless events onto the same internal payment events the Stripe pipeline uses |
| SEPA mandates | Built — stored with their own life cycle: pending, active, cancelled, expired, failed, kept in sync from the mandates.* webhooks |
| 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 |
Which events invoice, and which deliberately do not
The normaliser is stricter than "any payment event issues an invoice", and the reason is the SEPA guarantee window:
| GoCardless event | What it produces |
|---|---|
payments.confirmed | Treated as paid → the auto-invoicing flow runs |
payments.charged_back, payments.late_failure | Treated as a refund → corrective invoice flow |
payments.created, payments.submitted | Deliberately ignored — intermediate states of a deferred debit; invoicing before the collection is guaranteed would mean invoicing money that can still bounce |
payments.paid_out | No effect today (payout reconciliation for GoCardless is a separate follow-up) |
| Anything else | Recorded as an unknown event |
That is why a GoCardless charge does not become an invoice the instant it is submitted, and it is the main behavioural difference you will feel coming from Stripe.
The surface that appears on release
v1 endpoints
| Endpoint | Scope |
|---|---|
GET /v1/gocardless/mandates | gocardless_autoinvoicing:read |
GET /v1/gocardless-autoinvoicing/connected-accounts | gocardless_autoinvoicing:read |
GET /v1/gocardless-autoinvoicing/connected-accounts/{account} | gocardless_autoinvoicing:read |
PUT /v1/gocardless-autoinvoicing/connected-accounts/{account} | gocardless_autoinvoicing:write |
DELETE /v1/gocardless-autoinvoicing/connected-accounts/{account} | gocardless_autoinvoicing:write |
GET /v1/gocardless-autoinvoicing/payments | gocardless_autoinvoicing:read |
GET /v1/gocardless-autoinvoicing/correctives | gocardless_autoinvoicing:read |
Mandates are read-only on the public API: their life cycle is driven by the
mandates.* webhooks, not by your calls.
MCP tools
list_gocardless_mandates, list_gocardless_connected_accounts,
get_gocardless_connected_account, update_gocardless_connected_account,
disconnect_gocardless_connected_account,
list_gocardless_autoinvoiced_payments and
list_gocardless_autoinvoiced_correctives — one per endpoint above, with the
same scopes.
Plan requirement
The GoCardless integration is a module of the Empresario and Enterprise plans, like the Stripe and MONEI 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
Everything you already know from Stripe auto-invoicing transfers, because the gateway-specific part ends at the normaliser: from there on, both gateways share the same invoicing pipeline, the same fiscal decisions and the same VeriFactu registration.
| Concept | Stripe | GoCardless |
|---|---|---|
| Authentication | OAuth 2 (Stripe Connect) | OAuth 2 |
| Multi-store | connected-accounts per account | Same model, under gocardless-autoinvoicing/connected-accounts |
| "Charge succeeded" signal | charge.succeeded / invoice.paid | payments.confirmed (after the SEPA guarantee window) |
| Refunds | charge.refunded → corrective invoice | payments.charged_back / payments.late_failure → corrective invoice |
| Mandates | Not applicable | First-class resource with its own life cycle |
| Ordinary vs simplified invoice | Same decision rules | Same decision rules |
| Subscription cycles | invoice.paid with a subscription billing_reason | No equivalent branch: the normaliser maps payments.* events only |
| Payout reconciliation | Supported | Not covered today |
What works today regardless
The integration event inbox is
gateway-agnostic and is registered unconditionally. It records events from
every integration that writes history, including gateways that are not released
yet — because hiding those rows would leave you without an explanation for
charges that never got invoiced. provider=gocardless is a valid filter value
there on day one.