Collect bank debits with GoCardless: customers, mandates, payments, subscriptions, payouts and refunds.
GoCardless ships in the w6w first-party pack. It declares 16 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.gocardlessGoCardless collects bank debits — Direct Debit in the UK, EUR and SEPA zones, Bacs, ACH and the open-banking “Pay by Bank” rails — so a workflow can take recurring payments straight from a customer’s bank account instead of a card.
The path a GoCardless integration actually walks is: a customer, a mandate (the bank authorisation to debit them), and then payments and subscriptions against that mandate. This app covers the customer read/create, the mandate read/list/cancel, the payment read/list/create/cancel, subscription create/list/cancel, and the two books-keeping surfaces a payment operation needs — refunds and payouts — so a workflow can reconcile what was collected against what landed in the bank.
Both GoCardless environments are supported as one explicit choice at connect time: live (api.gocardless.com) and sandbox (api-sandbox.gocardless.com) are completely separate accounts with separate tokens, and nothing in the token’s own shape says which one it belongs to. Health checks track GoCardless’s own incident.io status feed and the live request-rate headroom GoCardless reports on every response.
Three routes to the same 16 actions. The Workflow tab is generated from GoCardless's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
cancel-mandate Cancel a mandate at the bank. Every future payment and subscription against it stops; already-collected payments are unaffected.
cancel-payment Cancel a payment that has not been collected yet. A payment already taken from the customer's account can only be refunded, not cancelled.
cancel-subscription Stop a subscription collecting. Payments it has already generated are unaffected — refund those with `create-refund` if they should not stand.
create-customer Create a GoCardless customer record. Restricted on accounts whose payment pages are not yet approved — a 403 here means the account is under review, not that the request is bad.
create-payment Collect a one-off payment from a customer's bank account against an active mandate. The amount is an integer in the currency's lowest denomination.
create-refund Refund a collected payment in full or in part. Supply `totalAmountConfirmation` to have GoCardless reject a refund that would double-refund the payment.
create-subscription Start a recurring collection against an active mandate. GoCardless generates each payment from the cadence you describe here.
get-mandate Fetch one mandate, including its current status and the bank account it debits.
get-payment Fetch one payment, including its status, charge date and linked mandate/subscription.
list-customers Search this GoCardless account's customers, one cursor page at a time.
list-mandates Search mandates, one cursor page at a time — the debit authorisations behind every payment and subscription.
list-payments Search payments by status, customer, mandate, subscription, currency or date range.
list-payouts Search the payouts GoCardless has made to this merchant's own bank account.
list-refunds Search refunds by the payment or mandate refunded, refund type, or creation date.
list-subscriptions Search standing-order style subscriptions by mandate, customer, status or creation date.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying GoCardless's real ids.
{
"manifestVersion": "2",
"name": "gocardless-example",
"steps": [
{
"id": "create-payment",
"uses": {
"app": "io.w6w.gocardless",
"action": "create-payment",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"amount": "<amount>",
"currency": "<currency>",
"mandateId": "<mandateId>"
}
}
]
}create-payment create-customer create-refund create-subscription get-customer +11 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for GoCardless, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to GoCardless. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "create-payment",
payload: {
amount: "<value>",
currency: "<value>",
mandateId: "<value>",
// description: "<value>",
// chargeDate: "<value>",
// reference: "<value>",
// retryIfPossible: "<value>",
// metadata: "<value>",
// idempotencyKey: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action create-payment --payload '{"amount":"<value>","currency":"<value>","mandateId":"<value>"}' Give an AI agent GoCardless — without giving it GoCardless's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.gocardless#create-payment",
"input": {
"amount": "<amount>",
"currency": "<currency>",
"mandateId": "<mandateId>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's GoCardless connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
GoCardless's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. GoCardless itself is MIT, and the runtime that executes it is source-available (FSL).
GoCardless declares its own checks, so its health is a property of the app rather than something the host guesses at.
Incident status from GoCardless's own status page (status.gocardless.com redirects to www.gocardless-status.com, an incident.io page), covering both the live and sandbox environments.
Requests remaining in this connection's allowance, read off the `ratelimit-limit`, `ratelimit-remaining` and `ratelimit-reset` headers GoCardless puts on every response.