The success page anyone could visit
Your app has 41 Pro accounts. shows 29 paying customers. Nobody hacked anything: twelve people just typed an address.
This answers: Should I grant access on the Stripe success page? No coding needed. 3 quick decisions.
- Payments and webhooks
- Who may see what
Step 1 of 3
After paying, sends customers to this page. Click the line that gives away Pro.
Click the line that causes it.
Should I grant access on the Stripe success page?
No. The success page is just where the browser lands after checkout, and anyone can type its address, so granting access there gives your paid plan away. Grant access in your when sends checkout.session.completed, verified by its signature. Let the success page only read and display the plan your database already holds.
Breaks at Your server: Pro given on page load, not on payment
Why AI tools write this bug
The success page is the first place that visibly 'knows' a payment happened, so AI tools often put the upgrade there to make the demo work end to end.
How to fix it
- Find code that sets plans or credits on page load.
- Move it into the verified webhook handler.
- Make the success page read-only, waiting briefly if the is late.
- Compare paying customers with Pro accounts to find freeloaders.
Check your own app
Paste this into Lovable, Cursor or Claude Code:
Without changing anything, find every place in this project that sets a user's plan, credits or paid access. For each, tell me what triggers it: a Stripe webhook, a page load, a button, or something else. Flag anything a user could trigger without a verified payment.
Common questions
- What if the webhook arrives after the success page loads?
- Show a short 'finishing up' state and check again after a moment. Webhooks usually arrive within seconds.
- Can I check the session id on the success page instead?
- Only if your server fetches that session from Stripe and confirms it is paid and belongs to the signed-in user. The webhook is still needed for customers who close the tab.