Refund the course, remove the access: getting the sequence right

It is a Thursday and a student who bought your course eleven days ago writes to say it was not what they expected. They are polite. They want their money back. You are willing, and you can send the money in about forty seconds. The part you are less sure about is what happens to their access afterwards, and whether anyone will ever check. That uncertainty is what turns a two-minute job into a task you leave sitting in your inbox for a week.

Why a course refund feels messier than a file refund

Refunding a downloadable PDF is emotionally simple. The file is already on their laptop, you cannot get it back, and everyone knows it. You send the money, you shrug, you move on. A course is different because the thing you sold is still running. There is a page with your lessons on it, and after the refund there is a question nobody wants to ask out loud: can they still open it?

The genuinely hard part is not technical. It is judging partial consumption. Someone who watched two minutes and asked for a refund is easy. Someone who watched eleven of twelve modules over three weeks and then asked is not, and no policy sentence you write will make that person feel unreasonable to themselves. You will make judgement calls, and some of them will be wrong in both directions.

The second hard part is delay. Most of the damage in refund stories comes from silence, not from money. A buyer who waits nine days for a reply starts reading your other posts differently, and eventually rings their bank instead of you. A dispute costs more than the refund did and takes the decision out of your hands entirely. Speed is the cheapest thing you control.

One record, or two records that disagree

The usual creator setup keeps the money in one system and the lessons in another. Nothing links them, so revoking access is a chore you have to remember, and remembering is the step that fails. On store.fan the course and the payment are the same order, which removes the remembering.

The sequence that keeps everything agreeing

Order matters here, mostly because doing it backwards produces the one outcome you want to avoid: a buyer who finds the door shut before anyone told them it would be. Work through these in order and the whole thing takes five minutes.

1. 1Open the order in your store.fan dashboard first. Confirm which course, which price and which date, because roughly one request in five turns out to be about a different product than the buyer remembers.
2. 2Find the person in your customer list. Lifetime value is right there, and a long-standing buyer with four purchases is a different decision from a first-time buyer who bought an hour ago.
3. 3Check the request against the refund window you published. Decide on the rule, not on the tone of the message.
4. 4Reply before you refund. One message: yes or no, the amount, and the sentence that access to the lessons ends with the refund.
5. 5Issue the refund in your own Stripe dashboard, in full or in part. That is where your money is, so that is where it moves from.
6. 6Confirm the order no longer stands as a valid purchase, so the private order page that was their way into the lessons is no longer their way in.
7. 7Write one line on the customer record: date, amount, reason in five words. Future you will want the reason more than the amount.
8. 8If the reason was the course rather than the buyer, fix the course. Where a lesson ships with a workbook, replacing the file updates it for everyone who already bought.

What this looks like across a small course launch

Suppose you sell a course at £79 and forty-one people buy it in the first month. Two ask for refunds inside the fourteen-day window you published. That is £158 back out, and on a platform taking 0% you are not also arguing about a commission on money you no longer have. Your per-product analytics still show forty-one buyers against that product, and your customer list still holds thirty-nine people who kept it plus two who did not.

The useful part is the second month. If the same course produces two more refunds and both messages mention module three, you have stopped looking at a refund problem and started looking at a module three problem. That is a rewrite, a re-record, or a clearer description on the sales page. None of those are visible if refunds live in a support inbox with no product attached to them.

The mistake most people make

The common mistake is the kind one: refunding the money and quietly leaving access open, because taking it away feels petty. It is not petty, it is arithmetic. You now have a person holding your entire course for nothing, a payment record and an access record that tell different stories, and a small resentment that will make you slower to refund the next person who deserves it. Refund fully or decline clearly. The middle option, where the money goes back and the product stays given, is the one that quietly makes you worse at this. If you want the wider version of that argument, our refund policy playbook covers how to word the rules themselves.

A refund is not a verdict on your work. It is a transaction reversing, and the only thing that makes it expensive is leaving loose ends: access that outlives the payment, a buyer who was never told, a reason nobody wrote down. Handle those three and the whole subject becomes admin. You can read how payouts and card fees are handled on the payments page, and what each plan includes on pricing.