All posts

January 13, 2026 · 4 min read

I Took Over a Client Project. The Old Debug Flag Was Still Bypassing Payment.

A small business owner hired me last year to take over a project from a previous freelancer who'd stopped responding. Nothing dramatic, a simple storefront someone had vibe-coded to sell a handful of physical products online. Before I touched anything, I did what I now do on every handoff: read through the code start to finish before writing a single line, rather than just diving in to add the feature I'd been hired for.

The line I almost skipped past

Near the checkout logic, there was a constant near the top of the file: something like SKIP_PAYMENT_CHECK, set to true. Right above it, a comment explaining it had been added temporarily to test the order flow without needing real card details during development. Reasonable thing to add while building. The problem was the date on the git commit that introduced it. It had been sitting there, set to true, in the live production build, for around four months.

What that actually meant

Every checkout on that store had been going through as if payment succeeded, regardless of whether a card was actually charged. For a small store with careful order fulfillment, that had apparently mostly gone unnoticed. Whether it had actually been exploited by anyone, or just quietly broken correctly-behaving customers' orders without anyone connecting the dots, I couldn't fully tell from the data available. Either way, it meant four months where anyone who found the checkout flow interesting enough to poke at could have ordered anything, for free, with no card required at all.

Why it happened the way it did

I don't think the previous developer was careless in any unusual way. This is exactly the kind of thing that happens when a flag gets added for a real, sensible reason during development, and then the project moves fast enough that nobody circles back to remove it before shipping. AI coding tools make this specific failure mode more likely, not less, because they'll happily leave a flag exactly where you told them to put it, forever, unless someone explicitly asks them to take it back out.

What I do differently on every handoff now

  • Search the entire codebase for any variable with words like SKIP, BYPASS, DEBUG, or TEST in the name, and check what each one actually does and whether it's still active.
  • Check the git history on anything payment-related specifically, not just the current state of the file, since a flag that looks intentional in isolation often has a very telling commit message from months earlier.
  • Actually run through a real checkout myself, on the live site, watching the payment processor's dashboard the whole time, to confirm a charge really happens rather than assuming the code does what it appears to do.
  • Ask directly, of anyone still reachable from the previous build, whether any temporary flags or shortcuts were ever added and possibly never removed.

The fix took thirty seconds once I found it: delete the flag, delete the bypass branch entirely, ship it. Finding it took reading code nobody had asked me to read yet, on a project I hadn't been hired to review, just because inheriting someone else's app without checking what's actually in it seemed like an obviously bad idea. It still surprises me how rarely that step happens before a handoff.

Related reading

Harbova is a security service for apps built with AI tools. Start with a free scan, and if it finds something serious, we can fix it and prove it is closed.