@vio-live/web-sdk 0.32.0 → 0.35.0

package/CHANGELOG.md

@@ -14,6 +14,129 @@ How to keep this file: see [CONTRIBUTING → Changelog](CONTRIBUTING.md#changelo
 The details of each feature live in the [README](README.md); this file says *what*
 and *when*, and links there.
 
+## 0.35.0 — 2026-10-29
+
+> 0.34.0 was never published on its own: its changes (section order of the product detail and layout tracking,
+> below) ship in this version too.
+
+### Added
+- **`vippsCartPayment: 'express' | 'checkout'`** (theme key, `--vio-vipps-cart-payment`) and the
+  attribute **`vipps-cart-payment`** on `<vio-cart>` and `<vio-product-detail>`. `express` is the
+  default; `checkout` restores the 0.31–0.34 behaviour exactly. See
+  [README → The hand-over to Vipps](README.md#the-hand-over-to-vipps-028).
+
+### Changed
+- **The Vipps buttons pay the sponsor's whole cart with Vipps Express** (Angelo, 2026-10-29: «el
+  botón negro va con el nuestro y el botón de Vipps paga el carrito entero»). The black «Til
+  kassen» is the way into our checkout; Vipps goes to Vipps.
+  - **`<vio-cart>`**: the Vipps button starts Express for the sponsor's whole cart — every line of
+    that sponsor's backend cart, never another sponsor's — the same Express as the detail: the
+    «Åpner Vipps …» overlay, `vio:payment-redirect-*` with `source: 'cart'`, `add_payment_info`
+    once, the return from Vipps and its confirmation. It no longer dispatches
+    `vio:checkout-open`. One payment at a time (the overlay takes every tap; a second tap while
+    one is starting does nothing).
+  - **`<vio-product-detail>`**: «Kjøp nå med Vipps» with lines already in the brand's cart adds the
+    product (size and quantity) and pays the **whole cart** with Express, instead of opening our
+    checkout. The line under the button says what will be paid before the tap: «Betaler hele
+    handlekurven · {n} varer · {total}» (n = every unit with this product at the chosen quantity,
+    total = the cart's subtotal with it; shipping is chosen in Vipps). It follows the cart and the
+    quantity. With an empty cart nothing changes.
+  - Express off for the brand, or a cart that cannot have it (several suppliers, no rate): the
+    checkout opens with Vipps preselected, as before.
+- **A redirect payment (Vipps, Stripe link) reuses only its own sponsor's open checkout.** A
+  payment for one sponsor's cart started while another sponsor's checkout was open would have
+  gone out on that checkout; it now creates its own.
+
+### ⚠️ Upgrade notes
+- **Hosts listening to `vio:checkout-open` from the cart's Vipps button no longer get it** by
+  default: the cart goes to Vipps directly. «Til kassen» still sends `vio:checkout-open`, and the
+  Vipps button sends it only when Express cannot start (then with `paymentMethod: 'vipps'`). To
+  keep the old flow, set `vipps-cart-payment="checkout"` or `applyVioTheme({ vippsCartPayment:
+  'checkout' })`.
+- **`vio:payment-redirect-start` / `-cancel` / `-error` with `source: 'cart'` are back** (gone
+  since 0.31). A host that draws its own loader (`preventDefault()` on the start) gets them from
+  the cart too.
+- The same for the detail with lines in the cart: no `vio:checkout-open` any more, the hand-over
+  events (`source: 'detail'`) instead.
+- **Backend:** nothing new. shopcart already builds Express on the checkout's cart, every line;
+  it refuses Express (`express: false`, no payment) for a cart of several suppliers, and the
+  checkout opens instead.
+
+## 0.34.0 — 2026-10-29
+
+### Added
+- **Section order of `<vio-product-detail>` and layout tracking** (asked by Replit for Mote &
+  Livsstil). `Vio.configureDetail({ layout: { id, revision, sections, experimentId?, variantId? } })`
+  orders the sections below the gallery for the page (`{ layout: null }` resets; open details
+  re-render); the element's `layout` property / attribute (JSON) wins. Section ids: `brand`,
+  `title`, `stock`, `price`, `options`, `purchase`, `highlights`, `description`,
+  `shippingReturns`; unknown ids are ignored, duplicates keep the first, the essentials (`title`,
+  `price`, `options`, `purchase`) are appended when missing. The real DOM is reordered, the same
+  on every screen. `el.appliedLayout`, `Vio.detailLayout()` and the event
+  `vio:detail-layout-applied` say what was applied. See
+  [README → Section order and layout tracking](README.md#section-order-and-layout-tracking-034).
+- **The layout on the funnel events.** `view_item` of a non-default layout carries `layout_id`,
+  `layout_revision`, `experiment_id`, `variant_id` in its `context`. The detail stores the layout
+  on the cart line origin (`CartOrigin.layoutId`, `layoutRevision`, `experimentId`, `variantId`),
+  and every item of `add_to_cart`, `remove_from_cart`, `view_cart`, `begin_checkout`,
+  `add_payment_info` and `purchase` carries `layout_id`, `layout_revision`, `experiment_id`,
+  `experiment_variant_id` (`""` when none; `items[].variant_id` stays the product variant). A line
+  with units from two layouts is two items. Nothing goes to Commerce.
+
+### ⚠️ Upgrade notes
+- **No change without configuration:** the detail renders exactly as in 0.33 and `view_item`
+  sends nothing new. The only difference on the wire: the items of the cart events now always
+  carry the four layout keys, empty (`""`) when the units came from no layout — the collector
+  ignores keys it does not know yet.
+
+## 0.33.0 — 2026-10-28
+
+### Fixed
+- **One cart per connection.** Every connection of a site (environment + key) shared one stored
+  cart, and every tab adopted what the others wrote: two tabs on two connections (Staging and Prod
+  side by side) could take each other's cart for a moment. Each connection now keeps its own
+  (`vio.cart.v1:<environment>:<hash of the key>` — never the key itself), a tab only listens to
+  its own, and `Vio.init` with another key switches `Vio.cart` to that connection's carts (the
+  first one's come back if the page switches back). An answer that arrives for the connection the
+  page left lands in that connection's cart, silently — never in the new one.
+- **The commerce key is the channel of the article's campaign, not the sponsor's first block.**
+  With two campaigns of one sponsor on a surface (Careless: campaign 2 on channel 482, an internal
+  test campaign 1 on channel 480), products, carts and checkouts used the default campaign's
+  channel even for an article of the other. The key now follows the campaign in context (the
+  click's `campaignId`, `vio-campaign`, `data-vio-campaign`, `Vio.init`'s), among the sponsor's
+  blocks (a block with `commerce: null` is skipped instead of throwing). `Vio.commerceFor(sponsorId)`
+  still works and takes an optional `{ campaignId?, channelId? }`; commerce clients are kept per
+  sponsor and key. New: `Vio.sponsorCommerce(sponsorId, ctx?)`.
+- **A cart remembers its channel.** `SponsorCartState.channelId` is stored when the backend cart is
+  created, and every later cart and checkout call for it (also the return from Vipps / Stripe,
+  through the per-checkout memory) uses that channel's key. If the bootstrap no longer lists the
+  channel, the stale `cartId` is dropped and the cart is created again on the current channel with
+  its lines — never a call with another channel's key. Carts from before keep the sponsor's first
+  block, as when they were created.
+- **The order's campaign belongs to the cart's sponsor.** `attribution.campaign_id` on the checkout
+  and `campaignId` on `vio:checkout-created` (→ `add_payment_info`) took the page's campaign even
+  when it was another sponsor's. Now: the campaign the cart's lines were added from, else the
+  page's (`data-vio-campaign` / `vio-campaign` on the page, then `Vio.init`'s) only when the sponsor
+  takes part in it, else the slices' rule — only campaigns of that sponsor.
+- **The bootstrap no longer lives for the whole page.** When the tab becomes visible again and the
+  cached bootstrap is older than 5 minutes, it is fetched again (the old one stays until the new
+  one arrives, and if the refresh fails). Carts keep their lines; an open checkout keeps paying
+  with its channel's key.
+- **«Frakt & retur» no longer shows filler as the delivery time.** A rate's description equal to
+  its own name (dashboard-created rates copied it), `By Outshifter` or `Default Shipping Method`
+  (products' defaults) is no description in `getShippingRates`; the detail also drops one equal
+  to the product's title or the brand / seller name.
+
+### ⚠️ Upgrade notes
+- **Hosts with several articles (Replit, Vev):** pass `sponsorId` **and** `campaignId` on
+  `vio:product-click`, set `data-vio-campaign` on each article's wrapper, and do **not** set a
+  site-wide `Vio.init({ campaignId })` — the campaign in context decides which channel sells.
+- The carts kept in the old shared entry move, once, to the first connection that opens with none
+  of its own. Nothing to do.
+- `Vio.cart` is the same object for the whole page, so listeners added to it keep working across a
+  re-init. A host that archived and restored carts per connection itself (Replit's
+  `vioCartConnections`) can rely on this instead.
+
 ## 0.32.0 — 2026-10-28
 
 > First version published to npm since 0.29.0: **0.30.0 and 0.31.0 were never published on their own** — their

package/README.md

@@ -226,7 +226,7 @@ a campaign to a slot. But an editorial page — a Vev article, a Replit article
 often *is* part of one campaign, and the page can say so:
 
 ```ts
-Vio.init({ apiKey: '…', campaignId: 12 })          // the whole page
+Vio.init({ apiKey: '…', campaignId: 12 })          // the whole page — only on a page of ONE campaign
 ```
 
 ```html
@@ -243,6 +243,19 @@ ancestors. On web/Replit a **per-article** campaign needs a per-article scope to
 same `carousel-1`, and the articles' campaigns would overwrite one another's
 assignment; Vev ids are per block, so it does not apply there. What it does:
 
+- **Which channel sells.** One article = one campaign = one channel = one
+  sponsor, and one sponsor may run several campaigns on a surface, each on its own
+  commerce channel. The SDK reads products, creates the cart and pays with the key
+  of the channel of the **campaign in context** — the click's `campaignId`, the
+  element's `vio-campaign`, an ancestor's `data-vio-campaign`, then `Vio.init`'s —
+  among the blocks of that sponsor (`Vio.sponsorCommerce(sponsorId, { campaignId })`,
+  `Vio.commerceFor(sponsorId, { campaignId })`); without one, the sponsor's first
+  block, as before. A cart remembers the channel it was created on (`channelId`)
+  and every later cart and checkout call uses that channel's key; if the bootstrap
+  no longer lists that channel, the cart is created again on the current one with
+  its lines. So on a site with several articles (Replit, Vev), **set
+  `data-vio-campaign` per article and pass `sponsorId` and `campaignId` on
+  `vio:product-click`; do not set a site-wide `Vio.init({ campaignId })`.**
 - **Declaration.** The manifest carries the page's campaign (top-level) and an
   element's own campaign per location when it differs. The campaigns service
   (campaigns micro PR #16) turns that into assignments of the page's slots
@@ -372,9 +385,11 @@ Since 0.26 the origins do not stay in the browser: **Commerce receives them**
 - **Per checkout.** `CreateCheckout` and the `UpdateCheckout` right before paying
   carry `attribution`: `surface_key` (the SDK key — the gateway sets it from
   `X-API-Key` anyway, and shopcart checks it against the cart's channel, so a page
-  cannot credit a sale to another surface), `campaign_id` (the page's campaign,
-  `Vio.pageCampaign()` — else the campaign that explains most units of the cart under
-  the same rule `purchase` is split by), `content_url` / `content_title` (the page at
+  cannot credit a sale to another surface), `campaign_id` (always a campaign the
+  cart's sponsor takes part in: the campaign the cart's lines were added from, else
+  the page's — `data-vio-campaign` / `vio-campaign` on the page, then `Vio.init`'s —
+  else the campaign that explains most units of the cart under the same rule
+  `purchase` is split by), `content_url` / `content_title` (the page at
   pay time) and `entry` (`{ referrer, utm_source, utm_medium, utm_campaign,
   landing_url }`: the landing the session **remembers** — the same memory the
   `client` block reads, which now keeps the landing page too — never the page the
@@ -697,6 +712,7 @@ or on the element (`vio-product-detail { --vio-detail-logo-height: 48px; }`).
 | `cartWidth` / `checkoutWidth` | `--vio-cart-width` / `--vio-checkout-width` | `440px` | Drawer widths (desktop) |
 | `confirmLogoHeight` / `confirmTitleSize` / `confirmCheckBg` | `--vio-confirm-logo-height` / `--vio-confirm-title-size` / `--vio-confirm-check-bg` | `40px` / `24px` / green | The confirmation |
 | `redirectBg` / `redirectSpinner` | `--vio-redirect-bg` / `--vio-redirect-spinner` | translucent white / Vipps orange | The «Åpner Vipps …» overlay |
+| `vippsCartPayment` | `--vio-vipps-cart-payment` | `express` | What the Vipps button of `<vio-cart>` and `<vio-product-detail>` pays when the cart has lines: `express` = Vipps Express for the sponsor's whole cart; `checkout` = our checkout with Vipps preselected (0.31–0.34). See [The hand-over to Vipps](#the-hand-over-to-vipps-028) |
 
 Also settable as CSS only: `--vio-detail-logo-max-width` (`220px`), `--vio-detail-image-position`,
 `--vio-detail-image-radius`, `--vio-detail-thumb-fit` (`cover`), `--vio-detail-thumb-border-width`,
@@ -747,6 +763,7 @@ whole page through `applyVioTheme` (theme key → custom property). The element
 | `highlights` | — | `[{ icon, title, text }]` (JSON) | The brand's promises under the buy zone. By default the brand's own (dashboard Settings → Brand, sponsor block `highlights`); this list replaces them on the page. Icons: `plane heart shirt truck return leaf star shield mailbox home pin clock`, or an image URL. `detailHighlightsDisplay: 'none'` hides the strip |
 | `delivery-time` | — | text, e.g. `2-5 virkedager` | «Leveringstid …» in «Frakt & retur» for a brand whose rates do not say it (each rate's own text in Commerce — «Leveringstid 1-5 dager» — wins) |
 | `carrier-logos` | — | `{ "Bring": "https://…" }` (JSON) | Carrier logos by the name the rate starts with («Bring - Pakke i postkasse»), for rates without their own logo in Commerce (`logo_url`, which wins); otherwise a line icon by the kind of delivery |
+| `vipps-cart-payment` | `vippsCartPayment` | `express` (default) · `checkout` | «Kjøp nå med Vipps» when the brand's cart already has lines: the product is added and the **whole cart** goes to Vipps Express, the line under the button saying «Betaler hele handlekurven · n varer · total»; or (`checkout`) the checkout opens first, Vipps preselected. Also on `<vio-cart>` (its Vipps button) |
 | — | `detailShippingReturnsDisplay` | `block` (default) · `none` | «Frakt & retur»: one row per carrier (logo or icon, carrier, how it delivers, price), the delivery time, the right of withdrawal and the brand's pages |
 
 The sheet closes with a pull down from its top bar, or from anywhere while its content is at the top.
@@ -770,6 +787,111 @@ line above the name). CSS only: `--vio-card-border-hover-color`, `--vio-card-add
 `--vio-card-retailer-{display,size,tracking,weight,color,margin}`,
 `--vio-card-description-{size,color,gap}`, `--vio-card-accent-text`.
 
+### Section order and layout tracking (0.34)
+
+The sections of `<vio-product-detail>` **below the gallery** can be put in any order, and the
+layout the shopper really saw travels with every event of the funnel — so a host can run an
+experiment on the product page and read its conversion. The header (selling brand + close) and
+the gallery stay where they are. Without any configuration nothing changes.
+
+```js
+// The whole page (every detail open now and later):
+Vio.configureDetail({
+  layout: {
+    id: 'pdp-sizes-first',        // required
+    revision: '3',
+    sections: ['title', 'stock', 'price', 'options', 'purchase', 'description', 'shippingReturns'],
+    experimentId: 'pdp-2026-11',  // optional
+    variantId: 'B',               // optional — the experiment variant
+  },
+})
+Vio.configureDetail({ layout: null }) // back to the default
+
+// One element (wins over the page): the property, or the attribute as JSON.
+detail.layout = { id: 'pdp-b', revision: '1', sections: ['price', 'title', 'options', 'purchase'] }
+// <vio-product-detail layout='{"id":"pdp-b","revision":"1","sections":["price","title","options","purchase"]}'>
+
+detail.appliedLayout   // what this detail applies
+Vio.detailLayout()     // what a detail without its own layout applies (the page's or the default)
+```
+
+**Section ids**
+
+| Id | What |
+|---|---|
+| `brand` | The product's brand line (`.brand`) |
+| `title` | The product name |
+| `stock` | «På lager» / «Få igjen» / «Utsolgt» |
+| `price` | Price + compare-at price |
+| `options` | The size / option groups and their prompt («Velg størrelse») |
+| `purchase` | The SDK's buy group, never split: «Frakt fra…», Vipps / Apple Pay / the other ways to pay, quantity + «Legg i handlekurv», «Du handler direkte hos …» and the terms links |
+| `highlights` | The brand's promises |
+| `description` | «Beskrivelse» |
+| `shippingReturns` | «Frakt & retur» |
+
+Default order — exactly the DOM before 0.34: `brand, title, stock, price, options, purchase,
+highlights, description, shippingReturns` (title and stock on one row; the options inside the
+buy zone; highlights, description and «Frakt & retur» after it).
+
+**Rules**
+
+- Ids, `revision`, `experimentId`, `variantId`: strings of at most 64 characters of
+  `[A-Za-z0-9._:-]`. An invalid `id` (or `sections` that is not an array) ignores the layout, with
+  one `console.warn`; an invalid `revision` / `experimentId` / `variantId` is treated as absent.
+- Unknown section ids are ignored; a duplicate: the first wins.
+- Essentials — `title`, `price`, `options`, `purchase` — are appended in that order when missing.
+  Any other section left out is not rendered.
+- `title` immediately followed by `stock` keep today's single row; otherwise each is its own block.
+  A run of `title` / `stock` / `price` is one `.headline` block.
+- `options` immediately before `purchase` render inside the buy zone (`.buy`), as today — so a
+  sticky buy zone still holds them. Anywhere else they are their own block
+  (`.buy-options.options-apart`, same `part="buy-options"`), and the buy buttons still require the
+  choice: the same «Velg størrelse» prompt, and the options are scrolled into view.
+- The real DOM is reordered (no CSS `order`), the same on phone and desktop. Every section after
+  `purchase` goes inside `.purchase`, as the description does by default: a sticky buy zone
+  (`detailBuyPosition: 'sticky'`) may slide over them, never over what comes before it.
+  `detailHighlightsDisplay`, `detailShippingReturnsDisplay`, `description-mode` and `gallery`
+  apply as before.
+
+**Applied layout** — `el.appliedLayout`, `Vio.detailLayout()` and the event
+`vio:detail-layout-applied` (bubbles, composed; React: `onLayoutApplied`), dispatched each time a
+detail renders a product with a layout it was not yet shown with (every open, every change while
+open; the detail also carries `productId` and `sponsorId`):
+
+```ts
+{
+  id: string, revision: string, experimentId?: string, variantId?: string,
+  sections: string[],                       // what is rendered, in order
+  adjusted: Array<{ section: string, reason: 'unknown' | 'duplicate' | 'added-essential' }>,
+  source: 'element' | 'global' | 'default',
+}
+// no configuration:
+{ id: 'default', revision: '0', sections: [/* the default order */], adjusted: [], source: 'default' }
+```
+
+**Tracking contract** (shared with the collector). Only a non-default layout (`source`
+`element` / `global`) adds anything; the default one sends nothing new on `view_item`.
+
+| Where | Fields | Value |
+|---|---|---|
+| `view_item` — `context` (next to `campaign_id`, `location_id`) | `layout_id`, `layout_revision`, `experiment_id`, `variant_id` | The layout the detail is shown with. `variant_id` here is the **experiment** variant (`context` has no product variant). Absent for the default layout; `experiment_id` / `variant_id` absent when the layout has none |
+| Every item of `add_to_cart`, `remove_from_cart`, `view_cart`, `begin_checkout`, `add_payment_info`, `purchase` — `commerce.items[]` | `layout_id`, `layout_revision`, `experiment_id`, `experiment_variant_id` | The layout the units were added under (their cart line origin). Always present on these items: `""` when the units came from no layout (a card, the default layout). `items[].variant_id` stays the **product** variant — hence `experiment_variant_id` |
+
+- The detail stores the layout on the cart line origin when it adds to the cart (any buy button):
+  `CartOrigin.layoutId`, `layoutRevision`, `experimentId`, `variantId` (the experiment variant),
+  taken from the layout shown at that moment. They persist with the cart (`localStorage`), so they
+  survive the return from Vipps / Stripe, a reload and another tab; changing the page's layout
+  later never rewrites lines already in the cart.
+- A line whose units came from several layouts is split per layout into several items (each with
+  its quantity), the same way the units are split per campaign / slot (`Vio.cartSlices()` items
+  carry `layoutId`, `layoutRevision`, `experimentId`, `experimentVariantId` when they have a
+  layout). A purchase is never credited whole to the last product opened.
+- `vio:added-to-cart` from the detail carries `layout: { layoutId, layoutRevision, experimentId?,
+  variantId? }` for a non-default layout (`variantId` of the event itself stays the product's).
+- Internal traffic stays excluded as before; campaign, sponsor, channel, content and slot are
+  unchanged. The layout is **not** sent to Commerce (the line origin's wire to shopcart has no
+  layout fields): the collector joins `order_paid` to these events by `checkout_id`.
+
 ### The hand-over to Vipps (0.28)
 
 Between the tap on Vipps (detail, cart or checkout) and the Vipps page, the SDK shows
@@ -785,24 +907,41 @@ tap, so a second payment cannot start. Events on `document`:
 `source` is `'detail'`, `'cart'` or `'checkout'`. The overlay is `.vio-redirect-overlay`
 in the light DOM.
 
-**The detail's Vipps button pays the whole cart.** «Kjøp nå med Vipps» on the product
-detail adds the product to the sponsor's cart and the checkout is built on that cart —
-every line in it. It goes straight to Vipps only when the cart was **empty**; with lines
-already in it, the product is added and the checkout opens first (`vio:checkout-open`
-with `paymentMethod: 'vipps'`, no hand-over events), every line and the total on screen,
-so what the Vipps page lists is what the shopper saw.
-
-**Two Vipps paths (2026-10-28).** The detail's «Kjøp nå med Vipps» is **Express**: the app
-fills in name and address. The **cart's** Vipps button opens the checkout with Vipps
-preselected, and the checkout's Vipps is always the **standard** payment, even when the
+**The Vipps buttons pay the sponsor's whole cart with Express (2026-10-29).** The black
+«Til kassen» in `<vio-cart>` is the way into our checkout; the Vipps buttons go to Vipps:
+
+- **`<vio-cart>`**: the Vipps button starts **Vipps Express for the whole cart** of the
+  sponsor (every line of its backend cart, never another sponsor's) — the hand-over above with
+  `source: 'cart'`, `add_payment_info` once, and the return from Vipps and its confirmation
+  exactly as from the detail. No `vio:checkout-open`.
+- **`<vio-product-detail>`**: «Kjøp nå med Vipps» adds the product (size, quantity) and starts
+  Express for the sponsor's cart. With an **empty** cart that is the product alone (the line
+  under the button: «Vipps fyller inn navn og adresse – du godkjenner og betaler i appen»). With
+  **lines already in it**, the whole cart is paid, and the line under the button says so before
+  the tap: «Betaler hele handlekurven · {n} varer · {total}» — n = every unit including this
+  product at the chosen quantity, total = the cart's subtotal with it (shipping is chosen in
+  Vipps).
+
+When the brand has Express off, or the cart cannot have it (several suppliers, digital goods,
+no rate for the country — shopcart answers `express: false` and creates nothing), the checkout
+opens with Vipps preselected (`vio:payment-redirect-cancel` with `'express-off'` /
+`'not-started'`, then `vio:checkout-open`).
+
+**The option: `vipps-cart-payment` / `vippsCartPayment`.** `express` is the default.
+`checkout` brings back 0.31–0.34 exactly: the cart's Vipps button opens the checkout with Vipps
+preselected (`vio:checkout-open`, `paymentMethod: 'vipps'`, no hand-over), and the detail's
+does the same when the cart already has lines (product added first); an empty cart is Express
+either way.
+
+**The checkout's Vipps is the standard payment** (2026-10-28), even when the
 brand has Express on. Our form collects name, e-mail, **Mobilnummer**, address and the
 delivery with its price before paying. The mobile is required for Vipps only and accepts any
 market's number: the `+` prefix or the shipping country sets the calling code. The delivery is
 saved on the cart first; if that fails, no payment starts. The payment goes out with
 `express: false`, and the address (with `phone` + `phone_code`) is on the checkout's shipping
-and billing address. **Apple Pay on the detail follows the same
-rule**: its sheet's amount is fixed before the tap, so it opens only on an empty cart, for the
-product × the chosen quantity; otherwise the checkout opens (`paymentMethod: 'apple-pay'`).
+and billing address. **Apple Pay on the detail** has its sheet's amount fixed before the tap,
+so it opens only on an empty cart, for the product × the chosen quantity; otherwise the
+checkout opens (`paymentMethod: 'apple-pay'`).
 
 ### What the shopper pays is what the page shows — the cart, the server, the other tabs
 

package/dist/chunk-3YFJFDSN.js

@@ -0,0 +1,3 @@
+
+//# sourceMappingURL=chunk-3YFJFDSN.js.map
+//# sourceMappingURL=chunk-3YFJFDSN.js.map

package/dist/{chunk-QGJUBVH3.js.map → chunk-3YFJFDSN.js.map}

@@ -1 +1 @@
-{"version":3,"sources":[],"names":[],"mappings":"","file":"chunk-QGJUBVH3.js"}
+{"version":3,"sources":[],"names":[],"mappings":"","file":"chunk-3YFJFDSN.js"}