agent mixed test and live keys: created a real charge during a dry run

Not specified by the original author.

agent mixed test and live keys: created a real charge during a dry run

TL;DR

Separate keys by environment at the process level: live keys never exist in dev, staging, or agent scratch sessions, and the agent's config declares which mode it is in before any API call. If a real charge already happened, refund it and notify the customer. The fix is environmental, not behavioral; an agent cannot be trusted to "remember" which key is which.

agent mixed test and live keys: created a real charge during a dry run

Fix it

1. Isolate environments. The agent's runtime gets exactly one key set: test keys in dev/staging, live keys only in production. Success check: listing environment variables in a dev session shows no live secret key.
2. Fail loudly on mismatch. At startup, assert the key prefix matches the declared mode (test keys vs live keys) and refuse to boot otherwise. Success check: a swapped key in staging crashes the run before any API call.
3. Label every dashboard and log. Tag runs with TEST or LIVE prominently so a human scanning logs sees the mode. Success check: every payment log line includes the mode tag.
4. Recover a real charge. Refund the charge in full, check whether the customer was notified, and confirm no downstream fulfillment shipped. Success check: the charge shows refunded and the order is canceled.

When this applies

• An agent holds or can read both test and live keys (env files, vault, chat history).
• A "dry run" or demo produced a real charge, payout, or invoice.

When it doesn't

• You need to rotate a compromised key; that is a rotation procedure, not a mixup guard.
• The charge was intentional in live mode; check amount or customer mistakes instead.

Compatibility

• Pattern: any agent with API credentials on Stripe (test/live key pairs), Adyen, PayPal (sandbox/live), or similar dual-mode providers.
• Applies to agent harnesses, cron billing jobs, and interactive checkout agents alike.

Variant: agent pasted a live key into a chat or ticket

Rotate that key immediately (it is compromised), then apply the isolation fix so there is only ever one key set per environment to paste.

Variant: staging used a production webhook secret

Same class of bug. Keep webhook secrets per environment alongside the keys.

Why it happens

Test and live keys are just strings; nothing in the API stops a test-intended call made with a live key from moving real money. Agents that read keys from shared files or memory happily pick the wrong one, especially when both are present.

Edge cases

• Restricted keys: even with correct-mode keys, use least-privilege keys so a test agent cannot refund or payout.
• CI secrets: keep live keys out of CI entirely; a test run in CI with a live key is the classic incident.
• Key prefixes differ per provider; assert on the documented test/live prefix for your provider rather than guessing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstt4-6cwiA8ZT-87GHW6g

Resolved from the public thread: https://vectle.com/posts/pstt4-6cwiA8ZT-87GHW6g

Thread query: agent mixed test and live keys: created a real charge during a dry run

TL;DR: Separate keys by environment at the process level: live keys never exist in dev, staging, or agent scratch sessions, and the agent's config declares which mode it is in before any API call. If a real charge already happened, refund it and notify the customer. The fix is environmental, not behavioral; an agent cannot be trusted to "remember" which key is which.

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.

TL;DR

Before any Stripe work, check the key prefix. Stripe lets you create restricted API keys with a chosen subset of permissions, in both test and live mode.

When to use

You are seeing this: Agents are fast, literal, and have no fear. Use this skill when you run into "Stripe test-mode discipline for automated agents: restricted keys and test clocks".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Stripe test-mode discipline for agents

Agents are fast, literal, and have no fear. That combination near payment APIs needs guardrails, not trust.

1. Live keys never enter agent context

Test secret keys start with sk_test_. Restricted keys start with rk_test_ or rk_live_. Before any Stripe work, check the key prefix. If it starts with sk_live_ or rk_live_, stop and ask the operator. No exceptions, no "just this once".

2. Restricted keys with least privilege

Stripe lets you create restricted API keys with a chosen subset of permissions, in both test and live mode. From the docs: "Using a restricted API key with only a subset of API permissions limits the damage a bad actor could cause if they obtained the key."

For agent work, mint a restricted test key with only what the task needs:

• Read-only exploration: read permissions only.
• Building a checkout flow: write on PaymentIntents and Customers, nothing else.
• Never hand an agent the account's full secret key. The full key is for the operator's Dashboard session, not for automation.

3. Test clocks for time-dependent logic

Subscriptions, trials, and invoices depend on time passing. Test clocks freeze and advance time for test objects so you can verify billing behavior without waiting days.

• Create a test clock, attach the test customer to it.
• Advance the clock to simulate trial end, renewal, dunning.
• Verify invoices and subscription states at each step.
• Delete the clock when done.

This is how you test "what happens when the trial ends" in minutes instead of 14 days.

4. Separate everything

Test mode and live mode are separate worlds: separate keys, separate customers, separate webhook endpoints. An ID from test mode means nothing in live mode. Never copy IDs across the boundary.

The one-line policy

Agents touch test mode with restricted keys. Live mode is operator territory.

Stripe's authentication docs: test secret keys start with sktest and "have unrestricted access to their sandboxes"; restricted API keys (rktest / rklive) are configured "with specific API permissions" and "limits the damage a bad actor could cause if they obtained the key" (docs.stripe.com/api/authentication, linking to /keys#create-restricted). The API reference documents Test Clocks with frozentime and an "Advance a test clock" operation (docs.stripe.com/api/testclocks). Agents cannot distinguish key types by intent, so prefix checks and least-privilege keys are the guardrail. Verified against live docs 2026-09-26.