In this guide 6 sections
Learners keep access after a refund because the payment gateway, the instalment tracker and the course platform each hold their own record, and none tells the others. Close the gap by making one refund event set a withdrawn status and an access end date across all three tools. Then test the lapsed instalment case.
Three tools hold three versions of the truth
A learner pays through a card gateway or PayPal. The course platform holds lessons, progress and certificates. A third tool, often a billing add-on or a spreadsheet, tracks the instalments for every learner on a payment plan. Each keeps its own status. None asks the others.
Support issues a refund inside the gateway dashboard. The gateway marks the charge as refunded. The course platform never hears about it. The enrolment stays active. The learner opens lesson four the next morning.
This is a data problem, not a people problem. Nobody was careless, and nobody was told. The refund lives in a system with no route to the enrolment, so the course platform carries on as though the sale were still good.
- Gateway: charge, refund and dispute status
- Instalment tool: plan, next due date, failed attempts
- Course platform: enrolment, lesson release, certificate
- Support inbox: the refund request and the promise made
Why a lapsed instalment leaves lessons open
Instalments cause a second leak. A learner pays two of six parts. The third card attempt fails. The billing tool retries a few times, sends a reminder email after each attempt and eventually cancels the plan, yet the enrolment created at the first payment stays open. That is the leak.
Most platforms open every lesson at once. Few withdraw access when a later charge fails. Withdrawal on a failed charge needs a written rule, and someone must test it and keep it current whenever the plans, prices or retry settings change. Write it. Decide whether access pauses after the first failed retry, after the plan is cancelled, or only once a grace period ends, and say so at checkout.
Chargebacks behave the same way. The bank pulls the money back weeks later, and by then the lessons have been open for a month with nobody watching the account. Treat a dispute as a trigger.
Link refund, withdrawal and the end of access in one step
Aim for one action. It does three things in order. It records the refund against the original order, sets the enrolment status to withdrawn, stamps an access end date and queues the confirmation email to the learner. Support should not repeat these jobs by hand.
Put the order in the middle. All three records point to one order number. When the order changes state, the other two follow. Without that shared key, someone matches names and emails by hand across three dashboards, and every typo becomes a learner who keeps lessons after the money has gone.
Settle partial refunds before they arrive. A learner who finished module one and asks for money back after a month is a policy case, not a software case. Write the rule once. Tie it to the window.
- Refund recorded against the original order number
- Enrolment marked withdrawn, never deleted
- Access end date stamped with the time of refund
- Certificate and workbook downloads withdrawn or flagged
- A short, plain confirmation emailed to the learner
Close the side doors: downloads, recordings and community
The lesson page is not the only way in. Learners hold PDF workbooks, recording links, a Discord or Slack invite and a calendar entry for live Q&A, and each of them outlives the enrolment. Ending access on the platform does nothing about these.
List each door and decide how it closes. Signed download links should expire. Recording links tied to the enrolment stop with it. Community invites need removal by hand or script. Add that line to the withdrawal routine.
Keep the learner’s progress and notes. If they buy again later, they can resume where they stopped, and nobody has to rebuild their history from an old email thread. Archive instead of deleting.
Test the gap before a learner finds it
Run four test enrolments in a sandbox. Pay in full, then refund. Pay by instalment and let the second charge fail. Pay, then raise a dispute. Pay, change the email address, then refund.
Log in as the learner after each case. Try a lesson, a download, a live link. Write down what still opens. That list becomes your fix backlog.
Repeat the check monthly on real orders. Export refunded charges from the gateway report and compare them with active enrolments by order number, looking for any order that appears on both lists. Any match is a leak. Close it, then ask which rule missed it.
Refund and access reconciliation sheet
A one-page worksheet. Each row is a refunded, failed or disputed order. Columns: order number, gateway refund reference, instalment plan status, enrolment status, access end date, downloads expired, community removed and the initials of whoever checked it. The four test cases are listed beneath it, with three tick boxes each.
Open a blank worksheet to printQuestions owners ask
Should a refund delete the learner’s account?
No. Mark the enrolment withdrawn. Keep the account, progress and order history. Deleting them removes the evidence you need in a dispute and makes a later purchase harder to reinstate, because the system no longer knows who the learner was.
Does a failed instalment always mean access should end?
Not at once. A grace period of a few days suits cards that fail for a simple reason such as expiry or a bank holiday hold. Pause access once the grace period ends. Restore it when payment lands.
What if the learner already finished the course?
That is a policy decision made before the sale. State the refund window on the checkout page. Software then applies it.
How do we find the leaks we already have?
Export refunded and cancelled orders from the gateway, then match them against active enrolments by order number or email in a spreadsheet. Each hit is open access.