Payment test mode key

Why it matters

Your published JavaScript contains {marker}, so payments on this site are being sent to {provider}'s test environment. Checkout will look like it works — the form submits, the card is accepted, a success page renders — but no money is ever charged and nothing reaches your account. This is not a security problem; it is a revenue one, and it is usually discovered when someone asks why a week of signups produced no payments. If the URL scanned was a staging or preview deployment rather than production, this is expected and can be ignored.

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 — Stripe's `pk_test_` prefix, Paddle's sandbox environment call, Polar's sandbox API 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. 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.0.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 live site is configured against {provider}'s test environment, so no payment made on it ever reaches your account. Find where the {provider} key or environment is set in your frontend — usually a NEXT_PUBLIC_/VITE_ prefixed environment variable, or an initialisation call in your checkout component — and point production at your live credentials. Set the live value in your hosting provider's production environment variables (Vercel, Netlify, Railway), keep the test value for local development and preview deployments only, and redeploy. Then verify with one real low-value transaction that money actually arrives, and check it appears in your {provider} dashboard's live view rather than the test view.

Frequently asked questions

What does "Payment test mode key" mean?

Your published JavaScript contains {marker}, so payments on this site are being sent to {provider}'s test environment.

How serious is it?

ShipReady rates this high. Fix before launch. A real weakness that an attacker can act on.

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.

Related checks

• Both live and test Stripe keys are shipped to the browsermedium