What Thaw actually does,
step by step.
The landing page is the summary. This is the whole thing: what we read from your Stripe account, how every sequence is planned, how retries are timed and constrained, what counts as a recovery and what we refuse to charge for, and how your customers' data is handled. Written so you can decide without a sales call.
What we read from your Stripe
Connecting grants read access through Stripe Connect. We never receive your API keys, and read access cannot send or charge anything. Here is the entire list of what we look at, and why.
Subscriptions
Every subscription and its price, quantity and billing interval — used to work out your MRR and what each at-risk customer is worth per month. Annual, weekly and daily plans are normalised to a monthly figure so nothing is double-counted or flattered.
Invoices
Open and uncollectible invoices, the amount due, the number of attempts already made against them, when Stripe intends to try again, and the hosted invoice link we can send a customer to.
Payment methods
The expiry month and year of the card behind each subscription — never the card number, which stays with Stripe. That is enough to see an expiry coming and nothing more.
Customers
Name, email and preferred language, so a message can be addressed properly and written in the right language. Nothing is used to build a profile and nothing is shared with other merchants.
Cancellations
Recent cancellations, when they happened, and the reason Stripe recorded — including whether a dispute or suspected fraud was involved, which determines whether it is appropriate to make contact at all.
Your business details
Your business name and the postal address on your Stripe account, so recovery emails can go out as you, from you, with a compliant footer.
Two things are worth saying plainly. We never see or store a card number — that stays with Stripe, which is what keeps card-data compliance out of your relationship with us. And the audit is produced entirely from read access: no customer is contacted and no charge is attempted to generate it.
The four leaks we look for
Detection runs two ways: live, from Stripe events as they happen, and again in a daily sweep that re-reads your account so a delayed or dropped event never turns into a missed leak. Findings are deduplicated per customer and per object, so one problem never becomes two chases.
| Leak | What triggers it | How it's valued | What we do |
|---|---|---|---|
| Failed payment | An invoice payment fails, or the daily sweep finds an invoice still open. | The monthly value of the subscription behind it, or the amount due on a one-off invoice. | One of two sequences, chosen by whether the decline could plausibly clear on another attempt. |
| Past due or unpaid | A subscription moves into a past-due or unpaid state. | The normalised monthly value of everything on the subscription. | The same sequence as a recoverable failed payment, joined partway in — the problem is already ageing. |
| Card expiring | The card behind a live subscription is approaching its expiry date. | The monthly value of the subscription that card is paying for. | Pre-emptive card-update requests, scheduled against the real expiry date. No retries — nothing has failed yet. |
| Cancelled | A subscription is cancelled outside the immediate refund window and without fraud or dispute involvement. | The monthly value of the cancelled subscription. | A winback, subject to a consent check before anything is sent. |
A leak closes itself the moment the underlying problem goes away — the invoice is paid, the card is updated, or the subscription returns to good standing. Nothing keeps chasing a customer who has already sorted it out.
Where we reach your customers
Three surfaces, all presenting as you. Thaw is deliberately invisible to the person on the other end — they are dealing with your business, which is both better for recovery rates and the only framing that makes sense.
The scheduled, outbound surface. Each message is generated when it is due rather than written in advance, so it reflects the customer's state at that moment.
- Sent under your business name, with your postal address, and replies routed to your own inbox
- Written in the customer's language where Stripe reports one, with amounts formatted for that locale
- Guardrailed: no all-caps, no alarm words, no debt-collection framing, no invented discounts, and a hard length limit
- A human-written template ships as the fallback, so a message still goes out if generation fails or a draft is rejected
- One-click unsubscribe in every message; a suppressed address is never contacted again through any sequence
- Timed to arrive in the customer's morning wherever their timezone is known
The branded update-payment page
Where every message sends the customer. A hosted page that presents as your business, not as Thaw — your name, a monogram, and your Stripe brand colour where you have set one.
- Routes straight to the specific unpaid invoice when there is one, so the actual failed charge is what gets settled
- Otherwise opens a Stripe billing-portal session on your account, deep-linked directly to updating the payment method
- The card update lands in your Stripe exactly as though the customer had done it themselves
- Links are signed and verified in constant time, so they cannot be tampered with, guessed, or pointed at another merchant's customer
The in-app banner
A pull-based surface for customers who never open billing email but use your product. One script tag on your own logged-in pages.
- Renders inside an isolated shadow root, so it cannot inherit from or interfere with your styles
- Shows only the single most urgent open item for that customer, and can be dismissed
- Sends nothing and schedules nothing — it displays state when a customer happens to visit
- Reached only with a short-lived signed token scoped to one customer, so your customer list cannot be probed or enumerated
- Written in your voice. Thaw is not named anywhere on it.
The cancellation offer
The second surface Thaw works, and the only one aimed at a customer who chose to leave rather than one whose payment failed. It renders inside your own cancellation flow at the moment someone tries to cancel — one integration on your side, the same pull-based model as the banner.
- Asks why they are leaving from a short, fixed list — the value is routing to the right offer, not running a survey
- Routes that reason to the offer that addresses it: a discount for price, a pause for a temporary break, a downgrade for too much plan, a person for something broken
- Offers nothing at all when nothing fits — and never more than twice in one customer's lifetime, with six months between attempts, so a customer who is genuinely done is not worn down
- Sends nothing and schedules nothing; it runs only because your customer opened your own cancel page
- Reached with the same signed, constant-time-verified token model as the other pull surfaces, scoped to a single customer
- Held-back control groups run only under the design-partner agreement that trades a 0% fee for permission to publish the measured lift — never on the standard fee, where withholding an offer would cost you the customer outright
How a message gets written
Nothing is written in advance. Each message is generated at the moment it falls due, against that customer's state right then — which is why the third email in a sequence doesn't read like the first, and why nothing goes out about a problem that has quietly resolved.
What the writer is given
The plan name, the amount, the currency, the customer's first name, how long the payment has been outstanding, which step of the sequence this is, why the card was declined, and the link to fix it. Enough to be specific; nothing that isn't needed to write the message.
What it is told to do
Write as your team, in the voice you chose, in your customer's language, briefly, as a service notification rather than a demand. Never mention Thaw. Never invent a discount or a promise. Never add its own footer.
What is checked before sending
Every draft is screened for alarm words, all-caps shouting, debt-collection framing, your own banned-word list, excessive length, and the presence of the real fix-it link. A draft that fails is discarded rather than patched.
What happens if that fails
A human-written template for that exact step is sent instead. The recovery continues either way — the AI makes messages better, but nothing depends on it being available.
What is always appended
The compliant footer is added by us, not by the writer: your business name, the sender disclosure where one is required, your postal address, and a working one-click unsubscribe. It cannot be omitted or mangled per language.
Who is not contacted
Anyone who has unsubscribed, anyone cancelled in circumstances involving a dispute or suspected fraud, and any ended relationship too old to have a lawful basis for contact. The basis for each send is recorded.
How retries are timed and constrained
A retry is the only recovery lever that needs nothing from the customer, which makes it the most valuable one and the easiest to abuse. Every attempt Thaw makes is deliberate, and several rules exist purely to stop us from making one.
Only declines that could actually clear
Declines are classified before anything is scheduled. A card reported lost, stolen, expired or fraudulent, or refused outright by the issuer, is never retried — it would decline every time. Those customers get a card-update request instead.
Backoff matched to the reason
An account with no money in it is given time for money to arrive. A brief processor or issuer blip is retried much sooner. The wait is chosen from the decline reason rather than applied uniformly.
Timed toward payday
Because a soft decline is so often simply "not yet", retries are nudged forward onto common payday windows — forward only, and within a small cap, so nothing is meaningfully delayed to achieve it.
Spaced, and capped
There is a minimum gap between our own attempts and a firm ceiling on how many we will make against one invoice — counted together with Stripe's own attempts, to stay well inside card-network reattempt limits.
Stripe goes first
If Stripe has its own reattempt due imminently, we stand down rather than compete with it, then reassess afterwards. A timing block defers the attempt; a permanent block cancels it outright.
Re-checked at the last moment
Immediately before charging, the invoice's live state is re-read and every guard re-evaluated, so a stale record can never produce an attempt that should not happen.
Yours to authorise
Until you turn autopilot on, every retry sits in the approval queue. Retries are never the thing that quietly starts happening on its own.
What counts as a recovery
This is the part of a success-fee model that deserves the most scrutiny, so it is built to be conservative on purpose: when causation is genuinely ambiguous, the money is not ours.
Billable
- Our own retry is what paid the invoice — a direct causal claim
- Or one of our messages reached the customer before they paid, and the payment is not simply Stripe's own scheduled retry succeeding on the same card
- The payment arrived inside the attribution window that follows an action we actually executed
- For a winback, a winback message specifically preceded the reactivation — and only the first month is billable
- For a save, a cancellation offer was accepted and the subscription was still alive when the confirmation window closed 30 days later — billed on the revenue actually retained, for at most three months
- The amount is net of any immediate refund
Not billable
- Stripe's own automatic retry collected the money and we never retried it ourselves
- The card networks silently updated the card and none of our messages were in play
- The payment landed outside the attribution window after our last action
- Nothing remained after refunds were netted off
- There was no executed action before the payment at all — nothing of ours to credit
- A cancellation offer was shown or declined but never accepted — seeing an offer is not a save
- A save was accepted and then abandoned inside its 30-day confirmation window, or at any checkpoint after it
- Stripe could not confirm the subscription was still alive at a checkpoint — an unreadable answer means no fee, never an assumed one
Measured against a control group
A rotating slice of eligible leaks is held back and worked on by nobody, so your dashboard can compare recovery where Thaw acted against recovery where it didn't. It costs us billable recoveries, and it is the only way to state lift honestly rather than take credit for what Stripe would have collected anyway. Expiring cards are never held back — pre-empting those is too valuable to withhold.
How the fee is calculated and charged
One fee, one invoice, once a month, always traceable to the recovered invoices behind it. 25% of what came back and stayed back — and nothing at all in a month where nothing came back.
The monthly invoice
At the start of each month we total the previous month's billable recoveries, charge 25% of that total to the card you put on file at activation, and itemise it against the specific recoveries involved. A month with no recoveries produces no charge.
Credits for money that didn't stick
If a recovery is refunded or charged back within the dispute window, the fee comes back. If we hadn't invoiced it yet, it simply never gets billed; if we had, it becomes a credit on your next invoice. A partial refund reverses only the fee on the refunded portion — a small refund against a large recovery does not wipe out the whole fee, and does not leave you paying for money you no longer have.
Winbacks are capped at the first month
Reactivating an annual plan is a real win, but billing 25% of a full year on the strength of one email would not be proportionate. The billable base for a winback is one month.
Saves are billed in two parts, on what you keep
A deflected cancellation is charged on the revenue you actually retain rather than the price on the plan — keep a customer with 50% off and the base is the discounted figure, because charging 25% of money nobody received is not a fee, it is a markup. It lands in two parts: one month once the save clears its 30-day confirmation window, two more if the subscription is still alive at day 90. Later parts bill the lower of what was retained at acceptance and what the subscription is worth now, so a downgrade in month two lowers the fee and an upgrade never raises it.
If our own fee charge fails
We re-attempt it on a widening backoff and email you to update the card — the same discipline we apply to your customers, applied to ourselves. No surprise double charges.
Your records
Recoveries and fee invoices both export to CSV, and every billing event is written to an append-only log you can read. Nothing needs to be reconciled by hand or taken on trust.
Security, consent and your data
Recovery means touching your revenue and writing to your customers. Both deserve to be verifiable rather than asserted.
Access
Standard Stripe Connect OAuth. Stripe offers platforms one access level, so its consent screen asks for read and write — but the audit only reads, and scheduling is gated on activation, which is a distinct, logged action. Disconnecting revokes everything immediately.
Isolation
Row-level security on every table, so one merchant's data is unreachable from another's session. Roles are enforced in code as well: viewers cannot send, approvers cannot change billing.
Integrity
Incoming Stripe webhooks are signature-verified and deduplicated, so a replayed event can't double-charge or double-send. Every link we put in front of a customer is signed and verified in constant time.
Audit trail
An append-only log of every email, retry, approval, permission change and billing event, with timestamps — readable by you, not just by us.
Consent
Before any commercial message we check there is a lawful basis for it and record which basis applied. Ongoing paying relationships qualify; long-ended ones and fraud- or dispute-related cancellations do not.
Deletion
Disconnect and scheduled actions are cancelled at once, with your customers' personal data purged after the retention window in our DPA. An owner can also erase a single customer's data on demand, for a subject request.
Who else touches the data
Our full subprocessor list, and what each one is for:
- Stripe — Payment data & connected-account access
- Supabase — Database, authentication (row-level security)
- Vercel — Application hosting
- Resend — Transactional & recovery email delivery
- Anthropic — AI-generated recovery copy (no training on your data)
- Google Workspace — Support, privacy, and security inboxes
The controls above are operating today and evidenced in-product; a formal SOC 2 Type II audit is scheduled rather than complete, and we say so rather than implying a certification we don't yet hold. The current control checklist, live uptime and incident history are on the trust page.
What Thaw will never do
The boundaries matter as much as the features. None of the following is a setting you could accidentally enable.
- Store card numbers. Card data stays with Stripe; we hold tokens and metadata only.
- Ask for your Stripe API keys. Access is granted through Stripe Connect and revocable by you at any time.
- Write to your account before you explicitly grant it, as a separate and logged step.
- Name Thaw to your customers. You are the sender and the brand throughout.
- Invent a discount, a deadline or a promise on your behalf.
- Use debt-collection language, alarm words or all-caps pressure.
- Email an address that has unsubscribed, or a cancelled customer we have no lawful basis to contact.
- Claim a recovery that Stripe's built-in dunning or the card networks produced.
- Sell, share or train third-party models on your data or your customers' data.
Start with the audit. Decide after.
No card required, and the numbers are yours to keep whether or not you ever switch recovery on.