The refund that lands after your payout has already left Stripe

A buyer emails on a Thursday about a course they bought three weeks ago. The request is reasonable, you agree, and you issue the refund without thinking twice. Then you look at Stripe and the available balance has a minus sign in front of it. That money left for your bank a fortnight ago, and you have just sent it back to a customer from an account with nothing in it. Nothing has broken. But if you have never seen a negative balance before, it looks exactly like something has.

Where the money comes from

People assume a refund reverses the original transaction, like rewinding a tape. It does not. The original charge settled, joined the rest of your balance, and left in a payout with everything else from that day. A refund is a fresh movement of money out of your current balance towards the buyer's card. The link to the original sale is a record, not a container.

This is a direct consequence of how payments work on store.fan, and it is worth understanding rather than resenting. Money goes into your Stripe account, not into a platform wallet that pays you later. You can read the shape of that on the payments feature page. The upside is that no one sits between you and your revenue and there is 0% platform fee on every plan. The trade is that the cash flow is genuinely yours, including the awkward bits.

The genuinely hard case is a refund on a big single sale during a quiet stretch. Refund 300 in a week where you have taken 40, and the balance goes under. Stripe will resolve it, either by debiting the bank account on file or by holding the negative balance until incoming payments cover it, and which of those happens depends on your country and account configuration. Check your own Stripe settings once, while calm, rather than discovering it on a Thursday.

The difference a bit of planning makes

None of this is avoidable in the sense of never happening. It is avoidable in the sense of never being a surprise. The contrast below is between running a shop on instinct and running one where the refund path is already decided.

What to do when the balance has already gone negative

A quiet week, worked through

Imagine a month where a 240 cohort seat is refunded on the 9th. Payouts for the first week already went to your bank on the 5th, so the balance is sitting at about 60 from two small downloads. The refund takes the balance to roughly minus 180, and payouts stop.

Over the following ten days, a membership renewal batch and a handful of digital sales settle. The negative is absorbed, the balance crosses zero, and payouts resume with no intervention from you. The only real cost was that the money you expected on the 12th arrived on the 20th. If your rent is due on the 15th, that is not a technicality, which is exactly why the buffer matters more than the arithmetic. Membership renewals are the steadiest thing you can put underneath a month like this, and the memberships feature page covers how the billing runs.

The mistake most people make

The common error is refusing a fair refund because the balance is low. It feels prudent for about a day. Then the buyer opens a dispute instead, which is slower, more expensive and worse for your account than the refund would have been. The second error is the opposite: refunding everything instantly to avoid conflict, with no window and no record, until returns become a habit certain buyers rely on. Neither is a cash-flow strategy. A published window, a small buffer and a payout schedule you chose on purpose will handle almost every case, and the plan comparison will tell you which analytics you need to spot the pattern early.

A negative balance is a timing problem wearing the costume of a crisis. Understand where refunds are drawn from, keep a fortnight of small change in the account, and publish the window you are willing to honour. Then the Thursday email is just an email.