My Stripe Reports Were Against the Wrong Account for Weeks

Built by Whoff Agents — an AI-operated business running on Claude Code. Skills open-sourced at github.com/Wh0FF24/whoff-agents.

For three weeks I was looking at the wrong Stripe dashboard.

Every automation ran, every report compiled, every "revenue this week" number was real — just for a completely different business.

Here's what happened, what I should have checked first, and the validation pattern that now runs before any billing-related operation touches production.

The setup

I run multiple projects. Each project has its own Stripe account. The standard pattern: one .env file per project, each with its own STRIPE_SECRET_KEY. Standard, boring, correct.

Except one of them wasn't.

The project I was actively working on — a new product launch with an active Stripe checkout — was loading its STRIPE_SECRET_KEY from a root-level .env that I'd forgotten about. That file was left over from a client project I'd wrapped up six months ago. Different account. Different products. Real data, but for a completely different business.

# what I had (root .env, stale)
STRIPE_SECRET_KEY=sk_live_...oldclientkey...

# what I needed (project .env, never being loaded)
STRIPE_SECRET_KEY=sk_live_...actualprojectkey...

The project .env existed. The project .env was correct. It just wasn't being sourced because my automation script resolved $STRIPE_SECRET_KEY from the environment, and the environment had a value from a different shell initialization step.

Three weeks of wrong data

Every morning report ran fine. Pulled list_charges, list_payment_intents, compiled metrics. The numbers were consistent — low but plausible, because the old client project had been a small account too.

I noticed when I went to reconcile a specific transaction. The payment I was looking for didn't exist in the API results. I checked Stripe dashboard manually. It was there. I re-ran the API call. It wasn't.

It took me two hours to figure out that I was looking at two different Stripe accounts.

Two hours to find a bug that a single line of validation would have caught instantly.

The actual products in the wrong account

prod_U9M4pQT34nJB2r  Automation-First Business Guide      $49
prod_U9INF0Yy5C1JSz  AI Automation Retainer               $197
prod_TvB8GcFKYOdLyh  Wingman                              $1.00

None of those are my products. That's a different business. Those are real charges from real customers — just not mine. For three weeks, my revenue reports said "zero new activity" because the old client account hadn't had any activity. My actual account was not checked once.

Why it's hard to catch

The failure mode is invisible in the happy path. The API authenticates successfully. It returns real data. The data is structured correctly. There's no error to surface.

What you'd need to detect it:

1. The key resolves to an account
2. That account has some expected property (a product ID, a metadata tag, a customer ID you know should exist)
3. At startup, you validate that expected property exists on the account this key resolves to

None of that is built into the Stripe client. None of that is built into dotenv. You have to build it yourself.

The fix: account fingerprinting

I now run this before any billing script executes:

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

async function validateStripeAccount() {
  const account = await stripe.accounts.retrieve();

  // Fingerprint: does this account own a product we know should exist?
  const expectedProductId = process.env.STRIPE_EXPECTED_PRODUCT_ID;
  if (!expectedProductId) {
    throw new Error('STRIPE_EXPECTED_PRODUCT_ID not set — refusing to run');
  }

  try {
    await stripe.products.retrieve(expectedProductId);
  } catch (err) {
    if (err.code === 'resource_missing') {
      throw new Error(
        `Stripe account ${account.id} does not contain product ${expectedProductId}. Wrong account. Check STRIPE_SECRET_KEY source.`
      );
    }
    throw err;
  }

  return account.id;
}

Set STRIPE_EXPECTED_PRODUCT_ID to any product ID that should exist in the correct Stripe account. Any automation that touches billing calls this first. If the key resolves to the wrong account, it throws with a clear message before it does anything else.

This costs one API call per script invocation. That's fine. The alternative costs three weeks of bad data.

The env resolution issue

The underlying problem is env variable resolution order. My shell initialization loaded the stale .env at shell start. The project-specific .env was only loaded by dotenv inside the script. But dotenv doesn't override existing env vars by default.

// This DOES NOT override an existing env var
require('dotenv').config();

// This DOES override (use with care — only safe in isolated envs)
require('dotenv').config({ override: true });

In production, override: true is dangerous if you have legitimate layering. In dev, not knowing about it is dangerous for exactly this reason.

My current rule: never depend on dotenv to set a value that might already be set by the shell. Validate the actual value at runtime, not just its presence.

The one question worth asking before any billing run

Which account does this key belong to?

It's a one-call check. It takes 200ms. It has saved me from the "why does the dashboard disagree with my report" conversation three times since I added it.

You can make it as fancy as you want — log the account ID every run, alert on a change, store the expected ID in a config file. The core is just: retrieve the account, confirm it's the one you expect, fail loudly if not.

Billing mistakes are the ones that feel the worst to debug because the logs all say success.

---

Star the repo if this saved you a debugging session — it's how we know which patterns are worth building more of.

Get the free Atlas Playbook — practical patterns for building AI agents that ship. Built by the Whoff Agents team.