Group
  • Payments

    Separate test and live payment modes completely

    Locks test keys and live keys to their environments so test charges can't hit real cards and vice versa.

    • Plan & validate
    • Improve quality
    • Beginner
    • General

Free Prompt

Audit my payment configuration for test/live mode separation. Check every environment's keys, webhook endpoints, and any mode flags. Verify and fix: each environment uses only its matching keys (development and staging get test keys, production gets live keys), loaded from environment variables with names that make the mode obvious; the code asserts at startup that the key's mode matches the environment (Stripe keys carry their mode in the prefix, sk_test_ versus sk_live_; refuse to boot on a mismatch rather than discovering it after charging someone); webhook endpoints are registered per environment with matching secrets (test-mode events can't trigger production handlers); and no test card numbers or test-mode shortcuts (skip-payment flags, fake checkout buttons) exist in production code paths. Don't put both key sets in one environment file with an if statement someone can flip. Don't leave a test-mode override query param reachable in production; if a staging payment test needs to bypass real charges, it belongs in staging only. Deliver: the per-environment key mapping, the startup mode assertion, the webhook endpoint audit, and verification: boot production config with a test key and confirm it refuses to start, and confirm production has no registered test webhook endpoints.

What This Does / How This Helps

Draws a hard line between test and live payment modes, enforced at startup, so a misconfigured environment can't charge real cards with test flows or leak test behavior into production. Mode mixups are a rite of passage for payment launches, and both directions are bad: production running test keys means nobody's actually being charged (free product, awkward emails), and a staging environment holding live keys means your QA flow just charged a real card. The startup assertion makes the mismatch impossible to boot with. The webhook audit matters too: events signed with the wrong secret or delivered to the wrong environment's endpoint create phantom state that's miserable to debug.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts