Overview

This is what Triage actually did with this batch of failed payments — how much money it got back, compared with what a simple unguarded system would have recovered on the exact same cases. Click any card or panel to see the full breakdown behind it.

At a glance

How it compares

Where the money went

Worst offenders

The gate at work

Comparison

Three versions of the same system ran over the identical set of payments, so the difference between them is a fair measurement, not a coincidence of luck.

The three configurations

Unguarded baseline: Retries every failed payment on a fixed schedule. No safety checks, no understanding of why any payment failed. This is what a lot of merchants run today.
Baseline + guardrails: The exact same blind retry logic, but every action is checked against a set of hard safety rules before it's allowed to happen — for example, a card that's permanently dead never gets retried.
Triage (full system): Reads the decline reason and the case's history before deciding what to do, and is still checked by the same safety rules as the other two.

Each configuration

Revenue recovered, and the cost that comes with retrying dead cards

Revenue recovered

higher is better

recovered amount

Retries against dead cards

lower is better

same-instrument retry proposed against a hard decline

What each piece contributes

Baseline vs. Triage, measure by measure

Measure	Unguarded baseline	Triage	Verdict

Funnel

Not every failed payment is worth chasing. This shows how many payments Triage started with, how many it judged worth acting on, how many it actually did something about, and how many it got the money back on.

Why cases dropped out

Reason	What it means	Cases

Decline codes

Every failed payment comes back from the bank with a reason code. The code tells Triage whether trying again is worth it at all, and if so, on which payment method.

Soft, hard, and ambiguous

Soft: A temporary problem — for example, not enough money in the account right now. Worth retrying once there's been time for the problem to resolve on its own.
Hard: The payment method itself is dead — an expired card, a closed account, a mandate the customer cancelled. Retrying the same card recovers nothing. The only way forward is a different payment method.
Ambiguous: The bank gave a vague "do not honour" response that could mean almost anything. Worth one careful retry, but repeating it over and over wastes effort without learning anything new.

Code	Cases	Attempted	Succeeded	Recovered	Wasted retries

Decision log

Real, individual decisions from this run — what the system chose to do, why, and whether the safety rules let it happen. Every blocked row here really was blocked: nothing was executed for it.

—

Case	Amount	Decline code	Config	Action	Reason	Gate rule	Result

How it works

Every payment moves through five stages. The fourth, the gate, is the one thing no strategy is ever allowed to skip.

Detect

Filters raw events down to cases actually worth pursuing, and ranks them.

Decide

A strategy proposes one action for the case, with a reason.

Gate

Checks the proposal against hard safety rules. Blocks it if it fails any of them.

Act

The only stage allowed to touch the outside world — the payment gateway, a message.

Measure

Rolls every case's outcome up into the numbers on this page.

Why the gate is its own separate step: if safety checks lived inside each strategy, a new or careless strategy could simply forget to include them — or a future AI-driven strategy could reason its way around them. Making the gate a separate stage that every proposal must pass through, regardless of which strategy produced it, means no strategy can opt out of the safety rules even by accident.

Questions worth asking