Should I refund the application fee?
Refunding a charge does not refund your application fee unless you ask. Whether you should depends on what the fee was for, and there is a defensible answer either way.
Should I refund the application fee?
It depends on what the fee was payment for, and both answers are legitimate. If your fee covers work your platform performed regardless of the refund — matching, payment processing, support, dispute handling — keeping it is defensible. If your fee is a commission on a completed transaction, and the transaction is now undone, keeping it is harder to justify. What is not defensible is not having decided, which is the position most platforms are in.
What happens if I do nothing?
You keep the fee. refund_application_fee defaults to false, so a plain refund call leaves the application fee attached to a charge that has been fully refunded.
await stripe.refunds.create({
charge: chargeId,
refund_application_fee: true,
});
Worth noting what this means in combination with the other default. If neither flag is set, a full refund leaves you holding your fee and leaves the seller holding their transfer, while your platform balance covers the entire refund. You keep a small amount of revenue and lose a much larger amount of cash. It is the worst of the available outcomes and it is what you get by writing the simplest possible refund call.
What is the fee actually paying for?
This is the question that resolves the rest, so it is worth answering explicitly rather than by instinct.
Work through what your platform did for that specific transaction and whether the refund undoes it:
- Payment processing. You incurred a cost, and on most arrangements you do not get the processing fee back on a refund. That portion of your fee is genuinely spent.
- Matching and discovery. You introduced the buyer to the seller. That happened, and a refund does not un-happen it — though whether you should be paid for an introduction that ended in a refund is a fair question.
- Support and dispute handling. Frequently the refund is the work. Charging for it is more defensible here than anywhere else.
- Commission on value delivered. If no value was delivered, this is the hardest position to hold, and the one most likely to generate complaints.
Most platforms find their fee is a mix, and the honest answer is a partial refund of the fee rather than all or nothing. Stripe will let you specify a fee refund amount independently, so the mix is expressible.
What do partial refunds do to it?
Nothing automatic, which is where the arithmetic gets away from people. A partial refund does not proportionally reduce the application fee unless you say so, and the reversal amount, the fee refund amount and the refund amount are three numbers you set independently.
The trap is that they can be individually reasonable and jointly wrong. Refund 40% of the charge, reverse 40% of the transfer, and refund none of the fee, and your effective take rate on the remaining 60% has quietly gone up — which may be exactly what your terms promise, or may be something you would struggle to explain to the seller if they worked it out. Across several partial refunds against one charge, the drift compounds and nobody notices, because each individual call succeeded.
Does it change if the seller was at fault?
It should, and this is the cleanest way to make the decision routine rather than case-by-case. Attach a reason to every refund, and derive both flags from the reason rather than hard-coding them.
Platform-fault refunds — duplicates, your own pricing errors, goodwill retention — are the case for refunding the fee and not reversing the transfer. You caused it, so you carry it. Seller-fault refunds are the case for reversing the transfer and keeping the fee, because your platform did its job and the seller did not. Buyer's-remorse and change-of-mind refunds sit in the middle and are the ones where your written terms have to do the work.
The mechanical benefit of deriving the flags from a reason is that it forces the decision to be made once, in code, where it can be reviewed — rather than a hundred times, implicitly, by whoever wrote the refund call.
What should my terms say?
Whatever you decide, in writing, before you need it. I am describing engineering consequences here and not offering legal advice, and the question of what your terms may say is genuinely one for someone qualified to answer it.
The engineering half is simple enough: your code and your terms should agree, and the only way to know whether they do is to read both. Take a handful of recent refunds, work out what actually happened to the charge, the fee and the transfer in each one, and compare that to the paragraph in your seller agreement that describes it. Where they disagree, one of the two is wrong, and it is usually the code — not because anyone chose badly, but because nobody chose at all.
FeeGuard is an independent product and is not affiliated with, endorsed by, or sponsored by Stripe, Inc. "Stripe" and "Stripe Connect" are trademarks of Stripe, Inc., referenced descriptively.