10. Payments¶

Menu: Payments

Collects money through GoCardless: a one-off registration fee taken immediately by Instant Bank Pay, and an optional instalment plan collected afterwards by Direct Debit.

Products¶

Payments → Products. A product bundles, under one name:

a registration fee — a single amount, collected instantly when the guardian completes setup;
an instalment plan — a fixed run of Direct Debit payments: an amount per instalment, how many, how often, and optionally the month and day the first one should land.

A product with no instalment amount is a one-off fee and asks the guardian for no Direct Debit mandate at all.

Each product also has:

a product type (required) — from the list you keep on Payments → Settings. Removing a type there leaves products already using it alone.
a season link (optional) — ties the product to a season. Defaults to the active season.
Hide product (optional) — keeps the product live but out of the way. See below.

Add Product opens its own page; so does clicking a product's name to edit it. The Products screen itself is just the list.

Archive a product when you stop offering it; players who hold it keep their record.

Hide product is the gentler alternative. A hidden product carries on exactly as before — players already on it keep being billed — but it disappears from every place you choose a product:

the product dropdowns on the Payments screen (single and bulk send);
the list of registration products parents are offered on the registration form.

Use it to stop offering a product without archiving it.

One squad paying something different¶

A squad can pay registration products of its own instead of the season's club-wide ones — a first-year rate, a squad that trains through the summer. It is set on the squad, not on the product, so several squads can share one product.

To set one up:

Create the product as normal on Payments → Products: type Registration, linked to the season it is for.
Open the squad on Squads, click Edit on Squad Details, and tick it under Registration override. Repeat for every squad that pays it.

On the registration page, parents of players in those squads are then offered those products alone, and nobody else is offered them at all.

Tick more than one to give the squad a choice — a full-year and a half-year rate, say. Its parents then pick between exactly those, and still see none of the club-wide products.
Squads with nothing ticked carry on seeing the club-wide products exactly as before.
The product carries the season, so point each squad at the new season's products when the season changes. Until you do, the squad simply pays what everyone else pays.
A product no squad has chosen stays a club-wide choice, so setting an override for one squad quietly takes that product away from everyone else — that is what makes it an override.
A player in two squads that each override is offered everything either squad names.
A setup link a parent has already been sent follows the same rule, and one for a product that isn't that player's — followed after you set the override — reports that it is no longer available rather than setting up the wrong payment.

Setting a player up¶

Payments lists every player with the products they hold and each product's status.
Choose a product and click Send setup email, or select several players and send in bulk. A player can hold several products at once — sending a different one adds to what they have.
Sends are queued and processed in the background; the page confirms immediately and a banner reports progress and any failures. For each player the plugin creates a GoCardless Billing Request and emails the guardian a link. Where a player has more than one guardian, it goes to the payment contact.
The guardian follows the link, pays the registration fee, and enters their bank details on GoCardless's own page.
Once the mandate is active and the registration fee has confirmed, the plugin creates the instalment schedule automatically.

As soon as the registration fee clears — before the Direct Debit is live — the club's registration inbox is emailed the registration paid alert, so nobody has to watch this screen to know a family has paid.

Paid offline records that a product was paid outside GoCardless — cash, bank transfer, anything. It captures who marked it and when.

Waive writes a fee off for one player: the club has decided this family is not paying, so they stop being counted and chased as unpaid without anyone having to record money that was never paid. Pick the product, optionally type a reason, and click Waive. It captures who waived it, when, and the reason.

Nothing is emailed. A waiver is an internal decision; the parent is told only in the sense that the registration page stops asking them for anything.
They stop showing as unpaid. The status reads Waived, the squad dot goes green, they are counted under Complete on the dashboard, and the bulk payment reminder skips them.
Nobody can bill them by accident. Sending a setup email for a waived product is refused — individually and in bulk — and so is any old payment link a guardian still has.
It is worth £0. No money is counted as collected, secured or outstanding, and the export writes it no money line. Marking a fee paid offline says money changed hands; waiving says it never will.
One waiver settles the season's registration. The registration page stops offering that player any of the season's other registration products, for the same reason it stops offering them once a payment is under way.
Remove waiver puts them back exactly where they were: due to pay, and showing as not set up until they do. It is on the player's row and on their payment page.

A waiver is refused where it would say something untrue: a player who has already paid has nothing to waive, and one part way through paying cannot be waived because money may already be moving — cancel the product on their payment page first. An unopened setup request is withdrawn at GoCardless as part of waiving, so no working payment link is left in anyone's inbox.

One registration at a time. A player registers once a season, so they can only ever have one of that season's registration products live. Sending a second one is refused and says which product they are already on — cancel that one first if they should be paying for a different product. Bulk sends skip those players and say how many. Everything else (kit, subs, anything that isn't a registration product) is unaffected, and re-sending the same registration product is a chase-up rather than a second payment, so it still works as it always did.

Stopping and scheduling a player's payments¶

Once a player's Direct Debit is running, two things can be done to it from their payment page, independently of each other. Open the player from Payments and look at the product's card.

A product card lists the instalment plans running on its Direct Debit — usually one, but a mandate can carry several once payments have been scheduled against it more than once. Each has its own Stop this plan button, and the payment ledger further down names the plan each payment came from, so it is plain what stopping one would cancel.

Stop this plan cancels that plan, and with it every payment on it not already sent to the bank.

The Direct Debit stays in place. Only the plan is cancelled, so nothing has to be set up again if the club schedules something else against it later. To end the arrangement altogether — mandate, setup link and all — use Cancel product instead.
Nothing already collected is refunded, and the registration fee is untouched.
One instalment may still be taken. GoCardless sends payments to the bank several working days ahead, and one already sent cannot be recalled by anybody. Stop the plan with a few days in hand if the next instalment must not go out.
The player stays on the product with nothing scheduled. The payment ledger further down the page shows each instalment turning to Cancelled as GoCardless confirms it, which takes a moment rather than being instant.

A plan at a time, not a payment at a time. That is the only unit GoCardless will cancel — it will not stop a single instalment out of a plan. So if one payment out of six should go, stop the whole plan and schedule the five that should remain.

Schedule payments sets up a new run of instalments on the same Direct Debit — the same questions the product form asks, answered for one player: the amount of each instalment, how many, how often, and when the first one goes.

The guardian is not involved. No new Direct Debit, no authorisation, no email. The mandate they set up at registration is what these are charged to.
The form starts blank, because it is not editing anything — it is scheduling new payments. What is currently scheduled is listed in the payment ledger below it.
They are added to whatever is already scheduled. To replace a plan rather than add to it, stop the scheduled payments first. To simply take a bit more — a late kit order, a tour instalment — just schedule it.
Only that player is affected. The product is untouched, so everyone else on it carries on exactly as they were.
The club's totals follow on their own. What has been collected and what is still to come are both read from the payments themselves, so the dashboard picks the new instalments up as soon as GoCardless confirms them.
It needs a Direct Debit and a paid registration fee. The form only appears on a product whose mandate is in place and whose registration fee has confirmed — the same rule the plugin follows when it schedules a plan itself.

Statuses¶

Status	Meaning
Not set up	Nothing sent yet
Awaiting guardian	A setup link is open and they haven't been through it
Awaiting bank	They have been through the payment flow; GoCardless is establishing the Direct Debit
Active	Mandate in place
Paid	A one-off product's fee is paid — no Direct Debit to set up, so nothing further is owed
Paid offline	Recorded as paid outside GoCardless
Waived	The club has written this fee off for this player — nothing is owed and nothing is chased
Failed	Setup did not complete
Cancelled, nothing paid	Cancelled without ever taking a payment — kept for reference, shown nowhere else
Cancelled, part paid	Took money, then the Direct Debit died — needs sorting out

A product with instalments is judged by its Direct Debit: it reads Active once the mandate is in place. A product with no instalments — a registration fee on its own — never sets up a Direct Debit, so it reads Paid as soon as the fee confirms.

Awaiting guardian vs awaiting bank¶

Only one of the two is a payment being set up. They are told apart because they want opposite handling:

Awaiting guardian — a setup link is open and nobody has been through it. Either the guardian clicked to start the payment and stopped part way, or they were emailed a link and never opened it. Nothing is authorised, nothing is scheduled, and nothing will happen until someone chases them. These are the same rows the Billing Requests page lists.
Awaiting bank — the guardian has been through the flow and GoCardless is establishing the Direct Debit. Chasing them achieves nothing except confusing someone who has already paid; a Bacs mandate simply takes a few working days. This is the amber dot on the squad page.

Awaiting guardian counts as "not set up", because it is: the club's job is the same one it has for a player nobody has sent anything to. So those players are in the dashboard's Not set up column, on the Not Set Up list, and show the same red dot on their squad page. They keep their own amber badge all the same — "a link is out with them" and "we have sent them nothing" are different pieces of chasing, and the badge is where you tell them apart.

A row moves from the first to the second as soon as the guardian turns up — as soon as the registration fee confirms, or as soon as GoCardless records a customer, mandate or payment against the row, whichever lands first. Those two halves confirm separately, so a mandate that is already being set up is never still reported as untouched.

Sending a fresh setup email puts the row back to Awaiting guardian, because it supersedes the old Billing Request and clears what the previous attempt recorded.

An Awaiting guardian row does not sit there forever: a week after the setup link was created, the club closes it automatically. See Chasing up setup links nobody used.

The two cancelled states¶

Cancelled rows split the same way, on whether any money was taken before the payment died:

Cancelled, nothing paid — a setup that was never activated. Nobody is out of pocket and there is no plan to unpick; it is noise, and the product stays available for the guardian to start again. The admin screens treat one of these as deleted. It is left out of the Payments list, the squad page, the dashboard and the status filters, and a player whose only products are these reads as Not set up — which is exactly the job the club has: nobody has a payment running for them, and someone needs to start one. The record itself is not thrown away; see Looking one up again below.
Cancelled, part paid — the registration fee was collected and the Direct Debit then died, so a guardian who has paid is left with no live plan. This is the one to look at. It usually means a bank rejected or cancelled the mandate after the guardian had already paid, and sorting it out is the club's job rather than the parent's — which is why no self-serve payment link is offered for one. Re-running the setup would charge the registration fee a second time. This one stays visible everywhere, and stays filterable.

The registration fee is what decides which, and it covers instalments too: a plan is only ever created after the fee confirms, so no payment collects an instalment without having collected its fee first. On the dashboard the money columns bear this out — a "nothing paid" line shows £0 collected, and a "part paid" line shows exactly what was taken before it stopped.

Failed is deliberately not split this way. A failed mandate with money against it has the same problem and is worth the same look; say if you want it broken out too.

Cancelled, part paid is one of the statuses you can filter the Payments list by, and one of the guardian email composer's payment-status filters. Cancelled, nothing paid is neither, because nothing anywhere shows those rows any more — a filter for them would find players and then show you none of the products it found them by.

Looking a cancelled request up again¶

A cancelled-and-unpaid request is hidden, not deleted. Open the player's payment page (Payments → their name) and look below their products: n cancelled setup requests (nothing was paid) expands to the full card for each one — the Billing Request, the dates, and every GoCardless ID it ever had — exactly as it was before it was hidden.

Cancelling a product never removes anything from the payment ledger or the GoCardless event log further down that same page either, and the reconciliation CSV still carries every payment GoCardless recorded against it. So the trail behind a cancelled request is complete; it simply stops interrupting the screens about what is owed today.

Open a player's payment page for the full history: the Billing Request, the registration payment, the mandate, the instalment schedule, every payment collected, and every GoCardless webhook event received.

Where the club has got to¶

Menu: Payments → Dashboard

The Payments list answers "what about this player?". The dashboard answers "how are we doing?" — for the whole club first, then squad by squad. It only counts; it changes nothing, and it has no player list of its own. When you have found where the problem is, the link out is to the page that can fix it.

Pick a Season at the top. It defaults to the active one, and only that season's products are counted, so last season's paid-up players never flatter this season's figures. All seasons counts everything.

The headline counts are players, one each, by how far their registration payment has got:

Card	Who is in it
Complete	Direct Debit active, one-off fee paid, marked paid offline, or waived
In progress	The guardian has been through the payment flow and their bank is finishing the job
Not set up	No live payment — nothing sent to them yet, a setup link nobody has been through, or what was sent has since been cancelled or failed

Every player is in exactly one of the three, so they add up to the Players count. Not set up is deliberately broad: a player whose payment was cancelled or failed, and a player sitting on an unused setup link, both have no live payment, so the club has the same job to do about them as for someone nobody has sent a link to. Which of them each player is — and what went wrong, where something did — is a troubleshooting question, and the Payments by status card is where it is answered.

In progress means somebody else's turn, and it is a short list on purpose: only a Direct Debit GoCardless is already establishing. Nothing there needs chasing, which is what makes the other two columns worth reading.

Not set up is split underneath the number, into how many have confirmed for the season and how many have not. They are the same players counted twice over, not a third figure — the three cards still add up to Players — and the split is there because the two halves are different jobs. A player who has not confirmed needs an answer first: sending them a payment link before they have said they are playing is chasing money for a season they may not be in. A player who has confirmed and still has nothing set up is simply not paying, and that is the payment chase.

The split needs a season, because confirming is something a player does for one season. On All seasons the number stands on its own.

"Set up" means set up right now, everywhere on the page. The Registration set up count on the Season registration card is exactly the players not in the Not set up column, so the two can never disagree about the same person. A payment that was set up and has since been cancelled does not count towards it — it was genuinely set up once, but that guardian needs setting up again just like one who never started, and this page reports where the club stands rather than what it has been through.

Players who declined the season are left out of the whole page — they are not playing, so they are not paying, and leaving them in would pad Not set up, which is the column you work through. Everyone else is counted whether or not they have confirmed, so Not set up covers the people nobody has asked yet as well as the people who have not replied. Only the registration product feeds these three — a paid-up kit order never reports registration as done.

The money¶

Three more figures sit under them:

Figure	What it is
Collected	Money that actually arrived
To collect	Money GoCardless is scheduled to take — an active Direct Debit, and nothing else
Taken and scheduled	The two added together

They always add up: Collected + To collect = Taken and scheduled. Every table on the page carries the same three columns, so a figure means the same thing wherever you read it.

All three are the club's position, not a forecast. To collect is deliberately narrow: the instalment schedule is only lodged with GoCardless once the Direct Debit goes active, so until then nothing is set to leave anybody's account. A setup email nobody has opened, and one still waiting on a guardian's bank, may well turn into money — but neither is coming on a date you could put in a cashflow, so neither is counted.

That means a payment a guardian has not finished setting up contributes only whatever has actually been collected on it, and often nothing at all. The rest of its price is not on this page. If the figures look lower than the club's income should be, that is why, and the Payments by status card is where to look: Awaiting guardian, under the Not set up heading, is money nobody has started paying, and chasing those guardians is what turns it into scheduled income.

A projected figure — covering un-started setups, and players who have never been sent a link at all — is planned but not built yet. Until then, do not read these three as the season's expected income.

What counts as collected:

Direct Debit instalments — payments GoCardless reports as confirmed or paid out. One still on its way is not counted; neither is one that failed, was cancelled, or was charged back.
The registration fee — counted once the fee is recorded as paid, including when an admin recorded it by hand with Mark reg. fee paid.
Paid offline — counts as the product's full price. That is what marking it offline says.
Waived — counts as nothing, on every figure. A waiver says the fee was never charged, so there is no money to report; the player is simply no longer expected to pay.

Two things worth knowing before you reconcile against the bank:

These figures cover only payments that have actually been set up, and of those, only what has been taken or scheduled. A player nobody has sent a link to contributes nothing, which is what the Not set up count next to them is for.
A cancelled or failed payment has nothing left To collect. Nothing is scheduled against it and no setup link is open, so the balance it stopped short of is money nobody will ever be asked for, and counting it would overstate what is coming. What it did take still shows under Collected, so its Taken and scheduled is exactly that — the payment ended up being worth what it managed to collect. A payment nobody ever set up is treated the same way.

So a cancelled payment never inflates the two forward-looking figures, but the money it really took is never lost from them either. To find these, use Cancelled, part paid on the Payments by status card — those are the ones where a guardian has paid and has no live plan.

Requests cancelled before they took anything are not counted here at all — not as a payment, not as money, and not in the Payments by status card. They collected nothing by definition, so leaving them out changes no figure on the page; it only stops the counts describing requests that are no longer anything. The players they belonged to are still counted, under Not set up.

A payment against a product with no recorded price contributes nothing either way, rather than a made-up figure.

Reconciling against GoCardless¶

Download reconciliation CSV, in the row of buttons under the dashboard's heading, produces a line-by-line file to open next to a GoCardless export. It ignores the filters above it on purpose: the payments a filter would drop — one that resolved to no player, one on an archived product — are the ones that explain a mismatch.

Each line carries the guardian, the product, the player, the amount, and the dates: the charge date, when the setup email went out, when the registration fee was paid, when the club first recorded the payment and when it last changed.

The column to sort by is counted_as_collected. Summing amount where it says yes gives you exactly the dashboard's Collected figure, so the file is not a second opinion — it is the club's own total, itemised, beside what GoCardless says. Where the two disagree, one line will show it.

The source column says where each line came from:

source	What it is
`gocardless`	A payment in the ledger — what GoCardless told us
`registration_fee`	The club's own record that a registration fee is paid. Only written when the player's record says the fee is confirmed — so a `gocardless` fee with no `registration_fee` line beside it is a fee the club is not counting
`offline`	A payment marked as settled outside GoCardless, counted at the product's full price

When a line is not counted, not_counted_because says why. Most reasons are unremarkable — the payment never arrived, or it is a registration fee already counted on its own line. The ones that begin ACTION: are not: they are money GoCardless collected that the club is not counting. Sort by that column and the discrepancies come to the top.

There are two of them:

"collected, but matches no player payment record" — the payment came in but nothing links it to a player's record any more. The usual cause is a record reset after the money arrived: sending a fresh setup email clears the payment and mandate IDs the payment was matched by. It can also be a player deleted or re-imported since.
"collected, but the record does not say the fee is paid" — GoCardless took the registration fee and the player's record still shows it unpaid, so no registration_fee line is written and the money is counted nowhere. The webhook that confirms the fee either never arrived or never applied.

Both mean a guardian has paid and the club's figures do not show it. Check the player's payment page against GoCardless before assuming either way; Mark reg. fee paid is what records a fee the webhook missed.

Three further things routinely account for a gap, and each is visible in the file:

A registration fee appears twice where GoCardless collected it: once as its payment, and once as the club's record of it. Only the second is counted, so nothing is double-counted — but if the two amounts differ, that is a real discrepancy and the pair sits next to each other. The fee is collected by the same Billing Request that sets up the Direct Debit, so GoCardless reports it against that mandate and it looks like an instalment; the club tells it apart by the payment ID the player's record stores for it.
offline lines and hand-confirmed fees are money GoCardless has never heard of. They are the usual reason the club's total is higher. A hand-confirmed fee says so in its description.
A gocardless line that is collected but not counted is the opposite, and the most useful line in the file: the bank took the money and the club is not counting it. That happens when the payment is on a mandate no player's record carries — usually a payment set up outside the plugin, or one whose player record was deleted or re-imported.

A line with an empty player_id is a payment that never resolved to a child at all. It is kept in the file rather than dropped, because it is money with no home.

The cards¶

Season registration — the season's players split into Confirmed (the parent said yes, or an admin recorded it for them) and Unconfirmed, with how many of each have a registration actually set up, and the money against them. This is the one that answers "we have confirmed 189 players — are they all paying?". It needs a season, so choosing All seasons replaces it with a note; across every season at once there is no single answer, and nobody is excluded for having declined either.
Registration payments by squad — the three counts and the money per squad, registration only, with a Total row under them. That total is the columns above it added up, not the club figure: a player in two squads is counted in both, so the rows — and the total — can add up to more than the club figures at the top of the page. Players in no squad at all get their own row, so nobody is invisible. Click a squad to narrow the whole page to it — and its own view covers everything that squad is paying for, not just registration.
Products — the same per product, over payments rather than players, so a player sent a link twice appears twice. This is where a kit or tour product that nobody is completing shows up. Archived products stay listed: money taken on them was still taken.
Payments by status — every payment counted for the season, under the same headings, broken down into the individual statuses from the table above, with the money in each. This is where In progress splits into the two that matter: how much is sitting with guardians who have not opened their link, and how much is genuinely being set up at GoCardless. Cancelled or failed splits the same way, into payments that never took anything and payments that took money before they died.

On a squad's own view, Open squad page takes you to the squad, where its players are listed with their payment state and you can act.

Who has not set up¶

Menu: Payments → Not Set Up

The dashboard tells you how many players have no registration payment, and which squads they are in. This page names them, squad by squad — the list you actually work from when it is time to chase people. Who is not set up on the dashboard is the link across.

Pick a Season at the top. There is no "All seasons" here, because there is no such thing as not being set up in general: a registration payment belongs to one season's products, so the season is the question rather than a filter on it. It opens on the active season.

The count at the top is split the same way the dashboard's is — confirmed and not confirmed — and each squad heading repeats its own split beside its total, which is exactly the two lists that squad's secretary gets emailed. Work the not-confirmed ones through the season approval email and the confirmed ones through a payment link.

Everyone listed is a player the dashboard counts under Not set up for that season, so the number there and the names here can never disagree. That includes players whose payment was cancelled or failed, and players sitting on a setup link nobody has been through (Awaiting guardian), as well as those nobody has sent a link to. None of them has a live payment, and the Registration payment column says which is which so you can tell a fresh setup from a repair — or from a link that just needs chasing — at a glance. Only a payment genuinely under way (Awaiting bank) keeps a player off this page.

Each squad gets its own table, and a squad with nobody outstanding is left out entirely — an empty heading is not news. A player in two squads appears under both, so the per-squad counts can add up to more than the total at the top. Players no squad has picked up are listed last, under Not in a squad.

Column	What it tells you
Player	Their name, linking to their payment page — where you set them up, mark them paid offline or waive the fee
Confirmed for season	Whether they have said yes to the season yet
Registration payment	Not set up when nothing was ever started, Awaiting guardian when a link is open and unused, or the status of what died
Payment contact	The guardian the club bills, and their email address

Confirmed for is worth reading before you chase anyone. A player still showing Unconfirmed has not said they are playing yet, so the job for them is the season approval email, not a payment link. Players who declined the season are not on this page at all — they are not playing, so they are not paying — and a note says how many were left out.

The page changes nothing itself. Everything you might want to do about a name on it lives on that player's payment page, and the name is the link.

What happens on confirmation¶

Confirming a player for a season — by parent or by admin — never sets a payment up on its own. Their guardian's confirmation email carries a link back to the registration page, where the season's registration products are listed for each of their confirmed children, and choosing one there is what starts it. Until a guardian chooses, no payment exists.

The link is that guardian's own registration link, the same one the approval email used, so it lands them on their children rather than on a "request a link" form.
Choosing an option does exactly what Send setup email does — it creates the GoCardless billing request and emails the guardian the link — and then takes them straight there. They wait on a short "setting up your payment" page while that happens, then land on GoCardless; the email arrives as well, so they can pick it up later if they don't finish in one go.
A child whose payment is already under way or paid is shown that state instead of the options, so nobody is charged twice.
A guardian who started the wrong option can change their mind. While their setup link is still unopened, the page offers choose a different option next to the continue link: it cancels that billing request at GoCardless and puts the full list of options back in front of them. Nothing has been collected on an unopened request, so nothing is refunded and nothing is owed.
That is only offered while the request is untouched. Once they have been through the flow — the fee taken, or a Direct Debit sitting with their bank — the option disappears, and the page says the payment is being set up instead. Changing one at that point is the club's job, from the player's payment page.
A player only ever has one registration payment on the go. If a guardian follows an older emailed link for a different option while one is live, it sets nothing up and tells them which payment they already have — so two links opened at once can no longer leave them with two.

Switch it on Payments → Settings: send them back to the registration page to choose, or say nothing about payment at all and set every payment up by hand from the Payments screen.

The club used to be able to nominate a default registration product per season and have it set up automatically on confirmation. That created a billing request for a payment option the guardian had never picked, so it has been removed — the season setting is gone, and any club still on it now sends guardians back to the registration page instead.

Chasing up setup links nobody used¶

Menu: Payments → Billing Requests

Starting a payment creates a billing request at GoCardless — the thing a setup link opens. Some are never finished: a parent clicks through from the registration page and stops, misses the setup email, or leaves the club before paying. This page lists only those, newest first, and nothing else: as soon as a guardian goes through the flow the request drops off, because it has been actioned.

Sort by Date created to bring the oldest to the top — those are the ones worth chasing or clearing out.

Requests close themselves after 7 days. Once a setup link has been sitting unused for a week, the club cancels it for you — exactly what Cancel Selected below does, and for the same reason: nothing has been collected against it, and leaving a live authorisation link out indefinitely is not something the club has any use for. So this page is the short list of what is still worth chasing rather than every request the club has ever abandoned, and a request you can see here is one a guardian could still complete. Cancel one yourself when you already know it is going nowhere; otherwise you can leave it and it will go.

The Setup link column opens the guardian's own link, exactly as it was emailed to them, so you can check whether it still works before chasing. It puts you in their payment flow with their details filled in, so treat it as a check rather than somewhere to pay. A dash means no link is stored for that request — older requests predate the plugin storing it — and those guardians need a fresh setup email rather than a link you can forward.

Tick the ones you want and choose Cancel Selected to cancel them at GoCardless. The links in those emails stop working. Nothing has been collected against an unopened request, so nothing is refunded, and you can send a fresh setup email from Payments afterwards whenever you need to.

Anything a guardian has already started or paid never appears here, so cancelling from this page cannot interrupt a payment in progress. A request that someone actions between the page loading and you pressing the button is left alone, and the confirmation says so. The automatic close is stricter still: it asks GoCardless for the request's own status before cancelling anything, and leaves alone any request a guardian has been through, however long ago it was created.

A request can also leave this page without you doing anything: a guardian who chooses a different option on the registration page cancels their own unopened request, exactly as Cancel Selected would have. Nothing was collected on it either way.

A closed request — however it was closed — is not deleted. It reads as Cancelled, nothing paid on the player's own payment page, the product goes back on offer for them to start again, and you can send a fresh setup email from Payments whenever you need to. The player is counted under Not set up meanwhile, which they were already: a link nobody used was never a payment.

Working out what actually happened¶

Menu: Payments → GoCardless Events

Everything GoCardless does to a payment it tells us about in a webhook event — a payment confirmed, a mandate cancelled, a Direct Debit failed. This page is the log of every one this site has received, so when a parent says they have paid and the plugin says otherwise, you can see for yourself rather than logging in to the GoCardless dashboard.

Nothing on this page changes anything. It is a record.

Each row is one event:

Event ID — GoCardless's own ID for the event, beginning EV. Open it to see the event in full.
Request type and Request ID — the thing the event happened to: a payment (PM…), a mandate (MD…), a billing request (BRQ…) or an instalment schedule (IS…). Open a request ID to see everything that has happened to that one request, which is usually the question you actually have.
Action — what happened, in GoCardless's words: confirmed, failed, active, cancelled and so on. Green is good news, red is bad, amber is still in progress, grey is neither.
Player — who it was matched to, linking to their payments page. A dash means the event could not be tied to anyone; that is normal for events about the club's own account rather than a parent's payment.
Date received — when the webhook reached this site. Click the heading to sort oldest first.

Filter by request type, action, player or date, or paste an event or request ID into the search box. Clear returns you to the full log.

Opening an event shows what GoCardless said about it — the cause, description and any failure reason — the other resources it names, the metadata this site tagged onto the payment, and the raw event exactly as received. The other resources are links wherever they have events of their own, so you can follow a payment to its mandate and back.

Events received before this page existed are still listed, but only their ID, type, action and player were kept — those rows show a dash for the request and say so instead of a payload. Everything received since keeps the lot.

Configuration¶

Payments → Settings holds:

Active environment — Sandbox (no real money) or Live.
Sandbox / Live credentials — an access token and a webhook secret for each. Sandbox tokens begin sandbox_. Keeping both means you can test without disturbing live settings.
Currency per environment.
Product types — one per line.
Direct Debit confirmation page — the headings and text a guardian sees when they come back from GoCardless, successfully or having cancelled.

Test connections checks each token before you rely on it.

The webhook URL shown on this page must be registered in your GoCardless dashboard, with the billing request, mandate, payment and instalment schedule event types enabled. Without it, nothing a guardian does on GoCardless's side is ever reflected here.