Make sure only paying customers get paid features
A message saved on a customer’s device can be changed. Your app should check its own trusted purchase record before delivering a paid lesson, file, report, or feature.
before you start
A payment screen can say that a purchase succeeded, but your app’s trusted purchase record must decide what the customer receives.
Understand what can go wrong
in plain words
A page saying that someone paid is not enough proof that the person should receive a paid feature.
Suppose your app sells a course, report, download, extra storage, or members-only tool. After paying, a customer expects it to open. Someone who has not paid should see an offer instead. When an AI builder creates this flow, it may save a simple paid or unpaid label in the customer’s browser. A browser is the program used to open your app, such as Chrome or Safari. Information saved there is on the visitor’s device and can be changed, erased, or copied to another session.
Your app therefore needs a trusted purchase record that visitors cannot edit. The protected computer that stores and checks this record is called a server. Before the app delivers anything paid, the server should match the signed-in customer with an active purchase, plan, trial, or approved exception. Developers call the resulting permission an entitlement. An entitlement answers a practical question: what may this particular customer use right now, and when should that access end? The thank-you page may display the result, but it should not make that decision.
- ▸Treat the thank-you page as a message, not as proof of access.
- ▸Choose the trusted record that allows each paid item.
common risk
An unpaid visitor reaches a members-only lesson because the page trusts a paid label saved in the browser, even though the app has no matching purchase record.
what to do now
Choose one paid feature and write down the customer record, product, status, and end date that should allow it.
ask your AI
Inspect my entire app and list every place where it decides whether a customer may use a paid page, lesson, file, report, export, or action. Explain each decision in beginner-friendly language. Flag every decision that trusts only a browser value, hidden button, page address, or payment return screen. Do not change anything yet; give me the complete list first.
Check before delivering each paid item
in plain words
Your app should use its protected purchase record at the moment it sends paid content or performs a paid action.
The page shown on a phone or computer is useful for menus, messages, and locked buttons. It is not a safe place for the final decision because it runs in an environment controlled by the visitor. Hiding a button only changes what the visitor sees. It does not protect a lesson, file, report, or costly action if the app will still deliver that result when asked another way. The decisive check must happen in the protected server immediately before delivery.
Developers call this server-side authorization. It means the server identifies the signed-in customer, reads the trusted purchase record, confirms that the correct product is active, and only then returns the paid result. Apply the check separately to every paid item, including downloads and actions that cost your business money. Passwords, payment keys, and staff access codes must also remain on the server. If one of those concrete items is placed in files sent to visitors, hiding it on the page does not make it safe.
- ▸Check the signed-in customer and active purchase immediately before delivery.
- ▸Keep passwords, payment keys, and staff access codes in protected settings.
common risk
A premium PDF is hidden behind a locked button, but the app sends the file to any visitor who asks for its direct location.
what to do now
Use an unpaid test account to request each paid page, file, export, and action separately.
ask your AI
Update my app so the protected server checks the signed-in customer’s trusted purchase record immediately before every paid page, lesson, download, report, export, and premium action is delivered. Deny the result when the purchase is missing, expired, refunded, cancelled, or for a different product. Show a clear upgrade message, and never rely on browser storage, hidden page elements, or the payment return screen as proof.
Keep the purchase record current
in plain words
Successful payments and later changes must update the trusted record used to open or end paid access.
A payment company can notify your app when a purchase succeeds, a renewal fails, a subscription ends, or money is refunded. Your protected server should verify those messages and update the correct customer’s purchase record. Access then follows the current record, even if the customer closes the payment tab, returns later, or signs in on another device. The visible confirmation page can still reassure the customer, but it should only report what happened.
Developers call an automatic payment message a webhook. A webhook is like business mail delivered directly from the payment company to your server. Your app should confirm that the message really came from that company, connect it to the correct customer and product, and avoid applying the same message twice. Store useful support details such as the payment reference, product, status, and access end date. Do not store full card details. Test successful payments as well as refunds, cancellations, failed renewals, and expired trials.
- ▸Connect each verified payment message to one customer and one product.
- ▸Handle events that both begin and end access.
common risk
A customer pays and closes the tab before returning to the app, so access never begins because the app depended on the visible return page.
what to do now
Complete a test payment, close the return page, and confirm that the trusted record still grants the correct access.
ask your AI
Review my payment update flow. Make the protected server verify messages from my payment company, connect each message to the correct customer and product, and prevent the same message from being applied twice. Update the trusted purchase record for successful payments, refunds, cancellations, failed renewals, and expired trials. Do not store full card details. Add safe tests for every case.
Protect every path to the result
in plain words
Every way of requesting a paid result needs the same trusted check, even when its button is hidden.
Customers can arrive through a menu, bookmark, email, search result, phone screen, or saved file location. One paid feature may also have several entry points, such as a dashboard card, download button, automatic report, and export option. Check all of them. A lock icon or upgrade message helps customers understand the plan, but it is only a visual guide. The actual decision belongs beside the step that returns the information or performs the action.
Developers call a server location that returns information or performs an action an endpoint. Each endpoint that can deliver something paid should repeat the same customer-and-purchase check. This matters because a new page may skip an older page without meaning to. Make a simple inventory of paid content, files, exports, generated results, and actions that create a business cost. Then test each item while signed out, with an unpaid account, with the wrong plan, and with an expired account.
- ▸Include direct requests, downloads, exports, and automatic actions in your inventory.
- ▸Test signed-out, unpaid, wrong-plan, and expired accounts.
common risk
The dashboard hides an export button for free accounts, but another app location still creates and sends the export without checking the purchase.
what to do now
Map every path to every paid result and mark where the trusted check occurs.
ask your AI
Create a complete inventory of every server location that returns paid content, files, reports, exports, generated results, or premium actions in my app. Add the same trusted purchase check to each one. Test signed-out users, unpaid accounts, accounts on the wrong plan, refunded purchases, and expired access. Return a table showing each paid item, its required product, the check location, and the expected denial message.
Test again whenever the app changes
in plain words
A later change can accidentally remove a working check, so paid access needs repeated testing.
Keep two test accounts: one with an active purchase and one that has never paid. After changing prices, plans, payment screens, member pages, downloads, or AI-generated features, try every paid result with both accounts. The paying account should receive exactly what its plan includes. The unpaid account should receive a clear offer or explanation, never the paid result. Also test an expired or refunded purchase when your business supports those states.
Decide who may grant access manually and record the customer, product, reason, approver, and review or end date. Remove exceptions that are no longer needed. VibeCodeWall checks the public app from the outside; it does not need to see private code. It can watch for important public changes over time. Use that outside check together with your own account tests. The two methods answer different questions: the outside check notices public changes, while your test accounts confirm that purchase decisions still work for real customer situations.
- ▸Repeat the full two-account test after payment or paid-area changes.
- ▸Review manual grants and outside monitoring regularly.
common risk
A redesigned report page goes live without the trusted purchase check that protected the old page.
what to do now
Add paid-access tests to the checklist you use after every important app change.
ask your AI
Create a repeatable test checklist for every important app change. Use one account with an active purchase, one account with no purchase, one expired or refunded account, and a signed-out visitor. Test every paid page, lesson, file, report, export, and premium action. Include expected results, a place to record failures, checks for manual access grants, and confirmation that passwords, payment keys, and staff access codes are not sent to visitors.
Quick checklist
- 01List every paid page, lesson, file, report, export, and action.
- 02Match each paid item to the purchase or plan that should allow it.
- 03Confirm that the app checks a trusted purchase record immediately before delivery.
- 04Test every paid item with one paying account and one unpaid account.
- 05Test refunds, cancellations, failed renewals, and expired trials.
- 06Keep passwords, payment keys, and staff access codes away from files sent to visitors.
- 07Record the customer, product, payment reference, status, and access end date.
- 08Review every manual access grant and give it an end or review date.
- 09Ask your AI builder to identify any decision based only on information saved in the browser.
- 10Use VibeCodeWall to check the public app from the outside and watch for important changes over time.
FAQ
Can the browser remember that a customer has a paid plan?
Yes, it may remember that information to display the page quickly. The protected server must still check the trusted purchase record before delivering each paid result.
What should happen after a refund or cancellation?
Update the trusted purchase record according to your business policy. Then test whether access ends immediately or on the recorded end date, whichever your policy promises.
Does every paid download need its own check?
Yes. Check the signed-in customer and current purchase whenever the file is requested, even if the customer previously visited a paid page.
How should I record free access given by my team?
Record the customer, allowed product, reason, approver, and review or end date. Test it like any other access and remove it when it is no longer needed.