First-party app
GoCardless

GoCardless

Collect bank debits with GoCardless: customers, mandates, payments, subscriptions, payouts and refunds.

stable Commerce & PaymentsFinance & Accounting

About

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.

App id
io.w6w.gocardless
Version
0.1.0
Author
w6w
Licence
MIT
Categories
Commerce & Payments · Finance & Accounting

Overview

GoCardless 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.

Build with GoCardless

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-mandate

Cancel a mandate at the bank. Every future payment and subscription against it stops; already-collected payments are unaffected.

Cancel Payment

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

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-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

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

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

create-subscription

Start a recurring collection against an active mandate. GoCardless generates each payment from the cadence you describe here.

Get Customer

get-customer

Fetch one customer by its GoCardless id.

Get Mandate

get-mandate

Fetch one mandate, including its current status and the bank account it debits.

Get Payment

get-payment

Fetch one payment, including its status, charge date and linked mandate/subscription.

List Customers

list-customers

Search this GoCardless account's customers, one cursor page at a time.

List Mandates

list-mandates

Search mandates, one cursor page at a time — the debit authorisations behind every payment and subscription.

List Payments

list-payments

Search payments by status, customer, mandate, subscription, currency or date range.

List Payouts

list-payouts

Search the payouts GoCardless has made to this merchant's own bank account.

List Refunds

list-refunds

Search refunds by the payment or mandate refunded, refund type, or creation date.

List Subscriptions

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>"
      }
    }
  ]
}

Here are some of the things you can do

  • Create Payment

    perform
    create-payment
  • Create Customer

    perform
    create-customer
  • Create Refund

    perform
    create-refund
  • Create Subscription

    perform
    create-subscription
  • Get Customer

    read
    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.

Install
npm install @w6w/sdk
yarn add @w6w/sdk
pnpm add @w6w/sdk
deno add npm:@w6w/sdk
Code
import { 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);
Install the CLI
npm install -g @w6w/cli
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.

What the agent gets

Credentials it can't read

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.

A tool surface scoped to the caller

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.

A durable workflow in one call

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.

Health-aware discovery

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).

Request MCP access

Health checks

GoCardless declares its own checks, so its health is a property of the app rather than something the host guesses at.

service

GoCardless platform status

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.

quota

Request-rate headroom

Requests remaining in this connection's allowance, read off the `ratelimit-limit`, `ratelimit-remaining` and `ratelimit-reset` headers GoCardless puts on every response.