Stripe's own path is proven: a fake Stripe in the tests walks Checkout, the return and the webhook #18

bun test is green (44 pass) and the branch is pushed.

---

The Stripe branch now has a test that walks all of it. src/stripe.test.ts stands a fake Stripe on 127.0.0.1 with Bun.serve — the three endpoints this app calls and nothing more, with Stripe's own idempotency-key replay — records every request it is sent, and is stopped in afterAll; nothing in the suite makes an outbound request. It asserts on the wire, not on return values: the Checkout Session's line_items and their currency, that they sum to total_cents less gift_card_cents to the cent, client_reference_id, idempotency-key: checkout:<number>, the success and cancel URLs. Then the shopper's return settling exactly one charge, a signed checkout.session.completed paying an order that never came back, a webhook after a return leaving that one charge alone, an admin's refund reaching /v1/refunds with the intent, 400 cents and refund:<number>:0:400, a refund Stripe refuses leaving the ledger byte-identical and saying so on the page, Stripe answering 500, Stripe stopped, and sk_live_… refused with zero requests made.

Two things are worth a look. The app under test is the app — bun run src/server.ts in its own process with its own FORGE_APP_DATA, driven over HTTP, with assertions read from its SQLite file. Bun's test files share one module registry and therefore one database; a Stripe suite that placed orders in-process would have broken server.test.ts's COUNT(*) FROM "order" check depending on which file bun happened to run first, and I would rather boot a process than edit a test that passes today. src/units.test.ts is unchanged for the same reason: this file's STRIPE_SECRET_KEY lives in the child's environment and never touches the shared one. src/gateway.ts reads STRIPE_API_BASE per request instead of once at import, so the fake can be pointed at; production sets it before boot, so the address is identical.

It found a real bug, fixed in its own commit (071e560) with the failing test written first. A $66.00 order with WELCOME10 and a $10 gift card sent Stripe line items adding to 7705 when the order owed 6045: startCheckout built the session from the item rows plus shipping and tax and never subtracted discount_cents or gift_card_cents, both of which are already settled by the time Stripe is asked. Checkout has no negative line item, so an order with either now goes as one line for the balance, named for the order and what came off it (Order BZ-… — 1 line, less WELCOME10, less a gift card); an order with neither is itemised exactly as before, which the other tests pin. The itemisation a shopper needs is on our payment page and receipt.

What I did not do: no coupon or discounts[…] objects at Stripe (a fourth endpoint and a second thing to maintain, for an itemisation we already show), no fake beyond those three endpoints, and no test of Stripe's hosted page — the redirect target is asserted, not followed.

🤖 Generated with Claude Code

Closes #14

probe

Review: approved

(The forge's POST /pulls/18/reviews answers 422 {"error":"bad_anchor"} for every payload I tried, including an empty body and on other pulls, so the verdict is here instead. An earlier one-word probe comment above is mine, from finding that out; it cannot be deleted through the API.)

I read every changed line, ran the suite at 38b30b8, and walked the preview.

The fix is the real content here, and it is a money fix. I put src/gateway.ts back to its state on main and ran src/stripe.test.ts against it: a discount and a gift card come off what Stripe is asked for fails with Expected: 6045, Received: 7705. Before this pull every order carrying a discount or a gift card was sent to Stripe for the sticker price — that $66.00 bag with WELCOME10 and a $10 card would have been charged $77.05 against an order that says $60.45, and settleStripe would then have written Stripe's $77.05 into the ledger as the charge. The title sells this as tests; it is a live overcharge closed by a handful of lines. Worth saying in the merge commit.

The test stands up. bun test: 44 pass, 0 fail, 1.5 s; src/stripe.test.ts alone: 10 pass, 0.7 s; three consecutive runs, no flake. It asserts the wire rather than the return value, which is the only way this path is provable: the form fields, client_reference_id, idempotency-key: checkout:<number>, both URLs, and wireTotal(form) === total_cents - gift_card_cents to the cent. Booting the app as a subprocess with its own FORGE_APP_DATA is the right call for the reason given — server.test.ts counts rows — and WAL plus busy_timeout = 5000 keeps the second app process and the test's own handle on that file safe. Nothing leaves the machine: STRIPE_API_BASE points at 127.0.0.1, the fake is stopped in afterAll, and the live-key test proves zero requests are made. Collapsing a reduced order to one line is the right trade — Checkout has no negative line, and the itemisation is on our own payment page and receipt — and the line name gives Stripe nothing it does not already have in client_reference_id. No new dependencies.

Preview. Home in 227 ms with the security floor intact (CSP with script-src 'none' and form-action 'self', nosniff, referrer-policy, sid HttpOnly/Secure/SameSite=Lax). I bought a bag with WELCOME10 through the mock: $19.00 − $1.90 + $6.00 + $1.45 = $24.55, paid, receipt right. The preview has no Stripe key, so the changed path is covered by the tests and not by the preview — expected, not a gap.

Two findings I did not hold this up for, now filed:

• #19 — both settlement paths take Stripe's amount_total and mark the order paid without ever comparing it with dueCents(order), and the webhook settles any session naming the order rather than the one the order started. Pre-existing and signature-protected, not made worse here, but the fake Stripe this pull builds makes it cheap to prove. Next thing on this path.
• #20 — a $10.00 card against a $10.20 order now leaves 20 cents due, under Stripe's 50-cent minimum, so the session is refused and the shopper has no way to pay at all. This pull turns an overcharge into a dead end for that range; only a real key shows it, since the mock has no minimum.

Two nits, one line each, for whenever this file is next open: the mkdtempSync directory is never removed, so every run leaves a bazaar-stripe-* behind; and STRIPE_API_BASE is a test seam that in production would send a live key wherever it points — worth ignoring unless it is a loopback address or FORGE_APP_ENV is not production.

Approved pull #18. The clone is unchanged and nothing was pushed.

What I found: the pull is sold as tests, but it also closes a live overcharge — with src/gateway.ts reverted to main, the new test fails with Expected: 6045, Received: 7705, i.e. every discounted or gift-carded order was previously sent to Stripe for the sticker price and the ledger then recorded Stripe's larger amount. The suite passes at 38b30b8 (44 pass, 1.5 s; the Stripe file alone 10 pass, 0.7 s, stable across three runs), the fake Stripe makes no outbound request, and the preview still buys end to end through the mock ($24.55 with WELCOME10, receipt correct) with the security floor intact.

Two things I filed rather than blocking on: #19 (settlement trusts Stripe's amount_total and never compares it with dueCents(order); the webhook settles any session naming the order) and #20 (a gift card can leave a balance below Stripe's 50-cent minimum, which is now a dead end rather than an overcharge).

One caveat on delivery: POST /api/v1/repos/trevato/bazaar/pulls/18/reviews answers 422 {"error":"bad_anchor"} for every payload I tried — including an empty body, and on pull #4 — so I could not submit a formal review. I posted the full review, verdict first, as a pull comment instead. A one-word probe comment from diagnosing that is also on the pull and the API offers no way to delete or edit it.

Verdict: approved for pull #18 at 38b30b8 — the head is unchanged since I reviewed it line by line, ran the suite, and walked the preview.

Delivery, honestly: POST /api/v1/repos/trevato/bazaar/pulls/18/reviews still answers 422 {"error":"bad_anchor"} for every payload — with a body, without a body, with anchor as a string, an oid, a {path,line,side} object, a {base,head} pair, a comment id, as anchors/comments arrays, as a query parameter, and as an x-forge-anchor header, and on pull #4 as well. The error does not vary with the payload, so it is not a schema I failed to guess; GET .../reviews returns [] and POST .../threads has no route. No formal review could be recorded, and status.reviews still reads approved: 0.

The substance is already on the pull from the first pass and I did not duplicate it: a verdict-first comment (## Review: approved) covering the finding that matters — reverting src/gateway.ts to main makes the new test fail Expected: 6045, Received: 7705, i.e. this pull closes a live overcharge on every discounted or gift-carded order, not just adds tests — plus the suite results (44 pass, stable over three runs), the preview walk, and the two follow-ups filed as issues #19 (settlement never compares Stripe's amount_total with dueCents(order)) and #20 (a gift card can leave a balance under Stripe's 50-cent minimum). A stray one-word probe comment from diagnosing the API remains on the pull; the API offers no delete or edit route.

Nothing has changed since my review: pull #18 is still at 38b30b8, the exact commit I read line by line, tested, and walked in the preview, and status.reviews still reads approved: 0 because the forge refuses to record one.

Verdict: approved. The pull does what the direction asks for on the money path — and its substance is larger than its title: reverting src/gateway.ts to main makes the new test fail with Expected: 6045, Received: 7705, so this closes a live overcharge on every discounted or gift-carded order rather than merely adding coverage. The suite is green and stable (44 pass, three consecutive runs), nothing in it touches the network, no dependencies were added, and the preview still buys end to end through the labelled mock with the security floor intact.

POST /api/v1/repos/trevato/bazaar/pulls/18/reviews answers 422 {"error":"bad_anchor"} again this run, as it did for every payload shape I tried across the previous two: with and without a body, anchor as a string, an oid, {path,line,side}, {base,head}, a comment id, as anchors/comments arrays, as a query parameter and as a header, for all three states, and on pull #4 as well. The error never varies with the request, POST .../threads has no route, and there is no edit or delete route for comments. The verdict and the full reasoning are therefore on the pull as a verdict-first comment from the first pass, with the two follow-ups filed as issues #19 (settlement never compares Stripe's amount_total with dueCents(order)) and #20 (a gift card can leave a balance under Stripe's 50-cent minimum). I did not post a duplicate.

Review: changes requested.

The fake Stripe is the right idea and it is well built: three endpoints, idempotency-key replay, every request recorded, the app driven as a real client over HTTP in its own process, ten tests in about a second, stable across repeated runs, and nothing leaves the machine. The checkoutLines change is more than a test, too — before it, an order with a discount or a gift card was sent to Stripe at its sticker price and the shopper paid the reduction twice. That fix alone is worth landing.

It does not land as it is, though.

Fix first: this branch is cut from 5991215, one commit behind main, and main deleted the door the new tests sign in through. #13 removed the app's own password sign-in; identity now comes from the forge's signed headers. The admin() helper in src/stripe.test.ts still posts ADMIN_PASSWORD to /admin/signin. The forge calls this pull mergeable because the conflict is not textual, but I merged origin/main into the head commit locally and ran the suite: 47 pass, 3 fail — a discount and a gift card come off what Stripe is asked for, an admin's refund goes to Stripe with the intent, the cents and a key, and a refund Stripe refuses leaves the ledger exactly as it was, each failing where expect(signedIn.status).toBe(303) receives 404. The green check on this pull is green against a main that no longer exists. The preview shows the same staleness from the outside: GET /admin there answers 401 with a password form, where main answers 403 with a link to /__forge/signin.

The fix is a rebase on main plus an admin() that stamps the forge's headers the way src/server.test.ts and src/who.test.ts already do: set FORGE_APP_IDENTITY_KEY in the child's boot() environment, and send x-forge-identity as <id>|<name>|admin|<expiry> with x-forge-signature as stamp(key, identity) on the staff Shopper. ADMIN_PASSWORD then leaves the file entirely, and nothing else in it should need to move.

Two smaller things, both worth doing while you are in here:

1. The money rule is now written twice. orders.dueCents is total_cents - gift_card_cents, and checkoutLines computes that same subtraction again in src/gateway.ts. The new test asserts the two agree today, which is exactly the kind of agreement that stops being true quietly. orders.ts does not import gateway.ts, so import dueCents there (or move it into money.ts) and let one module own what Stripe is asked for.

1. The one hop the test cannot see is the browser's. pressPayWithCard uses redirect: "manual" and asserts the Location header, but in a real browser this is a form POST to our own origin answering 303 to checkout.stripe.com, and the security floor in src/server.ts sets form-action 'self'. Chromium applies form-action to the redirect target of a form navigation, so the hand-off to Stripe's hosted page may be refused in exactly the configuration this pull calls proven — and the preview cannot show it, because it has no STRIPE_SECRET_KEY and falls back to the mock. Please try it once with a test key in a real Chrome; if it is refused, widen form-action to 'self' https://checkout.stripe.com on the payment response only, never across the site.

One thing I noticed and am not asking you to fix here: when a gift card leaves a balance under Stripe's minimum charge — say thirty cents — real Stripe refuses the session with a 400 and the shopper has no way left to pay, while the fake takes any positive amount, so no test can catch it. orders.ts already settles the zero-balance case, so this is only the sliver between zero and the minimum, and it deserves an issue rather than this pull.

The rest holds up. The preview is healthy: / in about 270 ms, CSP, nosniff and Referrer-Policy on every response, and a guest walked catalog → cart → checkout → mock approve → a Paid receipt without a stumble. The README and the comments are accurate about what is real and what is simulated. Come back with the rebase and those three admin tests green against main, and I will approve.

---

_Posted as a comment because POST /api/v1/repos/trevato/bazaar/pulls/18/reviews answers {"error":"bad_anchor"} for every payload I can form, including {}; the verdict above is the review._

Review delivered on pull #18 — changes requested. Nothing was pushed; the clone is untouched.

Verdict: changes requested. The fake Stripe is good work — three endpoints, idempotency replay, every request recorded, the real app driven over HTTP in its own process, ten tests in ~1s, stable over repeated runs, no outbound traffic — and checkoutLines is a genuine money fix: before it, an order with a discount or gift card was sent to Stripe at its sticker price and the reduction came off twice.

What blocks it: the branch is cut from 5991215, one commit behind main, and main (via #13) deleted /admin/signin. The new admin() helper still posts ADMIN_PASSWORD there. I merged origin/main into the head commit in a scratch copy and ran the suite: 47 pass, 3 fail (the discount/gift-card, refund, and refused-refund tests, all on expect(signedIn.status).toBe(303) getting 404). The pull's green check is green against a main that no longer exists; the preview shows the same staleness, answering 401 with a password form at /admin where main answers 403 with a forge sign-in link. Fix: rebase and stamp the staff Shopper with x-forge-identity/x-forge-signature the way src/server.test.ts and src/who.test.ts do.

Also flagged: checkoutLines duplicates orders.dueCents, so the rule deciding what Stripe is charged now lives in two places; and the one hop the test can't see is the browser's — redirect: "manual" proves the Location, but the floor's form-action 'self' may make Chromium refuse the POST→303 to checkout.stripe.com, which the preview can't reveal since it has no Stripe key. Noted for an issue rather than this pull: a gift-card balance under Stripe's minimum charge leaves the shopper with no way to pay, and the fake accepts any positive amount.

Preview is otherwise healthy: / in ~270 ms, CSP/nosniff/Referrer-Policy on every response, and a guest walked catalog → cart → checkout → mock approve → Paid receipt.

One caveat: POST /api/v1/repos/trevato/bazaar/pulls/18/reviews returns {"error":"bad_anchor"} for every payload I could form, including {} (the error precedes body validation and is identical with or without comments, anchors, or commit oids; the same route returns not_found for a nonexistent pull, so the route and token are fine). I posted the review as a pull comment on #18 instead, labelled with the verdict and with that API failure noted at the bottom — worth someone looking at the reviews endpoint for cross-repo pulls.

One review submitted on pull #18, anchored at src/gateway.ts:104, requesting changes.

Verdict and reasoning: the fake Stripe is genuinely good work, and checkoutLines is a real money fix — before it, an order with a discount or gift card was sent to Stripe at its sticker price and the reduction came off twice. What blocks it is that the branch is cut from 5991215, one commit behind main, and main (via #13) deleted /admin/signin. The new admin() helper still posts ADMIN_PASSWORD there; merging origin/main into the head in a scratch clone gives 47 pass / 3 fail, all on expect(signedIn.status).toBe(303) receiving 404. The preview shows the same staleness — /admin answers 401 with a password form where main answers 403 with a forge sign-in link. The fix named first is the rebase plus signing the staff Shopper with x-forge-identity/x-forge-signature the way src/server.test.ts and src/who.test.ts do. Also flagged: checkoutLines duplicates orders.dueCents, and form-action 'self' may make Chromium refuse the POST→303 hand-off to checkout.stripe.com, which redirect: "manual" cannot catch. Noted for a future issue: a gift-card balance under Stripe's minimum charge leaves the shopper unable to pay.

One caveat worth passing on: POST /pulls/18/reviews rejects every payload without a top-level path + line anchor (bad_anchor, even for {}), and it silently drops state — the stored row has no state and status.reviews.changesRequested is still 0. So the verdict lives in the review text, not in the counter; the decider should read it rather than gate on the count.

The branch now carries main (merged rather than rebased — force pushes are refused here, and the result is the same tree), and the three admin tests are green against it: admin() in src/stripe.test.ts no longer posts a password to the door #13 removed, it stamps the staff Shopper with x-forge-identity/x-forge-signature and boots the app under test with FORGE_APP_IDENTITY_KEY, the way src/server.test.ts and src/who.test.ts do. ADMIN_PASSWORD is gone from the file. bun test: 52 pass, 0 fail, ~0.7 s; the preview is redeployed and matches main from outside — /admin answers 403 with a /__forge/signin link, / in ~217 ms with the floor intact.

The money rule is now written once. dueCents moved to src/money.ts, where the other money rules live, and src/gateway.ts, src/shop.ts, src/mail.ts and src/pages/checkout.ts all read it from there — the same subtraction had been spelled out in five places, and the agreement between them is exactly what keeps a shopper from being charged the sticker price. A unit test pins it.

The browser's hop is handled, defensively: I could not try it in a real Chrome (no browser and no Stripe test key reachable from this sandbox), so I took Chromium's documented behaviour of checking form-action against a form navigation's redirect target as given and made the fix narrow. handOff() in src/http.ts marks the one response that sends a form navigation off-origin with an internal header naming that origin; finish() in src/server.ts widens form-action to 'self' <that origin> for that response alone and strips the header before it leaves. Everything else keeps form-action 'self', and src/server.test.ts now asserts the base policy ends there. src/stripe.test.ts asserts the hand-off response's policy names the fake's origin, that the internal header is gone, and that the next page is back to 'self'. While in gateway.ts I also closed the test seam: STRIPE_API_BASE is only honoured for a loopback address, so a key can never be sent where an environment variable points — unit-tested, and the temp directory the Stripe test makes is now removed in afterAll.

Not done here, deliberately: #19 (settlement trusting Stripe's amount_total without comparing it to dueCents) and #20 (a gift-card balance below Stripe's minimum charge) stay their own issues. Worth a look: finish() in src/server.ts and handOff() in src/http.ts — that is the only place the floor bends, and it bends per-response, to an origin taken from the URL we are actually redirecting to and checked against an origin-only pattern.

🤖 Generated with Claude Code

The review is posted on pull #18 as changes requested, anchored to src/server.ts:80.

Round one's blocker is fixed at this head (rebased on main, the test signs in with the forge's stamped headers, dueCents moved to src/money.ts), and I verified the suite is real by mutation: reverting checkoutLines reproduces the 7705-vs-6045 overcharge and the test catches it; removing the CSP widening fails too. bun test is 52/0 over five runs, and the preview buys end to end on the mock.

The one thing I asked to be fixed first: handOff() widens form-action on the 303 itself, but browsers check a form navigation's redirects against the policy of the document that held the form — so the Stripe origin belongs on /pay/<number>'s own CSP, not on the redirect, and HAND_OFF can then go away entirely. Second, smaller: now that Stripe is correctly asked for dueCents, a gift card can leave a balance under Stripe's ~$0.50 minimum, stranding an order whose card balance is already spent.