Why the zombies keep failing

The reason, one vote per series

Each series is counted once, on the most recent failed charge inside its current run. That is the reason it is failing now, not the reason it failed two cards ago.

Every reason code

Series counts the code as the latest word on that series. Failed charges counts every time the code came back during the runs, so a card that failed nine months running is nine.

The two codes that dominate — GENERIC_DECLINE and TRANSACTION_LIMIT — are the two that tell you least. Neither names a fault you can fix, which is the point: after four, nine or fifteen of them in a row, the code stops mattering and the count is the whole signal.

How deep the run is

By city

The damage is done at the FIRST miss

By the time a series is on this report it is already four cycles gone. The question is where it turns, and the invoices answer it on their own — no payment history, no joins, nothing that the missing-customer-id problem can distort. Given a series has just missed N cycles in a row, does the next one get paid?

19.0% of first misses are followed by a payment next cycle. 13.0% at the second, 8.0% at the third. The collapse happens between miss one and miss two — by the time anyone is looking at a four-run, the odds have already fallen by three quarters. $12,945,811 has sat in a first miss across the history; a cut-off at four is arguing over what is left after the loss has happened.

Who is in that window right now

2,854 series are at one, two or three misses today — $988,864 owed on those runs and $552,742 a month still being billed. That is the population an early intervention acts on, and it is a third the size of the zombie pile with a fraction of the damage done.

Note the last column. The share that has never paid a single cent climbs with every miss — 28.7% of payers, 41.5% at one miss, 52.5% among the zombies. A first miss on an account that has never paid is a different event from a first miss on one that has paid for a year, and it is the single strongest split available on day one.

How long we have had to act

What the first miss is telling us

The silent one is the worst one

A card that declines leaves a code, and a code can start something. A card that is never charged leaves nothing at all — no decline, no bucket, no list, nobody notices. Checked straight against Square, 6.5% of the invoices scheduled right now carry no card on file (sampled across all six recurring locations: 658 of 10,133). Those cannot auto-charge; they will fail on the due date by construction. Measured on 2026 first misses, where the payment history is at its most complete, the group with no traceable charge recovers next cycle 6.3% of the time against 28.2% for a straightforward no-money decline. It is the worst-performing group on the book and the only one nothing is watching.

Where an intervention would go

The report stops at the evidence; these are the triggers it supports, in the order the numbers argue for them. None of it is built and none of it is running.

The honest caveat on all of it: we have never run an early intervention, so its conversion is UNKNOWN. Do not borrow a number from the collector data to stand in for it — those rates are selected, because a collector only charges a card once someone has agreed to pay. Anything built here needs a control arm that gets the current treatment, or it will be measured against a human conversation rate and read as a failure however well it does.

Some do pay after four misses. This is who actually collected it.

Across the whole history a series has reached 4 consecutive misses 21,845 times, and 2,487 of those later paid an invoice — $510,941 all time, an average of $205 a time. The card-attempt history starts 2023-06-01, so 1,445 of them can be traced to the payment that settled them; 1,385 matched (95.8%). The rest are older than the history and cannot be matched by construction.

The machine or a person?

Square records how each card was presented. ON_FILE dated exactly on the invoice due date is the schedule firing on the stored card — nobody touched it. KEYED is a person typing the number in. A saved card charged on a day nobody scheduled is also a person.

That is the finding. Most of the money that lands after four misses is not a rescue — it is the billing itself, working on a later cycle. It does not contradict the rule that nothing retries a failed payment: nothing does. A failed invoice is never charged twice. What succeeds is the next invoice.

Was a discount involved? No.

So a discount is not the mechanism. Nearly three quarters paid the same amount they had been refusing, and no recovery was ever settled for less than the invoice asked. That matches what /reduction-recovery already found from the other direction: cutting a balance returns $0.12 per $1 given up, and 60.4% of reduced accounts pay nothing at all afterwards.

How long after the fourth miss

How deep the run was when the money landed

1,663 66.9% of all recoveries land at four or five misses — the cycle straight after the rule would have fired. Past nine it is a trickle. That is the whole argument for setting the cut-off deeper rather than switching it off at four.

Does the recovery stick? Mostly not.

Of the 824 recoveries with six further cycles billed behind them:

31.4% paid nothing at all in the next six cycles, and only 8.0% paid all six. One payment landing is not the account coming back — it is usually one cycle working before it stops again.

Can it be automated? Partly — and the part that cannot is the important part

Square's Invoices API does not support recurring invoice series at all. Square's own documentation lists "recurring invoices" under unsupported features and points at the Subscriptions API instead — which is not what this billing uses. There is no endpoint that pauses, ends or even reads a recurring series. So there is no single call that turns one of these off.

What the API can do

So the automation is a nightly sweep, not a switch

Because the series keeps minting a new invoice every cycle no matter how many have failed, cancelling this month's does not stop next month's from appearing. A job has to keep cancelling them. That is fine — it is cheap and it is safe — but it is a janitor, and it runs forever until someone ends the series in the Dashboard.

Before any of it runs

Three things this report cannot decide:

Nothing has been switched off. This page is the list and the mechanism; the sweep is not written and no cancel call has been made.

Every series on a 4+ miss run