Practical guide
Login, database or payment problems in an AI-built web app
Login, database and payment problems cross trust boundaries. Avoid experimenting with live customer records or real charges while trying to isolate the fault.
Understand the problem
Login, database and payment features connect parts of an application that do not automatically trust each other. A working screen does not prove that the signed-in user is allowed to read a record, that a database change completed, or that a payment event was processed once.
Investigate each boundary separately with test identities and provider test modes. Do not copy secrets into prompts or tickets, and do not retry uncertain actions against real users or real money.
A signed-in user can open another account’s record
The dashboard hides links to other accounts, but changing an identifier in the address opens a record owned by someone else.
- Create two disposable test identities in an isolated environment.
- Request each record as its owner and record the permitted result.
- Request the same records as the other identity and record the denied result.
- Inspect the server-side ownership check rather than relying on hidden navigation.
The route checked only whether someone was signed in. The repair adds a server-side ownership decision and tests both permitted and denied requests.
Safe ordered checks
Work from evidence, one layer at a time
- 1. Name the boundary
For login, separate identity, session and authorization. For data, separate validation, write and ownership. For payments, separate checkout, provider confirmation, callback processing and internal access.
- 2. Use safe test conditions
Use disposable identities, isolated records and provider test mode where available. Never test with a real charge or another customer’s data.
- 3. Capture the smallest useful evidence
Record the route, response status, time and synthetic test identity. Remove tokens, cookies, personal text and full private response bodies.
- 4. Check configuration by environment
Confirm that local, test and production settings use the intended service, callback URL and credentials without displaying the credential values.
- 5. Test success and refusal
A secure result includes the action that should work and the similar action that must be denied. Also test logout, expired sessions and repeated callbacks where they matter.
Reading the result
What different findings might mean
- Login succeeds but another user’s record opens
- Authentication works, but server-side authorization is missing or incomplete.
- The write appears successful and then disappears
- The database transaction may be rolling back, writing to another environment or failing after validation.
- Payment succeeds at the provider but access is missing
- The callback, signature check, duplicate handling or internal entitlement update needs inspection.
- The issue happens only after deployment
- Environment names, callback URLs, runtime versions or persistent storage assumptions may differ.
When to involve a developer
- Any test could affect real users, money or private records.
- One user can see or change another user’s information.
- A payment callback may repeat a business action.
- A production secret may have been exposed and needs controlled rotation.
Share the affected user action, the safe test evidence and the environment where it fails. Keep credentials and private response content out of the enquiry.