> For the complete documentation index, see [llms.txt](https://ctracker-docs.keywordrush.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ctracker-docs.keywordrush.com/members-and-payouts/handling-a-payout-request.md).

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

{% hint style="warning" %}
**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](/how-cashback-works/what-the-plugin-never-does.md).
{% endhint %}

### 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](https://3545740495-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M69sU0hfZj3QsteYxmI%2Fuploads%2Fgit-blob-a5b1cae3257f361519b03f61fda9231b52f586da%2Fpayouts-queue.webp?alt=media)

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

{% hint style="info" %}
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.
{% endhint %}

![One payout request, with the details needed to pay it](https://3545740495-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M69sU0hfZj3QsteYxmI%2Fuploads%2Fgit-blob-b39326166ee47160b37a0e6878cfa5b3754f1c8f%2Fpayout-details.webp?alt=media)

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

{% hint style="info" %}
**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.
{% endhint %}

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](/members-and-payouts/payout-methods.md)
* [The member account page](/members-and-payouts/the-account-page.md)
* [What the plugin never does](/how-cashback-works/what-the-plugin-never-does.md)