Stripe Can Now Tell You a Cash Balance Payment Came in Over FedNow. The Rail That Actually Fixes Reversal Risk Covers 1 in 5 Banks.
Stripe's Oct 28 release tags cash balance funding as RTP or FedNow. Only a fifth of US banks support either rail — most renewals still ride ACH's reversal risk.
Stripe's October 28 release added two new values to a field almost nobody checks: network, on the funded.bank_transfer.us_bank_transfer object of a Cash Balance Transaction. Until that release, a bank transfer that funded a customer's cash balance could only come back tagged ach, domestic_wire_us, or swift. Now it can also say rtp or fednow. On its own that's a one-line changelog entry. What makes it worth a second look is what it quietly exposes: cash-balance payments funded over ACH carry a reversal risk that RTP and FedNow payments structurally don't, and most SaaS teams running bank-transfer billing have never had a field to tell the two apart until now.
What a cash balance actually is, and why it exists
Cash balance is easy to misread as "Stripe's version of a stored-value wallet." It isn't. A customer's cash balance only accumulates funds when a bank transfer they sent doesn't cleanly reconcile against an outstanding charge — they overpaid, they sent the transfer before you created the invoice, or the amount just doesn't match anything open. Stripe holds the leftover as a balance you can apply to a future payment, or return. You can't let a customer add funds to it on demand the way you'd let them top up a prepaid account. It's a side effect of bank transfers being slow and imprecise, not a product in its own right.
That makes it a minority rail inside most SaaS billing stacks — the overwhelming majority of subscription revenue still runs on cards. But it isn't a rounding error either. Accounts that pay by bank transfer tend to be the ones who can't or won't put a subscription on a card at all: larger B2B customers settling invoices through treasury operations, accounts above a card network's per-transaction comfort zone, and businesses that specifically asked for a wire or ACH option during procurement. These are exactly the accounts where a quiet, after-the-fact revenue reversal does the most damage, because the dollar amounts are largest and the renewal is least likely to get a second look once it's marked paid.
The reversal Stripe already models, that most billing code ignores
Stripe's own Cash Balance Transaction type list has carried two values for years that describe exactly this failure mode: funding_reversed, for funds debited from the cash balance "due to an ACH reversal," and adjusted_for_overdraft, for when that same reversal drives the balance negative after the funds were already spent. Read those two together and the sequence is plain — a bank transfer funds the balance, Stripe applies it to an invoice, the invoice closes as paid, and then, sometimes days later, the originating ACH transfer unwinds and takes the money back out from under a payment that already happened.
That's not a hypothetical edge case; it's the entire reason those two transaction types exist in Stripe's data model. We've covered this general shape before with SEPA Direct Debit's 8-week no-questions-asked refund right — a European collection that can reverse itself weeks after it clears, long after your churn report already called the money safe. Cash balance funded by ACH is the US bank-transfer version of the same problem, just triggered by a return on the funding transfer instead of a scheme-level refund right. And it's a different mechanism entirely from the ACH Direct Debit failures we wrote up in our ACH dunning guide, which covers Stripe pulling money from a customer's account on your request. Cash balance works the other way: the customer pushes money toward Stripe, and it's that push transfer — not a debit you initiated — that can still come back.
| Funding rail | Typical settlement | Can it reverse after funding the balance? | Who controls whether it's used |
|---|---|---|---|
| ACH | 1–2 business days to post | Yes — funding_reversed / adjusted_for_overdraft, standard return windows up to 60 calendar days for unauthorized claims | Default rail; used whenever RTP/FedNow aren't available |
| RTP (The Clearing House) | Seconds, 24/7 | No — completed push payment, no return window behind it | Sending and receiving bank, both must participate |
| FedNow (Federal Reserve) | Seconds, 24/7 | No — completed push payment, no return window behind it | Sending and receiving bank, both must participate |
Compiled from Stripe's Cash Balance Transaction object docs and published RTP/FedNow network characteristics.
RTP and FedNow don't carry that risk, for a structural reason rather than a policy one: both are real-time, irrevocable push payment networks. Once a transfer over either rail confirms, it's a completed payment, not a provisional one waiting out a return window. That's the actual fix the October 28 field change lets you see — not that Stripe made bank transfers faster, but that it finally tells you which transfers were never exposed to ACH's reversal mechanics in the first place.
Why most of your traffic still won't show either value
This is the part the changelog entry undersells. Stripe's note on the change says the new values "appear only when the upstream banking partner classifies the transfer as an RTP or FedNow payment" — Stripe isn't routing anything onto a faster rail, it's just passing through what the banks on both ends of the transfer already decided. And most of them haven't decided to support instant rails yet.
Source: Federal Reserve Bank of Richmond, Economic Brief 26-28
Read the three numbers together and the picture is narrower than "instant payments are here now." Roughly a fifth of US depository institutions had joined FedNow at all by Q1 2026. Of the banks that did commit to an instant rail, most picked one or the other rather than both — the overlap between RTP and FedNow membership is well under total coverage of either. For a funding transfer to show up tagged rtp or fednow on a Cash Balance Transaction, both the customer's bank and Stripe's receiving bank have to support the same rail, at the same time, and the customer's bank has to actually choose to send it that way instead of defaulting to ACH. That's a fairly specific alignment for any single transfer to hit by accident.
None of this makes the field change pointless — it's genuinely useful once you have it. It just means you should expect the vast majority of cash-balance funding transfers to keep arriving as plain ACH for a while yet, carrying the same reversal exposure they always have. The new enum value doesn't close that gap; it just lets you finally measure how big it still is in your own account.
What to actually do with the new field
- Branch your "paid" logic on network, not just status. Before you count an invoice settled from cash balance as fully final — especially a large annual renewal — check whether the funding transaction's
networkisach. If it is, treat it the way we've recommended treating a fresh SEPA Direct Debit collection: provisional until the return window has realistically passed, not the moment the invoice status flips to paid. - Watch for funding_reversed and adjusted_for_overdraft as their own alert, not generic noise. These two transaction types are rare enough on most accounts that they get buried in a webhook log instead of routed anywhere useful. A reversal that lands after you've already recognized the revenue and renewed access is a different operational problem than a payment that simply failed up front, and it deserves its own queue.
- Don't build retention logic around a rail switch you don't control. You can't make a customer's bank join FedNow or RTP, and you can't force a transfer onto either rail even when both banks support it. The lever you actually have is visibility — knowing which of your bank-transfer renewals are sitting on ACH's reversal exposure right now, not assuming you can engineer your way onto a faster rail.
- If bank transfer is a meaningful slice of your book, size the exposure before you decide it matters. Pull a sample of cash-balance-funded invoices from the last quarter and check how many show
achversus the newer values. For most SaaS businesses that number will currently round to all of them — which tells you the real fix here is operational, not a flag you flip.
This is a small field addition dressed up as a routine changelog entry, but it sits on top of a real and underexamined gap in involuntary churn reporting. We've spent a lot of time on decline codes and unpaid net-terms invoices because those failures are at least visible the moment they happen. A cash-balance renewal that unwinds through funding_reversed weeks later isn't visible at all unless you're specifically looking for it — it just shows up eventually as a gap between the revenue you recognized and the revenue you actually kept. None of this is a reason to route customers away from bank transfer; for the accounts that need it, it's usually the only option procurement will approve. It's a reason to stop treating "funded" and "paid" as synonyms for that slice of your billing, and to make sure whatever reason a bank-transfer account eventually gives for leaving — reversed renewal or otherwise — actually lands in your cancel-reason data instead of a generic "payment issue" bucket. If you want to see what a quarter of silently reversed bank-transfer renewals is actually costing you against the rest of your churn, our churn calculator is a fast way to separate that number out before it gets lost in next quarter's dashboard.
Frequently asked questions
What is Stripe's customer cash balance?+
It's a reconciliation layer, not a digital wallet. When a customer sends a bank transfer that doesn't exactly match an outstanding invoice — an overpayment, a transfer made before the invoice existed, a payment Stripe can't auto-apply — the leftover funds sit in the customer's cash balance until they're applied to a future payment or returned. Stripe's own docs are explicit that you can't let customers top it up directly; it only exists because bank transfers don't arrive instantly or exactly matched the way a card charge does.
Can a Stripe cash balance payment be reversed after it already paid an invoice?+
Yes, if the balance was funded by ACH. Stripe's own transaction types include funding_reversed — funds debited from the cash balance because the originating ACH transfer got reversed — and adjusted_for_overdraft, for when that reversal pushes the balance negative after the money was already spent on an invoice. An invoice marked paid from an ACH-funded cash balance isn't final until the ACH return window has passed.
What's the difference between RTP, FedNow, and ACH for funding a cash balance?+
ACH is a batch system — credits typically post within one to two business days, and the underlying transfer can still return after that, usually within two banking days for standard codes but up to 60 calendar days for an unauthorized-transaction claim. RTP (The Clearing House) and FedNow (Federal Reserve) are both real-time, 24/7 rails that settle in seconds and function as completed, final push payments once confirmed — there's no multi-day return window behind them the way there is with ACH.
Does this Stripe update make bank-transfer-funded subscriptions settle faster?+
No. It doesn't change how money moves at all — it's purely visibility. Stripe added rtp and fednow as possible values of the network field on a Cash Balance Transaction, so you can see which rail actually funded a given payment. Whether a specific transfer arrives over RTP, FedNow, or plain ACH is decided entirely by the sending and receiving banks, not by Stripe or by you.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →