contact@corebaseit.com (Vincent Bevia) — Mon, 01 Jan 0001 00:00:00 +0000

Research brief: STIP and what really happens when issuers are down

Executive summary

Stand-in processing, usually called STIP, is the card-network fallback path used when the issuer, issuer processor, or an upstream authorization path cannot provide a real-time response. In simple terms: the card scheme or network may approve or decline on behalf of the issuer, based on pre-agreed parameters, scheme rules, risk data, and sometimes model-based decisioning.

The important point is this: issuer down does not automatically mean transaction declined. It means the normal issuer authorization decision is unavailable. What happens next depends on card scheme, region, product, merchant category, transaction type, amount, card-present/card-not-present context, issuer STIP settings, risk rules, and whether STIP is allowed for that transaction.

Visa’s public rules define STIP as the component that provides authorization services on behalf of an issuer when the issuer or its processor is unavailable, when issuer responses exceed the maximum response time, or when the issuer has instructed Visa to process on its behalf. Visa also states that the issuer is responsible for transactions approved or declined by STIP.

For POS architects, the most practical insight is that there are three different “fallback” concepts that people often confuse:

Network STIP — Visa/Mastercard/network responds because issuer is unavailable.
EMV offline authorization — terminal and chip complete an offline approval without online issuer contact.
Merchant/acquirer fallback during communications outage — deferred authorization, force post, store-and-forward, or other local procedures.

They are related operationally, but they are not the same thing.

⸻

Key concepts

1.1 Stand-in processing

Confirmed fact: Visa defines STIP as an authorization service performed on behalf of an issuer when the issuer, its VisaNet processor, or a Visa scheme processor is unavailable, when issuer response time exceeds the maximum response time, or when the issuer has instructed Visa to process the transaction on its behalf.

Interpretation: STIP is not “offline EMV.” It is still a network-side authorization response. The POS/acquirer receives an authorization response as if the normal authorization flow completed, but the decision did not come directly from the issuer host.

1.2 Authorization code during STIP

Confirmed fact: Visa rules state that if Visa approves a transaction in STIP, Visa provides the acquirer with an authorization code, and the acquirer must provide that authorization code to the merchant.

Practical implication: From the merchant/POS perspective, a STIP approval can look like a normal approval. The POS may not always know, unless the acquirer, processor, network fields, or reporting expose stand-in indicators.

1.3 Issuer liability and responsibility

Confirmed fact: Visa rules state that the issuer is responsible for any transaction approved or declined by STIP.

Interpretation: This is why STIP is not a random network guess. It operates within issuer/network-defined rules, parameters, and risk boundaries. The issuer has a strong incentive to configure STIP carefully.

1.4 Response code 91 and “issuer unavailable”

Confirmed fact: Mastercard’s developer documentation lists response code 91 as “Authorization System or issuer system inoperative.” Visa-related processor documentation also maps issuer/switch unavailability and STIP-not-applicable situations to issuer inoperative/no-STIP scenarios.

Interpretation: Code 91 does not always mean “try again and it will work.” It means the authorization path could not reach a proper decisioning endpoint, or STIP was not available/applicable. Whether retry is correct depends on channel, merchant type, risk policy, and acquirer guidance.

⸻

Current state of the topic

2.1 Traditional STIP: rule-based fallback

Visa describes traditional STIP as a process where Visa “stands in” for the issuer to approve or decline transactions using authorization parameters or predefined rules set by the issuer. Visa also notes limitations of traditional rule-based STIP, including BIN-level treatment and static predefined rules.

Interpretation: The old model is conservative and predictable, but coarse. A BIN-level rule may treat a low-risk cardholder and a high-risk cardholder similarly during outage conditions.

2.2 Smarter STIP: model-based fallback

Visa publicly describes Smarter STIP as a real-time decisioning deep-learning model used in VisaNet to determine authorization decisions when issuing banks are unavailable, learning decisions from banks’ own behavior. Visa says it launched Smarter STIP globally in October 2020.

Interpretation: The direction of travel is clear: STIP is moving from static fallback rules toward data-driven issuer emulation. That improves continuity but raises questions about transparency, explainability, issuer control, and dispute handling.

2.3 EMV offline authorization remains separate

The EMV Migration Forum explains that an offline EMV authorization occurs when the terminal asks the chip card for approval, producing a TC, without requesting real-time online authorization from the issuer host. It also states that both the card and merchant terminal must support and be certified for offline authorization.

Interpretation: In an issuer outage, a POS transaction may be handled by network STIP, EMV offline approval, deferred authorization, or declined. The outcome depends on the acceptance environment and certifications.

2.4 EMV security context

EMVCo describes EMV transactions as combining cardholder verification, localized card and terminal risk management, and card/transaction data authentication. It also notes that an EMV transaction produces a one-time security code and that offline and online cryptograms serve different verification paths.

Interpretation: STIP does not remove the need to validate EMV data correctly. A network stand-in approval still depends on the integrity of the transaction data, cryptogram context, POS entry mode, CVM, and risk signals carried in the authorization message.

⸻

What really happens when issuers are down

A simplified authorization path looks like this:

POS terminal → acquirer / PSP → card network → issuer processor / issuer host → response back to POS

When the issuer side is unavailable, delayed, or unreachable:

POS terminal → acquirer / PSP → card network → issuer unavailable / timeout → network STIP decision if allowed → approval or decline returned to acquirer

Possible outcomes

Situation Likely outcome STIP allowed and risk acceptable Network approves on behalf of issuer STIP allowed but risk too high Network declines on behalf of issuer STIP not allowed for product/transaction Decline or issuer/switch unavailable response Acquirer times out before response POS may show timeout; reversal may be needed if approval arrives later Terminal/card supports EMV offline authorization Offline approval may be possible, depending on terminal, card, floor limit, risk rules, and scheme rules Merchant/acquirer communications are down Deferred authorization, store-and-forward, or force-post logic may apply, but this is not network STIP

Visa rules state that an acquirer or merchant must not time out a POS transaction in less than 15 seconds, and if an approval response is received after timeout, an authorization reversal must be submitted.

⸻

Main benefits

4.1 Payment continuity

STIP prevents every issuer outage from becoming a merchant-facing outage. This is especially important in card-present retail, travel, transit, fuel, hospitality, and high-volume unattended environments.

4.2 Better customer experience

A cardholder with available funds may still complete a transaction even when the issuer host is temporarily unavailable. This avoids unnecessary declines caused by infrastructure failure rather than cardholder risk.

4.3 Network-level resilience

Because the card network sees large volumes of authorization traffic, it can apply network-wide risk signals, issuer parameters, product rules, and transaction context during outage situations.

4.4 Issuer-controlled risk appetite

The most important design principle is that STIP is not unrestricted. Issuers can define stand-in parameters, and Visa’s public rules explicitly assign responsibility for STIP-approved or STIP-declined transactions to the issuer.

⸻

Risks and limitations

5.1 STIP has incomplete issuer context

The network may not know the latest available balance, recently blocked account status, fresh fraud alerts, recent customer behavior, or issuer-specific internal risk decisions. This is the core limitation of any stand-in model.

5.2 False approvals

A STIP approval may later be problematic if the issuer would have declined the transaction due to insufficient funds, fraud, closed account, account restriction, or velocity rules unavailable to the network at decision time.

5.3 False declines

A conservative STIP profile may decline legitimate transactions to protect the issuer. This protects risk exposure but harms authorization rate and cardholder experience.

5.4 Transparency gaps

A merchant may simply see an approval, decline, or response code. Unless the acquirer exposes network indicators, the merchant may not know whether the issuer responded directly or the network stood in.

5.5 Model governance

Smarter, AI-based STIP can improve decision quality, but it introduces governance questions: how explainable is the decision, how closely does it mimic issuer behavior, how quickly does it adapt, and how are edge cases audited?

5.6 Not all transactions are eligible

Some transaction types, products, CVM scenarios, tokenized flows, high-risk MCCs, recurring transactions, account verification requests, or regional regulatory contexts may have special handling. STIP availability is not universal.

⸻

Practical examples

Example 1: Supermarket POS, issuer host timeout

A customer taps a debit card at a grocery store. The transaction is routed online. The issuer processor times out. The card network checks issuer STIP parameters, transaction amount, merchant category, card product, EMV data, and risk signals. If within allowed limits, the network returns an approval with an authorization code.

What the cashier sees: approved.

What actually happened: issuer did not make the decision in real time; network STIP approved on issuer’s behalf.

Example 2: High-value electronics purchase

A cardholder attempts a high-value purchase. The issuer is unavailable. STIP is technically available, but issuer parameters or network risk rules reject high-value transactions during stand-in mode.

What the merchant sees: decline, possibly generic.

What actually happened: the decline may not reflect insufficient funds. It may reflect “issuer unavailable and transaction too risky for stand-in approval.”

Example 3: Contact EMV with offline-capable card and terminal

A terminal cannot obtain an online response. If both the EMV card and terminal support offline authorization and are certified for it, the card may approve offline by returning a TC. The EMV Migration Forum stresses that both sides must support and be certified for offline authorization.

What matters: This is not STIP. It is an EMV offline authorization path.

Example 4: Merchant network outage

The POS cannot reach the acquirer at all. STIP cannot help because the transaction never reaches the card network. The merchant may use store-and-forward, deferred authorization, voice authorization, or force-post procedures, depending on acquirer rules and merchant risk appetite.

What matters: Network STIP solves issuer-side unavailability, not merchant/acquirer connectivity failure.

⸻

Opposing viewpoints and open debates

Viewpoint A: STIP is essential infrastructure

This view says STIP is necessary because a card network must preserve transaction continuity. Without STIP, every issuer outage directly harms merchants and cardholders. This is especially important in physical retail and critical acceptance environments.

Viewpoint B: STIP creates invisible credit and fraud exposure

This view says STIP can approve transactions without the issuer’s full real-time account state. That can create exposure if the account is over limit, compromised, recently blocked, or otherwise restricted.

Viewpoint C: AI-based STIP improves accuracy

Visa’s Smarter STIP material argues that model-based decisioning can learn from issuer behavior and improve stand-in decisions beyond static BIN-level rules.

Viewpoint D: AI-based STIP needs stronger governance

The counterargument is that model-based decisions must be explainable enough for issuer governance, audit, compliance, dispute analysis, and operational tuning. Better authorization rates are useful, but not at the cost of opaque risk transfer.

Open debate: should merchants know when STIP occurred?

From a merchant operations perspective, knowing STIP occurred can help explain unusual approval/decline patterns during incidents. From a network/issuer perspective, too much exposure of internal routing and fallback logic may create operational complexity or risk.

⸻

What matters most for professionals

For POS, acquiring, and EMV professionals, the practical checklist is:

Do not confuse STIP with EMV offline approval. STIP is network-side issuer stand-in. EMV offline approval is card-terminal authorization without online issuer response.
Preserve and log the raw authorization response. Capture DE39, authorization code, network response indicators, EMV tags, POS entry mode, CVM result, and reversal behavior.
Understand timeout behavior. A POS/acquirer timeout does not mean the network did not later approve. Visa rules explicitly address late approvals and reversals after timeout.
Treat response code 91 carefully. It usually means issuer/switch unavailability, but the correct handling depends on acquirer guidance, channel, transaction type, and retry policy.
Review store-and-forward separately. Merchant/acquirer communication outage is a different failure mode from issuer outage.
For SoftPOS and MPoC/CPoC flows, avoid inventing fallback. A SoftPOS app should not locally “approve” a transaction unless the scheme, kernel, acquirer, and compliance architecture explicitly support that flow.
Monitor issuer outage patterns. A spike in issuer unavailable, STIP indicators, generic declines, or reversals may reveal upstream instability rather than merchant-side problems.
For article framing: the strong message is: “When the issuer is down, the payment system does not simply stop. It enters a controlled risk-transfer mode.”

⸻

High-quality references

Primary / official sources

Visa Core Rules and Visa Product and Service Rules, April 2026 public rules. Useful for Visa’s STIP definition, issuer responsibility, authorization code handling, and timeout/reversal obligations.
Visa Smarter STIP white paper. Useful for traditional STIP limitations and AI/model-based stand-in direction.
Mastercard Transaction Processing Rules, June 2025. Useful for broader Mastercard authorization and processing rules.
Mastercard response code documentation. Useful for response code 91: authorization system or issuer system inoperative.
EMVCo EMV Security quick reference, May 2025. Useful for explaining EMV transaction security, local/remote cryptographic authentication, and one-time transaction codes.
EMV Migration Forum: Merchant Processing During Communications Disruptions, April 2016. Useful for distinguishing EMV offline authorization, deferred authorization, and force-post handling during communication disruption.

Academic / technical security context

Basin et al., “The EMV Standard: Break, Fix, Verify.” Useful for deeper EMV security analysis and the distinction between offline and online authorization models.

Useful article angle

A strong Corebaseit article could use this thesis:

“STIP is not a loophole and not a magic approval. It is a controlled fallback decision made by the network under issuer-defined risk boundaries when the issuer cannot answer in time.”

Researches on Corebaseit — POS · EMV · Payments · AI · Telecommunications