The First Fifteen Minutes: A Bristol Shop's Card-Outage Procedure

A card terminal that stops responding has a way of making a busy shop feel suddenly exposed. The queue keeps forming, the customer is still holding the card, and the staff member at the counter is left balancing commercial pressure against procedural caution. In Bristol, where independent retailers, cafés and service businesses often run lean teams, the first fifteen minutes after a failure determine whether the episode becomes a minor interruption or a reconciliation problem that lingers for weeks.

The practical answer is not to hope for the best. It is to have a short, written procedure that any member of staff can follow without needing to interpret a terminal error code from first principles. The aim is to protect sales where it is safe to do so, switch methods when it is not, and leave enough evidence for the day's takings to be reconciled cleanly.

Minute zero: establish what has actually failed

The first mistake is to treat every stalled payment as a terminal fault. A card reader may be working perfectly while the shop's broadband connection has dropped, or the acquirer may be experiencing a temporary service issue. Staff should check the obvious indicators before touching any settings: power, paper roll, display message, network icon and the status of the router or till system. If the terminal shows a connection error, the problem may sit with the broadband line rather than the device. If only one terminal has failed while another is working, the issue is more likely local to that device.

Record the time and the terminal identifier. Do not factory reset the device, repeatedly reboot it during a customer transaction, or start changing network settings without guidance from the terminal provider or acquirer. A clear note of the error message is more useful to support staff than a device that has been returned to default settings in frustration.

The offline question: permission before presumption

Offline card acceptance is not a universal right and it is not a substitute for authorisation. Many terminals can process transactions in store-and-forward or offline mode, but the terms are set by the acquirer and the merchant agreement. Floor limits vary. A terminal may permit an offline transaction up to a stated value, or it may require voice authorisation above a lower threshold. Some terminals do not support offline sales at all.

Staff should use offline mode only where the business has documented permission, the amount is within the agreed floor limit, and the terminal itself offers the function. An offline payment is still a promise of settlement, not a guarantee. If the card is later declined, reported as lost or stolen, or the transaction exceeds the merchant's risk tolerance, the acquirer may reverse it. The shop then faces the familiar chargeback question: what evidence exists that the cardholder authorised the sale?

For higher-value transactions, voice authorisation may be available through the acquirer's helpdesk. Where it is not, the safer commercial decision may be to decline card payment and offer an alternative rather than to improvise above the floor limit.

Scenario one: the Saturday market rush

A Saturday morning queue is not the moment for a debate about payment architecture. A Bristol retailer with a busy pitch or shopfront should have a backup method that is genuinely independent of the failed terminal. That might be a second handheld on a different mobile network, a countertop terminal connected by Ethernet, or a clearly signposted cash option. If the shop has a cash float, staff should know where it is and who can access it.

A queue host or second staff member can explain the situation without slowing the till further. The wording should be simple: the card machine is temporarily unavailable, cash is accepted, and card payments will resume as soon as possible. Staff should not invite customers to transfer money to a personal account or use an informal payment link that sits outside the business's normal reconciliation. Those shortcuts create exactly the kind of paper trail gap that becomes difficult to explain later.

If the terminal does support offline sales within a documented limit, the transaction should be logged as offline at the time, not reconstructed from memory at the end of the day. The customer should be told that the payment may appear slightly later than usual.

Scenario two: the cellar café with patchy signal

Period buildings and basement rooms are a familiar Bristol challenge. A café or bar below street level may have a working broadband line at the counter but unreliable mobile coverage at the tables. If the terminal relies on a mobile signal, staff should know the one or two positions in the room where connectivity is most reliable. Moving the terminal is preferable to repeatedly retrying a payment in a dead spot.

Where the business depends on card payments, a backup SIM router or a terminal on a different network is a modest insurance policy. Staff should also know whether the terminal can switch to the shop's Wi-Fi and whether that Wi-Fi remains available during a broadband outage. A terminal that depends on the same failed line is not a backup; it is a second version of the same problem.

Scenario three: the single-terminal retailer

Many independent shops run one terminal and no formal backup. In that situation, the first fifteen minutes should focus on containment. Stop trying the same card repeatedly. Ask the customer whether they have another payment method, but do not pressure them. Keep a written note of the time, the amount, the card's last four digits if visible on a receipt, and any authorisation code the terminal has produced. If the terminal is completely unresponsive, call the provider's support line and record the reference number.

A single-terminal retailer should also decide in advance what the fallback is. Cash is the obvious option, but it requires a float and a safe procedure. A second terminal on a different connection is more robust. A payment link sent by text or email can work for some service businesses, but it must be issued through the business's merchant account and reconciled in the normal way.

A paper trail that survives reconciliation

Every outage should produce a simple log. The log does not need to be elaborate, but it should capture the date, time, terminal identifier, error message, payment method used, amount, card last four digits where available, authorisation code if any, customer contact details where appropriate, and the initials of the staff member involved. Offline transactions should be marked clearly so that they can be matched against settlement later.

If an offline transaction is later declined, the business should contact the customer promptly and politely before a chargeback is raised. A contemporaneous log, a duplicate receipt and a note of what the customer was told are far stronger than a recollection reconstructed a fortnight later.

The staff protocol card

A one-page protocol is enough: pause and check the terminal and network; confirm whether offline mode is permitted and within limit; switch to the backup method; log every exception; and tell the customer clearly what has happened. One person should own the decision to use offline payments, and refunds or reversals should not be improvised during an outage.

The terminal going dark is inconvenient, but it is not a reason to abandon procedure. A Bristol shop that has thought through the first fifteen minutes will lose fewer sales, create fewer disputes and reconcile the day with far less guesswork.