Pricing a request

Run it with the offer and the submission reference the quote-request card printed, plus your price.

Amount is in minor units — pence, cents — so £250.00 is 25000. It must be a whole positive number; the recipe refuses a fraction rather than rounding one, because rounding somebody's invoice silently is not a thing software should do.

What happens, in order: the order is re-derived and confirmed to still be waiting for a price; core.seller.order.quote pins the total under a revision check; a Stripe Checkout Session is created for the total the server pinned (read back off the order, not off your input); the session is bound to the order with core.seller.order.attach-payment, which moves it to awaiting_payment; the session is re-read fresh from Stripe; and only then does the customer get an email with the figure and the link.

Every one of those writes is approval-gated, so you confirm the send before it leaves. That gate IS the approval step in this flow — there is no separate consent link to mint.

⚠ Re-running RESUMES. The run is phase-convergent: if the price is already pinned at the same figure it skips the quote, if a checkout session is already attached it reuses that session rather than minting a second one, and the mail's reconciliation id means an already-sent link is not sent twice. So a crash anywhere after the quote — before the session, after the session but before the bind, or at the send — is recovered by running it again with the same inputs.

⚠ A different price is refused. Once a figure is pinned the customer may already have seen it, so re-running with another amount stops before touching anything. To change a price, cancel the order and take a fresh request.

⚠ The Stripe idempotency key comes from the order, never composed here. That is what makes a crash between the Stripe call and the bind safe to retry: re-attaching the same session converges, and attaching a different one is refused as a double charge.

⚠ A retry must ask for the SAME price AND the same currency. An order already quoted at one currency cannot be re-quoted into another by re-running with a different currency — the run refuses rather than charging in the committed currency.

⚠ The checkout expiry is anchored to the quote, not to the clock. A Stripe idempotency key may only be reused with the SAME parameters, and the key here is stable per order — so if the expiry moved with wall-clock time, a run that died between creating the session and attaching it could never be retried. Deriving the expiry from the order's own quote timestamp makes every attempt byte-identical.

The trade is that the window ages. Stripe requires an expiry at least 30 minutes ahead, so if you retry long after quoting, the run refuses with a stale-quote guard rather than silently shifting the parameter. Cancel the order and take a fresh quote — the price the customer was shown has expired anyway.

⚠ Pricing refuses a request it cannot already find under this offer. order.open is deterministic in (offer, submission) but it CREATES on a miss, so a run pointed at the wrong offer used to mint a second order for the submission and only then stop — and a repeat of the same wrong run found that order waiting and priced it. The check is now a read that happens before anything is written: if Open a quote request has not run for this submission under THIS offer, pricing refuses and nothing is created.

What it writes back to the request record

After the mail is reconciled, the run records the subject and covering note it just emailed, and a quoted_at stamp, onto the pack's Records row for this request. That is what lets the board show what a quote was for months later, when the intake response is long out of the recent window.

Three things about that write are deliberate:

• It happens last. A failure there cannot affect the price, the session, or the email — all of which have already converged — and re-running recovers it.
• It happens once. If the row already carries a quoted_at, the run leaves it alone. The row records what was actually emailed; editing the note afterwards and re-running must not rewrite history into something the customer never saw. It also keeps a converged rerun quiet — no revision churn, and no change event for a change that did not happen.
• quoted_at is anchored to the order's own quote stamp, the same anchor the checkout expiry uses, so every attempt at the same run writes the same instant.

⚠ A missing request row does not stop anything. An order opened before this pack gained Records storage has no row to write to; the run prices and sends exactly as before and simply records nothing. The board shows a blank For for those, which is what it did for every row previously.

⚠ Nothing about money is copied onto the row. No total, no currency, no phase, no paid flag. The seller order store answers those, and a second copy that could disagree with it would be worse than no copy at all.