How to keep festival payments working when connectivity fails

Your bars are busy, a food trader's terminal stops responding, and someone radios to ask whether they should keep serving. You can feel how quickly the problem could spread. The queue is growing while your team tries to work out whether the last customer actually paid.

Keeping festival payments working through an outage starts before the festival. You need a payment system that explicitly supports your intended offline operation, limits on what you will accept while disconnected, and a tested way to recover the records afterwards. A second connection helps, but it doesn't answer those questions.

The important distinction is between recording a purchase and collecting the money. Some systems can do the first while offline and attempt the second later. Others can spend an existing festival wallet balance locally but cannot load fresh money into it. Your plan needs to explain which situation applies at each sales point.

Here's how to make that plan useful for the person running a bar, the person responsible for the network, and the person who has to pay your traders after everyone goes home.

Ask what the supplier means by offline

Start with a demonstration of your proposed setup. Use the actual payment application, reader model and account configuration you intend to hire. Ask the supplier to disconnect the relevant connection, make a purchase, then show where that purchase is recorded and what still has to happen before the seller receives money.

In its August 2024 research on offline payment reliability, the Federal Reserve distinguishes systems that complete work without connectivity from arrangements that still need a later connection to authorize or settle payments. That distinction matters at your bar. A recorded transaction can still represent money you haven't successfully collected.

Don't accept a demonstration on different equipment as proof. A provider might support offline collection on one reader and integration, while your chosen application doesn't expose it. A terminal's ability to take contactless payments also tells you nothing definite about how it behaves without a connection. Get confirmation for the full arrangement you are buying.

Ask the supplier to describe the screen your team will see when a sale is accepted offline, refused, or left uncertain. Then ask what customers see. Staff need to recognize each state without decoding an unfamiliar message in front of a queue. Put the supplier's own instructions into your operating brief where they affect the sale.

Separate the failures you are preparing for

A failure of public mobile reception is different from losing your event's internet connection. Your private local network might still work when its connection to the outside world fails. Equally, the internet connection might be healthy while one bar loses its local wireless coverage. Those incidents can leave different payment functions available.

List the dependencies with your network and payment suppliers together. Include the connection between the sales application and its reader, any local server, the site's internet service, and the provider's remote service. Add electrical power. You don't need to design the technology yourself, but someone must explain which parts each transaction requires.

Consider what a spare connection actually replaces. Another mobile router may help with a failed internet service. It won't necessarily fix a broken sales application, an unavailable payment provider, or a terminal that cannot communicate with its local controller. Ask both suppliers to demonstrate the proposed switch rather than describing every interruption as a Wi-Fi problem.

Keep this work connected to your broader event contingency plan. If an electrical incident stops refrigeration or makes an area unsafe, the decision about continuing sales belongs within that wider response. Payment continuity does not authorize a trader to keep operating when the event team has suspended service for another reason.

Check bank-card collection and wallet spending separately

If attendees pay directly with bank cards, find out whether your contracted system can collect a transaction while disconnected and seek authorization later. Ask which payment methods, devices, countries and transaction types qualify. Get the applicable restrictions from the provider. Don't copy a limit from another festival or assume a phone and a dedicated terminal behave identically.

For example, Stripe's offline Terminal documentation explains that supported setups can store payments locally and forward them when connectivity returns. It also distinguishes supported readers and payment methods. That is a reason to check your exact integration with your supplier, rather than treating offline acceptance as a standard property of every card reader.

If you use prepaid festival wallets, ask a different question. Where does the available balance live, and what lets disconnected sales points agree on spending? Ask the supplier to demonstrate successive purchases at separate outlets during the outage. Have it explain how the system prevents the same balance being spent twice and what happens when devices reconnect.

Funding needs its own answer. Existing credit might remain usable while a bank-card top-up cannot complete. Someone arriving with an empty wallet could still be unable to buy anything. Document how staff distinguish confirmed funding from a pending attempt. A customer's screenshot should never become an improvised instruction to increase their balance.

Agree who carries the loss before enabling offline sales

Keeping the queue moving can mean accepting a financial risk. If goods leave the counter before a bank approves the payment, somebody may lose money when the later attempt fails. Establish who that somebody is under your actual contracts. The answer may differ between organizer-operated bars and independent traders using their own merchant accounts.

Ask the provider to explain losses from declined transactions, expired upload windows, lost equipment and missing records. Then ask the trader what its agreement with the festival says. Don't promise that the organizer will cover everything simply because you supplied the network. Don't assume a trader has accepted every risk because its staff used the terminal.

Write a clear operating decision for each arrangement. A trader collecting into its own account may have its own authorized limits. A central festival wallet may need a shared rule across every outlet. Tell the site team which decisions they can make and which require the merchant or payment provider's approval before service continues.

Bring finance into this conversation while you can still change the contract. A small amount of controlled uncertainty may be commercially reasonable during a short interruption. An open-ended promise to reimburse every failed sale is a different commitment. Have the person responsible for the budget approve the exposure they can actually understand and monitor.

Set limits that work across the whole site

A per-purchase cap limits one transaction. It doesn't limit the total amount waiting to be collected across a festival. Ask the supplier which controls are available for individual purchases, each device, each merchant account and the entire event. Find out whether those controls continue working when devices cannot exchange updates.

Here's a fictional example in US dollars, purely to explain the arithmetic. Suppose ten disconnected terminals each hold $600 of unforwarded purchases. The site has $6,000 awaiting processing, even if no individual purchase exceeded $30. That $6,000 is pending exposure, not a forecast loss. The eventual outcome depends on what successfully processes and what remains unresolved.

If your team can tolerate only $3,000 awaiting processing, allowing those devices to accumulate $600 each would contradict that decision. Agree a lower allocation, fewer active devices, earlier reconnection, or a different service arrangement. Ask the supplier how to enforce the chosen rule. A central dashboard may not have current totals from disconnected equipment.

Include elapsed time and the age of the oldest pending transaction. Ask how staff receive a warning before a provider deadline or approved limit is reached. The action must be clear when the warning appears. Supervisors should know whether to stop offline acceptance, move sales to a working connection, or call the authorized decision maker.

Budget for the interruption you can afford to handle

Ask your bar manager which trading periods matter most. Losing payments during setup is inconvenient. Losing them just after a headline set can affect a much larger share of the night's sales. Use your own programme and previous trading records to identify those periods, then check what support and spare equipment the supplier provides at those times.

Compare improvements against that actual problem. A stronger dedicated connection may reduce some interruptions. Extra charged terminals may help replace failed hardware. Onsite support may shorten diagnosis. These purchases solve different problems, so ask what each would have changed in your rehearsal. A more expensive package should have a specific operational benefit you can explain to finance.

Include the cost of recovery in the quote. Who stays after the bars close to reconnect equipment, investigate failed forwarding and produce the reports? Does the hire period allow enough time to resolve pending transactions? You don't want a supplier collecting the readers while your finance team is still waiting for evidence that their records have reached the payment service.

Power belongs in that budget too. Ask production to identify what keeps the payment equipment and the network operating if the normal supply fails. Our guide to outdoor event power and water covers the wider production brief. Have the qualified supplier specify the electrical arrangement, including charging and any backup, instead of leaving bar staff to improvise extension leads.

Prepare the devices while everything still works

Offline capability can depend on preparation that requires a connection. Ask your supplier which settings, logins, downloads, security checks and device assignments must be completed before disconnection. Have it confirm the deadlines and verify that every hired device is ready. A spare in a sealed box may be physically present but unable to take a sale.

Keep an equipment register that names each device, its assigned outlet, its responsible supervisor and the account it uses. Record the supplier's identifying reference so support can find the right equipment. Make these details available without relying on the failing application. Your team should be able to report a problem without searching through packaging at the bar.

Check menus, prices, taxes, discounts and the products available during an interruption. Ask which changes reach disconnected equipment and which must wait. If an item sells out, staff still need a reliable way to stop selling it. Don't let outdated menus turn a payment incident into refunds for orders the kitchen cannot fulfill.

Plan charged replacements and safe access to charging equipment. Confirm how pending records behave during a battery change, restart or device replacement before staff try any of those actions. The correct process depends on where the provider stores the transactions. Teach the approved steps and mark actions that require support, particularly resets or returning hired equipment.

Protect the records as carefully as the takings

A terminal holding unsent transactions needs an accountable handover. Give it to a named supervisor, record where it goes, and follow the provider's recovery instructions. Don't let it disappear into a general returns crate because the screen no longer looks busy. The sale may still depend on the records stored on that particular device.

Never respond to a failed terminal by asking staff to photograph cards, collect security codes, or copy full payment details into messages. Your outage procedure should use only the payment methods and collection processes the provider has approved. A handwritten record of an order is not permission to create your own card-processing arrangement.

The PCI Security Standards Council's guidance on card verification codes says those codes cannot be retained after authorization, even when encrypted, and customer permission doesn't override that rule. For your staff, the practical instruction is straightforward. Don't collect card details in a notebook to try charging people later. Escalate through the approved payment process.

Keep incident notes focused on operational references, such as the outlet, device identifier, transaction reference and time. Restrict access to whoever needs them. If the provider requests diagnostic material, use its approved support route. Avoid posting payment screens into a large staff group when a smaller, controlled exchange will answer the question.

Before doors open, check a sale at every operating outlet through the agreed live verification process. Use the provider's approved method, record the result, and handle any test payment or refund as instructed. A successful rehearsal last week doesn't establish that today's account assignment, prices and device connections are correct after equipment has been moved onto the festival site.

Include the quieter outlets in that check. A merchandise stall or hospitality bar might share the same payment arrangements but receive less attention than the main bar. List it in the equipment register and contact plan. When the supplier gives an event-wide recovery confirmation, the duty manager should be able to identify which outlets have actually reported back and which still need checking.

Rehearse an outage with the people who will work it

Run the exercise with bar supervisors, trader representatives, finance, customer service and both technical suppliers. Start with a transaction while connected, remove the agreed connection, continue through the permitted workflow, then restore service. Someone should record the decisions and timing while everyone else does the work. A supplier presentation is not the same as your team operating the system.

Include awkward purchases. Try an amount above the approved offline limit, an unsupported payment method, an uncertain result and a customer asking for a refund. For wallets, include an empty balance and a funding attempt during disconnection. These situations reveal whether staff understand the limits or only know how a successful demonstration looks.

The UK National Cyber Security Centre describes structured incident exercises as a way to test defined response plans and identify improvements. Its guidance concerns cyber incidents, but the rehearsal approach is useful here. Agree what you are testing, observe the response, and assign the changes before accepting the payment setup.

Write down what would make the rehearsal fail. Examples include a supervisor unable to identify pending sales, two staff giving contradictory instructions, or equipment returned before its records are checked. Repeat the affected part after the fix. You want evidence that the operating process works, including recovery, rather than a reassuring memory that somebody once switched off the router.

Give supervisors a clear decision when service drops

When a terminal first fails, the supervisor should establish the outlet, device, last clear result and visible error. Have staff pause uncertain transactions while the supervisor checks the approved procedure. Repeatedly tapping the same card or reopening the same order can make a confusing result harder to resolve. The customer deserves a definite instruction.

Name the person who can authorize the offline operating mode and the person who can suspend it. At a larger site, those may be different roles, but everyone needs to know how to reach them. Publish an alternative to an internet-dependent staff chat. Test the contact method where the bars actually operate, including noisy service areas.

Use a short decision sequence that staff can follow. Is the equipment in a confirmed supported offline state? Is the transaction permitted? Is the outlet below its approved limits? If any answer is unclear, send the case to the supervisor rather than inviting the cashier to invent an exception. Keep a copy at the service point.

Record when the outage began, which outlets are affected and which instructions were issued. Send updates when the operating decision changes, even if the technical fault is still being investigated. Traders need to know whether to continue, restrict service or pause. They don't need a stream of speculative explanations about what might be wrong upstream.

Brief the replacement shift as carefully as the opening team. Someone starting work during an outage needs the current instruction, the outlet's remaining allowance and the cases already waiting for a supervisor. Put the handover through the named outlet lead. Otherwise a fresh cashier may assume the reader has just stopped working and repeat troubleshooting that risks the pending records.

Keep staff privileges consistent with the job. A person serving drinks shouldn't need permission to change the event's payment configuration just to complete an ordinary sale. Have supervisors practise the actions reserved for them, including stopping offline acceptance. If a supplier must make the change, confirm that its authorized contact will be available throughout the trading period.

Make the customer instructions match what still works

Explain the available payment method before somebody spends time ordering. If one bar is still connected and another is paused, signs and stewards can direct customers accurately. Don't send everyone to a distant sales point without checking its queue, capacity and ability to serve the products they want. Moving a problem can create a larger crowd elsewhere.

Avoid announcing a repair time the supplier hasn't confirmed. Say which sales points are operating and when the next update will come. If the situation changes, correct the signs and brief every customer-facing team together. A cashier should not be left defending an instruction that event staff have already replaced in another part of the site.

For a closed-loop wallet, explain separately whether existing balances can be spent and whether new funding is available. Those are different questions for an attendee with money already loaded and someone whose balance is empty. Give both a useful next step. Don't advertise the event as operating normally while a significant group cannot purchase food.

Put assistance where people can find it without depending on an online help page. Agree how customer service will handle a pending charge or disputed balance after the event, using the provider's records. Avoid asking customers to try a second payment solely because their banking application shows something unfamiliar. Staff should follow the confirmed transaction state and escalation procedure.

Decide whether a fallback will actually improve service

Cash can be a planned option where the event's arrangements permit it, but it requires preparation. You need floats, secure storage, receipts, authorized prices, reconciliation and staff who know the process. Think through how the trader records the sale and how any organizer revenue share is calculated. An unrecorded cash sale solves one problem by creating another.

For a prepaid wallet event, accepting cash for products directly may create a separate sales record outside the wallet. Taking cash to load credit creates a different transaction again. Ask the supplier which process it supports and how each appears in the final reports. Tell staff exactly which they are authorized to use before an interruption occurs.

A spare connected terminal can help when its account, menu and sales records fit the outlet. It can also create confusion if it collects into somebody else's account or cannot record the relevant order. Rehearse that fallback too. The fact that a card payment succeeds doesn't establish that the money will reach the correct trader or be matched afterwards.

Include a controlled pause as a valid option. Your priority may be keeping essential refreshments available through a smaller number of proven sales points while other outlets stop. Make that decision with production and customer service. Consider queue safety and access needs alongside takings, rather than letting each trader independently send disappointed customers across the site.

Treat reconnecting as a recovery job

Restoring internet service begins recovery. It doesn't prove that every sale has reached the provider, been approved, and entered the reports correctly. Agree who checks each of those steps. Ask the supplier what the operator can verify directly and which exceptions need its support team. Keep that team available through the recovery period.

NIST's guidance on information system contingency planning includes recovery of systems, operations and data following disruption. Apply that distinction to your festival. A connected device is useful evidence about the connection. You still need evidence about the transaction records before you close the incident and release equipment.

Maintain the equipment register during reconnection. Identify the device, outlet, pending transaction count or value where available, forwarding status and any unresolved error. Use the provider's supported process to move between states. Don't reset a device, delete the application or return it to the hire company to make an unexplained warning disappear.

Where the supplier provides automatic forwarding, let that process do its job and monitor the result. Staff shouldn't manually recreate the same purchases because the dashboard looks delayed. If a record remains uncertain, preserve its reference and ask support to determine the outcome. Confirm which sales can resume normally while the remaining exceptions are investigated.

Reconcile each outlet before calling the incident closed

Work through the interruption period by outlet and payment arrangement. Separate completed sales from transactions still pending, declined attempts, cancellations and refunds. Keep wallet funding separate from purchases made using that funding. Otherwise you can double-count money or treat an unsuccessful top-up as a customer balance that should have been available to spend.

Match the provider's transaction references to the sales records using the reports it supplies. Ask finance to review any unexplained difference before calculating trader payments. A handwritten incident note can help locate a transaction, but it shouldn't replace the payment system's confirmed result. Keep unresolved cases identifiable so they are not quietly absorbed into a total.

Apply the loss allocation you agreed before the event. If a later decline belongs to the organizer under the contract, record it that way. If a trader is responsible, show the evidence and calculation. Don't deduct an unexplained amount from a trader's payment and expect its team to reconstruct a busy service period from memory.

Check customer issues alongside merchant totals. A duplicate charge and an unpaid sale may have opposite effects on the accounts, but neither is resolved by offsetting them. Assign each exception to someone with a clear next action and contact route. Our guide to selling tickets at the door explains related admission controls; food and bar takings need their own reconciliation.

Choose a meeting point for unresolved equipment before pack-down begins. The person collecting it needs the device references and support instructions, not a pile of terminals whose owners have already left. Arrange enough supervised time for that handover.

Walk through one outlet's closeout before you accept the system

Imagine a food trader closing after an interruption. Its supervisor has a device with pending records, some confirmed sales, and a customer complaint about a possible duplicate. The trader wants to pack up. Your duty manager wants the site cleared. Finance wants a final total. Ask the supplier to demonstrate how those requests can be handled without losing the evidence.

The supervisor should know whether the equipment must remain powered, where it can reconnect and who takes custody if staff leave. Finance needs to know which report is provisional and when it becomes final. Customer service needs a reference it can use to investigate the complaint. Those responsibilities should continue after the trader's public service hours finish.

Now add a replacement device brought in midway through trading. Check whether the final outlet report includes both devices and whether each transaction remains traceable to its original record. A total that looks plausible is insufficient if nobody can locate the uncertain purchase. Have the supplier show how an exception is followed through the system without creating a second sale.

Agree what the trader receives when it leaves. That might be a provisional sales summary, a list of unresolved references and the date of the next reconciliation update. Explain what remains subject to confirmation under the contract. Clear provisional information is more useful than a supposedly final number that your team will quietly change after the trader has invoiced you.

Use the result to change the next event's specification

After the incident or rehearsal, compare what happened with the service you bought. Which failure occurred? Which functions remained available? Where did staff need help, and which recovery step took longer than expected? Keep the answers specific enough to change a supplier requirement. Saying the Wi-Fi was bad won't help you negotiate a better operating arrangement.

Review the financial effect without treating every unsent transaction as a loss. Record confirmed failures, duplicate refunds, additional staffing and any reasonable evidence of abandoned purchases separately. Distinguish measured amounts from estimates. The point is to understand the cost of the interruption and whether a proposed improvement is worth paying for at your next festival.

Bring the network and payments suppliers into the same review. If the spare connection worked but the application couldn't use it, buying another router alone won't address the problem. If wallet purchases continued but loading stopped, the customer instructions and funding arrangement need attention. The next specification should describe the work that must continue, not simply request more equipment.

Before signing the next hire agreement, ask for the outage demonstration and recovery process in writing. Confirm who will be available while you trade and while pending records are resolved. Document who owns each fix. Then have the supervisor who will actually run the bars explain the plan back to you. Any unanswered question at that point is something to fix before opening day.