Most failover marketing makes a claim nobody can verify: "we recovered revenue you would have lost." PAID's failure handling is built on a stricter contract — disclose what is knowable, refuse to fabricate what is not.
When a payment fails on one rail, the recoverable event is structural, not magical: a buyer who can pay another way often will. Multi-rail checkout — cards, ACH debit, and USDC on the same integration — is the failover mechanism. Resilience comes from having a second rail connected before the failure, not from a retry loop hidden inside the router (the router deliberately performs no retries).
PAID computes and discloses a specific, verifiable fact pattern: a merchant had one or more terminal payment failures on a rail within a disclosed window, and currently has zero other connected rails a future buyer could fall back to. That is a structural gap — knowable from the ledger, and worth acting on.
What PAID will not tell you: "this specific decline would have succeeded on rail Y." That is an unknowable, unfalsifiable prediction — the payment never touched the other rail, so no cross-rail success data exists. PAID's truthfulness contract forbids fabricating it, even though it would make better marketing.
A failed payment is written to the same hash-chained ledger as a successful one — signed, chained, and visible in reconciliation. PAID will never hide a failure or silently correct a discrepancy; discrepancies surface, they don't get smoothed over. See architecture for where failure events live in the flow.