Should cashless refunds be automatic or requested by attendees?

Your festival has finished, the traders are packing down, and attendees still have money on their wristbands. You know how much remains. You may even know which payments funded it. So why are you asking everyone to find a form and request their own money back?

For prepaid event wallets, automatic refunds are usually the better starting point when the system can calculate the refundable amount and return it through a verified payment route. Use attendee requests where you genuinely need information or a decision from the person entitled to the balance. A mixed approach often works best, with straightforward balances returned automatically and exceptions handled separately.

That recommendation needs a little care. Automatic doesn't mean instant, and a wallet balance doesn't always belong to the person who bought the ticket. A refund can involve several top-ups, different payers, cash and promotional credit. Your job is to choose a process your provider can complete accurately, then compare its real operating cost with the effort you're asking attendees to make.

First, make sure you're comparing the same refund

This article concerns unused money loaded into a prepaid event wallet. Someone adds funds, pays for drinks or merchandise, and leaves with an eligible balance. Returning that balance is different from refunding admission because an event was cancelled or an attendee couldn't come.

The distinction changes the decision. With a ticket refund, you may need to assess whether the request meets your rules. With an unused wallet balance, the system may already have everything needed to calculate what can be returned. Making someone request it then adds a step without necessarily adding useful information.

If you're setting ticket cancellation rules, our event refund policy guide covers that separate problem. Keep the two processes distinct in your support instructions too. An attendee asking about their wristband shouldn't receive an answer about the deadline for cancelling an admission ticket.

Also separate initiating a refund from approving a request. A provider may describe a service as automated because it approves eligible applications without staff intervention. The attendee still has to apply. Ask what actually starts the payment and whether a person who does nothing will receive their remaining eligible money.

Finally, check whether you need a prepaid wallet at all. Taking a bank-card payment for each purchase generally avoids a leftover event balance. Our guide to event tap-to-pay explains that wider payment choice. Once you've chosen a wallet, however, you need to budget for returning unused funds as part of running it.

Start with the route back to the payer

The first thing you want to do is ask your provider to show a refund against an actual top-up record in its demonstration. Follow the money through the example. Where did it enter, which wallet received it, what remains refundable, and where will the refund go?

For a simple card-funded wallet, returning eligible funds against the original payment can avoid collecting bank details afterwards. Stripe's refund destination documentation, for example, says its refunds return to the original payment method. That is a processor rule to account for when designing your operation, rather than permission to send money to any account an attendee supplies.

A wallet makes the relationship more complicated because its final balance may come from several payments. Suppose someone tops up with their card, a friend adds money later, and a parent originally bought the admission ticket. Those are different relationships. Refunding the ticket buyer because their email is easiest to find could send the money to the wrong person.

Ask how the provider allocates spending and remaining refundable value across those funding records. Does it refund the most recent eligible top-up first, apply another agreed allocation, or require a manual decision? Whatever method it supports needs to match the applicable terms and rights. Staff shouldn't invent an allocation after complaints arrive.

Cash loads need their own route because there is no original card transaction to reverse. Promotional credit may have different terms from purchased value. A wallet containing both needs records that distinguish them. Before choosing automatic refunds, establish exactly which balances the provider can return without asking for more information.

Where automatic refunds make the strongest case

Automatic refunds work well when the provider has reliable funding records, the eligible balance is clear, and the return destination is already established. In that situation, the attendee has no useful administrative task to perform. The system can start the return after your agreed closing checks.

That removes several ways a valid refund can go unfinished. Someone might miss the email, forget the password they created during the festival, or assume their small balance isn't worth another task. Someone who misses your message may never start the refund, even when payment records are correct. A balance still needs someone to act.

There's an operational benefit too. If a reliable process returns the eligible amount and sends a useful status message, your team can concentrate on exceptions. They spend less time explaining where the form is or confirming that someone has submitted it. Whether this saves money at your event depends on provider charges and the support workload you actually avoid.

Automatic processing also gives you a clearer starting population for checking completion. You can compare eligible balances with initiated and completed returns, then investigate what's missing. You don't have to treat the absence of a request as proof that the balance holder understood the process or chose to leave the money behind.

But the result still depends on execution. An automatic batch based on incomplete transactions can return the wrong amount. A message saying money has arrived when you've only submitted the payment creates another support problem. Choose automation because the records and follow-up support it, and make those requirements part of the supplier discussion.

When an attendee request serves a real purpose

A request is useful when you need information you don't already have. An anonymous cash-funded wallet may need a verified claim and an approved payout destination. A replacement wristband might need investigation before you can establish the remaining balance. Someone disputing a purchase needs a correction process before you decide the final refundable amount.

In those cases, explain why an action is necessary. An attendee can understand that you need to establish which wallet they held. They will have a harder time understanding why you need them to retype information your system already holds. Ask the provider which fields genuinely change the refund decision or make payment possible.

Attendee choice can also matter where lawful alternatives exist, such as requesting a return instead of choosing an optional donation. Keep those decisions explicit. Silence, a forgotten form, or an unchecked email doesn't tell you that someone wanted to donate. Don't build the financial case around treating inaction as a positive choice.

A requested process doesn't have to mean a staff member approves every ordinary case. You may be able to verify the wallet and initiate eligible returns automatically after submission. That can reduce your workload while retaining a necessary identification step. Make sure you describe the remaining attendee action accurately before people load funds.

If the supplier offers only requested refunds, evaluate the whole process rather than rejecting the option on its label. A short, accessible claim with helpful reminders and responsive support can be workable. The important question is whether each step solves a genuine problem and whether eligible people can complete it without unreasonable difficulty.

Use a mixed approach when funding methods differ

You don't have to force every wallet through the same route. Ask whether your provider can automatically process balances with verified return details while directing unresolved cases into an assisted process. This is often a more practical choice than making everyone submit a claim because some wallets need investigation.

The categories must be clear before launch. You might have card-funded wallets that qualify for automatic return, cash-funded wallets that require a claim, and disputed balances that need review. These are examples to test with the supplier, not a universal prescription. Its actual payment arrangements may require a different division.

Be particularly careful with partially eligible wallets. A person may have both card and cash top-ups, or money purchased alongside a promotional allocation. If the system can return only part automatically, tell the attendee which part it has processed and what remains. A generic completion email can wrongly suggest that the whole wallet has been settled.

The mixed approach adds reporting work, so insist on a complete view. Your finance lead needs to see total eligible value, the portion returned, the portion awaiting action and unresolved differences. The support team needs to identify an individual wallet's position without assembling fragments from several exports or asking the attendee to repeat their history.

Publish instructions that help someone identify their route. Avoid saying refunds are automatic at the top of the page and revealing a cash-load exception only inside a long answer below. Explain the common case clearly, then put the relevant exceptions where affected people will see them before they add money.

Compare costs without counting owed money as profit

This is where the decision can go wrong. One proposal appears cheaper because fewer attendees claim. Another sends more money back and therefore seems more expensive. But returning eligible customer principal is different from paying an additional operating expense. Compare the cost of administering returns separately from the money being returned.

Start with the supplier's charges. Ask whether it bills per wallet, per refund transaction, per attempted payment or through a fixed service fee. A wallet funded by several transactions may need several returns. Confirm whether failed attempts, retries and manual investigations attract charges, and whether the quote includes support after the event.

Then add your own work. Include preparation, customer messages, investigating mismatches, checking payments and handling complaints. Use your team's expected time and actual employment costs. Don't price every support request as free because someone on payroll can answer it. That work displaces other tasks after the event, even when it doesn't create an extra invoice.

Here is a fictional example in US dollars, not a benchmark or supplier quote. Both options concern $10,000 of eligible remaining value. Automatic processing costs $250 in provider charges and $150 in staff time. Requested processing costs $180 in provider charges and $450 in staff time. The operating totals are $400 and $630 respectively.

The requested option therefore costs $230 more to administer in this example. If only $8,000 is claimed initially, the remaining $2,000 does not become a saving in that comparison. Its ownership and treatment still need resolving. Keep it visible as outstanding value until your finance and legal advisers determine the correct treatment.

Check the assumptions behind the cheaper quote

The example is deliberately simple. Your own comparison should show the assumptions that could change the result. A low request rate may reduce processing transactions while increasing reminder work or complaints later. Automatic returns may involve more payment attempts but fewer questions about how to start. Ask the supplier to price both against the same eligible population.

Request a scenario with repeated top-ups, not just one payment per wallet. If someone makes several small loads, a charge per underlying return can behave differently from a charge per attendee. Get the provider to show its calculation in money, including any minimum charge, rather than relying on a percentage in the headline quote.

Check when you must fund the returns too. The cash may have reached an organizer account while the payment provider requires funds somewhere else to execute refunds. Agree who moves it, who checks availability and what happens if the balance is insufficient. Our event budget guide helps separate these commitments from money you can spend elsewhere.

Do not use a speculative lifetime-value number to make the preferred option look profitable. Easier refunds may support a better experience, but that doesn't establish a particular increase in repeat ticket sales. You can record complaints and later purchasing behaviour, while acknowledging that lineup, price and many other factors affect whether people return.

Where the options remain close, choose the process your team can operate consistently and explain honestly. A modest difference in fees may be worth paying for fewer unresolved balances. If the difference is substantial, investigate what causes it before shifting the work to attendees. You may be comparing different service packages rather than different refund methods.

Agree the rules before choosing the software setting

The payment method doesn't decide whether your refund terms are lawful. Your location, the wallet arrangement, the provider's role and applicable consumer rules matter. Have the relevant terms reviewed before announcing deadlines, deductions or forfeiture. A supplier's ability to configure a setting doesn't establish that you should use it.

For a UK operation, the Financial Conduct Authority's limited network exclusion guidance explains that some restricted payment arrangements have specific conditions and notification requirements. Don't assume that limiting spending to a festival settles the regulatory position. Ask the provider to explain its role and get advice where the arrangement is unclear.

That review should cover what happens to outstanding funds after the advertised claim period. Your operational deadline for handling routine requests isn't automatically the end of every legal obligation. Finance needs a documented basis for the treatment of unreturned balances, including any relevant unclaimed-property rules, rather than a habit inherited from last year's event.

Fees deserve the same scrutiny. Compare a supplier charging your business to perform refunds with you deducting a fee from the attendee's money. Those are different decisions. If a deduction is permitted, the public terms still need to explain it before loading, and your calculation needs to match what was disclosed.

You can then configure the actual process. Check that your public policy describes the refund process you've selected and tested. A policy promising automatic returns fails if the setup requires a claim. A request window is also misleading if the provider stops accepting submissions earlier than your published deadline.

Close trading before calculating the return

The last bar closing doesn't prove every transaction has reached the central records. Ask your provider how offline sales, late uploads, reversals and unresolved top-ups affect the final balance. You need a defined reconciliation point, meaning the team has checked the records agree, before it approves a refund batch.

Appoint someone to confirm that trading data is complete and someone to approve the amount to return. In a small operation those responsibilities may involve the same people, but the checks should still be explicit. Record when the balance was calculated so a later adjustment doesn't look like an unexplained change to the attendee.

Decide what happens if an outlet reconnects after refunds have started. The answer should come from the provider's supported process and your agreed terms. Staff should not improvise another charge or silently reduce a different payment. Test the situation before the event, when you can still change the configuration or support instructions.

This preparation matters for requested refunds as well. A form doesn't fix an incorrect balance. If attendees submit claims before the records are complete, you may simply create a queue of applications that need recalculating. Explain when the final amount will be available and what happens if someone believes a purchase was recorded incorrectly.

Keep enough capacity after the event to finish these checks. The person who understands the setup shouldn't disappear as soon as the equipment is collected. Agree named contacts, access to records and support availability through the expected completion period, including the route for investigating exceptions discovered afterwards.

Treat failed payments as unfinished work

A refund instruction is not the same as a completed return. Your reports need to distinguish money awaiting submission, processing, successfully returned and requiring attention. Ask what the provider's status labels mean and which evidence your team can use when an attendee says their money hasn't arrived.

Stripe's refund testing documentation notes that refunds are asynchronous and can appear successful before failing later. That is a practical reason to monitor results after the initial batch. Don't mark every submitted instruction as finished or close support while changes can still arrive from the payment system.

Build a follow-up route for failures. Identify who checks the report, who contacts the affected person and how a permitted alternative payment will be arranged. Before sending money another way, confirm the original return hasn't completed and that your provider's process allows the alternative. Otherwise your attempt to resolve one complaint can create a duplicate payment.

Expired cards don't automatically mean someone must send you new bank details. The original issuer may handle the return through its replacement-card process. Have support check the payment provider's guidance for the actual transaction before requesting sensitive information or promising another route. The attendee needs an accurate next step based on their case.

For a disputed wallet, preserve the purchase history and the explanation for any adjustment. Keep that review connected to the refund record so staff can see what has already been returned. An attendee shouldn't receive a second full refund merely because the complaint reached a different inbox or team member.

Make any necessary request easy to finish

When an attendee really does need to act, start with a short form and a clear explanation. Show the event name, what the request covers and the information needed to find the wallet. If the system already displays a verified balance, don't ask someone to calculate it again from memory.

The World Wide Web Consortium's accessible forms tutorial recommends clear labels, instructions and notifications that explain completion or errors. Apply that to your actual claim route. Test keyboard access, a small screen and mistakes in required fields. A form that works for your operations manager on a laptop may still fail for another attendee.

Minimise the information you collect. The UK's Information Commissioner's Office explains the data minimisation principle as collecting personal data that is adequate, relevant and limited to what is necessary. Ask what each field accomplishes, especially when considering identity documents or a new bank destination.

Use an approved secure process for any payment details that are genuinely needed. Don't direct people to send full card numbers or sensitive documents to a general event inbox. Decide who may view the information and how long it must remain available, consistent with your obligations and the provider's process.

Send confirmation when the request is received and distinguish it from payment completion. If someone must correct a detail, explain what went wrong and how to fix it without starting again unnecessarily. Provide an assisted route for people who cannot use the form, and tell support how to handle those requests consistently.

Test both methods before you commit

Ask the supplier to demonstrate your difficult cases with the people who will handle them present. Include a card-funded wallet, repeated top-ups, a cash load, promotional value, a replaced wristband and a failed return. Also test what happens when a support agent tries to process a case that's already in progress.

Follow each example through the attendee message and final financial record. You should be able to identify the refundable amount, the destination or required action, the payment status and any charge to your business. If the demonstration stops at pressing a refund button, you haven't seen enough to judge completion or workload.

Decide now which unresolved cases would prevent launch. An unclear allocation across different payers, missing refund records or no supported route for cash-loaded balances can require changing the setup. Capture those decisions before approving the supplier, rather than leaving the support team to discover them after people have paid.

Measure completion by money and by people

After the event, look at both the share of eligible value returned and the share of eligible wallets resolved. Those measures answer different questions. Returning the largest balances can produce an impressive money total while leaving many people with smaller amounts waiting. Counting completed wallets alone can hide a large unresolved payment.

Use the original eligible population as the starting point and record later adjustments separately. Otherwise, removing difficult cases from the report can improve the completion rate without returning any more money. Where a balance is genuinely ineligible, keep the reason available so finance and support can explain the decision rather than silently deleting the case.

Review outstanding cases by cause. Missing payout information, failed payments, purchase disputes and people who haven't submitted a necessary claim require different action. A general reminder won't fix a failed bank return. Equally, asking the supplier to retry payments won't help someone who needs an accessible way to establish ownership of a cash-funded wallet.

Add the age of unresolved cases to the review. Your team should know which are waiting within the expected processing period and which have exceeded the promised update time. Agree when an unresolved case goes to a named decision-maker, especially where the normal support team cannot approve the required correction or alternative payment.

If you change methods between editions, compare the workload and completion results with context. A different audience, more cash loads or a new provider can change the result independently of automation. Keep the comparison useful by documenting those differences and avoid attributing every change in support volume to the refund setting alone.

Agree who supports attendees after the supplier leaves

Your event brand will receive questions even when a specialist provider handles the payment. Before signing, decide which enquiries your team answers and which the provider owns. Ask how a case is transferred, what information travels with it and who tells the attendee when a decision has been made.

Pay attention to access after the event. If a temporary staff account expires or equipment is returned, can the responsible person still inspect the relevant transaction history? Arrange appropriate continued access through the supported system. Sending everyone a broad spreadsheet of personal information is a poor substitute for giving the right people access to the records they need.

Include the cost and duration of this support in the method comparison. Requested refunds may create work over a longer period, while automatic refunds can generate concentrated exception work after the batch. Neither pattern is inherently unmanageable, but you need people available when the work arrives rather than merely enough hours in the original event budget.

When ownership changes, make the handover specific. List unresolved cases, their current position and the next action already promised. The person taking over should be able to continue the conversation without asking the attendee to prove everything again. That matters particularly when a provider's onsite contact is replaced by a general support team.

Keep ticket refunds separate in your customer messages

Attendees may reasonably expect one event brand to explain all their payments. Your internal separation between ticketing and onsite wallets won't help them unless your messages identify which money is being returned. Use the wallet reference where appropriate and avoid saying the whole booking has been refunded when only an unused balance is involved.

Loopyah's ticket refund instructions describe configured ticket refund eligibility and customer requests. Direct admission questions to your ticketing support route and unused-balance questions to the wallet team. Name both routes in confirmation messages so attendees can find the right help. Give each team the other's escalation contact for enquiries involving both payment types.

Explain the method before people load money, then repeat the relevant instruction when trading closes. For automatic returns, say when you expect to initiate them and how people will hear about exceptions. For requested returns, make the action available through a reliable event communication route. Don't rely entirely on someone remembering a notice they saw beside a busy top-up station.

Check that your confirmation message reaches the person who can act. A group booking contact may receive ticket information while another person controls the wallet. The provider should explain how it identifies the appropriate contact and how someone updates incorrect details through an approved process. An email delivered successfully to the wrong person hasn't solved the communication problem.

Keep promotional messages separate from essential refund instructions. Someone trying to recover a remaining balance needs to find the amount, status and next step without reading an invitation to next year's festival first. If you offer an optional donation or future credit, explain it clearly and preserve the ordinary return route. The useful test is whether an attendee can understand what happens to their money after reading the message once.

Before launch, choose the automatic route wherever your provider can correctly identify and return eligible money, then document the exceptions that need attendee action. Put named people in charge of completing those exceptions. Your final test is whether you can explain, for every remaining eligible balance, what happens next and who will make it happen.