The Most Expensive Green Build: When Checkout Is Broken but CI Passes

Hypothetical scenario (not a customer case study)

A team ships a CSS refactor. Unit tests pass. Typecheck passes. Vercel preview deploys. CI is green.

On the preview, Add to cart still increments a badge, but Place order no longer navigates to confirmation — or the payment handoff never returns.

No dollar figure is claimed here. The cost structure is obvious without inventing revenue:

• every failed purchase attempt is lost intent
• support load rises
• trust erodes faster than a red unit test ever would

This is a mechanism article, not a measured customer outcome.

Why CI can stay green

Checkout breakage often lives in layers unit tests never enter:

• client routing after payment redirect
• cart state hydration
• third-party payment iframe / test-mode handoff
• confirmation page feature flags

If nothing in CI drives a browser through that path against the preview, the suite cannot see it.

What Endia’s example library checks (demonstration)

The public e-commerce example defines 9 checks, including add-to-cart, cart persistence, totals, payment step, and confirmation visibility.

The Stripe test-mode example defines 7 checks, including start checkout, test payment, success return, subscription fixture state, cancel path, and no secret leakage in UI. It is labeled test mode and does not use live charges.

These are neutral fixtures showing what a critical-flow gate can verify. They are not proof that a named merchant saved a named amount of money.

How to test it

1. Record the happy path: product → cart → checkout → test payment → confirmation.
2. Run it on every preview that touches cart, pricing, or payment UI.
3. Fail the PR when confirmation never appears or totals diverge.

Limitations

• No fabricated “$X lost per minute” statistics.
• Fixture checkouts are not production Stripe integrations.
• Passing the example flow on Endia’s demo does not certify your storefront.

Checklist

• [ ] Confirm CI includes at least one browser path through purchase confirmation.
• [ ] Separate unit “price calculator” tests from “customer can pay” verification.
• [ ] Keep payment verification in test mode until you intentionally promote.