/ admin / rails
Taking money
Two rails. Neither is live. What each one is handed, and the order the steps have to happen in.
Two rails, neither of them live. does not exist yet 11 Sep 2026 These are the plans that end that — what each provider is handed, what has to exist before a first real order, and in what order.
The rail for everything bought from a screen, and the one that turns a buyer into a customer — including a buyer who pays nothing.
Planned, half set up, and taken off the store for the MVP — the plan is kept rather than deleted.
What both rails are handed, and what neither ever is
This block changed on 16 September 2026 and the change is worth naming. Until that day it said the provider is handed an amount and a reference and nothing else — “neither provider gets a product list, a price list or a shape” — and the reason given was that a catalogue maintained in two places will one day disagree. That was the right instinct and the wrong conclusion, because it bought consistency by giving up the thing the store actually needs: a buyer who is a customer rather than a card charge. An amount-only link takes money from a stranger. A catalogue-backed checkout takes money from somebody with an email address, a name and a record, and it can charge them nothing at all and still do it. So Stripe now gets a catalogue, the drift risk is real, and the mitigation is written into the plan below rather than wished away.
Given
What is due NOW, which is the whole price at the two produced levels and a fifth at the two that are somebody's work. The split is a property of the offer and is computed here, not there.
SG- and six characters from an alphabet with no 0/O or 1/I, so it survives being read down a phone. It is generated in the buyer's browser and exists nowhere else until they pay.
SG-4A7434 ABP-GML-P ABP-GML-C. The reference is the whole order; the catalogue entry below is only what it cost.
Six products and eight prices, because a price here does not vary by shape. Level two costs £50 whether the subject is a browser agent or a payments bot, so Stripe needs the four levels, the two add-ons and the two deposits — and never the fifteen shapes. That is what makes the two-places objection survivable: the thing duplicated is eight rows that change when a price changes, not a product line that changes every week.
Which becomes a Customer, which is the entire reason for this rail. It is typed on Stripe's domain, into Stripe's form, and it never touches this one — there is no field on this site it could go in and a build check refuses to let one exist.
Never given
Fifteen shapes, and at level three a written brief. Neither is a price and neither goes to a provider. The shape rides in the order reference and is resolved here; the brief is a file the buyer keeps. A provider that knew which agent a company was worried about would know more about that company than the shop does.
No account, no cookie, no analytics, no name learned anywhere. The catalogue going to Stripe does not change that by one byte: it describes what is for sale, not who looked at it.
sk_live_, sk_test_ and whsec_ are refused everywhere by tools/secret-scan.sh, which runs on every release over the whole tree including the built site. A key lives in the provider's dashboard and in whatever runs the webhook, and in neither case in here. The publishable key is a different object and is not needed either, because this site loads nothing from Stripe.