Summary

  • Adyen's store-and-forward controls include a maximum payment amount and a transaction-count limit per terminal. A retailer must also consider how those allowances combine.
  • Settings can be inherited or overridden at different levels. A headquarters policy is not, by itself, evidence of every device's effective configuration.
  • Offline acceptance can preserve valuable trade. Its commercial result depends on later payment outcomes and the work needed to connect them to goods already released.

The extra till changes more than capacity

Opening another checkout usually looks like an operational decision: shorten the queue, redeploy an employee, add a payment device. When offline acceptance is enabled, it can also expand the amount a retailer is prepared to accept before the ordinary online decision returns. Nothing dramatic has to happen to the limit on an individual machine. The fleet simply becomes larger.

Adyen's Management API describes two separate store-and-forward controls: a maximum amount for one payment and a maximum number of payments per terminal while offline. Supported card types are another part of the configuration. These are useful, concrete restrictions. They are not a single monetary allowance shared by all of a retailer's tills. Terminal-setting definitions.

The distinction matters most when devices are affected together. A branch losing its internet connection may have several terminals ready to use their individual allowances. A common failure across branches would bring more into the same decision. These are scenarios, not reported Adyen incidents. They expose a procurement question that a device inventory does not answer: how much unresolved trade has the business authorized in one interruption?

A simple envelope illustrates the problem. Assume an unchanged group of eligible devices, one currency, empty queues at the start and a single uninterrupted offline period. Multiply the number of terminals by each terminal's remaining transaction allowance and its payment ceiling; for different settings, add the individual results. That is an upper envelope of original accepted basket value under the assumptions. It is not expected loss, a lifetime cap, or a calculation covering repeated reconnections and subsequent adjustments. Most importantly, it is not evidence that a merchant actually used the allowance.

Continuity has more than one meaning

Store-and-forward allows payment details to be retained and submitted after connectivity returns, with the possibility of a later refusal. Offline EMV is different: the issuer-configured card participates in approval. Adyen also identifies a German girocard offline-EMV case with guaranteed settlement. Describing all offline transactions as unverified or unprotected would erase commercially important distinctions. Its public guidance nevertheless places the stated risks of failed offline captures, chargebacks and disputes on merchants; that guidance is not a review of anyone's negotiated agreement. Offline-payment scope and risks.

Another option is to stay online through a different connection. Cellular failover is not delayed authorization disguised as resilience. It changes the network path. But a working mobile link on the payment terminal cannot fix every break elsewhere: a cloud-connected POS application still needs to reach the platform, and a local application needs a usable path to its terminal. The purchase of a cellular-capable device is therefore not proof that the whole checkout can continue. Cellular failover scenarios.

For a merchant, these alternatives have different economics. Restoring online communication may preserve the normal decision process. Accepting offline may preserve the customer visit while leaving more to resolve later. Stopping can lose an otherwise profitable sale. The sensible comparison includes all three possibilities, rather than treating either uninterrupted selling or absolute avoidance of exposure as a universal objective.

Eligibility also limits the scope of any calculation. Dedicated-terminal and mobile arrangements are not interchangeable. The documented mobile security-attestation window, for example, should not be treated as a fresh day of permission beginning whenever the shop loses internet. Nor does a product supporting offline payments promise continuity through every platform outage. The relevant unit is an eligible transaction on the actual integration, not every basket appearing at a counter.

Whose limit is on the device?

Adyen documents settings at company, merchant-account, store and terminal levels. Lower-level values can override those inherited from above. This is a practical way to accommodate different operating environments. It also means the finance-approved default and the configuration at a particular checkout need not be identical. Configuration hierarchy.

There are legitimate reasons for variation. An expensive-goods store may want a different payment ceiling from a low-value, high-throughput counter. One branch may have more reliable alternative connectivity. Another may operate with a smaller team able to investigate exceptions. Uniformity can be administratively convenient while producing a poor commercial fit.

The management problem is not the existence of exceptions. It is whether exceptions remain visible when the fleet changes. A temporary local override can outlive the event that justified it. A new device can inherit a policy that was approved for a smaller estate. A central reduction recorded during an interruption is not proof, without further evidence, that a disconnected till adopted it. None of those possibilities alleges a product defect; they describe the difference between setting a rule and knowing where it operates.

This makes offline permission a form of delegated commercial authority. The person maintaining terminal configuration need not be the person who absorbs an unrecovered sale. Retail operations sees waiting customers; finance sees the eventual outcome; the integration team sees devices and messages. A limit becomes meaningful when those perspectives meet before the queue starts moving.

Reconnection leaves a second job

A useful fallback must be matched to its administrative cost. Adyen's standalone option can let staff initiate payments without the integrated POS application, using an appropriate printer-equipped terminal with the necessary connectivity or offline capability. It also requires manual reconciliation against sales and returns. It can be a good continuity choice without being a cost-free copy of the main checkout system. Standalone operation.

Records must survive the handover. Offline responses and later platform records do not initially carry the same identifiers. Once transactions reach the platform, the Received payment details report offers a store-and-forward indicator and a POS tender reference. These help isolate the relevant transactions; a received-payment record is not itself a settlement guarantee. Report fields.

For analysis, the retailer needs a cohort of original purchases, not a growing count of processing attempts. A queued transaction sent successfully has crossed one boundary. A later successful authorization crosses another. Investigation can remain even after the terminal reports an empty queue. Equally, a delayed outcome is not automatically a loss: recovery can make the decision to keep trading worthwhile.

Adyen's documentation provides mechanisms and limits, not the merchant-level evidence needed to price that trade-off. There is no basis here to estimate an actual customer's losses, the frequency of correlated outages, or the profitability of a particular offline configuration. The bounded conclusion is that fleet growth, effective settings and recovery work belong in the same commercial review. Treating the allowance as only a device parameter leaves its combined effect to chance.