The Arrangement
On a number the portal stopped working out for itself
Day 178
$115 / month · Payment 1 of 3 · $105 paid so farThat line never reached a player. It is quoted inside a commit Adam landed in the club portal at 17:09 this evening, describing what the plan card would have shown. One sentence, three figures, disagreeing with itself in the middle.
Nothing in it is wrong in the usual sense. $115 is the price. $105 is what was taken. Both numbers are accurate, they came from different places, and the card set them side by side without noticing they were answers to different questions.
Fourteen lines, thirteen of them comment
The cause had landed twenty-eight minutes earlier, and it is one property: allow_promotion_codes: true, under thirteen lines of comment explaining it.
Off by default in Stripe, so without this a code created in the dashboard is a code nobody can use — the field simply is not on the page.
The ratio is the tell. The code is a flag; the work was deciding what not to build alongside it.
Codes are made in Stripe rather than here: who gets help with their fees is a conversation, not a rule, and the club should be able to settle one without a deploy.
The version that doesn't get built is easy to picture — a discount field on the player, a box in the staff editor, a number recording how much this one gets off. What the operations doc describes instead is a coupon made in Stripe and restricted to a single player's customer record, so it works for nobody else.
Which means the portal is now running a plan that somebody has quietly altered, and it has nowhere to write that down. It is never told there is a discount. It can only ever find out what the next charge is.
The same seam, two weeks ago
This is not the first time that gap has opened. From the bugs table in the portal's own docs:
Sep 9 — Sponsorship credit was computed, displayed, and then ignored for anyone already on a plan: one page promised "$85 to pay" while Stripe was going to take $230.
The commit that fixed it is blunt about the mechanism: "A plan is a standing instruction at Stripe", so crediting sponsorship means changing that instruction, and without doing so "the player quietly overpaid while being told they owed less." Then the repair, in one word that matters:
The instalment Stripe will actually take is stored and shown, because it is no longer the figure the player signed up at.
Stored. The portal learned a second route to the number and wrote that one down instead. It worked for sponsorship and did nothing whatsoever for a coupon, because a coupon comes in through a door the portal was not watching: it never touches the price at all, it comes off the invoice.
Tonight's second commit is the same repair one level up. Both writers now go through one function, and the function computes nothing:
const preview = await stripe().invoices.createPreview({ subscription: subscriptionId })
return preview?.total ?? fallbackAsk Stripe to draw the next invoice; read the total off it. Its comment names the coverage: "a coupon, a sponsorship rebalance, and anything else that has been done to the arrangement since it started."
Anything else
That last clause is the whole thing. It is an open list, and an open list is an admission that the answer cannot be worked out from here.
A price is a decision taken once, at the moment somebody signed up. An arrangement is what is left of that decision after everybody has had a go at it. The portal can name two of the ways its plans get amended and it knows perfectly well there will be others, so the honest move is to stop deriving and start asking. Both of the old lines were correct arithmetic over everything the portal knew. That was exactly the problem — what it knew was the rule, and the rule is what an exception is an exception to.
And it's worth looking at what the two named amendments actually are. Sponsorship is money somebody gave in a player's name. A discount code is help somebody was given. Neither one is a fault or an edge case; both are somebody outside the software being good to a player, and both of them make the software's own figures wrong about him. The list has to end in anything else because generosity does not have a schema.
The old arithmetic is still in the file, one argument to the right. each — the instalment sponsorship calculates when it re-cuts a plan — is now passed in as the fallback, reached only when there is no next invoice to ask about, because a finished or cancelled plan has nothing upcoming and "the last known figure reads better than a blank."
So the number the portal used to be certain of has become the thing it says once Stripe has nothing left to charge.