A PayPal order is priced in the browser

Why it matters

This page creates the PayPal order in client-side JavaScript, with the amount written into `purchase_units` before the call is made. Whatever that figure is derived from, it passes through the browser — so a buyer can edit it in devtools and approve an order for a price they chose. This is not automatically a loss. It becomes one only if your server fulfils the order without re-checking what was actually paid, which is the common shape in generated checkout code: the client reports success, the app grants access. We cannot see your server from here, so treat this as a question to answer rather than a confirmed loss. The configuration PayPal recommends removes the question entirely: create the order on your server from your own price record, return only its id to the browser, and on capture verify the amount and currency server-side before you deliver anything.

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 PayPal order is priced in the browser. Move order creation to your server so the amount comes from your own price record, and verify what was actually paid before you deliver anything.

WHAT YOU HAVE NOW. A client-side integration builds the order in JavaScript:

    createOrder: (data, actions) => actions.order.create({
      purchase_units: [{ amount: { value: '19.99' } }]
    })

That value reaches PayPal from the browser, so it can be edited in devtools before the call is made.

WHAT TO REPLACE IT WITH. Two endpoints on your server, and a client that only knows an order id:

    // client
    createOrder: () => fetch('/api/paypal/orders', {
      method: 'POST',
      body: JSON.stringify({ productId })      // an ID, never a price
    }).then(r => r.json()).then(o => o.id),

    onApprove: (data) => fetch(`/api/paypal/orders/${data.orderID}/capture`, {
      method: 'POST'
    }).then(r => r.json()).then(result => { /* server already fulfilled */ })

On the server, look the price up from `productId` in your own database, call PayPal's Orders v2 API to create the order with that amount, and return only the id.

THEN VERIFY ON CAPTURE, which is the half people skip. When you capture, read the response back and confirm `purchase_units[0].payments.captures[0].amount.value` and `.currency_code` match what you expected for that product, and that `status` is `COMPLETED`. Fulfil only then. Do not trust `onApprove` firing in the browser as proof of payment — it means the buyer approved, not that money moved.

MAKE IT IDEMPOTENT while you are there: store the PayPal order id against the fulfilment, and refuse to deliver twice for the same id. A retried capture is normal and should not grant a second entitlement.

IF YOU KEEP THE CLIENT-SIDE FLOW — PayPal does support it — then the server-side amount check on capture is not optional. It is the only thing standing between a buyer's edited figure and your product.

Frequently asked questions

What does "A PayPal order is priced in the browser" mean?

This page creates the PayPal order in client-side JavaScript, with the amount written into `purchase_units` before the call is made.

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
• Both live and test Stripe keys are shipped to the browsermedium
• Checkout price is submitted from a hidden form fieldmedium