Stripe Can Now Bill Your SaaS Fee From a Connected Account's Own Balance. Your Payout Schedule Can Empty It First.

If your platform runs Stripe Connect and charges your own connected accounts a recurring fee for using your software, you've been paying card rates to collect money that never had card risk attached to it in the first place. The connected account isn't pulling out a card at checkout — it's usually already sitting on a Stripe balance from its own payment processing. On September 30, Stripe shipped a payment method built specifically for that situation: it debits the SaaS fee straight from the connected account's existing balance instead of running a card, and it drops the rate from 2.9% + 30¢ to a flat 1%. It also introduces a decline reason that has nothing to do with whether the connected account is good for the money.

This isn't a general-purpose discount on Connect fees. It's a narrow, deliberately scoped feature, and the scoping is exactly what makes it useful. Understanding where it's allowed to apply is also what tells you where the new failure mode lives.

What Balance Pay actually does

Balance Pay only works for platforms on Stripe's Accounts v2 Connect integration, and only against a connected account that's active, controlled by the platform, and has accepted a full service agreement type. Within that scope, it's restricted further: you can use it to debit subscription payments for your own SaaS fee — the charge for using your platform — and nothing else. You can't point it at any other goods or services, and only funds the connected account actually earned through payment processing are eligible; balance sitting there from a top-up doesn't count. It requires Stripe Billing to run the recurring side and Connect to reach the connected account's balance at all.

Confirmation is business-initiated, meaning the platform triggers the debit on its own billing schedule rather than the connected account approving each individual charge — but Stripe still requires you to collect an explicit, logged authorization from the connected account before you ever turn this on, with suggested language that spells out you're debiting their Stripe balance for recurring charges owed under your terms. Settlement is same-day (T+0) when the connected account is in the platform's own country, and next-day (T+1) for cross-border accounts. There's no dispute mechanism — Balance Pay charges can't be disputed the way a card charge can — but full and partial refunds work normally.

The decline that isn't about the money being good

A card decline tells you something about the customer's bank, their credit limit, or their card status. A Balance Pay decline tells you something about your own payout schedule. Stripe's documentation is blunt about this: "payment from a connected account's Stripe balance requires sufficient available funds in the specified presentment currency. Otherwise, the PaymentIntent fails with an insufficient_funds decline code" — and it fails even if the account is holding real money in a different currency. The connected account can be entirely solvent and still fail the charge, because "available balance" on Stripe isn't the same thing as the account's total earnings. It's whatever hasn't already been swept out by a payout.

That's the part worth sitting with. Most SaaS dunning logic, the kind we cover in our guide to Stripe dunning, treats a decline as a signal about the payer. Here, the signal is about a race condition the platform itself set up: does the subscription fee get debited before or after the connected account's own payout sweeps the balance it would have been paid from? Stripe's own guidance names the exact mechanic — if you bill a SaaS fee on the 1st of each month and run weekly payouts every Monday, a month with five Mondays before the 1st pays the account more money, and pulls more of it out, than a month with four. The decline rate on an identical, unchanged fee can swing month to month purely because of calendar alignment.

When the charge does fail, the mechanics mirror what any SaaS team already tracks for card declines, just with a different trigger. The PaymentIntent moves to requires_action, the subscription's current invoice stays incomplete, and the subscription keeps generating future invoices in draft status rather than collecting them. invoice.payment_failed fires, same as a card decline, which means existing webhook handlers built for involuntary churn will pick it up without modification — they just can't fix it the way they'd fix a card failure, because there's no card to update and no account updater to run.

The fixes are about timing, not collection

Stripe ships one real lever here: automatic retries for balance payments, which you can enable for any amount at no extra fee. They're scheduled deliberately around the payout problem rather than around a generic retry curve — the first attempt comes at least 24 hours after the failure, and a second lands on the following Sunday, giving the account's payout cycle room to refill it before Stripe tries again. Beyond that, the fix is entirely on the platform's side of the configuration, not Stripe's.

None of these are things Stripe can do for you, because none of them are decisions Stripe is in a position to make. Only the platform knows its own billing calendar and only the platform controls the payout schedule it set for that connected account. Skip this configuration work and Balance Pay still functions — it just fails at a rate driven by your own payout cadence instead of by anything resembling creditworthiness, and every one of those failures lands in the same invoice.payment_failed bucket as a genuinely insolvent connected account, making your recovery numbers look worse than your actual collection risk.

Who this actually matters for

This isn't relevant to a typical B2C or horizontal B2B SaaS company billing end customers — it only applies if you're running a platform business on Connect that charges your own connected accounts a software fee for using you, the pattern behind vertical SaaS-plus-payments products and marketplace tools that monetize through a cut of processing rather than, or in addition to, a card-billed subscription. If that's your business, the fee savings are real: at 1% versus 2.9% + 30¢, a platform collecting a $49/month seat fee from ten thousand connected accounts saves roughly $21,000 a month in processing costs alone, before counting the instant same-day settlement that a card charge followed by a standard payout schedule doesn't give you.

It's also a new entry in the same category we wrote about in platform defensibility: your own SaaS fee collection is now coupled to the connected account's payout timing in a way a card charge never was. That's not a reason to avoid Balance Pay — it's a reason to treat the payout-schedule configuration as part of the billing integration, not an afterthought you tune after the first wave of declines. Stripe shipped a second Connect-adjacent feature in the same September release window, customer and payment method sharing across Organizations accounts, and the pattern across both is the same: Stripe is giving multi-account platforms sharper tools, and each one comes with its own specific failure mode that only shows up once you're actually running it in production.

If you're the platform collecting that fee, a connected account that misses a Balance Pay debit because your payout schedule drained it first is, functionally, a subscriber who didn't choose to leave — the same involuntary-churn category covered in more depth in our decline code guide, just with a decline code that's entirely of your own making. Before turning this on, it's worth running the numbers through our churn calculator against your current connected-account count and card fee spend, so the 1% savings aren't offset by a payout-timing failure rate nobody budgeted for. And whatever causes the collection to fail — a stale card, a payout race, or a connected account that's simply done — catching it before it quietly becomes a lost account is the same problem CancelFlow is built to solve on the other side of this relationship, where your own subscribers are the ones deciding whether to stay.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.