Wallets & Withdrawals

Every customer has two balances on your site: site credit (store credit that can only be spent on entries) and a cash wallet (real money that can be paid out to their bank). This page covers granting and correcting balances, letting customers buy credit with a card, reviewing withdrawal (payout) requests, viewing bank details securely, and monitoring how much cash you owe.

Where to find it: Admin → Withdrawals (/admin/withdrawals) for the payout queue, and Admin → Reports → Wallets (/admin/reports/wallets) for the report. Per-customer balance tools live on the customer's panel in Users.

Understand the two wallets

	Site credit	Cash wallet
What it is	Promotional store credit	Real money you owe the customer
How it's earned	Prizes won as credit, purchased credit (including any purchase bonus), referral rewards, sign-up bonuses, order refunds, cash-to-credit conversions, your manual adjustments	Cash prizes won, cash alternatives taken on prizes, your manual adjustments
Spendable at checkout	Yes	No — must be converted to credit first
Withdrawable to a bank	No	Yes
Can expire	Only if you switch on Site Credit Expiry — off by default	Never

Two one-way rules to keep in mind:

• Cash can become credit, but never the reverse. Customers can convert cash to site credit from their wallet page ("Convert to Credit") — see Cash-to-credit conversion below.
• Refunds returned to a wallet land as site credit. When you refund an order and part of the refund goes back to the wallet rather than the card, it appears in the customer's credit wallet as a Refund transaction — see Orders & Tickets.

How wallet money behaves at checkout is configurable: the Auto-Apply Wallet Credit toggle in Settings applies available balance automatically, and individual competitions can be flagged Exclude from Wallet Credit so they require full card payment — see Competitions.

View a customer's balances and history

Open the customer's panel from Users (or by clicking their name anywhere it appears, including on the Withdrawals page). The panel has a Credit Wallet section showing the Current Balance and a Cash Wallet section showing the Withdrawable Balance, each with its most recent transactions alongside.

To dig deeper, click View All next to Recent Transactions. The full history panel shows every transaction with a description, date, signed amount and the balance after it, and flags entries made by an admin as "Admin adjustment". Entries that relate to an order — purchases, refunds and prize credits — show an Order # link that opens the order directly. Filter the list by transaction type using the dropdown at the top:

• Credit wallet types — Purchase, Purchase Bonus, Deduction, Instant Win Prize, Main Prize, Credit Alternative, Ticket Prize Compensation, Admin Adjustment, Refund, Referral Reward, Affiliate Commission, Cash Conversion, Cash Conversion Bonus, Top-Up Refund, Top-Up Refund Reversed, Chargeback Debit, Expired, Jackpot Win, Cashback, Points Redemption (named after whatever you call your points, so if you've renamed them to Carp Coins this reads "Carp Coins Redemption"), Instant Win Reversed.
• Cash wallet types — Cash Prize, Cash Alternative, Admin Adjustment, Withdrawal, Withdrawal Refund, Converted to Credit, Affiliate Commission, Jackpot Win, Cashback, Cash Prize Reversed.

Instant Win Reversed and Cash Prize Reversed entries are written when an order is cancelled or refunded and an instant win on it had already paid out: the money comes back off the customer's balance automatically, and can take it below zero. See What a cancelled instant win takes back. While a cash wallet is below zero, the customer's pending withdrawal requests cannot be approved or paid: reject the request (the held money returns to the wallet and clears the debt) or settle the balance first.

To trace where a cash prize came from, either use the Recent Transactions list in the Cash Wallet section (entries that came from a competition or an order carry View Competition and View Order links) or open the full history panel — prize entries there link to the winning order too. Useful for payout disputes. See Orders & Tickets for the order side of that trail.

Grant site credit to a customer

Use this for goodwill gestures, compensation for a problem, or correcting a credit balance.

1. Open the customer's panel from Users and scroll to Credit Wallet.
2. In the Credit Adjustment form, enter an Amount — positive to add credit, negative to deduct it.
3. Enter a Reason (required, at least 3 characters), e.g. "Manual credit for customer service issue".
4. If you are adding credit, decide whether to tick Email the customer about this. It is unticked by default. Ticking it sends the customer an email with your reason, the amount, and their new balance.
5. Click Apply.

The balance updates immediately and the entry is recorded as an Admin Adjustment with your reason, visible to the customer in their own wallet history. The amount cannot be zero, and the form is not available for archived customers. Admin credits and debits also roll up into the Wallets report.

Telling the customer

The email box only appears when you are adding, never when you are deducting, and it starts unticked every time you open the form. That is deliberate: the most common reason to deduct or re-credit is fixing your own earlier mistake, and the customer does not need an email about each step of a correction.

What the customer gets is your reason, word for word. It is the same note they would see in their wallet history, so write it for them rather than for your records — "Goodwill credit for the delayed draw" rather than "ticket 4471 comp".

After you click Apply, the confirmation tells you what happened to the email:

• "Email sent." — it is on its way.
• "Email not sent — we cannot deliver to this address." — the customer is on your suppression list, so nothing was sent. The credit is still theirs; they will see it in their wallet. System Logs has the delivery history if you need it.
• "Email not sent — this customer has self-excluded or closed their account." — the credit went through, but we will not contact someone who has asked the site to stop, and an email about money landing in their account is exactly the kind of message self-exclusion exists to prevent.
• "Email could not be sent." — something went wrong at the sending end. The credit is unaffected. Nothing is retried automatically, so send them a note yourself if it matters.

The credit always goes through, whatever happens to the email. The two are never tied together.

You can change the wording of this email under Content → Email Templates → Balance Credited by Admin. See Email Templates.

Credit several customers at once

Use this when the same gesture goes to a group of people: everyone caught by an outage, everyone who entered a competition you had to postpone, a batch of prize draw runners-up.

1. Go to Admin → Users (/admin/users) and click Credit Wallets in the top right.
2. Under Customers, leave Search and select chosen. Search for each customer by name or email and pick them from the list. Type at least two characters to search. You can credit up to 100 customers in one go. (To credit a whole group instead of picking people one by one, see Credit a saved segment below.)
3. Enter the Amount each. This is what every customer receives, not the total.
4. Write the Note (between 3 and 500 characters). Your customers read this in their own wallet history, so write it for them, e.g. "Goodwill credit for the delayed October draw" rather than "batch 4".
5. Decide whether to tick Email each customer about their credit. It is unticked by default. One tick covers the whole batch: everyone credited gets their own email carrying the same note.
6. Check the running total under the form, then click Review credit.
7. The confirmation step restates how many customers, how much each, the total going out and the note they will see. If you asked for emails, it says so. Click Credit £X to go ahead, or Back to change something.

You then see exactly what happened, customer by customer: everyone credited with their new balance, and anyone who was not, with the reason. Anyone in the failed list received nothing, so you can select just those people and try again.

If you asked for emails, the result screen says how many went, how many could not be delivered, and how many were withheld because the customer has self-excluded or closed their account. Everyone in the credited list was credited either way — only the email is affected. Withheld is not a fault to chase: it means we deliberately left that customer alone.

Three things to know before you use it:

• It only adds credit. There is no bulk deduction, and the amount must be above zero. To take credit away, use the Credit Adjustment form on the customer's own record, where you can see the balance you are about to reduce.
• It only touches site credit, never the cash wallet.
• There is no undo, and clicking twice credits twice. The confirmation step exists for that reason, and the button is disabled while the credit is going through. If you do issue a batch twice, correct it with the Credit Adjustment form on each customer.

Every credit lands in the customer's history as an Admin Adjustment carrying your note, exactly as a single adjustment does, and the whole batch rolls up into the Wallets report under admin credits.

Who can use it: Admins and Shop Managers. Marketing users have no wallet access and will not see the button.

Credit a saved segment

Picking a hundred people by hand is fine when you know their names. When the group is a kind of customer — your biggest spenders, everyone who has gone quiet, everyone who bought into a particular sort of competition — use a saved audience segment instead and let the platform work out who that is.

1. Open Credit Wallets from Admin → Users as above.
2. Under Customers, click Use a saved segment. Your saved segments load into the dropdown; pick one.
3. Decide how many to credit. Only the top is on by default and set to 100 — the most you can credit in one go. Choose whether "top" means spend in the last 30 days or how recently they joined. Turn the tick box off to credit everyone in the segment.
4. Decide who counts. Only customers this segment can market to is ticked to start, and means the people the segment counts on the Audience Segments page: verified, and opted in to email or texts. Untick it to include everyone the segment's rules match, opted in or not. See Who gets left out for why the two numbers differ.
5. Read the line underneath: "Reaches 137 customers. Crediting the top 100 by spend in the last 30 days." That is the live answer for the segment as it stands right now. A second line tells you how many more people match the segment but are not opted in to marketing, so you can see what unticking the box would add.
6. Fill in the Amount each and the Note as usual, click Review credit, check the confirmation — it names the segment and says which of the two groups you chose — and go ahead.

Switching between Search and select and Use a saved segment clears whatever you had picked in the other one. A credit uses one or the other, never a mix of both.

Who gets left out, and who does not

Two kinds of customer are always skipped when you credit a segment, however the segment is built:

• Self-excluded customers. Someone who has asked you to stop them playing should not be handed credit to play with. They stay excluded until their self-exclusion ends.
• Closed accounts. Accounts that have been archived and had their details removed.

The panel tells you how many were left out and why, both before you commit and on the result screen — as counts, not names.

Everyone else in the segment can be credited, and this is the part worth understanding. The Audience Segments page counts the people a segment can market to: verified customers who are opted in to email or texts. A segment's rules usually match many more people than that — everyone who bought last week, say, whether or not they ever ticked a marketing box. So a segment that shows 4 email contacts can easily match 114 customers.

The Only customers this segment can market to tick box decides which of those two groups you credit:

• Ticked (the default): the same people the segment counts on the Audience Segments page. The number you see there is the number you credit.
• Unticked: everyone the segment's rules match. A customer who has unsubscribed from your emails or opted out of texts still gets the money, and so does a customer who has never verified their email address. Crediting a wallet is not marketing, and for a "thank you to our best customers" this is usually the fairer choice — being opted out of newsletters is not a reason to miss a reward.

Whichever you pick, the panel shows the other number too, so nothing is hidden: "Reaches 4 customers. 110 more match the segment but are not opted in to marketing."

Things to watch

• The 100 cap applies to segments too. If the segment reaches more than 100 people and you have turned Only the top off, the panel blocks Review credit and tells you the real number — nobody is credited and no money moves. Turn the limit back on, or use a tighter segment.
• "Top spenders" means money actually spent with you. It counts card and cash payments on completed, uncancelled competition orders in the window. Buying site credit does not count as spending it, and spending site credit does not count either — the same definition your segments use, so the two always agree.
• The segment is worked out at the moment you credit. A segment is a rule, not a fixed list, so the people it reaches today may not be the people it reached last month. Every credit records which segment it came from and what the segment was called at the time, so you can still explain a payment months later.
• The result screen does not name the customers. For a segment credit you get the counts, not a list of people — the platform works out who the segment reaches and does not hand that list back. Each customer sees your note in their own wallet history, the whole batch rolls up into the Wallets report, and anyone who could not be credited is named, so you can chase them.
• If the segment changes while you are looking at the confirmation, the credit stops. You confirmed "100 customers, £500". If three more people meet the segment's rules before you click, you get told the number has moved and nobody is credited — check it and go again, rather than spending more than you agreed to.

Who can use it: the same people who can credit wallets. You do not need marketing access to pick a segment here, though you do need it to create one.

If a credit times out

A batch of a hundred is credited one customer at a time, so a slow one can occasionally leave the page hanging or showing an error even though the credit went through. Do not simply try again — a repeat run credits the same people a second time, and there is no undo. Check the Wallets report or a few of the customers' own wallet histories first to see what actually landed.

Add or deduct cash from a customer's wallet

The Cash Adjustment form sits in the Cash Wallet section of the same customer panel and works identically: positive amount to add cash, negative to deduct, reason required, then Apply. Adding cash also offers Email the customer about this, unticked by default, exactly as the credit form does — see Telling the customer.

Use it sparingly — unlike site credit, this is real money the customer can withdraw, so every positive adjustment increases your cash liability. Typical uses: returning money after a payment you made bounced back, or correcting a balance error. The adjustment appears in the customer's history as an Admin Adjustment with your reason.

Let customers buy site credit

Customers can buy site credit with a card from their own wallet page, with an optional bonus percentage on top. Credit bought this way behaves like any other site credit: it can be spent on your site, but it can never be withdrawn as cash. It is off until you turn it on.

Turn top-ups on and set your amounts

1. Go to Admin → Settings (/admin/settings) and pick Wallet Top-Ups from the list on the left.
2. Switch on Allow customers to buy site credit. This toggle saves on its own the moment you flick it, and the Top Up button appears on customers' wallet pages straight away. While it is off, the rest of the section stays hidden and credit can only come from prizes, rewards and your own adjustments.
3. Set Minimum top-up (£), the smallest amount a customer can add in one go.
4. Set Maximum top-up (£), the largest amount in one go. It has to be at least the minimum.
5. Optionally fill in Suggested amounts, the quick-pick buttons customers see. Separate them with commas, smallest first, with no repeats (for example 10, 25, 50, 100). Leave it empty and customers simply type their own amount.
6. Click Save. This section has its own Save button rather than the settings page's bottom bar, and a Discard button appears next to it while you have unsaved edits.

Two things worth knowing about suggested amounts. Any suggestion that falls outside your minimum or maximum is quietly hidden from customers rather than flagged as a mistake, so tightening your limits can leave you with fewer buttons than you listed. And a customer can always type their own figure, so the suggestions are a nudge towards the amounts you want, not a restriction.

Give bonus credit on top-ups

1. In the same Wallet Top-Ups section, switch on Give bonus credit on top-ups.
2. Enter a Bonus percentage (%), the extra credit added on top of what the customer pays. It must be between 0 and 100.
3. Enter Bonus applies from (£), the smallest top-up that earns a bonus. Set it to 0 to reward every top-up.
4. Click Save.

For example, at 10% from £25, a customer paying £50 receives £55 of credit. A customer paying £20 receives £20, and sees a line in the top-up window telling them how much more to add to earn the bonus. When a bonus is switched on, the Top Up button on the wallet page also carries a small percentage badge, so the offer is visible before customers open the window.

The bonus is credit you are giving away, so keep an eye on what it costs you. It shows in the Wallets report under Purchase bonuses in the promotional credit block, and it is included in the Purchased (incl. bonus) line of credit in.

Follow a top-up from the customer's side

Handy when a customer is on the phone to you:

1. On their wallet page, a Top Up button sits on the Site Credit card.
2. The Top Up Site Credit window offers your quick-pick amounts and an Amount to Top Up (£) box, with the allowed range shown underneath.
3. A Top-Up Preview shows You pay, the Bonus if one applies, and You receive.
4. Continue hands them to your card payment page to finish.
5. On their return they see a Top-up Complete page listing what they paid, the bonus and the total credited. The credit is on their balance at that point.

How a top-up shows in your spend figures

The money a customer pays for a top-up counts as their spend, from the moment the card is charged. You will see it in the Spend column at Admin → Users, in their Lifetime Value on their profile, and in the Total Spent column of a users export.

It is counted once, at the top-up. When they later use that credit to enter, the entry charges their card nothing, so it does not add to their spend a second time. Two things deliberately stay clear of it:

• Their order count. A top-up buys credit, not entries, so it never adds to the number of orders on their profile.
• The gross figures in reports. Entry-value totals, such as Total Spend on the Customer Spend report, already count the money when the credit is used at checkout, so the deposit is not added on top.

If you refund a top-up, the refund comes back off their spend as well.

Refund a top-up

A top-up is an ordinary order, so a refund runs through the same flow as any other refund.

1. Go to Admin → Orders. Top-up orders carry a Top-up badge under the order number.
2. Open the order. In place of a ticket list you see Wallet credit top-up with a Wallet Top-Up label, because the order bought credit rather than entries.
3. Click Cancellation Options… and complete the form as you would for any refund (see Orders & Tickets).

Two limits apply, and both are checked when you submit rather than when you open the form:

• A top-up can be refunded for up to 14 days after it was bought.
• The customer must still be holding the credit. Once they have spent it, there is not enough left to take back.

If either rule blocks the refund, the form tells you so plainly and points you at the chargeback tool instead. When a refund does go through, any bonus you gave is taken back first and the rest goes back to the customer's card. It appears in their wallet history as a Top-Up Refund.

Record a chargeback on a top-up

Use this when the customer's bank claws the payment back, or when a refund is refused because the top-up is too old or the credit has already been spent. It takes the credit off the customer without touching their card.

1. Open the top-up order. On completed top-ups, a red Record Chargeback… button sits at the foot of the order panel. You only see it if your role can process refunds.
2. Read the warning in the Record Chargeback window. It names the order and spells out what comes off the customer.
3. Optionally enter a Reason (up to 500 characters, for example "bank confirmed a disputed payment"). It is for your own records.
4. Click Record Chargeback.

What happens next: everything that top-up credited, including any bonus you gave, comes off the customer's site credit and appears in their history as a Chargeback Debit. If they have already spent that credit, their balance goes negative and their account is locked until the balance is settled. There is no undo button, so if you record one by mistake, put the credit back with the Credit Adjustment form and say why in the reason.

Review and approve withdrawal requests

When a customer requests a withdrawal from their wallet page, the requested amount is held out of their spendable balance and the request joins the queue at Admin → Withdrawals. The page shows four stat cards (counts of Pending, Approved, Completed and Rejected requests), your Total Liability figure in the header, and the queue itself.

Each new request also emails your contact address, and if you'd rather hear about them the moment they happen, the Withdrawal Requested event can send a push notification to your phone or a message to a private team channel — see Webhooks & Push Notifications.

Filter the queue with the Status dropdown — All Statuses, Pending, Approved, Completed, Rejected or Cancelled. The table columns are:

• User — name and email; click to open their panel.
• Amount — the sum requested.
• Status — see Withdrawal statuses below.
• Requested — when the request was made, plus a "Processed" timestamp once it has been actioned.
• Notes — any note the customer added when requesting, your internal processing notes, and rejection reasons (shown in red).
• Bank Details — the eye icon for viewing details, with a view count; see View a customer's bank details.
• Actions — the buttons available for the row's current status.

Withdrawal statuses

Status	Meaning	Your next action
Pending	Awaiting your review; the amount is held from the customer's balance	Approve or Reject
Approved	You've approved it and now need to send the money from your bank	Pay, then Mark Completed
Completed	Paid and closed	None
Rejected	You declined it; the held amount goes back to the customer	None
Cancelled	The request was called off before processing; nothing is owed	None

Customers see the current status (and any rejection reason) against each request on their own wallet page. While a request is Pending their Withdraw button is switched off, with a line explaining that they can only have one withdrawal in flight, so they find out before filling in a form rather than after submitting it. If you have customer cancellation switched on, that line points them at cancelling and starting again.

A Cancelled request is one the customer called off themselves. They can only do that while it is still Pending, and only if you have switched on Let customers cancel a pending request — it is off by default. Cancelling returns the held amount to their cash balance straight away, so there is nothing for you to do and nothing owed. It is worth turning on: without it, a customer who asked for the wrong amount has to email you, because they cannot open a second request while the first is sitting in your queue.

Approve a withdrawal

1. Filter the queue to Pending.
2. Open the customer's panel if you want to check their history first — prize wins, previous withdrawals, and any account flags.
3. Click the tick icon (Approve) on the row. The modal shows the customer and amount; add optional internal Notes if useful.
4. Click Approve. The request moves to Approved — as the modal itself reminds you, approving does not send any money.
5. View the bank details and make the payment from your own bank.
6. Return to the queue and mark it completed.

Mark a withdrawal as completed

Once you have actually paid the customer, click the badge icon (Mark Completed) on the Approved row, add optional notes, and click Complete. The request moves to Completed and the queue, stats and liability figures refresh. Only mark a withdrawal completed after the money has left your bank — Completed is your record that the payout happened.

Reject a withdrawal

1. Click the X icon (Reject) on a Pending row.
2. Enter a Rejection Reason — this is mandatory, and the customer will see it, so write it for their eyes ("Bank details didn't match the account name — please resubmit").
3. Optionally add internal Notes (these stay in the admin queue).
4. Click Reject.

The held amount returns to the customer's cash wallet, appearing in their history as a Withdrawal Refund, so they can fix the issue and request again.

View a customer's bank details

If you collect bank details with withdrawal requests (see Configure withdrawal rules), each row with details shows an eye icon in the Bank Details column:

1. Click the eye icon. A confirmation warns that the view will be logged and attributed to your account — click Continue.
2. Enter the 6-digit code from your authenticator app when prompted.
3. The modal shows the Account Holder Name, Sort Code and Account Number, along with the total view count, when the details were first viewed, and how long until they expire.

One code covers 30 minutes. You are asked for a code the first time, then not again for half an hour, so a run of payouts does not mean an authenticator code per customer. After 30 minutes the next record asks for a fresh code. The window is fixed from when you entered the code — it does not extend while you keep working — and it closes if you reload the page. Every individual view is still logged against your account exactly as before.

If you have switched on saved payout details, nothing here changes: a customer paying from their saved details still produces a normal Bank Details row on the request, viewed the same way. What they saved is never visible to you as a standalone record — you see it only when they actually withdraw.

The count next to the eye icon shows how many times the details have already been viewed — an unexpectedly high count on a row you haven't worked on is worth querying with your team.

Account holder names are already bank-ready. When a customer enters their bank details, the account holder name is limited to 18 characters and to letters, numbers and spaces, which is what banks accept as a beneficiary name in a bulk-payment file. Apostrophes are closed up and other punctuation becomes a space, so Anne-Marie O'Neill is stored and shown as ANNE MARIE ONEILL. The customer sees the limit and a character counter while they fill the form in, so what reaches you can be pasted into your bank without editing. Receiving banks match on letters alone, so the tidied form still matches the account. Details a customer saved before this came in are left exactly as they are until the next time they save them.

A name using a letter outside A to Z, such as Ł, Ø or ß, is not guessed at or converted: the customer is asked to enter the name as their bank shows it, which is the plain-letter form their bank already holds for exactly the same reason. If a customer tells you they cannot save their name, that message is the fix, and there is nothing for you to change at your end.

Bank details are time-limited. They are automatically deleted after the retention period you set in Settings, so:

• The eye icon turns amber when the details expire within 12 hours — prioritise those rows.
• Once details have expired, Pending and Approved rows show a red Expired label and the details cannot be recovered. Reject the request (explaining why in the rejection reason) so the customer gets their money back and can resubmit fresh details.

If your code is rejected: you get a few retries in the same dialog. After that you'll see "Too many invalid codes. Close and try again." — close the dialog, reopen it and enter a fresh code. If invalid codes keep going in, the server locks you out with "Too many attempts. Please try again in 15 minutes." — wait out that lockout, and check your authenticator app's clock is set automatically if codes keep failing.

Export approved withdrawals for payment

Working from a spreadsheet is usually faster than opening each row, especially if someone else does the actual paying.

Approve first, then export. The export covers Approved requests only. That is deliberate: a customer can cancel their own withdrawal while it is still Pending, so exporting pending requests would risk paying someone who withdrew the request before the money went out. Approving is your decision that you intend to pay them, and it puts the request permanently beyond their reach — a customer cannot cancel an approved request no matter what your settings say.

So a payout run goes:

1. Filter the queue to Pending, tick the requests you intend to pay, and click Approve in the bulk bar. Each of those customers gets the usual withdrawal-approved email.
2. Click Export approved in the page header.
3. A confirmation explains what the file contains — click Export.
4. Enter your authenticator code if you have not already done so in the last 30 minutes.
5. A CSV downloads containing every approved withdrawal: your reference for the row, the date it was approved, the customer's name and email, the amount, and their account holder name, sort code and account number.
6. Pay them from the sheet, then mark them completed in bulk.

The export itself changes nothing and emails nobody. It is a read of what you have already approved.

A Details Status column explains any row with blank bank columns: EXPIRED (past its retention period), NOT_SUBMITTED (no details were ever supplied), or VIEW_LIMIT_REACHED (the record has been opened too many times and can no longer be shown). Those rows stay in the file so you know to chase them rather than silently missing a customer.

The file is real customer bank details in plain text, and unlike the details on your site it does not expire on its own. Delete it once the payments are made, and if you send it to someone, send it the way you would send anything else you would not want forwarded.

Sort codes in Excel

Excel drops the leading zero from a sort code like 012345 when it opens a CSV. If you are keying payments from the file, format the column as text before you trust what you see.

Approve, complete or reject in bulk

Every row in the queue has a tick box, and the header box selects the whole page. With rows selected, a bar appears above the queue with Approve, Mark completed and Reject.

Each button counts how many of your selection it applies to and ignores the rest, so selecting a whole page and clicking Mark completed completes the Approved rows and leaves the Pending ones alone. Rejecting asks for a reason once, which is applied to every request in the selection.

You are shown the total amount and the number of requests before anything happens. As with a single row, only mark withdrawals completed once the money has actually left your bank.

If some rows fail — usually because a colleague actioned them first, or the customer cancelled — the rest still go through, and the message names the first failure so you can see what happened.

Monitor your cash liability

The Total Liability figure in the page header is the total real money currently sitting in customer cash wallets. Below the queue, the Top Cash Balances table lists the customers holding the largest balances (click through to their panels) and shows how many customers hold any cash balance at all. For liability over time, use the Wallets report.

Configure withdrawal rules

The Withdrawals section in Settings controls how requests work on your site:

• Bank Details Collection — whether customers must supply bank details when requesting. When enabled, you set the retention period (in hours) before encrypted details are auto-deleted, and viewing details always requires an authenticator code (this cannot be switched off). One code covers 30 minutes of viewing and exporting.
• Saved payout details — optionally let repeat winners keep their bank details so they confirm rather than retype next time, with a retention window you set in days. See Save payout details for repeat winners.
• Withdrawal Limits — optional minimum and maximum request amounts; the customer's request form enforces them.
• Processing Message — a custom message shown to customers in the withdrawal request form (e.g. your payout timescale).

You can also require ID verification before a customer may request a withdrawal — see ID Verification.

Prize choices and wallets

When a prize is set up with a cash or credit alternative, the winner chooses what to take, and their choice lands in the matching wallet:

• Cash alternative taken → credited to the cash wallet as a Cash Alternative transaction (and counted under "Cash alternatives taken" in the Wallets report).
• Credit alternative taken → credited to the site credit wallet.

The Prizes section of the customer panel shows prizes still Awaiting a choice and labels decided ones with what was taken (e.g. "Took £500.00 cash"). Setting up alternatives and managing winners is covered in Winners.

Cash-to-credit conversion

If enabled in Settings, customers can convert cash wallet balance into site credit from their wallet page — optionally sweetened with a conversion bonus percentage (e.g. convert £50 cash, receive £55 credit at a 10% bonus). Conversions are permanent: credit can never be turned back into cash.

Conversions reduce your real-money liability while keeping the value on your platform, so a healthy conversion rate is generally good news. In the Wallets report, conversions appear as "Converted to site credit" in cash out and "From cash conversion (incl. bonus)" in credit in.

Run the Wallets report

Where: Admin → Reports → Wallets (/admin/reports/wallets). It requires the financial analytics permission — admins without it are sent back to the Reports hub.

1. The report loads automatically for This Month when you open it.
2. To change the window, pick a preset — Yesterday, Last 7 Days, Last 30 Days, This Month, Last Month or All Time — or set your own start and end dates and run it.

Read it with one rule in mind (stated under the date picker): snapshot totals are live; flow, withdrawals and the chart cover the window you picked.

Cash wallet section

• Cash owed right now (live) — total cash across all customer wallets and how many customers hold a balance. This is the number your bank needs to be able to cover.
• Pending payouts (live) — the value and count of withdrawals awaiting action. If this keeps climbing, work the withdrawals queue.
• Net cash movement — cash in minus cash out for the window.
• Cash in / Cash out — where cash came from (cash prizes won, cash alternatives taken, withdrawal refunds, admin credits) and where it went (withdrawals paid or held, conversions to site credit, admin debits).
• Withdrawals by status — requests raised during the window, grouped by status, with a "Manage withdrawals" shortcut into the queue.
• Daily cash flow — a day-by-day in-versus-out chart. The chart is available for ranges up to 12 months; for longer ranges it is omitted but all the totals still cover the full range.
• Top cash recipients — who received the most cash in the window, what they withdrew in the same window, and their current balance. A recipient with a large "Won" figure and zero withdrawals is either converting to credit (fine) or building up a balance you'll owe later.

Site credit section

• Credit outstanding (live) — total site credit held across all customers.
• Net credit movement — credit in minus credit redeemed for the window.
• Credit flow — credit won as prizes, purchased (including bonus), referral rewards, order refunds, cash conversions (including bonus) and admin credits, against credit redeemed at checkout and admin debits. If you sell site credit, two more lines appear in credit out when they apply: Top-up refunds (credit taken back when you refunded a top-up) and Chargeback debits (credit taken back after a disputed payment).
• Dormant balances: credit sitting idle, and how many customers hold it, for accounts with no wallet activity over the number of months shown on the card. These balances are part of the credit outstanding figure above, not an extra amount.
• Promotional credit: purchase bonuses, referral rewards, goodwill compensation, conversion bonuses and admin-granted credit, with a total. These figures are part of the credit issued totals above, shown separately so you can see what you gave away to attract and keep customers; they are not an additional amount.

Profit and loss, including scenario views, lives in the Revenue report (Admin → Reports → Revenue); this page tracks credit liability and flows so the two never double-count.

Troubleshooting

A customer says money vanished from their cash balance after requesting a withdrawal. That's the hold working as designed — the requested amount is held out of their spendable balance while the request is Pending or Approved, and their wallet page shows it as held. It's paid out on completion, or returned if the request is rejected or cancelled.

I rejected a withdrawal — do I need to give the money back manually? No. The held amount returns to the customer's cash wallet as a Withdrawal Refund transaction. Check their cash wallet history on the customer panel to confirm. Only use the Cash Adjustment form for genuine corrections outside that flow — for example, a completed payout that your bank later returned.

The Bank Details column shows "Expired" and I can't pay the customer. The details passed their retention period and were deleted; they cannot be recovered. Reject the request with a reason explaining that the details expired and asking the customer to resubmit — the money returns to their wallet and they can request again. To avoid repeats, action Pending requests before the eye icon turns amber (under 12 hours left), or lengthen the retention period in Settings.

My authenticator code keeps being rejected when viewing bank details. You get a handful of retries per attempt; after those the dialog says "Too many invalid attempts. Close and try again." — close it, reopen and enter a fresh code. If wrong codes keep coming, the server locks you out for 15 minutes ("Too many invalid codes. Please try again in 15 minutes."). Wait, then try again — and check your phone's clock is set to update automatically, since a drifting clock makes every code invalid.

A customer says they can't request a withdrawal. Check, in order: their cash balance (site credit is never withdrawable), your minimum and maximum withdrawal limits in Settings, and whether you require ID verification before withdrawals — if so, they must pass ID Verification first.

A request shows Cancelled — do I owe anything? No. Cancelled requests were called off before processing and hold no funds; no action is needed.

A customer says there's no Top Up button on their wallet page. Buying site credit is off until you switch it on. Go to Admin → Settings → Wallet Top-Ups and check Allow customers to buy site credit is on. That toggle saves itself, so there is nothing else to press.

The Save button in Wallet Top-Ups is greyed out. It only lights up when something has changed and every value is valid. Look for a red message under the fields: the minimum and maximum must both be above zero with the maximum at least the minimum, suggested amounts must be positive, smallest first and without repeats, and the bonus percentage must be between 0 and 100.

A suggested amount isn't appearing for customers. It falls outside your minimum or maximum, so it is hidden rather than shown as an error. Either widen the limits or drop that figure from the list.

I can't refund a top-up. Refunds are only possible for 14 days after the top-up, and only while the customer still holds the credit. If the order is older than that or the credit has been spent, the form refuses and tells you which rule applied. Use Record a chargeback on a top-up instead, bearing in mind that takes the credit back rather than returning money to the card.

I can't change the status on a top-up order. That is deliberate. A top-up moves money twice over, once as credit into the customer's wallet and once on their card, and the status dropdown only ever touched the order. Setting a completed top-up back to Pending and forward again used to pay the credit out twice, and marking one Refunded left the customer holding credit you had not taken back. Once a top-up has completed, use Refund to reverse it, or Record Chargeback if the bank has already taken the money back. You can still complete or fail a top-up that has not settled yet.

A customer's account locked itself after I recorded a chargeback. That is the negative balance doing it: the chargeback took back credit the customer had already spent, so they now owe you. The lock stays on until the balance is settled. If you decide to write it off, clear it with the Credit Adjustment form and record your reason.

A big cash prize was paid out but I don't recognise it. Open the Cash Wallet section of the customer's panel and use the View Competition / View Order links on the transaction in Recent Transactions to trace its source, and cross-check the winner record in Winners and the order in Orders & Tickets.