Checkout request sends an amount built in the browser

Why it matters

Client-side JavaScript on this page sends a request to `on your site` carrying a `amount` value in its body. The browser is not a trusted source for what something costs: anyone can pause the code, edit that value, or replay the request with a different number. Whether it is exploitable depends on code this scan cannot see — if your endpoint looks the price up from the product record and ignores what was posted, you are fine; if it charges the amount it receives, people can pay whatever they like. Worth confirming either way, because the request looks identical in both cases. The durable fix is to send an identifier for what is being bought (a product or price ID) and let the server decide the amount.

How ShipReady detects it

Payment configuration that stops money arriving. The failure this pillar exists for is mundane and catastrophic: a live site wired to a payment provider's TEST environment. Checkout appears to work, the form submits, a success page renders — and no money ever moves. It survives launch because the developer's own testing passes perfectly, and it is usually found when a founder wonders why a week of signups produced no revenue. Deliberately narrow. Every rule here keys off a marker that is definitionally a test credential — Razorpay's `rzp_test_` prefix, Paddle's sandbox environment call, Adyen's test Checkout host. None of them require interpretation, none of them can appear in a correctly configured production deployment, and none of them involve touching the payment provider or attempting a transaction. One marker is shared rather than definitional: `pk_test_` is issued by BOTH Stripe and Paystack. It still proves test mode, so it is still reported — but the provider is resolved from what the page actually loads rather than assumed from the prefix (see _publishable_key_provider). NOT checked, deliberately: whether a checkout page exists or is reachable. Payment routes have no convention — /checkout, /pricing, /billing, /upgrade, /subscribe are all common and most sites have none of them. Probing a list of guesses and reporting the 404s would produce noise on nearly every scan, which is the opposite of what this pillar is for.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.4.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

Your client-side JavaScript sends a `amount` value to a checkout endpoint, which means the amount to charge is being decided in the browser. Anyone can pause that code, change the value, or replay the request with a different number, so the endpoint must never trust it. Fix it on the server: accept an identifier for what is being bought — a product ID, or a Stripe/Paddle/Polar price ID — and look the real amount up from your database or the provider's catalogue when you create the charge. With Stripe that means passing `line_items: [{{ price: 'price_xxx', quantity: n }}]` to checkout.sessions.create rather than a `unit_amount` computed client-side. Quantity is fine to accept from the browser; the unit price is not. Then verify it: intercept your own request, halve the amount, and confirm the order is either rejected or charged the correct price. If it charges the altered amount, treat it as urgent and check past orders for prices that do not match your catalogue.

Frequently asked questions

What does "Checkout request sends an amount built in the browser" mean?

Client-side JavaScript on this page sends a request to `on your site` carrying a `amount` value in its body.

How serious is it?

ShipReady rates this medium. Fix soon. Meaningfully weakens a defence or degrades how the site works.

How do I fix it?

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• A payment form submits over an unencrypted http:// connectionhigh
• Card details are collected by your own page, not a hosted payment fieldhigh
• Payment test mode keyhigh
• Working discount codes are compiled into the browser bundlehigh
• A PayPal order is priced in the browsermedium
• Both live and test Stripe keys are shipped to the browsermedium