How I Fixed a Stripe Checkout Bug That Stopped Payment Buttons

I have a commit message that describes, in real detail, testing a payment flow end-to-end — a real Stripe Checkout session, completed with Stripe's own test card, a webhook replayed with a correctly signed header, and the resulting database row confirmed to hold the right plan, provider, and currency. A little over an hour later, the same night, none of that mattered: the buttons meant to get a visitor to that checkout in the first place were silently broken.

A plan, written the same afternoon

Hours before any of this shipped, a planning document was written out with a specific pricing structure for a US/UK expansion — a free tool as an acquisition funnel, feeding into a paid tier at $9, $19, and $39. When the code landed that night, the price points in it were exactly $9, $19, $39. The first commit's own message says as much directly: it exists to "seed the US/UK acquisition funnel described in the expansion plan." I'm not going to claim more certainty than that gives me about how closely the document was followed while typing, but the same-day timing and the exact match aren't circumstantial in the way most of what I can't explain in this series has been.

Built in two honest phases

The first commit added a free, anonymous ATS resume checker — no signup, IP rate-limited, nothing persisted, built by pulling the existing authenticated scoring logic into a shared, stateless core. India's pricing and copy were left untouched. Eleven minutes later, because the actual USD/GBP checkout didn't exist yet, the checker's upgrade button pointed at a prefilled email link instead — stated plainly in the commit as a stopgap, not a finished feature.

Thirteen minutes after that, real Stripe billing landed — deliberately built as its own separate integration next to the existing Razorpay flow, not merged into one abstraction. The reasoning is in the commit itself: the two providers' checkout flows are different enough — one verifies an order client-side, the other redirects to a hosted page and waits for a webhook — that unifying them for just two providers wasn't worth doing. The one thing kept consistent on purpose: Stripe writes the same plan names Razorpay does, so nothing downstream had to change. The commit is explicit that none of it actually worked yet — no real keys, checkout would fail outright.

What "verified end-to-end" actually meant

Twelve minutes later, real test-mode price IDs went in, and the same commit describes exactly what got tested: a live Checkout session, paid with Stripe's 4242 test card, and the resulting webhook replayed with its signature checked — not just fired and assumed correct. The database row it produced is described specifically: the right plan, the right provider, the right currency, real Stripe identifiers. Three minutes after that, the Stripe secrets got wired into the deploy pipeline, and the ATS checker's button finally pointed at the real checkout instead of the stopgap email link.

Then, the same night, the funnel's own front door

At 23:26 — a little over an hour after the first commit — a separate bug got fixed: unauthenticated visitors clicking a pricing button were being redirected to the homepage instead of the login page. No error, no message. To anyone not already signed in, every "Get Starter," "Upgrade to Pro," and "Go Premium" button on the page looked like it simply did nothing. And a visitor arriving through the new anonymous ATS checker — the entire point of that evening's first commit — is, by definition, not signed in yet. The exact path the whole night's work was built to create had a dead end sitting on it the whole time.

What I still don't know

Whether the two secrets Stripe checkout actually needs in production were ever added to the deploy pipeline's real configuration is something the repository doesn't confirm — nothing after this date touches that part of the deploy setup again. I also don't know how long the redirect bug actually existed before this — it could have predated this entire evening. What I can say is that it sat on the funnel's exact path for the thirty-five minutes between the CTA pointing at real checkout and the fix landing, and I don't know whether anyone real hit it in that window. And I don't know how many people, if any, used the stopgap email link in the twenty-eight minutes before the real checkout replaced it.

The part I can say for certain: testing one piece of a launch thoroughly doesn't mean every piece got the same treatment, and the commit history here proves that as cleanly as anything in this log so far.