How payments work

When a member settles a balance in Syndik8, the money goes to the syndicate, not to Syndik8. The syndicate connects its own payment account, and every charge a member pays lands directly in that account. Syndik8 never holds the funds and never sits between the member and the syndicate’s bank. This page explains that arrangement, the small fee Syndik8 takes for running the rails, and why a card payment and a Direct Debit behave so differently.

Where the money goes

The syndicate is the merchant. Before any member can pay online, an admin connects a payment account for the syndicate, and identity checks are completed on the payment provider’s hosted pages. From then on, when a member pays a charge, the payment is made directly to the syndicate’s connected account. The model is deliberately direct: there is no Syndik8-held balance that fills up and pays out later, and there is no waiting for Syndik8 to forward your money on.

Because the syndicate is the merchant, the syndicate also owns what comes after a payment. Refunds and disputes are the syndicate’s responsibility, settled against its own account, not Syndik8’s. That is the natural consequence of the money never passing through us: the party that received the funds is the party that can return them.

Owning them does not mean doing them elsewhere. An admin refunds from inside Syndik8 — choosing which charges the money comes off, seeing what will leave the account, and confirming it — and the app asks the provider to return the money and records what that meant for the member’s balance in the same step. That matters because only the app knows which charges a payment covered: a refund made in the provider’s dashboard instead arrives back here knowing nothing, and waits for an admin to say what it was for. See Refund or correct a payment.

The platform fee

Syndik8 charges a small platform fee on each payment for operating the payment rails. By default this is 0.5% of the amount collected, and it is taken from the syndicate’s side of the transaction. Stripe, the payment provider, also charges its own processing fee on each payment; like the platform fee, that comes out of what the syndicate receives rather than being added to what the member pays. The member always pays the face value of the charge: if a member owes £100, that is what leaves their account, and both fees are deducted from what the syndicate receives, not added on top of what the member pays.

The fee follows the money. When a payment is refunded, the platform’s cut on it is returned too, in proportion to the amount that went back: refund a third of a payment and a third of the fee comes back with it. When a member disputes a collection through their bank and the dispute goes against the syndicate, the whole fee is returned, because none of that money was ultimately collected. The one cost a refund does not undo is the payment provider’s own processing fee on the original payment, which it keeps; a bank dispute also carries a fee the provider charges the syndicate directly, and Syndik8 has no part in either.

This keeps the member’s experience simple. A balance reads as a single figure, a member pays that figure, and the cost of running the collection is borne by the syndicate that benefits from automated payments. The platform fee is separate from your Syndik8 subscription, which is what the syndicate pays to use the software itself.

Card payments are one-offs

A card payment is a single, member-initiated charge. From the My Balance screen a member chooses to pay one charge or to pay everything outstanding, and completes the payment there and then (in the native payment sheet on a phone, or in a hosted checkout in a browser). It is immediate and it is one-off: nothing recurring is set up, and the member decides each time whether and when to pay.

Card suits the member who wants to clear a balance on their own schedule, with no standing arrangement and no commitment to future collections. The trade-off is that someone has to remember to do it. Nothing is collected automatically, so an unpaid balance stays unpaid until a member acts.

One charge is paid gross, everything else is paid net

The two ways to pay by card are not the same arithmetic, and the difference only shows up when a member is holding a credit — an approved expense, say, or a goodwill adjustment. Pay All submits every outstanding row together, credits included, so the credit is set against the charges and the member pays the net. A Direct Debit does the same: it sums the same set and collects the difference, and skips the collection entirely when there is nothing positive left to take. Paying a single row is the exception. That row is charged in full, and the credit is untouched.

Neither is wrong, and which one a member wants depends on what they are doing with the credit. Paying a charge in full by card is how a member deliberately preserves a credit so it reduces a later Direct Debit, rather than letting today’s charge absorb it. The money works out the same in the end; what differs is when the credit is spent, and that is the member’s decision rather than ours.

What was missing was the member being told which of the two they were choosing. So when tapping Pay on one row would leave a member in credit overall, Syndik8 asks first. The confirmation names both figures — where the balance stands now, and where paying this row on its own would leave it — and, when Pay All is on screen, names it as the alternative that puts the credit towards the charges instead. The member can always go ahead: nothing is hidden and no button is taken away, because the deliberate version of this is a legitimate thing to want. It is a confirmation, not a refusal. A payment that clears the balance exactly, or leaves some of it still owed, is not confirmed at all — there is nothing surprising about it.

Direct Debit is automatic and scheduled

Direct Debit is the opposite trade. A member sets up a mandate once (a standing instruction permitting the syndicate to collect what is owed), and from then on whatever the member owes is pulled from their bank account a set number of working days after it became due. The amount is variable: it is whatever the member owes at the time of each collection, not a fixed figure, which fits the reality of varying usage and expenses. The timing follows the bill rather than a timetable of its own, so a syndicate never has a collection running out of step with its own billing.

The appeal is that nobody has to remember. Once the mandate is active, the member’s balance is collected automatically and the admin or treasurer is not chasing payments by hand. The trade-off is that Direct Debit runs on the Bacs scheme’s timeline rather than instantly, and that timeline brings rules a card payment does not have. The mechanics of mandates, schedules, and collections are set out in the Direct Debit reference.

Why a Direct Debit takes a few days, and why notice comes first

A Direct Debit does not move money the moment it is instructed. The Bacs scheme settles collections over a few working days, so the money leaves the member’s account some days after the collection is sent, and reaches the syndicate’s account after that rather than the same day. This is inherent to how Direct Debit works in the UK, not a delay Syndik8 adds.

Syndik8 does not name the day. The payment provider decides when a collection actually goes and does not tell us what it chose, so any date shown in the app would be a guess about somebody else’s behaviour presented to a member as a fact about their own bank account — the kind of fact a member might move money to meet. The app says a collection is on its way and what it is worth, and leaves the exact day to the provider’s own advance notice and to the member’s bank.

Bacs also requires that the member is told before each collection, so every Direct Debit is preceded by an advance notice. The payment provider emails the legal advance-notice message before the debit, and Syndik8 also shows an in-app “debit incoming” notice so the upcoming collection is visible inside the app. The in-app notice states the amount and that the money will leave over the next few working days, which means a member is never surprised by a Direct Debit landing; they have seen the figure in advance. The provider’s email is the one that carries a date, because the provider is the party that knows it.

The Direct Debit Guarantee

Direct Debit in the UK carries the Direct Debit Guarantee, and Syndik8 honours it. A member can reclaim any Direct Debit collection through their bank (an indemnity claim) without having to justify it. When that happens, the reclaimed collection is handled through Syndik8’s reversals flow, which re-opens the affected charges so the position is accurate again. The Guarantee is one of the reasons Direct Debit is a comfortable way to pay: the protection sits with the member who set up the mandate.

If a collection fails for another reason (insufficient funds, or a cancelled mandate), the member and the syndicate’s admins are notified, the charges are released, and they are retried on the next scheduled run. A failed collection does not quietly disappear; it comes back round on the next cycle.

Why a Direct Debit shows as “Stripe” on your statement

When a Direct Debit is collected, it appears on the member’s bank statement as “Stripe”, not as Syndik8 or the syndicate’s name. Stripe is the payment provider that operates the collection, and the statement descriptor reflects the entity that submitted the Bacs instruction. It is worth telling members this in advance: a line reading “Stripe” can look unfamiliar against a balance they expected to see attributed to their flying group, and knowing the name beforehand stops a correct collection from looking like a mistake.

This is the one place the provider’s name surfaces to a member, alongside the consent email that sets up the mandate. Everywhere else in Syndik8, payments are presented in the syndicate’s terms: your balance, your charges, your syndicate’s account.

What a card payment shows on your statement

A card payment behaves differently, because it is collected by the syndicate’s own payment account rather than by the provider on its behalf. The statement line therefore carries the syndicate’s own name, which Syndik8 sets from the syndicate name when the account is created.

Bank statements allow only 22 characters, so a long syndicate name is shortened to fit. A name a bank cannot carry at all, because it uses characters outside the Latin alphabet, falls back to the word “SYNDICATE” so the line is never left blank or rejected. An admin who wants different wording can change it in the syndicate’s own account settings with the payment provider.

The practical difference for a member is worth knowing in advance: a Direct Debit reads “Stripe”, and a card payment reads as the syndicate.

Seeing what happened

Whichever way a member pays, the record is in one place. The My Balance screen opens a Payment History showing each settlement (every card payment and every Direct Debit collection) with its current status. That history reflects the authoritative state on the server, so it is accurate about whether a payment is pending, in progress, succeeded, or failed, rather than an optimistic local guess. The detail of those statuses is in the Payment History reference.