Payment Amount Check — Can Customers Set Their Own Price?
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee.
What the issue is
When the amount sent to Stripe comes from the request body, anyone can edit the request and pay 1 cent for the full product — authentication and receipts all still work, so nothing looks wrong until the money doesn't add up.
Why AI tools generate it
AI-generated checkouts often pass the pricing page's amount straight through, because Stripe accepts any number and the demo purchase succeeds.
How DevMeth detects it
A code scan finds Stripe checkout/payment-intent creation calls and flags any whose amount is sourced from request data without a server-side price lookup or Stripe's explicit client-adjustable/donation contract.
Your payment amount comes from the client — anyone can set their own price
WHAT WE FOUND
C35 — masked sample
The fix, in three steps
Look prices up server-side (Stripe Price objects or prices.retrieve), accept only a product identifier from the client, and make genuine pay-what-you-want explicit via submit_type donation. Three steps.
Run a free scan and each finding carries a paste-ready fix prompt you can act on.
Try a free scanFAQ
The amount is validated as a positive number — is that enough?
No. Range validation still lets the customer choose the number. The amount must be derived server-side from what they're buying.
How do tips or donations work then?
Genuinely client-set amounts are a product decision, not an accident: make them explicit in the Checkout Session (submit_type donation with adjustable quantity) so the intent is part of the API contract.
What's the fix?
Send a product/price id from the client, resolve the amount server-side from Stripe Prices, and charge only that.
DevMeth checks the 48 known AI-code failure patterns — not a penetration test or a security guarantee. A clear result means each known pattern was checked and found clear or not applicable for your app; it is not a guarantee of security.