store.sgit.ai / admin · the shop · the ledger · this page as markdown noindex · not in the sitemap
Produced with model assistance. Every page on this site, and every document in the dev packs area, was drafted with a large language model and reviewed by a person before publication.

/ work / take-money

Take money at all

5 of 15 units done. No payment rail is live. Every checkout_url in data/checkout.yml is empty, so the store can be walked end to end and cannot be bought from. This is the workstream that ends that, and the shape of it changed on 16 September: the rail is no longer an amount-only link, it is Stripe's own catalogue and a real customer record behind every order including the free ones.

This workstream came out of a memo. Stripe end to end, with their SKUs — and a customer even at 100% off, 2026-09-16 — kept verbatim, read into a brief, and broken into the units below.

Queued5

TM-4Enable promotion codes on every link, prefill where a code was leaked

A link with the field switched off refuses a valid code with no explanation and the buyer blames themselves. Where a page publishes a code as part of a journey, the link on that page carries it already applied.

memo 2026-09-16
TM-6Stand up the checkout.session.completed webhook

The step that unblocks a first paid order at £50, £500 and £1,500. Listen to the session, not the payment: a hundred-per-cent order creates no charge, so a handler keyed on a succeeded payment sees every paid order and none of the free ones.

Blocked on Runs off this site. This site is static and opens no connection.
TM-7Take one real £10 payment and read the receipt

Every sentence on the rails page about what a receipt says is unverified. This is the task that makes them checkable.

Blocked on TM-1 and TM-6.
TM-8Retire the browser-side discount arithmetic

A code is honoured in the browser today and the page says it is a demonstration. Once a promotion code exists on the rail there are two implementations of one rule, and the browser one can be edited by the person it is discounting.

Blocked on TM-3.
TM-15Bring SumUp back once Stripe has taken money

The argument for running two rails is a good one and it is preserved on the parked plan. It stops being hypothetical the day the first rail has taken a real payment, which is the point at which there is something to compare against.

Blocked on TM-7 — a first real payment.memo 2026-09-16

Up Next5

TM-2Set customer creation to always, and prove it on a £0 order

The single setting most likely to be missed. Without it a hundred-per-cent order completes, the buyer sees a confirmation, and no customer record exists — which is the exact opposite of why this rail was chosen. Proof is a Customer visible in the dashboard after one free order, not a screenshot of the toggle.

The project lead, in conversation · memo 2026-09-16
TM-3Create the promotion codes over the three coupons

The coupons are done — 25, 50 and 100 per cent, created 16 September, all once, all reconciling against the percentages this store honours. Zero promotion codes exist, and that is the gap. A coupon carries the percentage; a promotion code is the string a person is handed and the thing a link can carry pre-applied. The seven strings in data/discounts.yml map onto these three — five at a hundred per cent, kept separate so an order record says which one produced it.

The project lead, in conversation · memo 2026-09-16
TM-11Get the codes into Price.lookup_key, not just the description

The six codes exist as ABP-T1, ABP-T3-DEPOSIT and the rest — in the price description, because the dashboard's product view surfaces no lookup key. That works for a person reading the dashboard. Price.lookup_key is a different field, it exists on the API, and it is the one a webhook uses to map a line item back to a level. Without it the handler has a product id and a free-text string, which is workable and is not the same as queryable.

The project lead, in conversation · memo 2026-09-16
TM-12Re-export the product CSV whenever the dashboard changes

The reconciliation reads a committed export, because this site opens no connection and that rule is not moving. It catches a price changed here and not there, which is the direction that happens; it goes stale in the other direction until somebody re-exports. That is the known weakness and it is written on the page rather than left to be discovered.

The project lead, in conversation · memo 2026-09-16
TM-13Decide what a DELIVERY-only purchase means

The split makes a new thing possible that no page describes: somebody buying the delivery line without ever having bought the deposit. Either the pages say what that is, or the link only ever offers the pair.

The project lead, in conversation · memo 2026-09-16

In Progress0

Done5

TM-1Create the products in Stripe

Done by the project lead on 16 September. Six products, GBP, and the shape is theirs rather than the one this plan first guessed: the two upper levels are a DEPOSIT and a DELIVERY that sum to the price, so a buyer paying in full adds both lines and a buyer starting adds one. That is the store's own “a fifth now and the rest on delivery” as two rows instead of a rule somebody has to apply. The dashboard's CSV export is committed and the build reconciles against it every release.

The project lead, in conversation · memo 2026-09-16
TM-5Bring the return address onto this site

Shipped in v0.3.0. The success address is this site's own page for the level, so there is nothing to settle with another team. The two parameters are unchanged; what moved is the origin.

memo 2026-09-16
TM-9SumUp — parked for the MVP

Taken off the store on 16 September. The finding that produced this task — that check_checkout_links pinned every destination to Stripe's hosts and would have refused a SumUp URL with a message about Stripe — is now moot rather than fixed, and stays written down because it will be true again the day the rail comes back. The plan is kept at /admin/rails/sumup/ rather than deleted.

TM-10Write the two rails up as plans rather than intentions

Shipped in v0.1.18 at /admin/rails/stripe/ and /admin/rails/sumup/, generated from data/admin/rails.json.

memo 2026-09-16
TM-14Caps on the hundred-per-cent coupon — ruled not needed

Ruled on 16 September: no cap, and the reasoning is recorded rather than the concern being dropped. Purchases are managed directly, so a redemption is seen rather than discovered in a total. Abuse at a volume worth doing is abuse at a volume that shows. And what the code skips paying for is already published free — it removes a payment for material anybody could download, and it does not remove the work at the upper levels, which a person does and would notice. The gate now reports the state every release instead of failing on it.

The project lead, in conversation · memo 2026-09-16

← every workstream

An operations surface for the people building this store, public because every page here is. It is not a selling page and nothing on it is an offer. The shop is here · every claim, with its state · the reviews