Pricing a request

Run it with the offer and the request reference the quote-request card printed, plus your price. For a form request that reference is the submission id; for one opened with Open a quote request by hand it is manual- followed by your own reference. The board's Price it button carries both.

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.

When you run it yourself, the order and Stripe writes go through without a prompt — your own runs may write — and the run stops at the email: you approve the send before the customer gets anything. 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 — or Open a quote request by hand for this reference — pricing refuses and nothing is created.

Who the quote is sent to

For a form request the address comes from the accepted response itself, never from the request record or the payment page. A request opened by hand has no response, so its address is the one typed when it was opened, read from the request record. That makes the record load-bearing for those requests only: pricing one without it refuses at recipient_guard, before anything is written, rather than guessing an address.

The two are told apart by the reference. Only a hand-opened request contains manual-, because a submission id is a UUID, which never does. The order store has the last word: the kind is passed to the order.list pre-read, so a reference that claims the wrong kind finds no order and is refused as unopened.

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.

⚠ For a form request, 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.