Offline card payments can keep a counter moving during a connection failure, while leaving the final authorization unresolved. Before enabling them, a merchant needs a policy for how much exposure to accept and a way to follow each stored payment after the customer leaves.

The useful product question is what “accepted” means at that moment. A terminal receipt, an issuer authorization and a captured payment describe different stages. Staff and finance teams need to know which stage the system has actually reached.

Two offline paths carry different decisions

Adyen’s offline-payment documentation distinguishes offline EMV from store and forward. In offline EMV, the card participates in a local approval under its issuer’s configuration. Store and forward retains transaction information for later processing, with the risk of a subsequent issuer decline.

Availability depends on the card, scheme, region and integration. Adyen also documents important exceptions: its Mobile solutions do not support offline EMV, and store and forward does not cover an outage of the Adyen payment platform itself.

Treat “the internet is unavailable” as a condition to diagnose. The payment product’s offline capability may address one broken connection while still depending on other parts of the system.

Describe the state the merchant can observe

Stripe’s Android smart-reader guide says offline authorization is attempted after connectivity returns and the payment is forwarded. The merchant bears decline and tamper risks.

For product design, keep separate operational states even if the provider uses a different set of names:

Operational state What staff need to know
Stored locally The terminal has retained the transaction; it still needs forwarding
Forwarded The record has reached the provider; inspect its actual result
Authorized or declined The later authorization result is available
Capture complete or outstanding Follow the configured capture flow

This is a proposed operational view, not a substitute for the provider’s status fields. In particular, local collection should not disappear from an exception queue merely because the checkout screen has moved to the next customer.

A hypothetical museum shop might give the customer the purchased item while marking the tender “stored, awaiting processing” in its own staff view. That wording helps the cashier explain the current state without promising the eventual result.

Put an exposure decision beside the enable switch

Adyen requires a transaction floor limit and supports store-and-forward amount and count controls. Stripe exposes the stored payment count and amounts by currency, and documents ways to require an online transaction when the business’s risk conditions are exceeded.

Use those controls to express a business decision. A low-cost postcard sale and an expensive, easily resold item may justify different policies. Define who can pause offline collection, which transactions staff must decline and who reviews exceptions after an outage.

The operational policy should answer these questions before a busy shift:

  • What single-sale and total queued exposure can the business accept?
  • Which devices and payment methods have been approved for this deployment?
  • Who watches the queue and restores connectivity?
  • What should staff do when the allowed exposure is reached?
  • Who owns a later decline after goods have been handed over?

Record the policy with the deployment, rather than leaving each cashier to interpret a technical maximum as permission.

Adyen warns that an offline response lacks its platform-generated PSP reference and recommends later webhooks or the terminal’s tender reference for reconciliation. Stripe similarly recommends a custom identifier for locally created PaymentIntents.

Keep the local record when the provider reference arrives. A useful matching record includes the device and store, local transaction time, amount, currency, forwarding time and later outcome. Do not overwrite the first identifier and lose the connection to the receipt given at the counter.

This is an earlier gap than the one in reconciliation across settlement dates. Here, operations must join the local tender to the processing outcome before treating an eventual payout as the end of the story.

Make device handling part of the outage runbook

Stripe warns that disconnecting or powering off a smart reader too soon can prevent forwarding. For manual capture, it requires waiting for successful forwarding and authorization before capturing.

The runbook should identify a person who checks the remaining queue after the network returns. A replacement reader that takes new payments does not, by itself, resolve the old device’s stored transactions.

Use the provider’s test environment to exercise the full sequence before relying on offline collection: a permitted connection failure, a locally stored payment, reconnection, forwarding, the later result and reconciliation. Also check what the staff view shows when a transaction exceeds the business limit or cannot be processed.

Treat a later failure as an owned exception. Record the outcome and follow the provider’s rules before considering another attempt. Our payment-retry guide explains why a declined attempt needs a reason and a permitted next action.

Reporting & Sources

Documentation reviewed October 20, 2026. The operational-state table, policy questions and runbook recommendations are editorial analysis. Capabilities vary by device, country, scheme and integration.