Some people who cancelled their subscription or stopped paying were still getting premium access for free. Normally, when someone's paid period ends, our system should drop them back to the Free plan automatically. That automatic step was broken, so 69 accounts kept their paid features without paying. We've now reset all of them, double-checked everything against Stripe (our payment provider), and fixed the underlying bugs.
| Accounts getting premium for free | 69 |
| → on the Max plan | 29 |
| → on the Pro plan | 3 |
| → on the Plus plan | 37 |
| Oldest case (free since) | late January 2026 |
All 69 are now back on the Free plan. The audit afterward came back 100% clean.
-
The "cancel cleanup" robot was unplugged. We have an automated daily job that's supposed to revoke access once someone's paid time runs out. Due to a configuration mistake, it had never actually run since launch - so nobody was ever automatically downgraded.
-
Some cancellations never reached us. When a member cancels, the payment provider (Stripe) is supposed to notify us when their time finally expires. For a group of accounts those notifications were lost, so our records still showed them as "active paying members" when they weren't.
We grouped the affected accounts by how they ended up wrong. This matters because each group required a slightly different fix.
These people clearly cancelled, and our system even knew they had cancelled. But because the cleanup robot was unplugged (problem #1), nobody ever flipped them back to Free. They simply kept their paid features after their time ran out. Fix: reset to Free.
These people cancelled too, but our system still showed them as active paying members - because the "your membership has now ended" notification from Stripe never arrived (problem #2). On paper they looked fine; in reality they'd stopped paying. We confirmed each one directly with Stripe before correcting it. Fix: matched our records to Stripe's truth, then reset to Free.
Their renewal payment failed. Stripe kept retrying for a while (so they were marked "payment overdue"), then eventually cancelled them - but again, that final cancellation never reached us, so they stayed on premium. We only spotted these when we widened our check to include "payment overdue" accounts. Fix: confirmed with Stripe, then reset to Free.
| Plan | Access ended | |
|---|---|---|
| longdoan20@gmail.com | Max | 2026-03-02 |
| khanhanh1999btbt@gmail.com | Max | 2026-03-26 |
| vuhoangdung086@gmail.com | Max | 2026-05-27 |
| nhattvdx@gmail.com | Plus | 2026-03-15 |
| nguyenhieu120225@gmail.com | Plus | 2026-03-27 |
| plmoknijb1408@gmail.com | Plus | 2026-04-18 |
| lordsauron5598@gmail.com | Plus | 2026-05-02 |
| kien178178@gmail.com | Plus | 2026-05-19 |
| trunghieu229buh@gmail.com | Plus | 2026-05-25 |
| admin@chuyentin.info | Plus | 2026-05-30 |
We added four layers of protection so that even if one part fails again, the others catch it:
- Reconnected and upgraded the daily cleanup job. It now also double-checks our records against Stripe every day and self-corrects any mismatch - so a missed notification can no longer cause a silent leak.
- Fixed the notification handling so end-of-membership events are no longer dropped.
- Added the "don't touch paying customers" safety rule (protects resubscribers and edge cases like Group H).
- Fixed a database rule that was causing some payment events to fail.
We also built reusable check-up scripts so we (or anyone) can re-run this audit anytime in minutes.
This was a revenue leak, not a data-loss or security breach - no customer data was lost or exposed, and no paying customer lost access. We've recovered the affected accounts, protected the genuine customers, and put safeguards in place so it won't quietly happen again.