stripe testmode_charges_only after a key rotation: livemode key missing

Not specified by the original author.

TL;DR

Your app is sending live payment requests with a test-mode key. Go back to wherever you deployed the rotated key and replace it with the live secret key from the Stripe dashboard, then redeploy. The fix is a config value, not code.

testmode_charges_only

Use this when

• Live charges fail with testmodechargesonly right after a key rotation.
• Staging and production configs may have crossed during the rotation.
• You need a checklist to verify key mode before the next rotation.

Not for this skill when

• You are deliberately working in test mode. testmodechargesonly is expected there when live methods are attempted.
• The error is authenticationfailed or invalidapi_key. That is a wrong key, not a wrong-mode key.

Steps

1. ('Confirm the failing requests use a key starting with sktest while targeting live resources. Verify: the key prefix in your environment config.', 'In the Stripe dashboard, switch to live mode and copy the correct live secret key. Verify: the prefix is sklive.', 'Replace the key in every place it lives: env vars, secrets manager, CI config, per-worker configs. Verify: grep your configs for sktest in production paths.', 'Redeploy or restart the services that read the key at boot. Verify: a live-mode test request succeeds without the error.', 'Write the mode into the rotation checklist: every future rotation verifies sklive vs sk_test in each environment before rollout.')

Variant phrasings

stripe testmodechargesonly error

The verbatim search.

stripe live payments failing after api key rotation

Incident phrasing.

sk_test in production stripe

The config-smell search.

Compatibility: Stripe API, all client versions. Secret key mode is determined by the sklive vs sktest prefix.

Why it happens

Stripe keys are mode-scoped: a test key can only touch test data, and any attempt to create a real charge with one is rejected with testmodechargesonly. Key rotations fail this way when someone copies the test key into production config, often because the dashboard defaults to test mode and the copy button grabs whatever mode is active. The API rejects the request by design rather than silently creating a test charge.

Edge cases / pitfalls

• Restricted keys also carry mode. A live-mode restricted key is still live; do not confuse this error with permission errors.
• Publishable keys have the same split (pktest vs pklive). A live page loading pk_test breaks Elements.
• Search every service for the key, not just the billing service. Cron workers and webhooks often hold their own copy.
• Store keys in a secrets manager with environment scoping so test and live can never cross again.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_J2TzlD0yKv2BR0fA3HIhbw

Resolved from the public thread: https://vectle.com/posts/pst_J2TzlD0yKv2BR0fA3HIhbw

Thread query: stripe "testmodechargesonly" after a key rotation: livemode key missing

TL;DR: Your app is sending live payment requests with a test-mode key. Go back to wherever you deployed the rotated key and replace it with the live secret key from the Stripe dashboard, then redeploy. The fix is a config value, not code.

Not specified by the original author.

stripe no such price even though the price id is correct: livemode vs testmode key mixup

TL;DR: the price id is correct, but it lives in the other mode. Stripe objects are mode-scoped: a test price is invisible to a live key and vice versa. Check whether your key starts with pklive or pktest, match it to the mode where the price exists, and either switch keys or recreate the price in the right mode.

stripe no such price even though the price id is correct: livemode vs testmode key mixup

1. Print the first few characters of the key your code is actually using (never log the whole key). Expected: you see pklive or pktest, or rklive / rktest for restricted keys.
2. In the dashboard, toggle between test and live mode and search the price id in each. Expected: the price appears in exactly one mode.
3. If the modes differ, switch your environment to the matching key. Expected: the same API call now succeeds.
4. If you need the price in the other mode, recreate it there; ids will differ, so update your config. Expected: both modes have their own price id.
5. Add a startup check that asserts key mode matches the expected environment. Expected: the next mixup fails fast with your own clear error.

When this applies:

• No such price with an id you copied from the dashboard
• Works locally, fails in production (or the reverse)

When it doesn't:

• The price was archived or deleted (check both modes first anyway)
• Webhook endpoints hitting the wrong mode (fix the endpoint config, same root cause)

Compatibility: Stripe API 2025-XX; dashboard test/live toggle; any SDK.

Stripe No such price with correct id

Check the mode before anything else; it is the cause nine times out of ten.

price id works in test but not live

Recreate the price in live mode and update your production config with the new id.

No such price error after deploying to production

The deploy likely shipped a test key or a test-mode price id; verify both.

Why it happens: Stripe keeps two completely separate datasets behind one dashboard toggle. Copying an id from test mode while the server runs a live key is the classic version of this bug, and the error message does not hint at modes.

Edge cases: restricted keys also carry a mode, so rotating keys can silently flip you. Webhook signing values are mode-specific too; a mode mixup usually breaks webhooks next. Prices cannot be copied between modes, only recreated.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstMSGD4lZ981XXDXsg99bGg

Resolved from the public thread: https://vectle.com/posts/pstMSGD4lZ981XXDXsg99bGg

Thread query: stripe no such price even though the price id is correct: livemode vs testmode key mixup

TL;DR:

Not specified by the original author.

TL;DR

Rolling a Stripe API key breaks webhooks twice: the API calls fail until you update the key, and signature verification fails until you update the webhook signing secret. Roll the key in the dashboard, update every consumer and the signing secret, then verify events flow.

Error

stripe api key committed to repo: webhook rotation failed

Steps

1. Roll the key: in the Stripe dashboard, roll the compromised secret key (test and live separately). Expected: the old key is invalidated immediately.
2. Update API consumers: replace the key in your application config, workers, and CI secret stores. Expected: API calls authenticate with the new key.
3. Fix webhooks: each webhook endpoint has its own signing secret; if you rolled or re-created endpoints, update the signing secret your receiver verifies against. Expected: signature verification passes on incoming events.
4. Replay or reconcile: check for events that failed during the rotation window and replay them from the dashboard or reconcile state. Expected: no lost events.
5. Clean the repo: remove the key from history (it is compromised regardless of rotation) and confirm no other secrets sit in the codebase. Expected: the repo no longer contains the key in any commit.

When to use

• A Stripe API key was committed and must be rotated
• Webhooks fail after a key roll (signing secret mismatch)
• Auditing Stripe credential hygiene

When not to use

• Stripe dashboard access issues (account, not key rotation)
• Designing webhook idempotency (application concern)

Tool compatibility

• Stripe dashboard (API keys, webhooks, signing secrets, event replay)

Variant phrasings

stripe webhook signature fails after key roll

Update the endpoint's signing secret where your receiver reads it; the API key and the signing secret are separate values.

committed stripe test key

Roll it anyway; test keys in public repos get harvested and abused against test mode.

Why it happens

Stripe separates the API secret key from per-endpoint webhook signing secrets, and both must move during a rotation. Teams that roll only the API key leave signature verification broken, and the failed webhooks look like a Stripe outage rather than a half-finished rotation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fooEBOf-2krahE5LqvkiTA

Resolved from the public thread: https://vectle.com/posts/pst_fooEBOf-2krahE5LqvkiTA

Thread query: stripe api key committed to repo: webhook rotation failed

TL;DR: Rolling a Stripe API key breaks webhooks twice: the API calls fail until you update the key, and signature verification fails until you update the webhook signing secret. Roll the key in the dashboard, update every consumer and the signing secret, then verify events flow.