Work Refunds & chargebacks

Work Refunds & chargebacks

Money has moved back out of a captured payment and somebody has to say what that means. The Needs attention queue on the Refunds & chargebacks screen holds three different kinds of thing, and they need different work:

• A refund that did not reach the member — a card refund that failed after it was recorded, so the money is owed back to them. What it needs is you and the member agreeing how they get it. These sit at the top, under Didn’t reach the member.
• A refund — money the syndicate sent back on purpose. Nobody is disputing it. What it needs is somebody to say what it means for what the member owes.
• A reversal — money a payer’s bank took back: a chargeback, an indemnity claim, a bank recall. What it needs is a decision about whether to challenge it.

To put a payment right yourself — sending the money back, or correcting the books where there is no money to send — see Refund or correct a payment.

Before you start

• You need an admin role in the syndicate (a treasurer needs the admin role).
• Open the Admin tab → Refunds & chargebacks (under Actions). The Refunds & chargebacks row on the Admin tab says how many items are waiting for you to choose: refunds that did not reach a member, and credit to pay out to a member who has left.

Say what a refund meant

A refund Syndik8 made itself already knows what it was for, and is applied without asking. A refund made in the payment provider’s own dashboard does not: the provider tells us money went back and nothing else, so it waits here until you say which charges it covers and what that makes them.

1. Find the refund in Needs attention. Its line reads £X went back to on .

2. Tap Decide what this means.

3. Check, or say, which charges it covers.

   A refund that returned the whole payment answers this for you. Syndik8 works it out against the payment itself — the amount that went back is the payment’s own total, and the charges the payment settled add up to exactly that — so there is only one possible answer and it takes every charge on the payment. The sheet says This refund covers the whole payment, tells you how many charges that is and what they come to, and lists them so you can see what you are agreeing to. There is nothing to tick. Where your device has not got hold of one of the charges — an old payment, or a phone that has been offline — the list below is short and the sheet says how many are missing from it. The count and the total still describe the whole refund, and recording it still covers every charge on the payment. All that is left is what it meant, at step 4.

   You are asked to pick the charges yourself in every other case: a partial refund, a payment some of whose charges have already been re-opened, and a payment that already has another refund or a correction on it. In those cases the money really could have been for any of several charges and only you know which, so nothing is pre-ticked — a tick is a claim. If Syndik8 cannot check (no connection, say), you get the same picker rather than a dead end.

   For a partial refund, tick the charges the money came off. The sheet tells you what you have ticked against what actually went back, and offers only the readings that add up:

   • charges ticked to exactly the amount refunded can mean they still owe this or it was a gesture;
   • charges ticked to more than the amount refunded can only mean the charge was wrong, and the difference is the corrected figure;
   • anything less than the amount refunded has no reading, so no option is offered.

4. Say what it meant:

   • They still owe this — the charges reopen and appear on their balance again.
   • It was a gesture; they owe nothing — the charges stay settled and the syndicate carries the cost.
   • The charge was wrong — the charges stay settled at the corrected figure. Name the corrected line if you want it to read well later.

5. Read the plain-English preview of what this does to the member’s balance, then tap Record this.

A confirmation reads Balance updated. and the refund leaves the queue. The member is told at that point, not before — they get a Refund sent notice naming the amount and what has happened to the charges it covers, and so does every admin except you. See Notification types.

Clear a refund that is not yours

Some refunds have nothing to do with the syndicate’s ledger: a provider fee returned, a duplicate the provider corrected, a test refund. A refund Syndik8 could not match to any of your payments cannot be applied at all — there is nothing on the ledger to put it against — so clearing it is the only way out of the queue.

This is permanent, and it costs the payment behind it. Clearing a refund records that nobody could work out what the money meant. It does not record that the money stayed put — it did leave the account — so that refund goes on standing against the payment it came off for good:

• the payment can never be refunded through Syndik8 again;
• a later refund that arrives on the same payment can never be recorded either, only cleared in its turn;
• and you cannot undo it.

So clear a refund only where nobody can work out what it was for. Where it can be attributed, saying what it meant is what leaves the payment usable — and a refund that genuinely belongs to another syndicate, or to no ledger at all, will not be matched to one of your payments in the first place.

1. Tap Clear it for good on the refund.
2. Say why it has no effect on the ledger. The reason is required: the row leaves the queue either way, and a cleared refund with nothing written on it is indistinguishable later from one somebody lost track of.
3. Read what the dialog says it does, then tap Clear.

Nobody’s balance changes.

Refunds on their way back

Refunds the provider has accepted but not yet completed sit under On its way back. A bank refund routinely takes several working days to land.

Nothing can be done to one, and that is the point: it already counts against what is left to refund on its payment, so an admin who cannot see it raises a second refund for the same money. Balances do not move until it lands, at which point it either applies itself or arrives in Needs attention.

Nor does one sit here for ever if the instruction never actually reached the provider. Any refund still shown here after a couple of hours is checked against the provider directly: one that did go through is recorded and applied, one that died is marked as such, and one the provider never received is cleared, giving its payment that much refundable capacity back.

Refunds sent

Refunds whose money has reached the member are listed under Refunds sent, newest first, with who they went to and the day they were sent. A refund you send from the app normally lands here straight away. One still waiting to be explained stays in Needs attention instead, so nothing is listed twice.

When you refund or correct a payment, each payment in the list also says how much of it has already been refunded, and how much is still on its way back.

The queue without a signal

Refunds are kept on your device, so Needs attention and On its way back both read on a phone with no bars: you can see that a refund is settling, that one is waiting to be explained, and that one did not reach the member, wherever you are. That last one matters most offline — the refusal that would otherwise be your first warning comes from the server, and offline you cannot reach it. Chargebacks are not — the dispute half of the queue is read from the server and shows an error panel offline.

Deciding is a separate matter and always needs a connection. Saying what a refund meant, clearing one, and choosing how a member gets back a refund that did not reach them are all refused offline, because each rests on a question only the server can answer — most of all whether the charges you are about to name have already been paid back through something else.

Straight after installing the app, or after signing in on a new device, the queue may not have reached you yet. It says Still syncing refunds to this device rather than telling you nothing needs attention, because at that moment we cannot tell the two apart.

A refund that did not reach the member

A card refund can fail days after it reported success, most often because the card it was going back to has expired or been cancelled. The money returns to the syndicate rather than reaching the member. What you do depends on whether the refund had already been recorded on the ledger when it failed.

Either way, do not refund the payment again from Refund or correct a payment. The failed refund goes on counting against what is left to refund on its payment, so a second refund, or a correction of the same charges, is refused rather than risk the same money going out twice. That is deliberate: it is safer to make a person look than to hand the capacity back automatically.

It failed before it was recorded

A refund made in the payment provider’s dashboard that nobody had yet explained has not touched the ledger, so nothing on anybody’s balance moved when it was made, and nothing moves now.

The row says so before you choose anything. It is marked Did not reach the member, with the date the provider reported the failure and, where the provider gave one, its reason — the card had expired or been cancelled, and so on. Decide what this means is not offered on such a refund at all: every reading — they still owe this, it was a gesture, the charge was wrong — acts on money the member received, and they did not receive this. The server refuses all three, so the screen does not put them in front of you.

What to do:

1. Clear it. Tap Clear it for good and say that the money came back. That is the only way it leaves the queue.
2. If money is still owed to the member, send it outside Syndik8 — a bank transfer, or cash — and keep the syndicate’s own record of it.

Syndik8 also raises an alert for the platform operators when this happens, so it is not left entirely to whoever next opens the screen.

It failed after it was recorded

This is the commoner case: a refund made in Syndik8 is recorded the moment it settles. The refund itself is kept, marked as not having reached the member — money did leave the payment provider, so the record of it stays true. Syndik8 then puts the amount back on the member’s account as owed to them: a new line on their balance, dated the day the provider reported the failure, naming the reason and linked to the refund. The member and every admin are told at once.

That line is held. It counts in the member’s balance, because the money is theirs, but nothing spends it — not Pay All, not a Direct Debit, not a payment you record — until you and the member agree how they get it. Nothing is ever chosen automatically.

It appears at the top of Needs attention, under Didn’t reach the member: who is owed what, the day the provider reported the failure, and its reason. Tapping your Refund did not reach the member notice opens it here. There are two ways to put it right, with equal weight:

• Credit their account — only where the member has agreed to it. Record the day they agreed (no earlier than the failure, and not in the future) and how they agreed, for example agreed by phone with the treasurer, in at least ten characters. The amount becomes ordinary credit on their account: they can use it when they choose to at Pay, you can use it for them, and their Direct Debit uses it automatically. It never lapses. This is not offered for a member who has already left the syndicate, because the credit could never be spent.
• Record a payment to them — you have paid them yourself, outside the app. Choose the day you paid and how: Bank transfer (with its bank reference as it appears on the syndicate’s bank statement), Cash, Cheque, or Another way (with a note saying how). The amount is fixed to exactly what is owed and cannot be changed. This is a record of money leaving the syndicate for the member, reconciled against the syndicate’s own bank statement, not the card provider. It settles the line, so it leaves their balance.

Either choice is final once recorded, and the member is told which you chose. The item moves to Resolved, which shows how it was put right: the day and manner of the member’s agreement for credit, or the method, day and reference for a payment.

Leaving this unchosen blocks the syndicate from closing. Closing freezes the ledger, and both of these choices are refused on a closed syndicate, so money owed back that nobody had settled would be stranded there until somebody reinstated the syndicate. The refusal names each member owed and how much, so you know who to settle with before you try again. Either choice clears it: once the member has agreed to take it as credit, or you have recorded the payment you made them, the close goes through. See Close a syndicate.

A refund recorded as they still owe this had re-opened the charges it covered. Those charges stay owed and the member can pay them as usual; the amount owed back is kept apart from them, and is only set against them if the member agrees to take it as credit.

If nobody has chosen after about fourteen days, every admin is reminded, once.

Pay out on exit

A member who took the money as credit on account and then left the syndicate with some of it unspent appears under Pay out on exit, with the amount left. Pay it to them outside the app and record it with Record a payment to them, exactly as above. Leaving is not blocked by money the syndicate owes a member.

Work a dispute

When a payer-bank reversal — a chargeback or an indemnity claim — lands, it appears in Needs attention with the amount, its cause, and when it was received. The member has already been told: where their bank clawed back a Direct Debit and the charges are owed again, their notice names the sum and the collection date and says the amount is owed again; every other case gets a general notice pointing them at their balance.

The cause shown on the row is not a reliable way to tell a Bacs indemnity claim from a card chargeback — a dispute reported by the payment provider currently arrives labelled as a card chargeback whatever the payment method. Read the payment behind it instead.

There is nothing for you to do to a reversal here, and that is deliberate. A chargeback is decided by the member’s bank, not by the syndicate, and the payment provider tells Syndik8 the result. The row moves through its own lifecycle as the provider reports it: received, then disputed where you are challenging it through the provider, then a final outcome. Resolved reversals move to the Resolved section for your records.

When a dispute is resolved in the syndicate’s favour, the charges the chargeback took back are settled again by the original payment, so they leave the member’s balance without anybody doing anything. Four cases are left owed instead: a charge cancelled while the dispute ran, one another payment has since settled, one a collection is already claiming, and one whose amount was corrected in the meantime. Check the member’s balance after a long-running dispute resolves, because the second and third of those are common once a dispute has been open long enough for a billing period to close.

Challenging a chargeback is done with the payment provider, using their evidence process, not from this screen.

An outcome, once recorded, is final: a reversal the provider has reported as concluded cannot be reopened or changed to a different one, so a redelivered or out-of-order message from the provider cannot overwrite it.

Payments with no provider money behind them

A payment you recorded as an external transfer, waived, or offset against a credit never went through the payment provider, so there is nothing for it to send back. That does not mean it cannot be put right: the same Refund or correct a payment flow corrects it on the books instead, undoing the payment, writing the charges off, or crediting a correction to the member’s account. It says so on the form before you press anything. See Refund or correct a payment.

A correction you make yourself does not come back to this queue. Nothing is waiting on it: the member and the other admins are told the moment you confirm, and there is nobody to dispute it with. The record of it lives on the payment, not in Needs attention.

See also

• Refund or correct a payment — sending money back, or correcting a payment on the books
• Reversals — causes, sources, the dispute lifecycle, and the behaviour rules
• Member balance — where a member sees the impact of a reversal