The Objection That Kept a Billing Bug Alive Was Never Checked

An offer that expired on its own

A client’s plan offer in our billing system went to Cancelled about 23 hours after it was created, while a status card in our notes still read as open. The other agent described the failure plainly: no error to the customer, no alert to staff, and the client’s page just goes blank.

Our agent confirmed the cause in our own code. We created each offer as a real Stripe subscription with payment_behavior: "default_incomplete". Stripe holds an unpaid subscription like that open for 23 hours and then lets it expire. That is the right behavior when someone is on the page right now. It is the wrong tool for “here is your offer, pay when you are ready”.

The objection nobody had checked

The fix that was skipped: stop making Stripe the home of the offer. According to our agent, the other side skipped building it because of our remark on 08-28: don’t bounce a client to Stripe’s bare page. That objection was marked unverified.

Our agent read the Stripe SDK already in our repo. The type definitions showed UiMode = 'custom' | 'embedded' | 'hosted'. Checkout can render embedded inside our own /plan page, and nobody gets redirected. Its conclusion: the objection that stopped the fix is not real.

The same session corrected a few other things. The other agent had said there was no test mode for this integration. Our agent checked and the sk_test_ key worked. It also found five incomplete_expired subscriptions on the live account and nearly told us the bug had hit five times. Four were test fixtures. The only real client it had happened to was the one.

What changed

An offer is now a row in client_plans and touches Stripe not at all. The client pays through embedded Checkout on our own page, so nothing exists in Stripe until money moves, and there is no unpaid object left to expire. A webhook records what happened into an append-only client_charges. The old invoice tables, pages and both staff commands that raised Stripe invoices were deleted. The commit message says four other board items were the same bug counted again.

Review before shipping caught real problems. Checkout was pricing from the catalog rather than the offer, so staff could offer any amount and the client would have been billed the catalog price instead, now and monthly. The commit message says it was verified fixed by offering a different amount for a catalog product and confirming that Stripe’s own form showed the offered total. Refunds were being dropped. Tenant database policies let a client write its own plan.

What we did not verify

Typecheck was clean and 491 tests passed, but 364 database-backed tests are skipped on that machine, a gap that already existed. Our agent tested against a cloned database branch and a Stripe sandbox. Production was healthy with 2 plans live and 0 charges, because nobody had paid yet. No real payment had gone through production, so that path was not exercised. Our agent framed a rehearsal payment as the first charge for that reason, so it would be our own money and not a client’s.

Takeaway

Find one reason your team gives for not fixing a known bug, such as “we can’t do X because of Y”. Then open the library or API docs and check Y yourself. Ours was a single type definition.

dxdev LESSON · paste into your AI coding agent
LESSON: Own Entitlement State Outside Your Payment Processor
SOURCE: dxdev.com/blog/billing-state-must-be-owned
WHAT HAPPENED: Plan offers were pre-created as unpaid Stripe subscriptions in `default_incomplete`. Stripe expired one after 23 hours with no error and no alert, and the fix had been skipped because of an unverified belief that Checkout would bounce clients to a bare Stripe page. Reading the Stripe SDK showed Checkout can render embedded in our own page. The offer became a row in our database, the client pays through embedded Checkout, and nothing exists in Stripe until money moves. It was tested on a cloned database branch and a Stripe sandbox, and nobody had paid on production yet.
THE RULE: Keep entitlement and offer lifecycle state in your own durable database, even when a payment processor handles payment. Treat processor events as inputs that update local state, and make disagreements between the two systems visible reconciliation failures.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Each customer offer has a local database record before any payment processor subscription or payment is created.
      2. Your application determines plan access from locally stored entitlement state rather than directly from payment processor subscription status.
      3. Any disagreement between the local offer record and the payment processor is visible to you as two records you can compare.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.