Open-loop or closed-loop payments: which should your festival use?

You've got bars to run, traders to pay and a crowd arriving with bank cards, phones and very different ideas about how festival payments should work. One supplier wants everyone to preload a wristband. Another says ordinary contactless payments will do everything you need. Both can show you a fast tap on a reader.

Start with direct bank-card payments unless a prepaid event wallet solves a specific problem you can demonstrate. Open-loop payments let attendees use an accepted bank card or mobile wallet at the sale. Closed-loop payments put a separate event balance between the attendee and the purchase. That balance can be useful, but somebody has to manage it.

For a festival with repeated purchases across centrally managed bars and traders, a closed-loop system deserves a serious look. For independent traders already accepting cards, or an audience visiting for a short session, it may add work without improving service. Attendance alone doesn't settle the question. The decision depends on who sells, who receives the money and what happens when something goes wrong.

Understand what you're actually buying

In an open-loop setup, an attendee orders a drink and pays with a method your payment provider accepts. Their bank card or mobile wallet works through the payment system supporting that transaction. You don't require them to buy festival credit first. The seller receives the proceeds according to its payment agreement, after any charges and adjustments.

In the prepaid closed-loop setup we're comparing here, the attendee first loads money into an event wallet. A wristband, card or another identifier gives them access to that balance at participating outlets. A purchase deducts value from the wallet. Funding the wallet and buying the drink are separate events, even if the attendee experiences both as a tap.

That distinction matters because suppliers use these labels differently. A wristband linked to a bank card might trigger card payments without holding prepaid festival credit. A branded card may work more widely than your site. Ask the supplier to describe the actual movement of money before you compare proposals that happen to use the same category name.

The physical device doesn't answer the question either. A wristband used for admission isn't automatically a payment wallet, and a contactless reader doesn't prove that a system accepts bank cards. Our guide to RFID wristbands versus QR tickets covers the separate admission decision. Keep that specification separate when you ask for a payments quote.

EMVCo's explanation of EMV contactless chip payments describes the technology behind contactless cards and payment devices. It doesn't promise a particular festival queue time. Contactless tells you how a device communicates with a reader. Open or closed loop tells you something different about the payment arrangement. Neither label establishes the full service your team will operate.

Follow one purchase all the way through

The first thing you want to do is follow an ordinary attendee through your proposed system. They buy a ticket, arrive, order food and make another purchase later. Where do they have to register, collect something, load money or ask for help? Explain every required action in the order it happens. You'll quickly see which work the payment demonstration left out.

With direct card acceptance, they may already have everything they need to pay. The remaining questions include accepted cards, terminal placement, payment confirmation and what happens when a payment needs another step. With prepaid wallets, add the loading journey. Can somebody load online beforehand, at the venue, or both? Can they do it without downloading an app?

Now give that attendee an awkward but realistic problem. Their phone battery dies. They lose the wristband. They have enough money in their bank account but too little in the festival wallet for their next order. Ask the supplier to show each recovery process, including what staff can see and who is allowed to change a balance.

A closed-loop system can make repeated purchases convenient after loading. It can also move delay from the bar to a top-up point. Online top-ups may reduce that work, provided attendees can access them and the funding actually reaches the wallet. Measure the whole experience rather than celebrating a fast sale after somebody has already waited elsewhere to fund it.

Write down the public instructions while you're evaluating the supplier. If you can't explain how to pay in ordinary language, you haven't finished the buying decision. Your ticket confirmation, arrival information, bar signs and help team need to describe the same process. A late discovery that the food vendors accept a different method will become your problem at the gate.

Decide who sells and who gets paid

Imagine a festival where the organizer runs every bar and contracts food traders on an agreed revenue share. Central reporting may be important because the organizer needs consistent sales records across outlets. A shared wallet can support that arrangement if its reports, deductions and payments match the trader contracts. The technology should follow the agreement you want to operate.

Now imagine a different site. Each trader brings its own terminal, takes payments into its own account and pays the festival a fixed pitch fee. Direct card acceptance may already fit that arrangement. Requiring every trader to join your wallet introduces onboarding, equipment, reporting and payment obligations that previously belonged to each business. There needs to be a useful reason for changing them.

Ask whose name appears on the customer's payment record and receipt. Establish who is responsible for a disputed sale, a refund and an incorrect charge. If your organizer account receives all the money, don't assume the trader remains responsible for every consequence simply because its staff served the customer. Have the contract describe the arrangement your provider actually supports.

Agree the trader payment calculation before opening sales. Does the revenue share apply before or after tax, discounts, payment fees and refunds? Who funds a promotional offer? When can a trader inspect the records, challenge an adjustment and receive the amount owed? A central dashboard is helpful only when both parties can understand how its sales total becomes a payment.

This is also where you find exceptions. An artist's merchandise seller may have a separate agreement. A charity stall may need a different process. Your hospitality area may include products already covered by a package. List these cases before choosing a system so you can see whether a common wallet simplifies the event or creates avoidable reconciliation work.

Test connectivity rather than choosing by reputation

Neither payment label guarantees your bars will keep trading through an outage. A closed-loop supplier may support purchases on local equipment when the wider internet fails. That still leaves questions about local communications, power, balance updates and funding. A bank-card provider may support particular offline arrangements, with conditions and financial exposure that you need to understand before enabling them.

Ask the supplier to separate a failure of public mobile reception from a failure of your dedicated network. Then ask about a disconnected terminal, a failed local server and an interruption to power. These are different incidents. A reassuring answer about one doesn't establish that the others have been addressed, and a spare mobile connection doesn't fix every dependency.

For any offline operation, find out what the terminal accepts and what can be refused later. Who carries the loss if a transaction is subsequently rejected or a balance conflict appears? What limits stop an incident becoming a large loss? Ask for the settings in writing. Staff need an approved procedure rather than permission to keep accepting anything while service is down.

Closed-loop funding deserves its own test. Existing balances might remain spendable while a card-funded top-up cannot complete. Someone with an empty wallet would still be unable to buy. Ask how staff distinguish a pending top-up from a confirmed one and how the system avoids crediting it twice when the connection returns. Never treat a payment screenshot as proof that money arrived.

Rehearse these failures before the festival with the actual devices and configuration. Record who notices the problem, who can change operating mode and who confirms that transactions have recovered correctly. Your production lead should have a contact who can act during trading hours. A support inbox that responds after the headliner finishes doesn't meet that requirement.

Find the real cause of the queue

Here's the useful question for a sales demonstration. How long does the complete order take, including the awkward ones? Have your staff enter the menu, apply a legitimate discount, remove an item and take payment. Include a customer who needs to try another payment method. A perfect tap after a prepared order tells you very little about your busiest bar.

If drinks production is the slowest step, a faster payment won't automatically increase drinks served. You may need a shorter menu, different stock placement or more preparation capacity. If taking payment is holding up completed orders, changing the payment arrangement may help. Observe the work before assigning all the delay to the terminal, particularly when a supplier forecasts extra sales.

For closed-loop proposals, include wristband distribution and top-up demand in the rehearsal. For direct cards, include declines, additional cardholder checks and terminal recovery. Keep the same menu and staffing when comparing the two. Otherwise you're measuring different service arrangements and calling the difference a payment improvement. That makes the forecast look more precise than the evidence allows.

Use your own event observations to estimate the commercial effect. Record completed orders, abandoned queues and staff time, while noting other constraints. Don't turn a supplier's transaction speed into a promise about your total revenue. Our broader guide to event tap-to-pay explains the contactless setting; this purchasing decision still needs a test of your proposed operation.

A busy rehearsal also shows whether errors are easy to correct. A fast system that encourages staff to repeat uncertain transactions can create duplicates, complaints and a difficult closeout. Make the confirmation unmistakable and teach staff what to do when it is missing. The person serving drinks shouldn't have to guess whether the attendee has paid.

Compare charges across the same activity

Ask both suppliers to price the same event assumptions. State the event days, sales outlets, expected purchase value and number of purchases. For the wallet proposal, state the expected number and value of top-ups separately. You may pay a bank-card processing charge when money enters the wallet, plus other charges when it is spent or returned.

That is why a low fee on wallet purchases doesn't establish the cheaper arrangement. Equally, charging a card for every small purchase may cost more than funding a wallet less frequently under a particular quote. Fixed charges, percentage charges and minimum commitments change the result. Use the actual proposed rates and charging points rather than a generic claim about which model saves money.

Include equipment hire, software, bands, configuration, freight, training, onsite support and returns. Then identify which costs you would incur anyway for admission or an existing bar operation. Count only a genuine replacement as a saving. If you still need the entrance team, its wages haven't disappeared just because the wristband also supports payments.

Separate payment costs from the cost of running the wallet. Somebody needs to handle loading questions, replacements and unresolved balances, even when the provider automates much of the process. Ask what its service includes before adding manual tasks to your staffing plan. You should know which exceptions remain your responsibility and what happens if support demand exceeds the included allowance.

Compare totals at lower sales as well as your expected result. Fixed equipment and support commitments may remain payable even when rain reduces attendance. Don't make a proposal affordable by assuming an unexplained increase in spending. A payment system should survive a realistic trading result before you credit it with improvements that haven't happened yet.

Keep wallet funding separate from event income

Here's a fictional example in US dollars to make the distinction clear. These are invented amounts, not festival benchmarks, supplier rates or Loopyah charges. Attendees load $100,000 into event wallets. They spend $80,000 at participating outlets. Before other adjustments, $20,000 of loaded value remains unspent. Calling all $100,000 sales would misrepresent what customers actually bought.

The $80,000 of purchases isn't automatically the organizer's money either. Part may belong to food traders under their agreements. Part may cover tax and other obligations. Fees and refunds affect the amount finally available. Your reporting needs to distinguish funding, purchases, remaining balances and the money owed to each seller. Ask to see those records in the demonstration.

When the supplier talks about receiving money earlier, ask when you can actually access it and under what conditions. A provider may retain amounts, deduct charges or control payments according to its agreement. Having a balance visible in a dashboard is different from having unrestricted money in your bank account. Confirm the dates before relying on it to pay production bills.

Use your event cash-flow forecast to show payment dates alongside obligations. Keep amounts that may need to be returned or paid to traders identifiable. An early inflow should not conceal a later shortfall. This matters when the festival has already committed deposits and is tempted to treat every incoming payment as money available for the next supplier invoice.

Agree the records your finance team will receive after trading stops. They should be able to follow a correction or refund through the relevant reports without asking staff to reconstruct it from messages. If the supplier can demonstrate this before the contract, you can judge the workload. If it can't, don't assume the final export will solve it.

Check the obligations behind a prepaid wallet

A wallet restricted to your festival doesn't automatically sit outside payment regulation. In the UK, the Financial Conduct Authority explains the limited network exclusion, including conditions and notification obligations. It also directs businesses to seek independent advice if they are unsure whether their activities constitute regulated payment services. The category name alone isn't a legal conclusion.

Ask the supplier to identify the legal entities providing the service, holding funds and contracting with attendees. Have it explain the basis on which the proposed arrangement operates in your event's jurisdiction. A familiar brand name on the wristband is not an answer to those questions. You need the explanation for your actual seller and funding arrangement.

Don't transplant a UK explanation into a US or Australian event. Local requirements and the commercial structure can change the answer. Have the appropriate adviser review the arrangement and any claims about how attendee money is protected. Focus the review on who owes what to whom if the event or provider cannot complete its obligations.

You also need a clear route for remaining balances and disputes before attendees load money. Confirm refund deadlines before choosing your payment provider. For choosing the system, establish whether it can support the approach you intend to offer, who performs the work and what records prove completion. A policy your technology cannot carry out will create problems after the festival.

Ask what happens when you stop working with the supplier. Can attendees still obtain help, can your team access the necessary records and who completes outstanding payments? The end of equipment hire should not end responsibility for unresolved balances. Agree how long the relevant services remain available and how any unfinished work transfers before you sign.

Decide what information you actually need

Closed-loop suppliers often emphasise connecting purchases to an event account. That can help answer a defined question, such as which package holders used an included benefit. It does not mean every purchase should become an identifiable marketing record. Begin with the decision you need to make and ask whether aggregate sales information would answer it adequately.

Open-loop payments also generate useful operational information. Depending on the product and permissions, sellers may obtain item, outlet and transaction reports. Don't accept a comparison that treats direct cards as having no reporting at all. Equally, don't assume a standard card transaction tells you which ticket holder purchased something. Ask for the fields and permissions each proposed system actually provides.

EMVCo explains how payment tokenisation replaces a card's account number with a payment token. That security mechanism doesn't establish an attendee's identity or grant marketing permission. A payment identifier, a ticket record and permission to contact somebody are different things. Have the supplier demonstrate any proposed connection rather than treating them as interchangeable.

For UK events, the Information Commissioner's Office explains collecting only necessary personal data. Its page notes that guidance is under review following legislative changes. For the purchasing decision, ask what information each party collects, why it needs it and how long it retains it. Your privacy arrangements should match the service attendees actually use.

Keep useful reporting requirements concrete. You might need sales by outlet to calculate trader payments, failed top-ups to resolve support requests and totals by product to plan stock. Each has a clear operational purpose. Ask for an example export and test access restrictions. Extra personal information is not automatically more useful, especially if nobody has agreed what to do with it.

Make exceptions work without embarrassing attendees

Direct cards are familiar to many people, but that doesn't mean every attendee can use your accepted methods. A prepaid band may be convenient once issued, but some people will need another way to carry or present it. Design the exception process alongside the standard one. Don't leave frontline staff to negotiate access to food and drink at a busy counter.

Check the requirements that apply where your event operates, including any rules about accepting cash. If you provide cash-to-wallet loading or another alternative, explain where it happens and whether any fees apply. Test what someone can do without a smartphone or bank card. A process that requires an online account at every step may exclude people you intended to accommodate.

Keep promotional credit distinct from money an attendee paid into the wallet. Included hospitality allowances, staff meals and sponsor offers may each need different permissions and treatment. Staff should understand which balance is being used and what happens when it runs out. Otherwise a customer can reasonably think they have paid value remaining while the seller sees a different restriction.

Security responsibilities also remain relevant when a provider handles the processing. The PCI Security Standards Council explains that outsourcing payment processing does not remove every merchant responsibility. Ask your provider and payment partner to specify the requirements for your setup. Train staff on the approved devices and support process rather than collecting card details to solve a problem themselves.

Have the help team rehearse a lost credential, an incorrect deduction and a funding dispute. Set the evidence needed for each correction and restrict who can authorize it. That protects attendees and your staff. Good support should make a legitimate correction possible without allowing somebody to obtain the same balance twice through different help desks.

Ask for a written operating proposal

Ask for more than a price and a list of features. Your proposal should explain which outlets participate, which equipment each receives and who configures the menu. It should name the person responsible for correcting an incorrect price during the event. If a trader changes its offer after testing, somebody needs to approve and distribute that change before it reaches customers.

Specify the support hours against your full trading schedule. Camping arrivals, late bars and the final morning can fall outside the main programme. A wallet that works at the evening bars may still need support when a breakfast trader opens. Confirm whether the same team handles equipment faults and payment problems, and how staff reach the right person without transferring the attendee repeatedly.

Get changes to the event priced before you need them. Ask what happens if another trader joins, an outlet moves or a device fails beyond repair. Find out whether spare equipment is configured and ready to use. An unopened reader in the production office is only useful if someone can activate it without interrupting the rest of the payment operation.

Your agreement should also describe delivery, training and the point at which you accept the system as ready. Allow time to correct problems found in rehearsal. If the provider arrives immediately before gates open, your practical options for fixing a failed setup become limited. Match the preparation schedule to the dependencies rather than assuming a familiar payment method needs no testing.

A useful final test is to hand the instructions to someone who hasn't attended the supplier meetings. Ask them to explain how an attendee pays, how a trader receives money and where either person goes for help. If they need you to translate the proposal, improve it before handing the process to temporary staff. They will have less time to learn it than your planning team.

Keep the accepted proposal with your production documents and identify who can approve a change. A decision made at a bar during a rush can affect money owed elsewhere, particularly when staff offer credit or bypass the normal recovery process. Give supervisors a clear way to escalate those situations. Agreeing that authority beforehand helps the team protect service without making financial promises nobody has approved.

You should be able to hand the document to finance and the event manager without either discovering a different version of the deal.

Review the result before the next edition

Decide what you will measure before the festival so the review can answer why you chose the system. Keep service observations by outlet and time, not just a single event total. A payment setup might work well at the main bar while a distant food area struggles. That difference can reveal a local problem rather than a reason to replace the entire arrangement.

Track help requests by the problem people brought you. Loading questions, missing balances, lost bands, card declines and incorrect prices need different fixes. Your provider may already report these, so ask for its supported records before creating another manual log. Add staff observations where they explain something the transaction data cannot, such as confusing signs or a queue blocking the route to assistance.

Compare the final bill with the signed quote and explain each change. Higher sales may legitimately increase processing charges. Additional support might reflect an agreed extension or a problem that should have been included. You need to know which before planning another edition. Otherwise an apparently successful implementation can quietly establish a more expensive recurring cost than you approved.

Check the trader experience too. Ask whether sellers could see the information they needed, whether adjustments were understandable and whether payments arrived as agreed. A system that simplifies the organizer's reporting but creates uncertainty for every trader may make recruitment harder next year. Resolve a disputed calculation while the records and people involved are still available.

Finally, separate measured improvements from impressions. Staff may prefer the new devices even when total service speed is unchanged. Attendees may appreciate familiar card payments even when the processing bill is higher. Those are useful findings, but they support different decisions. Keep them visible alongside the financial result so you can change the right part of the operation next time.

Choose a model your festival can explain and operate

Open-loop payments are a sensible starting point when attendees can use accepted payment methods directly, traders have suitable arrangements and you don't need a separate event balance. Choose the provider by its actual reporting, support, connectivity plan and charges. Familiar payments still require preparation, but you avoid introducing a wallet that has no clear job to do.

Closed-loop payments become more persuasive when a common balance solves repeated purchasing or centrally managed entitlements across outlets. The case improves when the supplier demonstrates the exact operating benefit and takes responsibility for the services it promises. You still need an affordable quote, a workable loading journey and clear treatment of money owed after trading stops.

A mixed setup can be appropriate if different outlets genuinely need different arrangements. It also gives you more to explain and reconcile. Specify where each method works and how exceptions are handled. Don't buy a combined package merely because it sounds flexible; ask whether the second method solves enough real problems to justify operating both.

Before signing, ask the supplier to run your event scenario with your operations lead, finance lead and a trader representative present. Follow a purchase, a failed top-up, a disconnected terminal and a refund into the final reports. Then compare the quote with what the demonstration actually proved. Choose the arrangement your team can run and your attendees can understand.