Review, approve, and reject learner refund requests, and understand how refunds tie back to the original transaction.

Refunds

The Refund Requests screen is where Admins manage refunds raised against paid enrollments. Each request originates from a specific transaction, carries a reason and an amount, and moves through a review workflow that ends with approval or rejection. This page explains how to read the queue, process a request through the approve or reject modals, and how each refund relates back to the transaction it came from.

Refund Requests page showing status stats, filter tabs, and refund request cards — The Refund Requests screen — pending/approved/rejected stats, status filter tabs, search and date range, and a card for each request

Opening the Refund Requests screen

In the manage dashboard, go to Payments in the left sidebar.
Select Refunds from the payments navigation.

The header shows the page title Refund Requests with three at-a-glance stat cards — Pending, Approved, and Rejected — so you can immediately see how much of the queue needs attention.

Reading the queue

Below the header is a filter bar. On the left, status tabs let you narrow the list: All Requests, Pending, Approved, and Rejected. Each tab shows a live count. On the right you can:

Search by user, transaction… — matches on the transaction ID, the requesting user, or the customer note text.
Pick a From / To date range to limit the list to a period.

Each request renders as a card. The card header shows the requester's name, when the request was made, and a colored status tag. The card body lays out the core details:

Field	What it shows
Transaction ID	The original transaction this refund is raised against, shown as `#<id>`.
Amount	The refund amount requested, formatted in the transaction currency (USD is used for display).
Reason	The categorized reason (see below), shown in its friendly label form.
Customer Note	The free-text detail the requester added, when present.
Admin Notes	Notes recorded by the reviewer, shown on processed requests.

If the request is still pending, the card also shows action buttons: Approve, Reject, and View Transaction. Once a request has been processed, the card instead shows who approved or rejected it and when.

Refund reasons

When a refund is requested, the requester selects one of these reasons:

Reason	Meaning
Not Satisfied with Content	The course content did not meet expectations.
Technical Issues	Problems accessing the content.
Wrong Purchase	The wrong course was purchased by mistake.
Duplicate Purchase	The learner was charged twice for the same course.
Course Canceled by Instructor	The course the learner paid for was canceled by the instructor.
Other	A reason not covered by the options above.

Statuses

A refund tag reflects where the request is in its lifecycle:

Status	Meaning
Pending	Awaiting admin review — this is the only status with action buttons.
Approved	The request has been accepted. Approving records the decision, notifies the learner, and marks the request approved — but it does not yet move money automatically. An Admin must issue the actual refund in the Stripe or Razorpay dashboard.
Rejected	Declined; the customer is notified with the reason you provide.

Use the Pending tab as your working queue. When it is empty, the screen shows the message "No pending refund requests. Great job!" — a quick signal that nothing needs attention.

Approving a refund

On a pending request card, click Approve.
The Approve Refund modal opens with a summary of the User, Amount, and Reason.
Optionally add Admin Notes (Optional) — an internal note about why you approved.
Confirm the approval. Approving records your decision, moves the request to Approved, and notifies the customer that their refund was approved.
Click Approve Refund.

On success the request moves to the Approved status and the queue refreshes.

Approving a request does not automatically return funds through the payment gateway — it records the internal decision and emails the learner. To actually return the money, issue the refund manually from your Stripe or Razorpay dashboard against the original charge. Automatic gateway refund processing is not yet wired up.

Rejecting a refund

On a pending request card, click Reject.
The Reject Refund modal opens with the User and Amount summary.
Enter a Rejection Reason. This field is required — the modal warns that the customer will be notified of this rejection, so provide a clear, respectful reason.
Click Reject Refund.

The rejection reason is shared with the customer. If you leave it blank, the modal blocks submission with "Please provide a rejection reason." Write the message as if the learner will read it, because they will.

How refunds relate to the original transaction

Every refund request points back to a single transaction — shown as the Transaction ID on the card. From a pending request, click View Transaction to jump to that transaction in the Transactions list, where you can confirm the original charge, the item purchased, and the amount before you decide.

The refund amount is bounded by what was actually paid: a request cannot exceed the transaction's final amount. This keeps refunds tied to real revenue and prevents over-refunding a single purchase.

The empty state

If there are no refund requests at all, the screen shows an empty state with an inbox icon and the heading No refund requests. The message beneath it adapts to context:

On the Pending tab with nothing pending: "No pending refund requests. Great job!"
When a search returns nothing: "No refunds match your search criteria."
Otherwise, when none have ever been raised: "No refund requests have been submitted yet."

Transactions — review the original charge a refund is raised against
Course Pricing — set the prices that refunds are calculated from
Coupons and Discounts — pre-purchase discounting, versus post-purchase refunds

Refunds

On this page