Skip to main content
Commerce Security Authority
Category: Transaction Processing

Store-and-Forward

Also known as: SAF, Store and Forward
Simply put

Store-and-forward is a communication method where information is held at an intermediate point before being sent onward to its destination, rather than passing straight through. This lets a system wait until it has received a complete message or has a working connection before forwarding it.

Formal definition

Store-and-forward is a telecommunications and data-transmission technique in which information is received and retained in full at an intermediate station or device, and only then forwarded to the next hop or ultimate destination. In switching contexts, a store-and-forward switch buffers the entire frame or packet before making a forwarding decision, which supports integrity checking on the complete unit prior to transmission, in contrast to cut-through switching that begins forwarding before the whole frame is received. The evidence provided describes store-and-forward as a general networking and telecommunications concept and does not address its use in payment transaction handling; any payment-specific implications would need to be confirmed against applicable payment security standards and card brand rules.

Why it matters

Store-and-forward is a foundational communication technique that shapes how reliably and completely data moves across networks. By holding an entire message, frame, or packet at an intermediate point before sending it onward, the method allows the intermediary to verify that the unit is complete and intact before it commits to forwarding. This supports integrity checking on the full unit, which is why store-and-forward switching is often described as favoring correctness over raw speed when compared with cut-through switching that begins forwarding before the whole frame has arrived.

The same principle also underpins resilience when connectivity is intermittent. Because a message is retained at an intermediate station and sent at a later time, store-and-forward can bridge gaps where a downstream link or destination is temporarily unavailable, releasing the message once a working path exists. This trade-off between latency and reliability is central to how engineers reason about network design.

The evidence provided describes store-and-forward strictly as a general networking and telecommunications concept and does not address its use in payment transaction handling. Any payment-specific implications, such as how held transactions would be secured, scoped under PCI DSS, or governed by card brand rules, would need to be confirmed against the applicable payment security standards and network rules rather than assumed from the general definition.

Who it's relevant to

Network Engineers
Engineers designing or operating switched networks weigh store-and-forward against cut-through switching. Store-and-forward buffers the entire frame before making a forwarding decision, supporting integrity checking on the complete unit at the cost of added latency, so the choice depends on whether reliability or speed is prioritized for a given segment.
Systems and Infrastructure Architects
Architects planning communication paths across systems that may face intermittent connectivity can use store-and-forward to hold complete messages at intermediate points and forward them once a working link is available. This helps design for resilience where end-to-end connectivity cannot be guaranteed at all times.
Payment Security and Compliance Teams
The evidence describes store-and-forward only as a general networking and telecommunications concept and does not cover payment transaction handling. If a store-and-forward mechanism is used anywhere data is held before onward transmission, teams should determine independently what data is retained, how it is protected, and how the arrangement is scoped against the current PCI DSS standard and applicable card brand rules, rather than inferring payment implications from the general definition.

Inside SAF

Store-and-Forward (SAF) Transaction
A processing mode in which a merchant terminal or payment application temporarily stores transaction data locally when real-time authorization is unavailable (for example, due to connectivity loss or acquirer downtime), then forwards the batched transactions for authorization once connectivity is restored.
Local Data Storage
The temporary retention of transaction data on the terminal or system pending forwarding. This storage must be scoped carefully because sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization even when encrypted, while some cardholder data (such as PAN) may be retained only under defined protective controls.
Deferred Authorization Risk
Because authorization occurs after the fact, the merchant assumes the risk that a forwarded transaction may be declined, that funds may be unavailable, or that the card may be invalid, since real-time issuer checks did not occur at the point of interaction.
Floor Limit / Value Threshold
A configured monetary ceiling below which offline store-and-forward may be permitted, intended to limit exposure per transaction when online authorization cannot be obtained. Applicable thresholds and rules are governed by card brand and network rules, which vary by region and change over time.
Forwarding and Reconciliation
The process of transmitting stored transactions to the acquirer or processor once connectivity returns, followed by reconciliation of approved, declined, and errored items so the merchant can account for outcomes and handle exceptions.
Protection of Stored Data
Controls applied to data held during the store-and-forward window, which may include encryption, and the requirement to securely delete sensitive authentication data after authorization. How these controls affect PCI DSS scope depends on implementation and validation, not on the label alone.

Common questions

Answers to the questions practitioners most commonly ask about SAF.

Does store-and-forward let a merchant hold full track data or CVV2 during the offline period since it will be deleted after the transaction clears?
No. Sensitive authentication data, including full track data, CAV2/CVC2/CVV2/CID, and PIN blocks, must not be stored after authorization, and this prohibition is not waived by store-and-forward workflows. The offline window in store-and-forward covers the period before an authorization is obtained, not after it. Whether any data is retained during that window depends on the specific implementation and the controls applied, but treating store-and-forward as a blanket exception for retaining sensitive authentication data is a misreading of PCI DSS expectations. Confirm the applicable requirements against the current published PCI DSS.
Is store-and-forward the same thing as offline authorization, so that a transaction is effectively approved without the issuer?
No. Store-and-forward describes queuing a transaction locally when a real-time connection to the acquirer or processor is unavailable, then transmitting it once connectivity is restored. The authorization decision still comes from the issuer or its stand-in process when the transaction is forwarded; store-and-forward does not itself authorize the transaction. Any risk acceptance for completing a sale before a forwarded authorization returns is a business and card brand rules question, and liability outcomes are governed by network rules that vary by region and change over time.
How should stored transactions be protected while they sit in the store-and-forward queue?
Data held in the queue is subject to the same cardholder data protection expectations that apply elsewhere in the environment, and sensitive authentication data should not be retained. Where cardholder data is queued, controls such as strong cryptography for stored data, restricted access, and secure key management may apply, and the effect of any tokenization, truncation, or encryption on scope depends on how it is implemented and validated rather than on the label alone. Verify the specific applicable controls against the current published PCI DSS.
How does store-and-forward affect PCI DSS scope for the device or system doing the queuing?
Any system component that stores, processes, or transmits cardholder data, including a device that queues transactions for later forwarding, is generally in scope for PCI DSS. The precise scope depends on the data handled, the network connectivity, and how the queued data is protected. Reducing scope through methods such as validated point-to-point encryption is a separate consideration governed by PCI P2PE, and its applicability depends on the specific solution and its validation.
What operational controls help manage the offline window in a store-and-forward setup?
Practical controls may include limits on the number, value, or age of queued transactions, monitoring of connectivity status, secure handling and prompt forwarding of queued items, and logging of queue activity. These measures are intended to reduce the exposure and business risk of transactions completed before a forwarded authorization returns, but they do not remove the need to obtain authorization or the possibility of declines or chargebacks once transactions are forwarded. Chargeback and liability outcomes are governed by card brand and network rules that vary by region and change over time.
What happens if a forwarded transaction is declined after the sale was completed?
If a queued transaction is declined once connectivity is restored and it is forwarded, the merchant may not receive funds for that sale and may face additional exposure depending on the applicable card brand and network rules. This is a known trade-off of completing a sale during the offline window before an authorization decision is available. The specific handling, liability, and any dispute or chargeback outcomes depend on network rules that vary by region and change over time, so merchants should confirm current rules with their acquirer.

Common misconceptions

Store-and-forward lets a terminal safely store CVV2/CVC2 or PIN data because it is only kept temporarily and is encrypted.
Sensitive authentication data such as CAV2/CVC2/CVV2/CID, full track data, and PINs or PIN blocks must not be stored after authorization, even when encrypted and even for a short window. Store-and-forward may retain certain cardholder data under defined controls, but it does not create an exception permitting retention of sensitive authentication data.
Because transactions are stored offline, store-and-forward removes the merchant's environment from PCI DSS scope.
Temporarily storing, processing, or transmitting cardholder data keeps that environment in scope. Whether tokenization, encryption, truncation, or other controls reduce scope depends on how they are implemented and validated, not on the fact that transactions are queued locally. Readers should confirm applicable requirements against the current published PCI DSS.
Store-and-forward transactions carry the same approval certainty and fraud protection as real-time authorization.
Store-and-forward defers issuer authorization, so the merchant takes on the risk that a forwarded transaction may later be declined or turn out to be fraudulent. It does not perform real-time issuer checks and does not eliminate card-present or card-not-present fraud; liability and chargeback outcomes are governed by card brand and network rules that vary by region.

Best practices

Configure applications and terminals to securely delete sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) after authorization, and never retain it in the store-and-forward queue.
Apply strong protective controls to any cardholder data (such as PAN) held during the store-and-forward window, and confirm those controls against the current published PCI DSS rather than assuming a fixed requirement number.
Set conservative floor limits or value thresholds for offline transactions to bound per-transaction exposure, and align these with the applicable card brand and network rules for your region.
Minimize the retention window by forwarding stored transactions and reconciling approvals, declines, and errors as soon as connectivity is restored.
Treat the store-and-forward environment as in scope for assessment unless a scope-reducing approach (such as tokenization or P2PE) is properly implemented and independently validated.
Monitor and log store-and-forward activity, and establish exception-handling procedures so declined or errored forwarded transactions are identified and acted upon, recognizing this helps reduce but does not eliminate fraud loss.