Offline Processing

The RESTful API is designed to allow most merchants to connect directly to the data centers of Shift4. However, depending on the devices or flows a merchant plans to use, an interface may need to send requests to a locally installed UTG in order to control the devices. Using a local UTG has another advantage -- the UTG software has a few capabilities that make it simple for your interface to support offline transaction processing when a merchant’s internet connection goes down. The following section applies only to those who are using locally installed UTGs.

Offline mode mimics online transaction processing by locally tokenizing CHD and returning an ‘R’ (referral) response when a card is swiped, tapped, or manually entered. While offline, the merchant can use their backup voice referral procedures to obtain a referral code for all of the transactions that they process (since a Get Merchant Information request won’t work offline). For added security, the UTG will hold the tokenized CHD in an encrypted file until connectivity is reestablished.

Shift4’ Secure Offline Stand-In® (SOS) feature provides advanced offline processing by allowing a merchant to set a threshold (a maximum dollar value) below which they are comfortable issuing automatic “stand-in” authorizations without requesting voice authorizations. All transactions above this amount will prompt for voice authorization.

An interface can determine that the UTG was offline for a transaction by checking the transaction.authSource field in the response. A value of "O" indicates an offline transaction, while a value of "E" indicates an online transaction. Once the merchant’s internet connectivity is restored, the UTG will transmit the transaction data and acquire authorizations (when required), and normal processing can continue.

During the certification process, you may be asked to run a few tests to make sure offline processing is working as expected. For additional information, see the Configuring Offline Mode section in the UTG Installation and Configuration Guide. Your API analyst will assist you with testing offline functionality when you’re ready to do so.

Store and Forward (SAF) allows Commerce Engine to keep accepting eligible card-present payments when it cannot reach the Shift4 platform or a connected downstream system. Commerce Engine makes a local decision, returns a provisional response to the point-of-sale system, and stores the encrypted transaction until it can be submitted for authorization.

Store and Forward is not offline EMV. Offline EMV is a decision made between the card and the issuer, and it applies only when the card's own parameters permit an offline approval — it is not something the terminal configuration selects or the merchant can rely on for coverage. Store and Forward instead lets Commerce Engine apply a Shift4-configured acceptance profile that the merchant controls: which payment types are eligible, up to what exposure, and for how long. Commerce Engine makes a local decision, securely stores eligible payments, and automatically forwards them when connectivity returns. The issuer authorizes the transaction only after it is forwarded.

Offline EMV can shift chargeback liability for eligible disputes, but it applies only to chip transactions on cards whose parameters permit an offline approval, and usually only under a low offline limit. It cannot be configured, so the merchant has no control over which payments are accepted, no exposure limit, and no way to predict coverage during an outage. Store and Forward covers the payment types the merchant actually accepts, applies limits the merchant sets, and provides a stored transaction that can be tracked and reconciled to a final outcome.

The merchant bears the risk of accepting the payment before authorization. A forwarded transaction may be declined because of insufficient funds, a blocked or closed account, issuer fraud controls, or another condition that was not available to Commerce Engine offline. Local checks and limits reduce this exposure, but they do not guarantee funding or eliminate fraud and dispute risk.

Effective when:

• Commerce Engine remains operational and reachable by the point-of-sale system, but the Shift4 platform or a connected downstream system is temporarily unavailable.
• The payment is eligible for SAF and within the merchant's acceptance profile.
• The merchant can reconcile the final result later.
• The merchant accepts the risk of a later decline to maintain payment acceptance continuity.

Not effective when:

• The point-of-sale system or payment device cannot reach Commerce Engine.
• The payment device is unavailable or without power.
• The payment requires online processing.
• Configured amount or duration limits have been reached.
• The merchant cannot accept the risk of a later decline.

The standard Commerce Engine host timeout is 30 seconds. By default, the first qualifying timeout or connection failure puts Commerce Engine into offline mode; the trigger can instead require up to 10 consecutive qualifying failures. Commerce Engine On Premise can also be placed offline before planned network work with a Go Offline request.

After entering offline mode, Commerce Engine remains there for a persistence period. This avoids repeatedly switching between online and offline processing during an unstable connection. A Go Online request can start an earlier connectivity check on Commerce Engine On Premise.

Shift4 configures SAF for the merchant’s market and risk profile. The main controls are:

• Exposure limits: The maximum amount for one offline transaction and the maximum total value waiting to be forwarded.
• Payment eligibility: Which card brands, transaction types, and card-entry methods are eligible, including whether contactless transactions can be stored.
• Offline duration: How long Commerce Engine can continue accepting eligible payments without reaching the Shift4 platform or a connected downstream system.
• Entry and recovery: The failures that trigger offline mode, how long Commerce Engine remains offline, and how it checks and retries the connection.
• Forwarding: How stored transactions are retried and how many independent invoice groups can be sent at the same time.

Commerce Engine also applies built-in safeguards that cannot be relaxed through SAF configuration. For example, it will not store:

• A new payment made with an expired card.
• A payment when the card number fails length or leading-zero validation.
• A payment that includes online PIN data.
• A contactless payment that fails the terminal's risk checks.

QR payments are not available while offline.

Eligible transactions are approved locally and stored.

SAF eligibility is subject to local regulation and payment-network rules. Payment methods that depend on online authorization, PIN verification, or another real-time check may be unavailable for offline processing. Shift4 applies the supported payment methods and limits for each deployment.

Regional authentication requirements also continue to apply. In the European Economic Area, for example, SAF does not replace Strong Customer Authentication (SCA); a transaction must meet the applicable SCA requirements or a valid exemption before it can be stored.

The response looks like an online approval, but these fields identify it as local and deferred:

{
  "result": [
    {
      "server": {
        "name": "Commerce Engine S"
      },
      "transaction": {
        "authorizationCode": "G90764",
        "authSource": "O",
        "responseCode": "A",
        "deferredAuth": "D"
      }
    }
  ]
}

• transaction.authSource: O and server.name: Commerce Engine S identify the Commerce Engine offline response.
• A locally generated authorization code is G followed by five digits. A follow-on request that already has an authorization code can preserve it.
• responseCode: A combined with authSource: O means the transaction has not yet been authorized by the issuer.

After the persistence period, Commerce Engine confirms connectivity with the Shift4 platform or a connected downstream system before returning to online processing. Stored transactions are then forwarded in the background while new requests continue.

• A new request with no relationship to a pending invoice is sent online normally.
• A request that uses the same invoice as a stored transaction cannot overtake it. Supported captures, voids, and incremental authorizations remain with that invoice and are forwarded in order.
• Different invoice groups can be forwarded concurrently, while order is preserved within each group.
• The final Shift4 response can approve or decline the transaction and may include values that were unavailable offline, including the host-issued card token.

A local approval is provisional, so the point-of-sale system must reconcile the final outcome. Reconciliation is required when a transaction that was approved locally is later declined during forwarding, or is forwarded after the batch cut-off time and settles in a different batch than the sale.

Persist transaction.invoice with the original order record so the payment can be matched to its final host outcome, and handle these outcomes through an exception process. The cardholder has usually left by the time the transaction is forwarded.

Coordinate offline testing with your Shift4 Integration Analyst. Include eligible and ineligible payment methods, automatic and point-of-sale-initiated offline mode, new transactions during forwarding, and both successful and declined final results.