Skip to main content

Case Study: The Morning an Issuer Went Dark (and Every Merchant Blamed Their Checkout)

· 6 min read
Matt Grossmann
Payments, Fraud & Risk Leader, CFE

One morning in late 2025, I watched a card program's approval rate go to zero. Not at one merchant. At every merchant, everywhere, for about seventy minutes.

I was running fraud at the issuer. This is what happened, what it looked like from the merchant side, and the five things I now believe every merchant's decline monitoring should do because of mornings like that one.

Details below are anonymized and numbers are rounded. The mechanics are exactly as they happened.

What happened​

A single account, almost certainly running a bot, started firing authorization attempts at one hyped limited-release merchant. Not a few hundred attempts. Roughly 20,000 authorization requests from one account in a short window, each one a fresh chance to snag a checkout slot before inventory sold out.

Card issuers run on authorization platforms that are sized for normal traffic with headroom. This was not normal traffic. The platform fell behind, then fell over. For about seventy minutes, the issuer could not answer authorization requests at all.

Here is the part most merchants have never heard of: when an issuer stops answering, the card network does not just decline everything on its own. It switches to stand-in processing (STIP): the network answers on the issuer's behalf, using rules the issuer configured in advance.

Our stand-in rules were configured conservatively: decline by default. The logic behind that choice is defensible from a pure fraud standpoint (if we cannot score it, do not approve it). The consequence was not. Roughly 4,400 legitimate cardholders got declined at grocery stores, gas stations, and subscription renewals, none of whom had anything to do with a sneaker bot.

One bot, at one merchant, got thousands of people declined at every merchant.

What it looked like from your side of the network​

If you were a merchant that morning, here is what you saw, and probably how you misread it:

  • Your approval rate dipped. Not to zero, because only one issuer's cards were affected, but noticeably if that program's cards were common in your customer base.
  • The declines came back as code 91 (issuer unavailable) while the platform was down and timing out, and as generic declines once stand-in processing took over.
  • Your support queue filled with "my card works everywhere else" tickets. Except it did not work anywhere else either, but customers do not test that claim before typing it.
  • If you run subscriptions, your billing system counted a batch of failed renewals, and depending on your dunning setup, may have started emailing customers about payment failures they did not cause.

Most merchants who noticed anything blamed their own checkout, then their gateway, then moved on. Almost nobody correctly diagnosed "an issuer went down and its stand-in rules declined everyone," because nothing in a standard payments dashboard surfaces that.

Five things your decline monitoring should do​

1. Segment approval rate by issuer BIN, and alert on divergence. Overall approval rate is a blunt instrument. The signature of an issuer-side incident is unmistakable if you look for it: one BIN range craters while every other issuer holds steady. That pattern is never your bug, never your fraud problem, and never worth an emergency deploy. Five minutes of BIN segmentation saves your team a fire drill.

2. Treat code 91 as "back off," not "try harder." When an issuer is drowning, automated retries are more water. From inside, we watched merchant retry storms extend the queue we were trying to drain. Respect what the code is telling you: pause retries for the affected BIN range for 30 to 60 minutes, then re-attempt once after recovery. (Retry discipline has network rules attached, too. See The Four Outcomes of an Authorization.)

3. Do not let an outage write itself into your churn numbers. Subscriptions that failed during those seventy minutes were not cancellations, and the cardholders were not delinquent. If your dunning system fired "your payment failed" emails during the window, you converted an issuer outage into your own retention problem. Log the incident window, exclude it from involuntary-churn metrics, and quietly re-present the failed renewals after recovery.

4. Give support a script for bank-side declines. "Please try a different card, this looks like an issue at your card's bank" resolves these tickets in one touch and is accurate far more often than support teams assume. The worst outcome is your agent confidently telling a customer the problem is fixed when the issuer is still in stand-in mode.

5. If you run drops or flash sales, rate-limit authorization attempts per card at your edge. The merchant in this story was a victim too, but not an innocent bystander: their checkout happily relayed 20,000 attempts from one account into the network. You pay for authorization attempts, declined or not, and issuer fraud teams absolutely notice which merchant names arrive attached to bot floods. A per-card, per-account attempt cap at your edge protects your fee bill, your merchant reputation, and, as it turns out, everyone else's Saturday morning groceries.

What changed on the issuer side​

We blocked the offending card, scaled the pipeline that had buckled, and, most importantly, rewrote our stand-in rules: instead of declining everything during an outage, the network now approves low-value, low-risk transactions on our behalf and declines only where the fraud math genuinely demands it.

That last change is worth understanding as a merchant, because stand-in behavior varies enormously by issuer. During any given issuer outage, one bank's cards keep working for small purchases while another bank's cards fail completely. You cannot predict or control which. You can only detect the pattern fast, respond calmly, and avoid making it worse.

The uncomfortable truth of payments operations is that some of your worst checkout hours will have nothing to do with you. The difference between a mature payments operation and a panicked one is whether your dashboards can tell you that while it is happening.

I spent 15+ years running payments, fraud, and risk on both sides of the network: at merchants processing over $1B a year and at a card issuer. If this was useful, there is a lot more in the docs, or reach out.