Handling a payout request

Cashback Tracker → Payouts is the queue: everything a member has asked to be paid, and everything you have already dealt with.

You send the money. Cashback Tracker records that a member asked and that you paid; it never moves money itself. Nothing on this screen makes a payment — see What the plugin never does.

The five states

	What it means	The member's balance
Requested	They have asked.	Held — set aside, and not spendable again
Approved	You have checked it and intend to pay.	Held, exactly as above
Paid	You sent the money.	Spent
Rejected	You refused it.	Back in their available balance
Failed	You sent it and it came back.	Back in their available balance

Approved changes nothing about the money. It is a marker for you: I have looked at this and it is going in the next run, kept separate from I have sent it. If you pay as you go, ignore it and mark things paid directly — Requested goes straight to Paid.

It earns its keep when you pay in batches. Approve what you intend to pay, export just those, pay them at your bank, and import the results.

Working through the queue

Tick the rows you want and the toolbar acts on all of them — approve, mark paid or reject together. Each row reports its own result, so a payout a colleague moved a minute ago is reported and skipped rather than failing the rest.

The filters above the list take a member's name, login or email, a method, a date range and an amount range. They apply to the status tabs too: with a filter on, a tab reading Paid (3) means three matching payouts, and opening it shows those three.

The payout queue

Looking at one request

Details on a row opens everything needed to decide, without leaving the screen.

• Where to send it — the amount and the payment details, each with a Copy button. The amount copies as a bare number because that is what a bank form wants.

• What this member holds — their available, pending and paid-out balances.

• Where it came from — the cashback behind the balance.

• Their earlier payouts — whether this is their first, and how the last ones went.

• What has been done to it — every change, who made it and when.

That last one is never deleted. Diagnostic logs are pruned after a year; a record of who moved money is not.

Any warning about the payment details shows here too, and on the row. Cashback Tracker checks what it safely can — an IBAN's checksum, an email's shape — and warns rather than blocks, because a format we modelled wrongly must not stop a member being paid. Read the warning before you pay; it is usually right.

One payout request, with the details needed to pay it

Paying

Notes on a row opens three fields that look alike and are not:

Field	Who reads it
Payment reference	The member. Answers most "has it been sent?" emails before they are written.
Message to member	The member, on their account page.
Internal note	Only you. Never shown, never emailed.

If the payout can still be paid, that dialog also offers Save and mark paid — reference and payment in one action, since you have just done both.

Set the payment date if you sent the money earlier than you are recording it. Leave it empty for today. A transfer made on Friday and ticked off on Monday should say Friday, and the member's own record will.

Paying a batch

Export CSV takes your selection, or the whole current filter if you have selected nothing, and downloads one file per payout method — a bank batch and a PayPal batch need different columns.

Pay the batch however you normally do. Then fill in the status column of that same file — paid or failed on each row — and bring it back with Import results.

Fill in reference and note as well if you have them. Leave them blank and whatever is already stored stays.

Check the file first. The import shows what every row would do and writes nothing, so you can run it as often as you like. It is how you find out that a column is wrong before half a batch has been applied.

Three rules worth knowing, because each one is protecting you:

• Rows are matched on payout id only — never on a member's email and an amount. Two members can be owed the same sum on the same day.

• The amount in your file is never written. If it disagrees with the payout, that row is reported and skipped. Your file is telling you something is wrong, not correcting the record.

• Importing the same file twice is safe. The second run reports every row as unchanged. If you are not sure an import finished, run it again.

Large files are applied in the background, so the page comes back straight away and the queue fills in as it goes.

When a payment comes back

Mark it Failed. The money returns to the member's available balance, it stops counting toward their paid-out total, and they can ask again.

They are emailed that the payment could not be completed and asked to check their details — not that they were declined, which would be untrue and would not prompt them to fix the account number that bounced.

A failed payout keeps the date you sent it, shown to the member as Sent 18 Aug 2026, then returned.

Rejecting

Rejecting needs a reason, because the member reads it, on their account page and in the email.

The amount goes back to their available balance and they can request again — but a rejection cannot be undone. Only the member can raise a new request. The dialog says so before you confirm.

Use Failed instead when you did send the money and it came back; declined would be both wrong and an accusation.

Related

• Payout methods and the minimum

• The member account page

• What the plugin never does