@blamejs/blamejs-shop 0.4.5 → 0.4.7

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.7 (2026-06-05) — **Payment page: Trusted Types now permits Stripe's loader through a real allowlist, and the Amazon Pay button loads.** Two payment-page fixes. The site enforces Trusted Types, and Stripe's browser library assigns script URLs without registering a policy — the console logged a TrustedScriptURL violation on every payment page, the failure class that can break a 3-D Secure challenge mid-payment. Rather than relaxing enforcement, the page now registers the default Trusted Types policy before Stripe loads: it admits script URLs from Stripe's own origins and throws for anything else, so enforcement stays on with a genuine gate. Second, the express-wallet row offered an Amazon Pay button whose frame the payment page's policy refused to load; the page's frame allowance now includes the Stripe-operated CDN that serves wallet buttons, scoped to the payment page only. Every other page keeps the strict policy unchanged. **Fixed:** *Trusted Types policy for the Stripe loader* — The payment page registers the default Trusted Types policy before the Stripe script tag, synchronously, integrity-pinned like every other script. The policy admits script URLs whose origin is js.stripe.com or a subdomain of it and throws for any other host — lookalike domains, plain http, and non-Stripe CDNs are refused. Browsers without Trusted Types are unaffected. Pages outside the payment route keep require-trusted-types-for enforcement with no registered loader policy, exactly as before. · *Express wallet buttons can load their frames* — The payment page's frame allowance adds Stripe's wallet-button CDN (b.stripecdn.com) and Stripe's dynamic subdomains (*.js.stripe.com) alongside the existing js.stripe.com and hooks.stripe.com entries, restoring the Amazon Pay express button. The allowance is scoped to the payment page; the storefront-wide policy still permits no third-party frames at all.
+
+- v0.4.6 (2026-06-05) — **Guest order pages require proof of purchase, and guests can save their order to an account in one tap.** Two changes to what happens after a guest checks out. First, the order confirmation page — which shows the buyer's name, address, and items — is no longer reachable by anyone who learns the order id. A guest order now admits exactly three readers: the browser that placed it (a sealed device cookie set at checkout, surviving the payment redirect), anyone opening the signed link in the order-receipt email (an order-scoped, expiring signed token that works on any device), and the signed-in account that owns it. Everything else sees a 404 indistinguishable from a missing order, and the reorder action is gated the same way. Second, the confirmation page now offers a guest one tap to save the order to an account: it emails a sign-in link to the address they checked out with — shown masked on screen, held only in a short-lived encrypted cookie, never written to the database — and redeeming the link creates the account if needed and attaches their guest orders by a hashed-email match. The response is identical whether or not an account already exists, the trigger is rate-limited, and a second click sends nothing. **Added:** *One-tap account setup after checkout* — A guest buyer's confirmation page offers to save the order to an account: one click emails a magic sign-in link to the checkout address (masked on screen, e.g. r***@e***.com), creating the account on redemption if none exists and linking the buyer's guest orders by hashed-email match at the moment they prove control of the inbox. Signed-in buyers never see the offer; buyers whose address already has an account get sign-in wording with the identical send path. The plaintext address lives only in an encrypted cookie for fifteen minutes — the database keeps only the one-way hash it already kept. **Changed:** *Guest order confirmation pages are access-gated* — A guest order's page requires the placing browser's sealed device cookie (set at checkout, capped to recent orders, 30-day refresh), the signed token in the order-receipt email's view-order link (order-scoped, roughly 90-day expiry, constant-time verified), or the signed-in owner. Unauthorized requests — including a signed-in customer who does not own the order — receive a 404 identical to a missing order. The reorder action carries the same gate; cancel, rating, and return actions were already owner-only. The payment-provider return flow and order analytics are unaffected: the device cookie is set before the redirect to the payment page, so the buyer lands back on their confirmation with access intact.
+
 - v0.4.5 (2026-06-05) — **One sign-in screen: passkey first, email sign-in link as the built-in fallback.** The sign-in page previously offered the passkey ceremony with the email magic-link alternative a page away behind a link. Both now live on one screen: passkey stays the primary action, and an "Email me a sign-in link" form sits inline beneath it — a plain server-rendered form that works with JavaScript disabled. The page meets failure gracefully: a browser without WebAuthn support disables the passkey button and points to the email form, and a failed or cancelled passkey ceremony scrolls the shopper to the fallback with their typed email carried over, one tap from a sign-in link instead of a dead end. Responses are identical whether or not an account exists for the address, the trigger is rate-limited, and a visitor who is already signed in is redirected to their account instead of seeing a login form. **Changed:** *Sign-in page unifies passkey and email-link paths* — Passkey remains the primary action; the email sign-in link form renders inline on the same screen when transactional email is configured, works without JavaScript, and inherits the existing magic-link token semantics unchanged (single-use, expiring). Browsers without WebAuthn support are steered to the email form up front, and any passkey ceremony failure lands the shopper on the fallback with their email pre-filled. The email form's responses do not reveal whether an address has an account, the trigger endpoint is tightly rate-limited, and signed-in visitors are redirected away from the login form.
 
 - v0.4.4 (2026-06-05) — **Placement-targeted promo banners with scheduling, audiences, and click tracking.** Operators can now run placement-specific marketing banners alongside the existing sitewide announcement bar. A banner targets one of six placements — the top strip, the homepage hero, the product-page side, the cart side, the empty-search state, or the footer — with a schedule window, an audience (everyone, signed-in, or guests), one of four visual themes, a priority for choosing among overlapping banners, and a call-to-action whose clicks and impressions are counted. Banners are authored, edited, archived, and restored at /admin/promo-banners, render identically on edge-cached and container-rendered pages, and the click counter works on both. Separately, the edge's Permissions-Policy header now denies the same full directive set as the container's, closing a drift where nine newer denials were missing from edge-served pages, and a parity test keeps the two substrates locked together from here on. The vendored blamejs framework is refreshed from v0.14.21 to v0.14.22. **Added:** *Promo banners* — Define a banner with a slug, placement, headline, optional body, call-to-action, audience, schedule window, theme, and priority; the highest-priority active banner per placement renders. Operator-authored text is escaped at render on both substrates. Clicks route through a counting redirect that works whether the page came from the edge cache or the container; impressions count on container renders. The admin screen covers the full lifecycle including archive and restore, and the same operations are available as JSON under the admin bearer token. The sitewide announcement bar is unchanged and remains the simpler always-on notice strip — if you define a top-strip promo banner while an announcement is active, both render, so pick one for the top of the page. **Fixed:** *Edge pages deny the same Permissions-Policy directives as container pages* — The edge-served pages' Permissions-Policy was missing nine newer directives the container already denied (among them shared-storage, run-ad-auction, join-ad-interest-group, and smartcard). Both substrates now send the identical deny-all list, and a test fails the build if a framework update ever grows one list without the other.

package/README.md

@@ -86,7 +86,7 @@ Every primitive is composed on the vendored blamejs surface — no npm runtime d
 | **`lib/bundles.js`** | Sell products together at a set price. A product page shows the bundles it belongs to as a "Bundle & save" offer — the member products, the bundle price, and the saving against the parts. `POST /cart/bundle` adds the whole bundle in one action: the price is recomputed from the live catalog and allocated across the member lines (proportional to list price, remainder on the last line) so the cart subtotal matches the quoted price. The add is atomic — an archived or out-of-stock member shows the bundle unavailable and adds nothing rather than a partial set; an unpriceable bundle (missing member price / currency mismatch) is shown unavailable, never a 500. The client sends only the bundle code; the server prices it. The offer renders identically from the edge worker and the container. |
 | **`lib/quantity-discounts.js`** | Reward buying more. A product with quantity breaks shows its price tiers on the page (e.g. 1–2 / 3–5 / 6+ at descending unit prices). In the cart, each line is priced at the unit price for its quantity — reapplied on every cart render so changing the quantity re-prices, and again at checkout so the per-line price and order total written onto the order reflect the break, not the list price. A quantity under the first tier falls back to the base price; over the top tier takes the top tier. The client sends only a quantity; the server prices it. The tier table renders identically from the edge worker and the container. |
 | **`lib/recently-viewed.js`** | Signed-in customer browse history. A product-page visit records the view server-side against the customer's account (drop-silent — never blocks the page); `/account/recently-viewed` lists them newest-first as a grid with a Clear-history control. De-duped + capped per customer, archived products drop out, login-gated. Guest/session history is opt-in (a client beacon) and not shipped — the lib's `forSession` + `merge` support it. |
-| **`lib/recommendations.js`** | Product-recommendation engine. Operator-curated override pins first (`setOverride` — "when viewing A, show B", kind-scoped + weight-ordered), then a signal-based fallback: co-purchase (products bought in the same orders), category-popular, and in-stock-random filler. `recommendForProduct` / `recommendForCart` / `recommendForCustomer` / `recommendForCategory` each return renderable picks (active + in-stock, source product excluded). The order confirmation page (`/orders/:id`) renders a "Customers also bought" rail from it — best-effort, anchored on the order's items, excluding what was just bought. |
+| **`lib/recommendations.js`** | Product-recommendation engine. Operator-curated override pins first (`setOverride` — "when viewing A, show B", kind-scoped + weight-ordered), then a signal-based fallback: co-purchase (products bought in the same orders), category-popular, and in-stock-random filler. `recommendForProduct` / `recommendForCart` / `recommendForCustomer` / `recommendForCategory` each return renderable picks (active + in-stock, source product excluded). The order confirmation page (`/orders/:id`) renders a "Customers also bought" rail from it — best-effort, anchored on the order's items, excluding what was just bought. The confirmation page itself is access-gated: a guest order admits the placing browser (sealed device cookie set at checkout), the signed link in the order-receipt email, or the signed-in owner — a bare order UUID 404s. A guest buyer also sees a one-tap "save this order to an account" offer there: it emails a sign-in link to the checkout address (shown masked; the plaintext lives only in a short-lived sealed cookie, never the database) and links their guest orders to the account when the link is redeemed. |
 | **`lib/collections.js`** | Curated + smart product groupings. `GET /collections` lists the shop's active collections; `GET /collections/:slug` renders the grid — manual collections list hand-picked members, smart collections evaluate stored rules against the active catalog and apply the collection's sort strategy. Each product resolves fresh, so archived products drop out. Public, no sign-in; a bad or unknown slug is a 404 (never a 500). Linked from the footer on every page. |
 | **`lib/category-navigation.js`** | Hierarchical category tree surfaced as public browse pages. `GET /categories` lists the active top-level categories as a card grid; `GET /categories/:slug` renders one category — its title and optional description, a breadcrumb chain from the catalog root down to the current category, an optional hero image, and a grid of the category's direct child sub-categories. Each page reads fresh against the active tree, so archived / unpublished categories drop out of every surface. Public, no sign-in; an unknown, archived, or malformed slug is a 404 (never a 500), and a category with no children renders a graceful empty state. Linked from the footer on every page. The tree itself (define / move / reorder / archive, with cycle defense bounded by `MAX_TREE_DEPTH`) is operator-managed through the primitive's write API. |
 | **`lib/search-facets.js`** | Filterable search. A search result page renders facet groups — collection, price range, in-stock — as server-rendered controls; selecting one narrows the results and rides the URL query string (`?q=…&collection=…&in_stock=1`), counts beside each option reflect the current result set, facets combine across groups, and active filters show as removable chips with a clear-all path that survives result pagination. All filtering is server-side from the query string (no client JS); unknown facet keys, out-of-range prices, and garbage values are ignored rather than erroring; an empty filtered result shows a clear-filters state. Runs identically at the edge worker and the container — the edge reads the catalog and facet registry straight from D1, missing-table-resilient. |

package/SECURITY.md

@@ -112,6 +112,15 @@ node -e "
 
 ## Application checklist
 
+- **Guest order pages are access-gated, not capability URLs.** A guest
+  order's confirmation page (name, address, items) requires the placing
+  browser's sealed device cookie, the signed `?k=` token carried by the
+  order-receipt email link (HMAC-SHA3-512, order-scoped, expiring), or
+  the signed-in owner — a bare order UUID returns 404. The token key is
+  derived from the app secret (`VAULT_PASSPHRASE`, falling back to
+  `D1_BRIDGE_SECRET`), so rotating that secret invalidates outstanding
+  emailed order links; rotate deliberately and expect customers to use
+  fresh links afterward.
 - **D1 bridge secret.** When deploying on Cloudflare, the container
   reaches D1 through a Worker service binding. The bridge is gated by
   a shared-secret header (`X-D1-Bridge-Secret`) so the route only

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.5",
+  "version": "0.4.7",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-6k53cvkRrxMgmeStLIoLjVXZQHqIJgTmv1Izd8TYhh1HOC4POgE6GCvx1bsalyEP",
@@ -37,6 +37,10 @@
       "integrity": "sha384-BjuUhbPZ18pHFMyOwT+309BEXu+VAc54RSj8lvN93jfFGDydEgmapiAOKTQM1yma",
       "fingerprinted": "js/passkey-register.02b0e196fb9608d8.js"
     },
+    "js/pay-trusted-types.js": {
+      "integrity": "sha384-jD90N8l7J3Vcu+aPSFRi6AE/5XKHQl58/avwHE9PH0mHwMavX991OCsEcznEf3n5",
+      "fingerprinted": "js/pay-trusted-types.53d0df13f9480a66.js"
+    },
     "js/pay.js": {
       "integrity": "sha384-W11JVQhv1RZq4WhsAOglu56gTZTDz1ByLd+b1HFQBCi8xGoEhJ0PZ2yI3FqbYzt6",
       "fingerprinted": "js/pay.683a905563e54a47.js"

package/lib/email.js

@@ -71,7 +71,15 @@ function _formatMoney(amountMinor, currency) {
 // keys at composition time. Plain-text alternate parts use the same
 // data; mail clients pick whichever they prefer.
 
-var ORDER_RECEIPT_HTML =
+// The receipt splits around an OPTIONAL "view your order" link block. The
+// order-confirmation link carries a signed, order-scoped access token
+// (?k=<token>) so a guest buyer can open their receipt on any device without
+// the placing browser's access cookie. The token is minted by the caller
+// (which holds the signing key); email only renders the already-built URL,
+// HTML-escaped through the strict {{order_url}} slot like every other value.
+// When no URL is supplied (e.g. the admin resend, which has no signing key),
+// the link block is omitted entirely and the receipt renders as before.
+var ORDER_RECEIPT_HTML_HEAD =
   "<!DOCTYPE html>\n" +
   "<html lang=\"en\"><head><meta charset=\"utf-8\"><title>Order receipt — {{order_id}}</title></head><body>\n" +
   "<h1>Thanks for your order</h1>\n" +
@@ -82,18 +90,29 @@ var ORDER_RECEIPT_HTML =
   "  <tr><td>Tax ({{tax_jurisdiction}})</td><td align=\"right\">{{tax_formatted}}</td></tr>\n" +
   "  <tr><td>Shipping</td><td align=\"right\">{{shipping_formatted}}</td></tr>\n" +
   "  <tr><td><strong>Total</strong></td><td align=\"right\"><strong>{{grand_total_formatted}}</strong></td></tr>\n" +
-  "</table>\n" +
+  "</table>\n";
+
+var ORDER_RECEIPT_HTML_LINK =
+  "<p style=\"margin:24px 0;\"><a href=\"{{order_url}}\" style=\"background:#fa4f09;color:#ffffff;padding:12px 20px;text-decoration:none;display:inline-block;font-weight:bold;\">View your order</a></p>\n" +
+  "<p style=\"margin:0;color:#0d0d0d;font-size:13px;\">If the button doesn't work, paste this link into your browser: {{order_url}}</p>\n";
+
+var ORDER_RECEIPT_HTML_TAIL =
   "<p>We'll email you again when your order ships.</p>\n" +
   "</body></html>\n";
 
-var ORDER_RECEIPT_TEXT =
+var ORDER_RECEIPT_TEXT_HEAD =
   "Thanks for your order, {{customer_name}}.\n\n" +
   "Order: {{order_id}}\n" +
   "Subtotal:                  {{subtotal_formatted}}\n" +
   "Tax ({{tax_jurisdiction}}):                {{tax_formatted}}\n" +
   "Shipping:                  {{shipping_formatted}}\n" +
   "-------------------------------------\n" +
-  "Total:                     {{grand_total_formatted}}\n\n" +
+  "Total:                     {{grand_total_formatted}}\n\n";
+
+var ORDER_RECEIPT_TEXT_LINK =
+  "View your order: {{order_url}}\n\n";
+
+var ORDER_RECEIPT_TEXT_TAIL =
   "We'll email you again when your order ships.\n";
 
 var SHIP_NOTIFICATION_HTML =
@@ -349,12 +368,41 @@ function _email(s) {
   return b.guardEmail.sanitize(s, { profile: "strict" });
 }
 
+// Guest-order access-token format. MUST stay byte-identical to the verifier
+// in lib/storefront.js (`_verifyOrderAccessToken`): the link this module mints
+// is validated there. `<exp_b36>.<hmac_hex[:32]>` over
+// "order-access:v1:" + orderId + ":" + exp_b36, keyed by the operator's app-
+// derived signing secret. HMAC-SHA3-512 is the PQC-aligned keyed MAC from the
+// vendored crypto surface. ~90-day lifetime so a guest can reopen the link
+// weeks later on any device. A change to either side without the other breaks
+// every emitted link, so the two are kept in lockstep by this shared contract.
+var ORDER_ACCESS_TOKEN_NS  = "order-access:v1:";
+var ORDER_ACCESS_TAG_HEX   = 32;
+var ORDER_ACCESS_TTL_MS    = b.constants.TIME.days(90);
+
+function _mintOrderAccessToken(secret, orderId) {
+  if (typeof secret !== "string" || !secret || typeof orderId !== "string" || !orderId) return "";
+  var expB36 = (Date.now() + ORDER_ACCESS_TTL_MS).toString(36);
+  var tag = b.crypto.hmacSha3(secret, ORDER_ACCESS_TOKEN_NS + orderId + ":" + expB36).slice(0, ORDER_ACCESS_TAG_HEX);
+  return expB36 + "." + tag;
+}
+
 function create(opts) {
   opts = opts || {};
   if (!opts.mailer || typeof opts.mailer.send !== "function") {
     throw new TypeError("email.create: opts.mailer (a b.mail.create result with .send()) is required");
   }
   var mailer = opts.mailer;
+  // Optional order-confirmation deep-link material. When BOTH a signing
+  // secret and a shop origin are wired, `orderReceipt` auto-builds a
+  // tokenized "View your order" link (so a guest's resend / confirmation
+  // mail opens their receipt on any device). Absent either, the receipt
+  // simply omits the link (unchanged behaviour).
+  var orderAccessSecret = (typeof opts.orderAccessSecret === "string" && opts.orderAccessSecret) ? opts.orderAccessSecret : "";
+  // Trailing-slash trim as a loop, not `/\/+$/` — the regex shape is
+  // superlinear on long runs of '/' and this value is library input.
+  var shopOrigin = (typeof opts.shopOrigin === "string" && opts.shopOrigin) ? opts.shopOrigin : "";
+  while (shopOrigin.charCodeAt(shopOrigin.length - 1) === 47) shopOrigin = shopOrigin.slice(0, -1);
 
   async function _send(to, subject, html, text, replyTo) {
     var msg = {
@@ -388,8 +436,25 @@ function create(opts) {
     orderReceipt: async function (input) {
       if (!input) throw new TypeError("email.orderReceipt: input object required");
       var vars = _orderVars(input.order, input.customer);
-      var html = _render(ORDER_RECEIPT_HTML, vars);
-      var text = _render(ORDER_RECEIPT_TEXT, vars);
+      // Optional order-confirmation link. A caller may hand a fully-built URL
+      // (input.order_url); otherwise, when the factory was wired with a signing
+      // secret + shop origin, mint a tokenized link here so the guest can open
+      // their receipt on any device (?k=<token>, validated by storefront's
+      // access gate). Each segment is rendered with EXACTLY the vars it
+      // references so the strict renderer's unused-var guard stays on (the
+      // head/tail never see {{order_url}}; the link block never sees the money
+      // vars). Absent a URL and the mint material, the link block is dropped.
+      var orderUrl = (typeof input.order_url === "string" && input.order_url) ? input.order_url : "";
+      if (!orderUrl && orderAccessSecret && shopOrigin) {
+        var k = _mintOrderAccessToken(orderAccessSecret, input.order.id);
+        if (k) orderUrl = shopOrigin + "/orders/" + encodeURIComponent(input.order.id) + "?k=" + encodeURIComponent(k);
+      }
+      var html = _render(ORDER_RECEIPT_HTML_HEAD, vars) +
+        (orderUrl ? _render(ORDER_RECEIPT_HTML_LINK, { order_url: orderUrl }) : "") +
+        _render(ORDER_RECEIPT_HTML_TAIL, {});
+      var text = _render(ORDER_RECEIPT_TEXT_HEAD, vars) +
+        (orderUrl ? _render(ORDER_RECEIPT_TEXT_LINK, { order_url: orderUrl }) : "") +
+        _render(ORDER_RECEIPT_TEXT_TAIL, {});
       return await _send(input.customer.email, "Your order " + input.order.id, html, text, input.replyTo);
     },
 
@@ -725,8 +790,12 @@ module.exports = {
   // — operators may inject their own strings via opts.templates
   // (added in a follow-up patch alongside b.theme).
   templates: {
-    ORDER_RECEIPT_HTML:      ORDER_RECEIPT_HTML,
-    ORDER_RECEIPT_TEXT:      ORDER_RECEIPT_TEXT,
+    ORDER_RECEIPT_HTML_HEAD: ORDER_RECEIPT_HTML_HEAD,
+    ORDER_RECEIPT_HTML_LINK: ORDER_RECEIPT_HTML_LINK,
+    ORDER_RECEIPT_HTML_TAIL: ORDER_RECEIPT_HTML_TAIL,
+    ORDER_RECEIPT_TEXT_HEAD: ORDER_RECEIPT_TEXT_HEAD,
+    ORDER_RECEIPT_TEXT_LINK: ORDER_RECEIPT_TEXT_LINK,
+    ORDER_RECEIPT_TEXT_TAIL: ORDER_RECEIPT_TEXT_TAIL,
     SHIP_NOTIFICATION_HTML:  SHIP_NOTIFICATION_HTML,
     SHIP_NOTIFICATION_TEXT:  SHIP_NOTIFICATION_TEXT,
     REFUND_HTML:             REFUND_HTML,

package/lib/security-middleware.js

@@ -265,9 +265,27 @@ function securityHeadersOpts() {
 // what the provider's own CDN requires.
 var CSP_HOSTS = {
   stripe: {
-    script:  ["https://js.stripe.com"],
+    // Stripe.js v3 starts sub-frames on per-origin `*.js.stripe.com` hosts
+    // for performance (Stripe security guide), and its dynamic loader
+    // injects those sub-resource <script>s at runtime — so BOTH the apex
+    // and the wildcard must be admitted on script-src, or the
+    // TrustedScriptURL/dynamic-load path is refused (the 3DS challenge
+    // loader rides this).
+    script:  ["https://js.stripe.com", "https://*.js.stripe.com"],
     connect: ["https://api.stripe.com"],
-    frame:   ["https://js.stripe.com", "https://hooks.stripe.com"],
+    // frame-src: the apex + `*.js.stripe.com` carry the Payment Element /
+    // 3DS challenge frames; hooks.stripe.com carries redirect-style
+    // confirmations. `b.stripecdn.com` serves the Express Checkout wallet
+    // button assets (e.g. the Amazon Pay button iframe at
+    // b.stripecdn.com/stripethirdparty-srv/...) — without it the express
+    // wallet button iframe is blocked (net::ERR_ABORTED) while Link /
+    // Google Pay, which render from *.js.stripe.com, load fine.
+    frame:   [
+      "https://js.stripe.com",
+      "https://*.js.stripe.com",
+      "https://hooks.stripe.com",
+      "https://b.stripecdn.com",
+    ],
   },
   paypal: {
     script:  ["https://www.paypal.com", "https://www.paypalobjects.com"],

package/lib/storefront.js

@@ -452,8 +452,14 @@ function _islandScript(name, opts) {
   // construction at the call site, so they go in without escaping.
   var idAttr     = (opts && opts.id)     ? " id=\"" + opts.id + "\"" : "";
   var policyAttr = (opts && opts.policy) ? " data-consent-policy=\"" + opts.policy + "\"" : "";
+  // Islands `defer` by default (run after parse, in document order). The
+  // Trusted Types `default` policy is the exception: it MUST register
+  // synchronously BEFORE the parser-inserted Stripe SDK <script> executes,
+  // so `opts.sync` drops `defer` (and adds no `async`) — a classic blocking
+  // <script> that runs the instant the parser reaches it.
+  var timing = (opts && opts.sync) ? "" : " defer";
   return "<script" + idAttr + " src=\"" + _assetUrl("js/" + name) + "\"" +
-    (sri ? " integrity=\"" + sri + "\"" : "") + " defer" + policyAttr + "></script>";
+    (sri ? " integrity=\"" + sri + "\"" : "") + timing + policyAttr + "></script>";
 }
 
 // ---- announcement bar --------------------------------------------------
@@ -7170,6 +7176,11 @@ var PAY_PAGE =
   "    <button id=\"submit\" type=\"button\" class=\"btn-primary pay-card__submit\">Pay {{grand_total}}</button>\n" +
   "    <p id=\"payment-message\" class=\"pay-card__message\"></p>\n" +
   "  </div>\n" +
+  // Trusted Types `default` policy — MUST be registered before the Stripe
+  // SDK loads (emitted sync/blocking, no defer) so Stripe.js's dynamic
+  // script-URL injections (perf sub-frames + the 3DS challenge loader) pass
+  // the createScriptURL gate instead of being refused as un-typed.
+  "  RAW_PAY_TT_SCRIPT\n" +
   "  <script src=\"https://js.stripe.com/v3/\"></script>\n" +
   "  RAW_PAY_SCRIPT\n" +
   "</section>\n";
@@ -7195,6 +7206,10 @@ function renderPayPage(opts) {
       pk:                  opts.publishable_key,
       client_secret:       opts.client_secret,
       pay_script:          opts.theme.assetUrl("js/pay.js"),
+      // Trusted Types `default` policy asset — rendered (sync, no defer)
+      // BEFORE the Stripe SDK tag in pay.html so it registers the
+      // createScriptURL gate ahead of Stripe.js's first dynamic load.
+      pay_tt_script:       opts.theme.assetUrl("js/pay-trusted-types.js"),
       asset_css_main:      opts.theme.assetUrl("css/main.css"),
     });
   }
@@ -7206,7 +7221,9 @@ function renderPayPage(opts) {
     grand_total:        grandTotal,
     pk:                 opts.publishable_key,
     client_secret:      opts.client_secret,
-  }).replace("RAW_PAY_SCRIPT", _islandScript("pay.js"));
+  })
+    .replace("RAW_PAY_TT_SCRIPT", _islandScript("pay-trusted-types.js", { sync: true }))
+    .replace("RAW_PAY_SCRIPT", _islandScript("pay.js"));
   // Operator trust badges at the checkout placement (container-only — the pay
   // page isn't edge-cached). Pre-resolved + sanitized by the route; appended
   // after the pay card. Empty string when no badges / no dep.
@@ -7599,6 +7616,50 @@ function _orderRatingBlock(opts) {
   return "";
 }
 
+// Post-checkout "save your details / create an account" offer on the order
+// confirmation page. Shown ONLY to a guest who just checked out (the route
+// resolves the sealed claim cookie for THIS order and confirms the visitor
+// is not signed in) — a signed-in buyer never sees it. One click sends a
+// single-use sign-in link to the email the buyer checked out with; the
+// address is MASKED on screen (the route passes `masked_email`, never the
+// full address) so the confirmation HTML never carries the plaintext. When
+// an account already exists for that email the copy says "sign in" instead
+// of "create an account" — but the SEND path is identical either way (no
+// account-existence oracle; the response after the POST is the same
+// regardless). `claim_notice` flags the post-send confirmation (the POST
+// redirects to ?claim=sent), replacing the form with a neutral "check your
+// inbox" line. The form posts to /orders/:id/claim-account with no email
+// field (the address lives only in the sealed cookie) and is auto-tokened
+// by _injectCsrfFields (/orders/ is not an edge-exempt prefix).
+function _orderClaimAccountBlock(opts) {
+  if (opts.claim_notice === "sent") {
+    return "<section class=\"order-claim\" aria-live=\"polite\">" +
+      "<h2 class=\"pdp__variants-title\">Check your inbox</h2>" +
+      "<p class=\"order-claim__sent\">If that address can have an account, we've emailed a single-use sign-in link. " +
+      "Follow it to finish setting up your account — your order will be saved to it automatically.</p>" +
+      "</section>";
+  }
+  var offer = opts.claim_offer;
+  if (!offer || typeof offer.masked_email !== "string") return "";
+  var esc = b.template.escapeHtml;
+  var o = opts.order;
+  var exists = !!offer.account_exists;
+  var heading = exists ? "Sign in to save this order" : "Save your details";
+  var lede = exists
+    ? "Looks like you already have an account with <strong>" + esc(offer.masked_email) +
+      "</strong>. Sign in and we'll attach this order to it — one click, nothing to type."
+    : "Create an account with <strong>" + esc(offer.masked_email) +
+      "</strong> to track this order and check out faster next time. One click — we'll email you a secure sign-in link, nothing to type.";
+  var cta = exists ? "Email me a sign-in link" : "Create my account";
+  return "<section class=\"order-claim\">" +
+    "<h2 class=\"pdp__variants-title\">" + esc(heading) + "</h2>" +
+    "<p class=\"order-claim__lede\">" + lede + "</p>" +
+    "<form class=\"order-claim__form form-stack\" method=\"post\" action=\"/orders/" + esc(String(o.id)) + "/claim-account\">" +
+    "<div class=\"form-actions\"><button type=\"submit\" class=\"btn-primary\">" + esc(cta) + "</button></div>" +
+    "</form>" +
+    "</section>";
+}
+
 // Map a ?rate_err= code (set by a rejected rating POST on its PRG redirect)
 // to a clean, operator-safe correction message rendered above the rating
 // form. Defensive request reader — an unknown / absent code yields no
@@ -7711,6 +7772,11 @@ function renderOrder(opts) {
   // passes the resolved getRating row (rating) + the eligibility/notice
   // flags; the edge render never does, so the panel is empty at the edge.
   var ratingHtml   = _orderRatingBlock(opts);
+  // Post-checkout account-claim offer — container-only (the route resolves
+  // it from the sealed claim cookie; the edge render never passes it). Empty
+  // string for a signed-in buyer, a non-guest order, or any page without a
+  // matching claim cookie.
+  var claimHtml    = _orderClaimAccountBlock(opts);
   if (opts.theme) {
     return opts.theme.render("order", {
       title:               "Order " + o.id,
@@ -7731,6 +7797,7 @@ function renderOrder(opts) {
       gift_html:           _orderGiftBlock(opts.gift_options),
       actions_html:        actionsHtml,
       rating_html:         ratingHtml,
+      claim_html:          claimHtml,
       can_return:          _orderEligibleForReturn(o.status),
       can_reorder:         _orderEligibleForReorder(o.status),
       can_cancel:          _orderEligibleForCancel(o.status),
@@ -7810,12 +7877,17 @@ function renderOrder(opts) {
   // can't trip String.replace dollar substitution. Empty string when no badges
   // / no dep.
   var trustBadgesHtml = typeof opts.trust_badges_html === "string" ? opts.trust_badges_html : "";
+  // The claim offer carries only escaped values (the masked email is run
+  // through escapeHtml in the block builder, the rest is static copy), so a
+  // direct concat is safe — no `$`-substitution hazard. Placed right after
+  // the order body so a just-checked-out guest sees the offer before the
+  // cross-sell rail.
   return _wrap({
     title:      "Order " + o.id,
     shop_name:  shopName,
     cart_count: cartCount,
     theme_css: opts.theme_css,
-    body:       body + railHtml + trustBadgesHtml,
+    body:       body + claimHtml + railHtml + trustBadgesHtml,
   });
 }
 
@@ -8788,6 +8860,21 @@ var OAUTH_COOKIE_NAME = "shop_oauth";
 // Sealed so it can't be forged to mis-attribute a signup.
 var REFERRAL_COOKIE_NAME = "shop_ref";
 
+// Sealed cookie carrying the just-checked-out buyer's plaintext email so
+// the order confirmation page can offer a one-click "save your details"
+// account-creation prompt WITHOUT persisting the plaintext anywhere
+// durable. The customers store keeps email only as a one-way hash; the
+// plaintext exists transiently at checkout confirm, so it is stashed HERE
+// (AEAD-sealed, never written to D1) keyed to the order id, then read back
+// on /orders/:id and the claim-account trigger. Short-lived (matches the
+// pay-window TTL) and Path "/" so it survives the Stripe /pay → /orders
+// return. Sealed so a tampering client can't swap in another address to
+// trigger a victim-addressed sign-in mail. `email` is the address the
+// buyer typed at confirm; `order_id` pins the cookie to the one order so a
+// stale cookie from an earlier order doesn't surface on a different
+// confirmation page.
+var CLAIM_COOKIE_NAME = "shop_claim";
+
 // Sealed cookie holding the visitor's chosen DISPLAY currency (ISO 4217).
 // Display-only: the cart / order / payment currency is unchanged — this
 // only selects which currency the price strings are rendered in. Sealed
@@ -8934,6 +9021,187 @@ function _readReferralEnv(req) {
   try { return JSON.parse(raw); } catch (_e) { return null; }
 }
 
+// Post-checkout account-claim cookie. Carries the plaintext buyer email
+// (sealed) + the order id it was placed under, so the confirmation page can
+// mask the address on screen and the claim-account trigger can mint a
+// sign-in link to it — without ever reading the plaintext from D1 (the
+// customers store has only the hash). 15-minute TTL matches the pay window;
+// the post-redemption order-link uses the durable email-hash match, so the
+// cookie's only job is the on-page offer + the one-click send.
+function _setClaimCookie(req, res, env) {
+  var T = b.constants.TIME;
+  var secure = _secureForReq(req);
+  _cookieJar().writeSealed(res, CLAIM_COOKIE_NAME, JSON.stringify(env), {
+    expires: new Date(Date.now() + T.minutes(15)),
+    secure:  secure,
+  });
+}
+function _clearClaimCookie(req, res) {
+  var secure = _secureForReq(req);
+  _cookieJar().clear(res, CLAIM_COOKIE_NAME, { secure: secure });
+}
+function _readClaimEnv(req) {
+  var raw = _cookieJar().readSealed(req, CLAIM_COOKIE_NAME);
+  if (raw === null) return null;
+  try { return JSON.parse(raw); } catch (_e) { return null; }
+}
+
+// Sealed cookie that grants the PLACING browser durable read access to its
+// own guest-order confirmation pages. A guest order carries no customer_id,
+// so the IDOR ownership check can't gate it the way it gates an owned order;
+// without this, the order's full name / address / line items would be
+// readable by anyone who learns (or guesses, since ids are timestamp-ordered
+// UUIDv7) the order UUID. At confirm time the order id is prepended to a
+// capped, rotating list sealed into this cookie; a later GET /orders/:id for
+// a guest order is admitted only when the id is in this list (the buyer's own
+// browser), a valid emailed access token is presented (any device), or the
+// request is the signed-in owner. The list is capped so the cookie can't grow
+// without bound (a heavy guest buyer keeps access to their most recent
+// GUEST_ORDER_ACCESS_MAX orders; older ones fall off and are reachable only
+// via the emailed token). 30-day TTL, refreshed on each write. Sealed so a
+// tampering client can't forge access to an arbitrary id.
+var GUEST_ORDER_ACCESS_COOKIE_NAME = "shop_oacc";
+var GUEST_ORDER_ACCESS_MAX = 20;
+
+// Read the placing browser's granted guest-order id list. Defensive reader:
+// a missing / tampered / malformed cookie reads as "no grants" (empty array)
+// rather than throwing — the cookie grants only read access to one's own
+// just-placed receipt, so a bad value simply withholds it.
+function _readGuestOrderAccessIds(req) {
+  var raw = _cookieJar().readSealed(req, GUEST_ORDER_ACCESS_COOKIE_NAME);
+  if (raw === null) return [];
+  var env;
+  try { env = JSON.parse(raw); } catch (_e) { return []; }
+  if (!env || !Array.isArray(env.ids)) return [];
+  var out = [];
+  for (var i = 0; i < env.ids.length && out.length < GUEST_ORDER_ACCESS_MAX; i += 1) {
+    var id = env.ids[i];
+    if (typeof id === "string" && id && out.indexOf(id) === -1) out.push(id);
+  }
+  return out;
+}
+
+// Grant the placing browser durable access to `orderId` by prepending it to
+// the rotating list and resealing (newest-first, de-duplicated, capped). Must
+// run on the confirm path BEFORE the Stripe redirect leaves the site so the
+// buyer returns (redirect_status=succeeded) already holding access; the
+// 303 PRG strip preserves it (the cookie is set on the redirect response).
+function _grantGuestOrderAccess(req, res, orderId) {
+  if (typeof orderId !== "string" || !orderId) return;
+  var T = b.constants.TIME;
+  var secure = _secureForReq(req);
+  var ids = _readGuestOrderAccessIds(req);
+  var idx = ids.indexOf(orderId);
+  if (idx !== -1) ids.splice(idx, 1);
+  ids.unshift(orderId);
+  if (ids.length > GUEST_ORDER_ACCESS_MAX) ids = ids.slice(0, GUEST_ORDER_ACCESS_MAX);
+  _cookieJar().writeSealed(res, GUEST_ORDER_ACCESS_COOKIE_NAME, JSON.stringify({ v: 1, ids: ids }), {
+    expires: new Date(Date.now() + T.days(30)),
+    secure:  secure,
+  });
+}
+
+function _hasGuestOrderAccessCookie(req, orderId) {
+  if (typeof orderId !== "string" || !orderId) return false;
+  return _readGuestOrderAccessIds(req).indexOf(orderId) !== -1;
+}
+
+// ---- emailed guest-order access token ----------------------------------
+//
+// A signed, order-scoped token carried in the confirmation email's order
+// link (?k=<token>) so the buyer can open their receipt on ANY device, not
+// just the placing browser. The token is `<exp_b36>.<tag>` where `exp_b36`
+// is the base-36 expiry (epoch ms) and `tag` is HMAC-SHA3-512(secret,
+// "order-access:v1:" + orderId + ":" + exp_b36), truncated to 32 hex chars
+// (128 bits — ample for an unguessable, non-replayable-past-expiry handle).
+// HMAC-SHA3-512 is the PQC-aligned keyed MAC from the vendored crypto
+// surface; the key is derived in server.js from the operator's app secret
+// (domain-separated via namespaceHash), never a per-request value. The link
+// is MINTED in lib/email.js (which holds the same key) and only VERIFIED here:
+// the tag is recomputed over the SAME orderId+exp and compared constant-time
+// (b.crypto.timingSafeEqual), then the embedded expiry is checked — so a
+// tampered id, a tampered exp, or an expired link all fail closed (→ 404).
+// The two sides share the `order-access:v1:` namespace + 32-hex-char width
+// as one contract; email.js mints with the identical format.
+var GUEST_ORDER_TOKEN_NS = "order-access:v1:";
+var GUEST_ORDER_TOKEN_TAG_HEX_LEN = 32;
+
+function _orderAccessTokenTag(secret, orderId, expB36) {
+  // hmacSha3 returns a lowercase hex string; truncate to a fixed width so the
+  // token stays compact while keeping 128 bits of MAC.
+  return b.crypto.hmacSha3(secret, GUEST_ORDER_TOKEN_NS + orderId + ":" + expB36)
+    .slice(0, GUEST_ORDER_TOKEN_TAG_HEX_LEN);
+}
+
+// Verify a presented token for `orderId`. Constant-time tag compare, then the
+// embedded-expiry check. Any structural problem, a tampered id/exp, or an
+// expired token returns false (the route maps that to a 404). No secret wired
+// → no token can ever verify (false).
+function _verifyOrderAccessToken(secret, orderId, token) {
+  if (typeof secret !== "string" || !secret) return false;
+  if (typeof orderId !== "string" || !orderId) return false;
+  if (typeof token !== "string" || !token) return false;
+  var dot = token.indexOf(".");
+  if (dot <= 0 || dot === token.length - 1) return false;
+  var expB36 = token.slice(0, dot);
+  var tag    = token.slice(dot + 1);
+  if (!/^[0-9a-z]+$/.test(expB36) || !/^[0-9a-f]+$/.test(tag)) return false;
+  var exp = parseInt(expB36, 36);
+  if (!isFinite(exp) || exp <= 0) return false;
+  var expected = _orderAccessTokenTag(secret, orderId, expB36);
+  // Compare the supplied tag against the recomputed one in constant time
+  // BEFORE the (cheap, non-secret) expiry check — a length mismatch is its
+  // own non-match. timingSafeEqual throws on unequal-length inputs, so guard.
+  if (tag.length !== expected.length) return false;
+  if (!b.crypto.timingSafeEqual(tag, expected)) return false;
+  return Date.now() < exp;
+}
+
+// Mask an email for on-screen display so the confirmation page can show
+// WHICH address the sign-in link goes to without printing the full address
+// into cached/over-the-shoulder-visible HTML. `robert@example.com` →
+// `r***@e***.com`: first char of the local part, first char of each
+// dot-segment of the domain, the TLD kept whole (it's not identifying).
+// Defensive: a missing `@`, an empty part, or a non-string returns a fixed
+// "your email" so the offer never throws or leaks a malformed value.
+function _maskEmail(email) {
+  if (typeof email !== "string" || email.indexOf("@") === -1) return "your email";
+  var at = email.lastIndexOf("@");
+  var local = email.slice(0, at);
+  var domain = email.slice(at + 1);
+  if (!local.length || !domain.length) return "your email";
+  var maskedLocal = local.charAt(0) + "***";
+  var segs = domain.split(".");
+  var maskedDomain;
+  if (segs.length >= 2) {
+    var tld = segs[segs.length - 1];
+    var head = segs.slice(0, segs.length - 1).map(function (s) {
+      return s.length ? (s.charAt(0) + "***") : "***";
+    }).join(".");
+    maskedDomain = head + "." + tld;
+  } else {
+    maskedDomain = domain.charAt(0) + "***";
+  }
+  return maskedLocal + "@" + maskedDomain;
+}
+
+// Derive a non-empty display name for an account auto-created from a
+// post-checkout claim. customers.register refuses an empty / control-byte /
+// over-long name, so take the local part of the email, strip control bytes,
+// and fall back to a fixed "Shopper" when nothing usable remains. Capped well
+// under the store's display-name limit. Never carries the full address (only
+// the local part) and is the buyer's to rename from their account.
+function _displayNameFromEmail(email) {
+  var fallback = "Shopper";
+  if (typeof email !== "string") return fallback;
+  var at = email.lastIndexOf("@");
+  var local = at > 0 ? email.slice(0, at) : email;
+  // Strip control bytes; keep it readable + short.
+  var clean = local.replace(/[\x00-\x1f\x7f]/g, "").trim();
+  if (!clean.length) return fallback;
+  return clean.length > 64 ? clean.slice(0, 64) : clean;
+}
+
 // ---- cookie-consent cookies --------------------------------------------
 //
 // Two cookies carry a visitor's cookie-consent decision:
@@ -11199,6 +11467,41 @@ function mount(router, deps) {
     return env;
   }
 
+  // The operator's order-access signing key (derived in server.js from the
+  // app secret, domain-separated). Absent it, the emailed-token access path
+  // is inert — the placing-browser cookie and signed-in-owner paths still
+  // gate a guest order. Read once at mount.
+  var _orderAccessSecret = (typeof deps.order_access_secret === "string" && deps.order_access_secret)
+    ? deps.order_access_secret : "";
+
+  // Whether THIS request is permitted to read/act on order `o`.
+  //
+  //   * Owned order (customer_id set): the signed-in owner ONLY — anyone else
+  //     (different customer or anonymous) is refused. This is the pre-existing
+  //     IDOR gate, unchanged.
+  //   * Guest order (no customer_id): admitted only when the request proves it
+  //     is the buyer — the placing browser (sealed access cookie carrying this
+  //     id), a valid emailed access token (?k=, any device), OR a sealed claim
+  //     cookie pinned to this order (the post-checkout account-claim offer
+  //     requires that cookie, and holding it implies the buyer placed the
+  //     order). A bare-UUID request with none of these is refused, so a guest
+  //     order's name/address/items no longer leak to anyone who learns the id.
+  //
+  // Returns true when access is granted, false when the route should 404
+  // (indistinguishable from a missing order).
+  function _orderAccessGranted(req, o, orderAuth, accessToken) {
+    if (!o) return false;
+    if (o.customer_id) {
+      return !!(orderAuth && o.customer_id === orderAuth.customer_id);
+    }
+    // Guest order — capability proofs, any one suffices.
+    if (_hasGuestOrderAccessCookie(req, o.id)) return true;
+    if (_orderAccessSecret && _verifyOrderAccessToken(_orderAccessSecret, o.id, accessToken)) return true;
+    var claimEnv = _readClaimEnv(req);
+    if (claimEnv && claimEnv.order_id === o.id) return true;
+    return false;
+  }
+
   // Resolve a product id into the { slug, title, price, image_url,
   // image_alt } shape `_buildProductCard` expects. Returns null for an
   // archived / missing product so it drops out of any grid (collections,
@@ -13104,6 +13407,43 @@ function mount(router, deps) {
         // schedule land here. A failure must never roll back a paid order, so
         // each is its own try/catch (mirrors _recordAutoDiscounts).
         await _persistGiftAndPickup(c, result.order, body);
+        // Guest-order access grant. A guest order (no owner) is gated on
+        // GET /orders/:id by a capability proof — stamp the placing browser's
+        // sealed access cookie HERE, before either redirect leaves the site,
+        // so the buyer can revisit their confirmation. Critically this runs
+        // BEFORE the Stripe hand-off: the buyer returns from Stripe
+        // (redirect_status=succeeded) in THIS browser already holding access,
+        // and the 303 PRG strip preserves it (the cookie rides the redirect
+        // response, not the URL). Independent of the magic-link surface — it's
+        // the buyer's own receipt access, not the account-claim offer. Keyed
+        // on the resulting ORDER being a guest order (no customer_id), NOT on
+        // the requester's sign-in state: a signed-in shopper whose cart had no
+        // customer_id (checkout.confirm derives a guest order) needs this grant
+        // too — the owned-order auth gate can't admit them since the order
+        // carries no owner to match. Drop-silent: a grant failure must never
+        // break the checkout redirect.
+        if (!result.order.customer_id) {
+          try { _grantGuestOrderAccess(req, res, result.order.id); }
+          catch (_eAccess) { /* drop-silent — receipt access is best-effort */ }
+        }
+        // Post-checkout account-claim stash. A guest (no signed-in customer
+        // on this request, and the order carries no owner) just typed a
+        // deliverable email at confirm — seal it into the short-lived claim
+        // cookie keyed to this order so the confirmation page can offer a
+        // one-click "save your details" sign-in-link send to it. The
+        // plaintext lives ONLY in this AEAD-sealed cookie (never D1: the
+        // customers store keeps only the hash). Skipped for a signed-in
+        // buyer (their order is already owned / they have an account) and
+        // only when the magic-link surface is wired (no mailer = no
+        // deliverable link, so no offer). Drop-silent: a stash failure must
+        // never break the checkout redirect.
+        if (deps.customerPortal && deps.customerPortalEmail &&
+            !result.order.customer_id && !_currentCustomerEnv(req) &&
+            typeof body.email === "string" && body.email) {
+          try {
+            _setClaimCookie(req, res, { order_id: result.order.id, email: body.email });
+          } catch (_eClaim) { /* drop-silent — the offer is best-effort */ }
+        }
         // Consent-gated funnel event — checkout_complete (an order was
         // placed: the cart converted via checkout.confirm). Fires for both
         // the gift-card-fully-paid path and the Stripe-intent path (the
@@ -13338,43 +13678,40 @@ function mount(router, deps) {
         res.status(503);
         return res.end ? res.end("Stripe publishable key not configured") : res.send("Stripe publishable key not configured");
       }
-      // Route-scoped CSP that admits js.stripe.com on script/connect/frame-src
-      // (and Trusted Types stays on) so the Stripe SDK + the same-origin
+      // Route-scoped CSP that admits Stripe's hosts on script/connect/frame-src
+      // (and Trusted Types stays ON) so the Stripe SDK + the same-origin
       // pay.js island load — without relaxing the app-level strict CSP that
       // governs every OTHER route. setHeader OVERWRITES the app-level header
       // for this response only.
       //
-      // KNOWN, NON-BLOCKING Trusted Types violation on this route (operator
-      // follow-up, intentionally NOT fixed here). The app-level CSP carried
-      // through verbatim by scopedCsp keeps `require-trusted-types-for
-      // 'script'` + `trusted-types 'allow-duplicates' default`. Stripe.js v3
-      // does NOT register a named Trusted Types policy of its own; instead it
-      // expects the APPLICATION to define a `default` policy whose
-      // createScriptURL vets Stripe's own hosts (per Stripe's integration
-      // security guide). When Stripe.js dynamically injects its sub-resource
-      // <script> (the frame-spawning performance path on *.js.stripe.com), the
-      // browser refuses the TrustedScriptURL assignment because no `default`
-      // policy is registered — the console logs "This document requires
-      // 'TrustedScriptURL' assignment ... @ https://js.stripe.com/v3/". The
-      // card form is unaffected: it loads from the STATIC <script
-      // src="https://js.stripe.com/v3/"> tag, which is a direct HTML src (not
-      // a JS-driven sink), so require-trusted-types-for does not gate it —
-      // which is why card captures complete with the violation present. The
-      // blocked path is Stripe's dynamic sub-frame/3DS loader.
+      // TRUSTED TYPES, RESOLVED. The app-level CSP carried through verbatim by
+      // scopedCsp keeps `require-trusted-types-for 'script'` +
+      // `trusted-types 'allow-duplicates' default`. Stripe.js v3 registers no
+      // Trusted Types policy of its own; it expects the APPLICATION to define
+      // a `default` policy whose createScriptURL vets Stripe's hosts (Stripe
+      // security guide). The pay page now ships that policy in
+      // `pay-trusted-types.js`, emitted (sync, no defer) BEFORE the Stripe SDK
+      // tag, so when Stripe.js dynamically injects its sub-resource <script>
+      // (the perf sub-frames on *.js.stripe.com and the 3-D Secure
+      // challenge-frame loader) the browser routes the URL through the policy
+      // and admits it — instead of refusing it with "This document requires
+      // 'TrustedScriptURL' assignment". The policy throws for any non-Stripe
+      // origin, so Trusted Types stays a real gate, not a relaxation. The
+      // scoped CSP's script-src/frame-src admit both `js.stripe.com` and
+      // `*.js.stripe.com` (the sub-origins the dynamic loader uses).
+      //
+      // EXPRESS WALLET FRAMES. The scoped frame-src also admits
+      // `b.stripecdn.com`, where the Express Checkout Element loads its wallet
+      // button iframes (e.g. the Amazon Pay button at
+      // b.stripecdn.com/stripethirdparty-srv/...); without it that iframe is
+      // blocked (net::ERR_ABORTED) while Link / Google Pay, served from
+      // *.js.stripe.com, render fine.
       //
-      // We do NOT loosen Trusted Types to silence it. Naming a Stripe policy
-      // in the trusted-types directive does nothing (Stripe registers none);
-      // the only fix Stripe documents is the app shipping a same-origin
-      // `default` createScriptURL policy that allows js.stripe.com /
-      // *.js.stripe.com AND widening this scoped CSP's script-src/frame-src to
-      // *.js.stripe.com. A `default` TT policy is page-global (it vets EVERY
-      // TrustedScriptURL/TrustedHTML/TrustedScript sink, including any future
-      // app sink), so adopting it is a deliberate posture change, not a
-      // drive-by — left as an operator follow-up. To reproduce + verify a fix,
-      // pay with the Stripe 3-D Secure test card 4000002760003184 (forces an
-      // authentication challenge, which exercises the dynamic challenge-frame
-      // loader that trips this) and confirm the console violation is gone and
-      // the challenge frame renders.
+      // A live 3-D Secure path still warrants a production verification: pay
+      // with the Stripe 3DS test card 4000002760003184 (forces an
+      // authentication challenge that exercises the dynamic challenge-frame
+      // loader) and confirm the challenge frame renders with no TrustedScriptURL
+      // console violation.
       res.setHeader && res.setHeader("content-security-policy", securityMiddleware.scopedCsp(["stripe"]));
       // Route-scoped Permissions-Policy that re-enables the `payment` feature
       // for this one response (same origin + the Stripe / Google Pay wallet
@@ -13407,20 +13744,33 @@ function mount(router, deps) {
       try { o = await deps.order.get(orderId); }
       catch (e) { if (e instanceof TypeError) { o = null; } else throw e; }
       if (!o) return _send(res, 404, renderNotFound({ shop_name: shopName, theme: theme }));
-      // Ownership gate against IDOR: an order's confirmation page exposes
-      // the customer's name, address, and line items by UUID alone. An order
-      // that BELONGS to a customer (customer_id set) is viewable only by that
-      // signed-in customer — anyone else (a different customer OR an
-      // unauthenticated request) 404s rather than leaking it. A guest order
-      // carries no customer_id and remains reachable via its unguessable URL
-      // (the capability-URL model), so BOTH the just-placed-as-guest path AND
-      // the signed-in-shopper-with-an-anonymous-cart path (checkout.confirm
-      // derives the order from a cart that has no customer_id) still render
-      // their own confirmation here.
+      // Access gate against IDOR: an order's confirmation page exposes the
+      // customer's name, address, and line items by UUID alone — and ids are
+      // timestamp-ordered UUIDv7, so a bare UUID is not a secret. An OWNED
+      // order (customer_id set) is viewable only by that signed-in customer.
+      // A GUEST order (no customer_id) is admitted only when the request
+      // proves it is the buyer: the placing browser (sealed access cookie),
+      // a valid emailed access token (?k=, any device), or a sealed claim
+      // cookie pinned to this order. Anything else 404s rather than leaking a
+      // stranger's receipt. The signed-in-shopper-with-an-anonymous-cart path
+      // (checkout.confirm derives the order from a cart that has no
+      // customer_id) still renders via the access cookie stamped at confirm.
       var orderAuth = _currentCustomerEnv(req);
-      if (o.customer_id && (!orderAuth || o.customer_id !== orderAuth.customer_id)) {
+      var ordAccessToken = (req.query && typeof req.query.k === "string") ? req.query.k : "";
+      if (!_orderAccessGranted(req, o, orderAuth, ordAccessToken)) {
         return _send(res, 404, renderNotFound({ shop_name: shopName, theme: theme }));
       }
+      // A guest order opened from the emailed access link (?k=) arrives on a
+      // device that may hold no access cookie yet. Stamp one now so the
+      // receipt keeps resolving after the ?k= param is gone (a refresh, or the
+      // PRG strip below) — the token proved the buyer; the cookie carries that
+      // proof forward on this device. No-op for an owned order (the signed-in
+      // owner is gated by auth, not the cookie) and idempotent when the cookie
+      // already carries this id. Drop-silent: a stamp failure must never break
+      // the receipt render.
+      if (!o.customer_id && ordAccessToken && !_hasGuestOrderAccessCookie(req, o.id)) {
+        try { _grantGuestOrderAccess(req, res, o.id); } catch (_eGrant) { /* best-effort */ }
+      }
       // Stripe's post-payment return lands here with ?redirect_status=
       // succeeded — the moment the payment actually settled client-side,
       // with the shopper's session + consent readable. Record the funnel's
@@ -13535,6 +13885,37 @@ function mount(router, deps) {
         try { giftOptionsRow = await deps.giftOptions.getForOrder(o.id); }
         catch (e) { if (!(e instanceof TypeError)) throw e; giftOptionsRow = null; }
       }
+      // Post-checkout account-claim offer. Resolved ONLY when the magic-link
+      // surface is wired, the order is a guest order (no owner), and the
+      // request is unauthenticated — a signed-in buyer (their order is theirs
+      // already) never sees it. The buyer email was sealed into the claim
+      // cookie at confirm time; here we read it back, confirm it pins to THIS
+      // order (a stale cookie from an earlier order is ignored), mask it for
+      // display, and check whether an account already exists for the address
+      // (to pick "sign in" vs "create" wording). The plaintext is read only
+      // from the sealed cookie — never from D1. `?claim=sent` flips the form
+      // to the post-send confirmation. Drop-silent: a bad-shaped email or any
+      // lookup failure simply suppresses the offer rather than 500-ing the
+      // confirmation page.
+      var claimOffer = null;
+      var claimNotice = ordUrl ? ordUrl.searchParams.get("claim") : null;
+      if (deps.customerPortal && deps.customerPortalEmail &&
+          !o.customer_id && !orderAuth && claimNotice !== "sent") {
+        var claimEnv = _readClaimEnv(req);
+        if (claimEnv && claimEnv.order_id === o.id &&
+            typeof claimEnv.email === "string" && claimEnv.email) {
+          var accountExists = false;
+          try {
+            var claimHash = deps.customers.hashEmail(claimEnv.email);
+            var claimCust = await deps.customers.byEmailHash(claimHash);
+            accountExists = !!(claimCust && claimCust.id);
+          } catch (_eClaim) { accountExists = false; }
+          claimOffer = {
+            masked_email:   _maskEmail(claimEnv.email),
+            account_exists: accountExists,
+          };
+        }
+      }
       _send(res, 200, renderOrder({
         order:           o,
         product_lookup:  productLookup,
@@ -13548,11 +13929,130 @@ function mount(router, deps) {
         rating_notice:   ordUrl ? _ratingNoticeFor(ordUrl.searchParams.get("rate_err")) : null,
         reordered:       ordUrl ? ordUrl.searchParams.get("reordered") === "1" : false,
         cancelled:       ordUrl ? ordUrl.searchParams.get("cancelled") === "1" : false,
+        claim_offer:     claimOffer,
+        claim_notice:    claimNotice === "sent" ? "sent" : null,
         shop_name:       shopName,
         theme:           theme,
       }));
     });
 
+    // POST /orders/:order_id/claim-account — the one-click "save your details
+    // / create an account" trigger from the confirmation page. Mounts only
+    // when the magic-link surface is wired (customerPortal + a mailer); absent
+    // it the offer never renders, so the route is inert. The buyer email is
+    // NOT in the request body — it lives only in the sealed claim cookie set
+    // at confirm time (the customers store keeps no plaintext). This handler:
+    //
+    //   1. resolves the order (malformed/unknown id → the order page, never a
+    //      raw 500);
+    //   2. no-ops for a signed-in buyer or an already-owned order (nothing to
+    //      claim) — redirect to the order page;
+    //   3. reads the sealed claim cookie and requires it to pin to THIS order
+    //      (a missing / mismatched cookie can't trigger a send — defends a
+    //      cross-order or forged-trigger attempt);
+    //   4. resolves the customer by email hash, CREATING the account if none
+    //      exists, mints a single-use portal sign-in token, and emails the
+    //      link to the checked-out address;
+    //   5. links the guest order(s) for that email to the account by the
+    //      durable email-hash match (the redemption flow re-links idempotently
+    //      on click, so a not-yet-existing account still gets its orders).
+    //
+    // The response is IDENTICAL whether the account already existed or was
+    // just created, and whether the send succeeded — always a 303 to
+    // ?claim=sent (no account-existence oracle; no enumeration). Rate-limited
+    // by the /orders/ TIGHT_PREFIXES budget; CSRF-tokened by _injectCsrfFields
+    // (/orders/ is not an edge-exempt prefix). Each external step is wrapped so
+    // a failure still lands the buyer on the neutral confirmation.
+    if (deps.customerPortal && deps.customerPortalEmail) {
+      router.post("/orders/:order_id/claim-account", async function (req, res) {
+        var orderId = req.params && req.params.order_id;
+        function _bounce(loc) {
+          res.status(303);
+          res.setHeader && res.setHeader("location", loc);
+          return res.end ? res.end() : res.send("");
+        }
+        if (!orderId) return _bounce("/account/login");
+        var o;
+        try { o = await deps.order.get(orderId); }
+        catch (e) { if (e instanceof TypeError) { o = null; } else throw e; }
+        if (!o) return _bounce("/account/login");
+
+        // A signed-in buyer already has an account — nothing to claim.
+        if (_currentCustomerEnv(req)) return _bounce("/orders/" + o.id);
+        // An order that already has an owner isn't a guest order to claim.
+        if (o.customer_id) return _bounce("/orders/" + o.id);
+
+        // The email lives ONLY in the sealed claim cookie, pinned to this
+        // order. No cookie / a different order's cookie → cannot trigger a
+        // send (a forged or cross-order POST has no address to mail). Bounce
+        // back to the order page WITHOUT the sent flag so no offer-state lie
+        // is shown.
+        var claimEnv = _readClaimEnv(req);
+        if (!claimEnv || claimEnv.order_id !== o.id ||
+            typeof claimEnv.email !== "string" || !claimEnv.email) {
+          return _bounce("/orders/" + o.id);
+        }
+        var email = claimEnv.email;
+
+        // Resolve or create the account, mint a sign-in link, send it, and
+        // link the guest order — all best-effort so the response stays
+        // enumeration-safe (same outcome regardless of which branch ran or
+        // whether a step failed). The claim cookie is one-shot: cleared here
+        // so a refresh / back-button can't re-trigger a mail cannon.
+        try {
+          var emailHash = deps.customers.hashEmail(email);
+          var customer = await deps.customers.byEmailHash(emailHash);
+          if (!customer) {
+            // No account yet → create one. register() is the same path the
+            // passkey / OAuth signups use; it stores only the email hash.
+            // customers.register requires a non-empty display_name (it never
+            // stores the plaintext email), so derive a friendly default from
+            // the local part of the checked-out address — the buyer can rename
+            // it from their account later.
+            var derivedName = _displayNameFromEmail(email);
+            try {
+              customer = await deps.customers.register({ email: email, display_name: derivedName });
+            } catch (eReg) {
+              // A racing create (CUSTOMER_DUPLICATE) means the row now
+              // exists — re-read it rather than failing the claim.
+              if (eReg && eReg.code === "CUSTOMER_DUPLICATE") {
+                customer = await deps.customers.byEmailHash(emailHash);
+              } else {
+                throw eReg;
+              }
+            }
+          }
+          if (customer && customer.id) {
+            // NOTE: the guest order is deliberately NOT linked here. Linking
+            // would set the order's customer_id, and the IDOR gate on
+            // GET /orders/:id then 404s the guest who is still sitting on the
+            // confirmation page (they're not signed in yet) — they'd lose
+            // their own receipt until they clicked the email. The link is
+            // instead performed at sign-in (portal-token redemption), which
+            // is also the moment the buyer PROVES control of the email
+            // (clicking the mailed link). Until then the order stays a guest
+            // order reachable on its capability URL.
+            var minted = await deps.customerPortal.createSession({
+              customer_id: customer.id,
+              scope:       "full",
+            });
+            var origin = "";
+            try { origin = new URL(_requestUrls(req).canonical_url).origin; }
+            catch (_eOrigin) { origin = ""; }
+            var linkUrl = origin + "/account/portal/" + encodeURIComponent(minted.plaintext_token);
+            await deps.customerPortalEmail.sendMagicLink({
+              customer_email: email,
+              link_url:       linkUrl,
+            });
+          }
+        } catch (_eClaim) { /* drop-silent — neutral confirmation regardless */ }
+
+        // One-shot: clear the claim cookie so the offer can't be re-fired.
+        try { _clearClaimCookie(req, res); } catch (_eClear) { /* best-effort */ }
+        return _bounce("/orders/" + o.id + "?claim=sent");
+      });
+    }
+
     // Stripe webhook — the order-completion path. A PaymentIntent succeeds
     // asynchronously (the customer may close the tab before Stripe fires),
     // so the order's pending→paid transition lands here, not on the return
@@ -13865,6 +14365,23 @@ function mount(router, deps) {
             if (anonCart) await deps.cart.setCustomer(anonCart.id, rv.customer_id);
           } catch (_e) { /* best-effort merge; sign-in itself succeeds */ }
         }
+        // Reconcile any guest order(s) placed under this account's email to
+        // the now-authenticated customer. The portal token already proved
+        // control of the email (the link was mailed to it), so the customer's
+        // own stored email_hash is the verified linking key — pass it to
+        // linkGuestOrdersByEmailHash, which only adopts NULL-owner orders.
+        // Idempotent (re-running on a later sign-in links nothing new) and
+        // best-effort: a link failure never blocks the sign-in. This is the
+        // payoff for the post-checkout "save your details" claim — the buyer
+        // clicks the link and finds the order already on their account.
+        if (deps.order) {
+          try {
+            var portalCust = await deps.customers.get(rv.customer_id);
+            if (portalCust && portalCust.email_hash) {
+              await deps.order.linkGuestOrdersByEmailHash(rv.customer_id, portalCust.email_hash);
+            }
+          } catch (_eLink) { /* drop-silent — sign-in itself succeeds */ }
+        }
         _setAuthCookie(req, res, { customer_id: rv.customer_id, exp: Date.now() + b.constants.TIME.days(14) });
         res.status(303); res.setHeader && res.setHeader("location", "/account");
         return res.end ? res.end() : res.send("");
@@ -18008,8 +18525,15 @@ function mount(router, deps) {
       try { o = orderId ? await deps.order.get(orderId) : null; }
       catch (e) { if (e instanceof TypeError) { o = null; } else throw e; }
       if (!o) return _send(res, 404, renderNotFound({ shop_name: shopName, theme: theme }));
+      // Same access gate as GET /orders/:id — reorder reads the order's line
+      // items (the variant ids it rebuilds a cart from), so a guest order
+      // must be gated by a capability proof (placing-browser cookie, emailed
+      // token, or claim cookie) exactly like the confirmation page. A bare
+      // UUID with no proof 404s rather than letting a stranger enumerate a
+      // guest order's contents by reorder.
       var reAuth = _currentCustomerEnv(req);
-      if (o.customer_id && (!reAuth || o.customer_id !== reAuth.customer_id)) {
+      var reAccessToken = (req.query && typeof req.query.k === "string") ? req.query.k : "";
+      if (!_orderAccessGranted(req, o, reAuth, reAccessToken)) {
         return _send(res, 404, renderNotFound({ shop_name: shopName, theme: theme }));
       }
       if (!_orderEligibleForReorder(o.status)) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.5",
+  "version": "0.4.7",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {