When the Issuer Goes Down: STIP, EMV Offline, and Authorization Continuity

contact@corebaseit.com (Vincent Bevia) — Tue, 19 May 2026 10:00:00 +0100

When an issuer or its processor drops offline, the POS does not always get a clean decline. The card scheme may stand in and approve or decline on the issuer’s behalf. The chip and terminal may complete an offline approval without reaching the issuer at all. Or the merchant’s acquirer link may fail, triggering an entirely different fallback path.

These are three separate mechanisms — network Stand-In Processing (STIP), EMV offline authorization, and merchant/acquirer deferred authorization — and conflating them leads to wrong timeout handling, missing reversals, and reconciliation gaps. This post maps each path, the liability shift when STIP activates, and what POS architects should implement before the next issuer outage.

The diagram above traces the full stand-in path: the POS routes an authorization through the card network to an issuer that is unavailable or slow to respond; the network steps in with either traditional rules or an AI-driven model; the merchant receives a normal authorization code and the checkout continues. The lower panels show how decision logic has evolved, where liability lands, and why STIP must not be confused with EMV offline.

Three fallback paths that must stay decoupled

Architects building for high availability need to treat three concepts as distinct failure modes:

Network Stand-In Processing (STIP): The card scheme (Visa, Mastercard, and others) approves or declines on behalf of the issuer using predefined parameters, scheme rules, and in some cases model-based decisioning.
EMV offline authorization: A local cryptographic decision between the merchant terminal and the chip card, with no real-time online contact to the network or issuer.
Merchant/acquirer fallback (deferred authorization): Local operational procedures — store-and-forward, force-posts, voice authorization — used when the merchant’s communication path to the acquirer is down.

STIP is network-side. EMV offline is card-terminal. Store-and-forward is acquirer-side. Each has different eligibility rules, certification requirements, and liability profiles.

Issuer down does not mean transaction declined

A useful continuity strategy treats “issuer unavailable” as a transition into controlled risk-transfer mode. Decisioning shifts from the issuer’s real-time host to a surrogate — the network or the terminal — within boundaries the issuer or scheme has already defined.

The diagram above isolates the STIP path on the authorization chain. Under normal conditions, the request runs POS → acquirer → card network → issuer host and back. When the link to the issuer host times out or is unavailable, the card network’s STIP engine takes the decision — approve or decline on the issuer’s behalf — and returns the response to the acquirer along the same route. The merchant still sees a standard authorization response. Nothing in the terminal UI signals that the issuer never answered.

For the merchant, a STIP approval is often operationally indistinguishable from a normal online approval. The network returns a valid authorization code, and the POS processes the transaction as successful unless the software captures specific network response indicators and exposes them in application logic.

That opacity is a feature for checkout continuity and a liability for reconciliation. Architects should decide deliberately what gets logged, displayed, and acted on when stand-in indicators are present.

Traditional STIP vs. Smarter STIP

Stand-in processing has moved from rigid, conservative rules toward data-driven issuer emulation. Traditional STIP provided a basic safety net. Visa’s Smarter STIP, launched globally in October 2020, uses deep-learning models trained on bank authorization behavior to produce stand-in decisions that more closely mirror what the issuer would have done online.

The “Evolution of Decision Logic” panel in the diagram captures this shift clearly. On the left, Traditional Rule-Based STIP evaluates the transaction against a static parameter set — often at BIN level — and returns a coarse approve-or-decline for the whole card range. On the right, Smarter STIP (AI-driven) replaces that checklist with a model that learns from the issuer’s historical authorization patterns. The goal is not a generic network guess; it is issuer emulation under outage conditions.

Feature	Traditional STIP	Smarter STIP (AI-driven)
Decision engine	Static, predefined rules and parameters	Real-time deep-learning models
Granularity	BIN-level treatment	Individualized issuer emulation
Logic source	Fixed authorization parameters set by the issuer	Learning from the bank’s past authorization behavior
Accuracy	Coarse; high-risk and low-risk cardholders treated similarly within a BIN	Higher; historical data mirrors specific bank risk appetite
Availability	Long-standing industry standard	Visa global launch, October 2020

From the merchant’s perspective, both paths look the same at Step 3 in the diagram: the network returns a standard authorization code and the receipt prints “Approved.” The POS has no native way to distinguish traditional stand-in from Smarter STIP unless the acquirer or processor surfaces network response indicators in the authorization message. That is why logging raw response data matters — the checkout experience is identical even when the decision engine behind it has changed.

The practical gain from Smarter STIP is fewer false declines during issuer outages — the kind of conservative BIN-level rejections that leave funds-available cardholders stranded. The constraint remains the same: STIP is a network-side service. It only runs if the terminal can reach the card scheme. AI-driven stand-in does not change connectivity requirements; it changes how the network approximates issuer intent once the normal authorization path is down.

The diagram also highlights two constraints worth keeping in view. Total issuer liability does not move with the decision engine — issuers remain financially responsible for STIP outcomes, including fraud or over-limit approvals whether the stand-in decision came from static rules or a model. And the STIP vs. EMV offline comparison is a different axis entirely: STIP is a remote network decision that still requires merchant-to-network connectivity; EMV offline is a local chip-terminal decision that can run with no live link at all.

EMV offline authorization and certification

When online connectivity fails — preventing the POS from reaching even the card network — terminal-level decisioning becomes the last line. STIP is a remote network service. EMV offline is a hardware-to-credential protocol between chip and kernel.

EMV offline is not a default state. It requires specific technical and compliance conditions:

Dual certification: Both the chip card and the merchant terminal must be explicitly certified by the schemes to support offline approvals.
Floor limits: Transactions must stay within pre-set currency amounts (floor limits) and pass local risk rules to remain eligible.
Transaction Certificate (TC): For a successful local approval, the terminal requests and the chip generates a TC — the cryptographic proof of the local decision, required for downstream reconciliation and clearing.

The architectural distinction matters. STIP protects against issuer-side outages but requires a working merchant-to-network connection. EMV offline can operate with no live communications at all. STIP depends on issuer network-side configurations; EMV offline depends on local kernel support and card-level risk parameters.

Timeout management and response code 91

Standardized messaging and timing protect transaction integrity during outages. Ignoring them produces ghost approvals, duplicate billing, and reconciliation failure.

The 15-second rule. Visa rules require that an acquirer or merchant must not time out a POS transaction in less than 15 seconds.

Authorization reversals. If an approval arrives after the terminal has already timed out, the system must submit an authorization reversal automatically. A late-arriving stand-in approval must not leave an incorrect hold on the cardholder’s available balance.

Response code 91 indicates the authorization path could not reach a decisioning endpoint because the switch, issuer processor, or authorization system was unreachable, and STIP was either unavailable or not applicable. Handling depends on context:

Scenario	Interpretation	Recommended action
High-value / high-risk	Transaction exceeds stand-in or floor limits	Final decline; do not retry
Switch unavailability	Temporary network-path disruption or STIP not applicable	One-time retry based on merchant risk appetite
Ineligible product	Product type or MCC excluded from STIP	Hard decline; do not retry

Code 91 does not always mean “retry and it will work.” It means the normal authorization path failed and stand-in was not available or allowed for that transaction.

Liability and risk governance

Payment continuity is never risk-free. Stand-in mode shifts financial responsibility in ways architects and risk teams must account for upfront.

Issuer liability. Card network rules are explicit: the issuer bears responsibility for transactions approved via STIP. If the network issues a stand-in approval for a transaction the issuer would have declined — insufficient funds, fraud, closed account — the issuer is still held responsible. Those false approvals are the primary financial reason issuers pre-configure STIP parameters and risk boundaries before an outage, not during one.

Auditing model-based STIP. Deep-learning stand-in models like Smarter STIP raise governance questions that static rules mostly avoided:

Transparency and explainability: Can you determine why the model made a specific decision for compliance and dispute analysis?
Adaptability: How quickly do models respond to sudden anomalies in consumer behavior?
Edge case handling: Are unique transaction types handled consistently with bank policy?
Emulation accuracy: Do ongoing checks confirm the model’s decisions match the bank’s actual risk appetite, rather than transferring opaque risk to the issuer?

Implementation checklist for payment architects

A high-availability payment architecture balances customer experience with risk controls. Use this as a deployment roadmap:

Decouple fallback paths. Treat network STIP, EMV offline, and merchant deferred authorization (store-and-forward) as distinct failure modes with separate handling logic.
Log raw authorization data. Capture and store raw responses, including DE39, authorization codes, network response indicators, and CVM results.
Maintain cryptographic integrity. Capture all EMV tags, especially the TC for offline approvals, to ensure successful clearing.
Enforce timeout protocols. Hard-code a minimum 15-second timeout and automate reversals for approvals received post-timeout.
Avoid invented fallback. In SoftPOS and MPoC environments, do not fabricate local approvals. A transaction should only be approved locally if the kernel, scheme, and compliance architecture explicitly support it.
Audit code 91 responses. Monitor for spikes in response code 91 to identify upstream instability and define retry policies aligned with merchant risk tolerance.
Separate store-and-forward. Review store-and-forward as a local communication failure mode, distinct from issuer-side outages.

When the issuer is down, a well-designed payment system does not simply stop. It enters a controlled continuity state — provided the architecture distinguishes which surrogate is making the decision and logs enough data to reconcile it later.

References

Visa Inc., Visa Core Rules and Visa Product and Service Rules, Apr. 2026 — STIP definition, issuer responsibility, authorization code handling, timeout and reversal obligations.
Visa Inc., Smarter STIP white paper — traditional STIP limitations and model-based stand-in direction.
Mastercard, Transaction Processing Rules, Jun. 2025 — authorization and processing rules.
Mastercard Developer, response code 91 documentation — authorization system or issuer system inoperative.
EMVCo, EMV Security quick reference, May 2025 — EMV transaction security, local and remote cryptographic authentication, one-time transaction codes.
EMV Migration Forum, Merchant Processing During Communications Disruptions, Apr. 2016 — EMV offline authorization, deferred authorization, and force-post handling during communication disruption.
D. Basin, R. S. Chander, L. Demont, S. Dreier, S. Krampf, and R. Künnemann, “The EMV Standard: Break, Fix, Verify,” in Proc. IEEE Symp. Security and Privacy (SP), 2016 — EMV security analysis and the distinction between offline and online authorization models.

Offline-Authorization on Corebaseit — POS · EMV · Payments · AI · Telecommunications