All third-party services are on production plans

Launching with sandbox or test-mode third-party integrations means the application appears functional but produces no real outcomes: Stripe test keys accept payment flows that charge nobody, email sandbox providers accept API calls that deliver nothing, and development OAuth apps reject real user tokens. CWE-798 and OWASP A05 cover misconfigured credentials as a security defect, but the business impact here is more immediate — users complete onboarding flows, enter payment details, and receive no confirmation, then churn. Every sandbox-mode integration is a silent conversion killer.

Verify each integration's production credentials before launch and trigger a real end-to-end test after switching.

// lib/stripe.ts — confirm production key
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)
// STRIPE_SECRET_KEY must start with sk_live_, not sk_test_

Checklist: Stripe STRIPE_SECRET_KEY starts with sk_live_; Stripe webhook endpoint registered in production dashboard points to your production URL. Email provider uses production API key (not sandbox). OAuth apps (Google, GitHub) are production apps with your real domain in authorized redirect URIs. Storage buckets are production buckets, not development. After switching every credential, trigger a complete user journey: sign up, payment, confirmation email.

• ID: pre-launch.final-verification.third-party-production

• Severity: medium

• What to look for: Count all third-party service integrations (Stripe, auth providers, email, storage). Enumerate which are configured with production API keys vs. test/sandbox keys. Check for common third-party service integrations and their plan/mode indicators. Look at: Stripe configuration (test mode vs live mode patterns in env var naming), email provider setup (test API keys vs production), authentication providers (development OAuth app vs production), storage configuration (development bucket vs production), feature flag services (development vs production environment), and any other third-party SaaS integrations. Check for "sandbox", "test", "dev", "staging" indicators in service-related environment variable names in .env.example.

• Pass criteria: All detected third-party service integrations appear configured for production use, or the project has no third-party service integrations. 100% of third-party integrations must use production API keys.

• Fail criteria: Evidence of test/sandbox/development-mode configurations for services that process real user actions (payments, communications, authentication).

• Skip (N/A) when: Never for projects with third-party integrations. Skip only if no third-party service integrations are detected.

• Cross-reference: For environment variable configuration, see env-vars-production.

• Detail on fail: "Third-party service integrations appear to be in test/sandbox mode based on environment variable patterns — users may interact with services that do not perform real actions"

• Remediation: Running production with sandbox services means payments don't charge, emails don't send, and auth flows may use test certificates:

  // lib/stripe.ts — ensure production mode
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)  // Must be sk_live_*, not sk_test_*
  

  1. Stripe: Verify STRIPE_SECRET_KEY starts with sk_live_ (not sk_test_). Update webhook endpoints from Stripe dashboard to point to your production URL.
  2. Email providers: Ensure API keys are production keys, not sandbox keys. Verify sender domain authentication is complete.
  3. OAuth providers (GitHub, Google, etc.): Ensure you're using a production OAuth app with your real domain in the authorized redirect URIs, not a development app with localhost.
  4. Storage (S3, Cloudflare R2, etc.): Ensure you're using a production storage bucket, not a development one.
  5. Trigger a real end-to-end user journey after switching to production credentials to confirm all integrations work.