Integración GoCardless
Estado de la integración con GoCardless — todavía no liberada, qué existe ya detrás del flag, y la superficie v1 y MCP exacta que aparece el día que se enciende.
GoCardless todavía no está disponible. Sus endpoints v1 y sus tools MCP
no están registrados, así que llamarlos hoy devuelve
404 route_not_found. Esta página documenta el estado de la integración y
la superficie que aparecerá cuando se libere — no es una guía de uso, y nada de
lo que sigue debe leerse como «esto ya se puede llamar».
GoCardless cobra por adeudo directo SEPA: en lugar de cargar una tarjeta, tu cliente firma un mandato que te autoriza a sacar dinero de su cuenta bancaria, y todo cobro posterior corre contra ese mandato. Ese modelo cambia dos cosas frente a una pasarela de tarjeta — el dinero se mueve con un calendario diferido y una ventana de garantía, y el mandato tiene vida propia: nace, se activa y se puede cancelar o caducar con independencia de cualquier cobro concreto.
Qué significa «todavía no liberada»
La única fuente de verdad es la lista de pasarelas de pago liberadas del backend
(integrations.released_providers), que hoy contiene solo Stripe. Es
configuración, no código, así que una pasarela se enciende sin desplegar código.
Mientras GoCardless esté fuera de esa lista:
- Su bloque de rutas v1 no está registrado.
GET /v1/gocardless/mandatesy los endpoints/v1/gocardless-autoinvoicing/*no existen — no están en el registro de rutas, ni en la especificación OpenAPI, ni en la referencia de API de este sitio. - Sus tools MCP quedan filtradas del servidor público, así que un agente ni las descubre ni las puede llamar.
- La pasarela aparece como «Próximamente» en el marketplace de integraciones del Dashboard, y el flujo de conexión está bloqueado también en el command handler — incluso para un super-admin que se salte el middleware de módulos.
- El endpoint de cuentas conectadas agnóstico de pasarela filtra sus resultados a las pasarelas liberadas, así que ninguna cuenta de GoCardless puede asomar tampoco por ahí.
No falta nada ni hay nada a medio construir: las clases están dormidas, no ausentes. La liberación cambia una lista.
Qué existe ya detrás del flag
| Pieza | Estado |
|---|---|
| Flujo de conexión OAuth 2 | Construido. GoCardless se autentica con OAuth 2, a diferencia de MONEI |
| Verificación de la firma del webhook | Construida |
| Normalizador de eventos | Construido — mapea los eventos de GoCardless sobre los mismos eventos de pago internos que usa el pipeline de Stripe |
| Mandatos SEPA | Construidos — se guardan con su propio ciclo de vida: pending, active, cancelled, expired, failed, sincronizado desde los webhooks mandates.* |
| Cuentas conectadas por pasarela | Construidas — listar, obtener, actualizar y desconectar, replicando el modelo multi-tienda de Stripe |
| Cobros y rectificativas auto-facturados | Construidos — mismas reglas de decisión, misma alta en VeriFactu que en Stripe |
Qué eventos facturan, y cuáles no lo hacen a propósito
El normalizador es más estricto que «cualquier evento de pago emite factura», y la razón es la ventana de garantía SEPA:
| Evento de GoCardless | Qué produce |
|---|---|
payments.confirmed | Se trata como cobrado → corre el flujo de auto-facturación |
payments.charged_back, payments.late_failure | Se tratan como devolución → flujo de factura rectificativa |
payments.created, payments.submitted | Se ignoran a propósito — son estados intermedios de un adeudo diferido; facturar antes de que el cobro esté garantizado sería facturar dinero que todavía puede volver atrás |
payments.paid_out | Hoy no tiene efecto (la conciliación de payouts de GoCardless es un seguimiento aparte) |
| Cualquier otro | Se registra como evento desconocido |
Por eso un cobro de GoCardless no se convierte en factura en el instante en que se envía, y es la principal diferencia de comportamiento que notarás si vienes de Stripe.
La superficie que aparece al liberarse
Endpoints v1
| 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 |
Los mandatos son de solo lectura en la API pública: su ciclo de vida lo
gobiernan los webhooks mandates.*, no tus llamadas.
Tools MCP
list_gocardless_mandates, list_gocardless_connected_accounts,
get_gocardless_connected_account, update_gocardless_connected_account,
disconnect_gocardless_connected_account,
list_gocardless_autoinvoiced_payments y
list_gocardless_autoinvoiced_correctives — una por cada endpoint de arriba, con
los mismos scopes.
Requisito de plan
La integración con GoCardless es un módulo de los planes Empresario y Enterprise, igual que las integraciones con Stripe y MONEI. Estar en el plan correcto no bastará por sí solo mientras la pasarela siga sin liberarse — tienen que cumplirse las dos condiciones.
Equivalencias con el flujo de Stripe
Todo lo que ya sabes de Auto-facturación con Stripe se traslada, porque la parte específica de cada pasarela termina en el normalizador: a partir de ahí, ambas pasarelas comparten el mismo pipeline de facturación, las mismas decisiones fiscales y la misma alta en VeriFactu.
| Concepto | Stripe | GoCardless |
|---|---|---|
| Autenticación | OAuth 2 (Stripe Connect) | OAuth 2 |
| Multi-tienda | connected-accounts por cuenta | Mismo modelo, bajo gocardless-autoinvoicing/connected-accounts |
| Señal de «cobro con éxito» | charge.succeeded / invoice.paid | payments.confirmed (pasada la ventana de garantía SEPA) |
| Devoluciones | charge.refunded → factura rectificativa | payments.charged_back / payments.late_failure → factura rectificativa |
| Mandatos | No aplica | Recurso de primer nivel con su propio ciclo de vida |
| Factura ordinaria o simplificada | Mismas reglas de decisión | Mismas reglas de decisión |
| Ciclos de suscripción | invoice.paid con un billing_reason de suscripción | Sin rama equivalente: el normalizador solo mapea eventos payments.* |
| Conciliación de payouts | Soportada | Hoy no cubierta |
Qué funciona hoy de todas formas
La bandeja de eventos de integración es
agnóstica de la pasarela y está registrada sin condiciones. Registra eventos
de cualquier integración que escriba historial, incluidas las pasarelas que
todavía no están liberadas — porque ocultar esas filas te dejaría sin explicación
para cobros que nunca se facturaron. provider=gocardless es allí un valor de
filtro válido desde el primer día.