A subscription payment fails and the customer never finds out. Their card expired, or the bank declined it, and three weeks later the account is closed.
They did not decide to leave. That is involuntary churn, and it is the cheapest customer a SaaS business will ever win back, because they still want the product — nobody has to be convinced of anything, a card just has to be updated.
Recovery Pay does that part.
What it does
It watches the payment provider for failed subscription charges. When one happens the invoice becomes a tracked case rather than a webhook that fired once and disappeared.
From there it works the recovery: the customer is emailed, the retry is scheduled, and when they update their card the invoice is charged again and the subscription comes back. The dashboard shows what is open, what recovered, and what did not.
The point is that it is a process with state. A one-shot "payment failed" email that nobody opened is not a recovery attempt, it is a notification.
Built to be tested on the failure path
The part of a payments integration that normally ships untested is the part that only runs when something goes wrong, because reproducing it means having a card that declines.
So the failure path is the one with a sandbox: create a test customer, attach a card guaranteed to fail, let the subscription break, attach a working card, retry the invoice — the whole recovery sequence, on demand, without waiting for a real customer's card to expire.