DEV Community

Cover image for Our CI mocked Stripe. Production still broke on step two.
FetchSandbox
FetchSandbox

Posted on • Originally published at fetchsandbox.com

Our CI mocked Stripe. Production still broke on step two.

Green CI. Broken staging. Sound familiar?

Our pipeline mocked POST /v1/payment_intents and asserted 200. Merge button enabled. First real checkout in staging failed because the handler never stored the PaymentIntent ID — step two of the webhook path read undefined.

Mocks proved shape. Not lifecycle.

What unit tests miss

CI check What it proves What it skips
Mocked fetch() Request JSON looks right Step 2 cannot read step 1's ID
Snapshot tests Handler code unchanged Webhook branch never runs
Manual smoke doc Someone remembers sometimes Agents ship faster than the checklist

The bug class: IDs do not chain across steps. Webhooks fire on mutations your mock never triggers.

What we run now — MCP locally, same workflow in CI

Before an agent touches payment code, we prove the provider flow in the IDE via FetchSandbox MCP:

quickrun stripe / accept_payment
→ create PaymentIntent
→ confirm / capture path
→ read back state
Enter fullscreen mode Exit fullscreen mode

That is the contract the integration must satisfy — not a paragraph in the PR description.

Then CI runs the same curated workflow headless:

# .github/workflows/api-integration.yml
- name: Prove Stripe integration before deploy
  run: npx fetchsandbox run stripe --all --json
Enter fullscreen mode Exit fullscreen mode

Exit code 0 → workflows passed, merge allowed.

Exit code 1 → named step failed (create_payment_intent, webhook reconcile, etc.) — PR blocked.

No staging dependency. No IP whitelist. No "works on my machine."

Why MCP belongs in the loop

Coding agents edit integration code constantly. Without a runnable proof:

  • The agent "fixes" the handler and moves on
  • CI mocks still pass
  • Production breaks on the path the agent never exercised

MCP gives the agent (and you) a receipt: sandbox timeline, step statuses, real provider-shaped IDs from the run — before opening the PR.

CI is the gate that keeps that proof from regressing on the next agent session.

What a workflow run actually checks

Not "does POST return 200 once."

  • Create a resource → mutate it → GET the same ID back
  • Trigger the webhook branch when state changes
  • Fail with a named step when auth or transitions break

That is integration testing — not HTTP cosplay.

What we stopped doing

  • Treating mocked unit tests as "integration covered"
  • Running only manual smoke before deploy
  • Letting agents merge Stripe/Resend/Clerk changes without a workflow receipt

Try it

Full write-up: API integration testing in CI

MCP + agent workflows: Agent API workflow testing

Install MCP in Cursor/Claude → run a Stripe workflow locally → paste the same npx fetchsandbox run step into Actions.


fetchsandbox.com · MCP setup

Top comments (0)