Offline card payments: accepting a transaction without live authorisation creates merchant risk

Some card-acceptance systems can store or approve transactions temporarily when a live connection to the processor is unavailable. This can keep trading during an outage, but the merchant may accept the risk that the issuer later declines the payment because the transaction was not authorised in real time.

Offline can mean different things in different payment systems

A terminal can use offline EMV logic in some circumstances, while certain merchant systems offer store-and-forward that queues transactions until connectivity returns.

Merchants should use only the offline functionality explicitly supported by the terminal, acquirer and card scheme. Writing down card numbers for later entry is not a safe substitute.

The merchant can lose the sale if later authorisation fails

Without live issuer approval, the customer can have insufficient funds, a blocked card or a fraud issue that the terminal could not check.

Set low offline limits and use the function only where the commercial cost of stopping trade exceeds the controlled payment risk.

Define when offline mode is allowed

A restaurant can accept small offline transactions during a brief network outage, while a jeweller should be far more cautious with a £5,000 sale.

Use transaction caps, employee approval and product restrictions based on the business's fraud exposure.

Restore connectivity and submit queued transactions promptly

Queued payments should be uploaded as soon as the provider connection returns. Long delays increase the chance of expired or invalid authorisations and complicate customer service.

Monitor whether every queued item received a final approved or declined status.

Prevent the same order being charged twice

During outages, employees can retry at another terminal or ask the customer to pay by bank transfer. When the original queue later uploads, both payments can complete.

Use order IDs and a clear fallback process so staff know when to cancel the queued card transaction after another payment succeeds.

Keep offline batches separate until final status is known

Do not mark queued offline sales as settled cash. Record a pending payment status and clear it only after the processor confirms successful capture.

Review declines and losses after every outage to decide whether offline limits remain appropriate.

Worked example: a café loses connectivity for 45 minutes and accepts 60 small store-and-forward transactions below £40. When the network returns, 58 approve and two decline. Finance should treat only the 58 as successful card receipts and follow up the two failed payments under its normal loss process.

Keep the outage start and end time in the incident record. That makes it easier to isolate the affected transaction batch and prevents normal online declines being confused with offline risk.

Test offline behaviour before relying on it for business continuity. Staff should know the terminal icons, transaction limits and how to identify queued items, not learn the feature during a live outage with customers waiting.

Set offline limits by location and staff role. A festival kiosk can need more resilience than a normal high-street store with two broadband connections, but it can also face greater theft risk. The limit should reflect both outage probability and fraud exposure.

Worked example: a store queues £8,000 of card sales during a two-hour network failure. If £600 later declines, the merchant has £600 of goods or services delivered without successful payment. That loss should be included when management decides whether offline mode was still worthwhile.

Keep battery and terminal clock settings accurate. Some offline payment features depend on device state, timestamps and secure storage, and poorly maintained terminals can create failures unrelated to the customer's card.

After each material outage, review whether a secondary internet connection, mobile backup or alternate payment method would reduce future exposure more effectively than increasing offline limits.

Review whether offline capability applies equally to physical cards and mobile wallets. Provider rules and terminal behaviour can differ, so staff should follow the supported process rather than assume every contactless credential can be queued.

Cap the total offline exposure per site as well as per transaction. One £50 offline limit still creates £25,000 of risk if 500 transactions accumulate during a long outage.

Keep offline acceptance disabled by default where the business does not need it. A feature enabled "just in case" can create unmonitored risk during normal connectivity problems if staff do not understand when it activates.

Define how long offline transactions can remain queued before management review. If connectivity does not return promptly, the business may need to stop accepting offline cards and switch to another verified payment method rather than accumulating unlimited unsecured exposure.

Set a post-outage review owner. Someone should confirm every queued payment reached a final state and that customers who paid through an alternative route were not charged again when the connection returned.