Refunds · request entry

Raising a refund starts inside your account.

This page points you at the safe route and tells you plainly which refund terms are approved and which are still pending. It does not promise a window that has not been approved.

The route

How a request actually travels.

Refund handling belongs to the account layer because it needs your order, your entitlement and your identity together. That is why the request starts in billing help rather than on this page.

01
Start from the order, not an email

The authenticated billing route can bind a request to the exact order without exposing payment or learner data. A message from an unverified address is not treated as proof of account ownership.

02
Read the published terms first

The refund and cancellation record states what is approved today. Terms shown at checkout must match that page word for word.

03
A person reviews it

Eligibility depends on the product class. Where the rule is not yet approved, the request goes to a human owner rather than an automatic decision.

Not yet approved

What we cannot promise you today.

Telling you this up front is better than a promise that fails at the moment you need it. These publish the day the policy record is approved.

No blanket refund windowNo seven-day or no-questions promise is currently approved for publication, so none is advertised.
No published decision timelineReview time, provider processing time and failed-reversal handling await commerce and legal approval.
No appeal SLAAppeal steps exist in the policy draft but no response time is claimed until an owner is named.
If billing help is not the right door

There is always a human path.

A payment problem that is not a refund, a grievance, or a request about your data each have their own route. None of them dead-ends in a bot.