Refund requests from an online course creator's receipt link are checked against the refund policy using the Stripe purchase date and LMS progress. Clear cases are refunded with access removed automatically, and borderline ones reach the creator in Slack with one-tap buttons.
Typical results
≈70%
Requests decided without the creator
≈3 hrs/wk
Creator time on refunds saved in launch weeks
100%
Refunds that also remove course access
Figures reflect typical results for this kind of automation.
The challenge
After each cohort launch, refund requests arrive by email and direct message. The creator looks up each purchase in Stripe, checks the student's progress in the LMS, compares it with the refund policy and replies by hand. Decisions take days, students who were refunded sometimes keep course access, and similar cases get different answers.
Before and after
Minutes from request to refund decision
−99%Creator hours per launch week on refunds
−86%Refunded students keeping course access
−100%The automation
Refund requests come through a form linked from every receipt. The automation reads the purchase date in Stripe and lesson progress in the LMS and checks them against the policy: within 14 days and under 30% of lessons watched. Clear cases are approved automatically: Stripe issues the refund, course access is removed and the student gets a confirmation email. Borderline or out-of-policy requests reach the creator in Slack with purchase and progress details and one-tap approve or decline buttons.
How it works
- 01
Request from the receipt link
The student fills in a short refund form linked from every receipt, with the order and a reason.
- 02
Purchase and progress checked
The automation reads the purchase date in Stripe and the student's lesson progress in the LMS.
- 03
Policy applied
Requests within 14 days and under 30% of lessons watched are approved automatically.
- 04
Refund issued, access removed
Stripe issues the refund, the LMS removes course access and the student gets a confirmation email.
- 05
Borderline cases to Slack
Out-of-policy or borderline requests go to the creator in Slack with the details and one-tap approve or decline buttons.
Starts from
- Refund request form
- Stripe purchase record
- LMS lesson progress
Delivers
- Auto-approved refund
- Slack approve or decline
- Confirmation email
The impact
In-policy refunds are decided in under 10 minutes, and about 70% of requests never need the creator. Refunded students lose access every time, the policy is applied the same way to everyone, and the creator saves about 3 hours a week during launch periods.
Questions about this automation
What if a student is close to the policy limits?
Requests near the edges, such as day 15 or 32% of lessons watched, are treated as borderline and go to the creator in Slack instead of being declined. The message shows the purchase date, the progress and the student's reason, and one tap approves or declines with the right email to the student.
Can the automation decline a request on its own?
Only if the creator chooses that. By default, it approves clear in-policy cases and sends everything else to Slack, so a person makes every decline. Some creators let it decline requests far outside the policy, such as a purchase several months old, with a polite email explaining why.
Which tools does it work with?
It is built for Stripe and an LMS that reports lesson progress through an API, with Slack for approvals and email for confirmations. Other payment processors or course platforms can be swapped in. This is a multi-step build, usually rolled out in stages, beginning with the policy check and the Slack approvals.