@moonbase.sh/storefront 2.9.1 → 3.0.1

package/README.md

@@ -99,6 +99,9 @@ Moonbase.configure({
   cart: {
     quantity: 'single',
   },
+  checkout: {
+    redirect: 'auto',
+  },
   pricing: {
     trailingZeros: 'always',
     currencyDisplay: 'code',
@@ -116,6 +119,27 @@ Moonbase.configure({
 })
 ```
 
+`checkout.redirect` decides where checkout happens:
+
+| Value | Behavior |
+| --- | --- |
+| `'auto'` (default) | Overlay on desktop, full-page redirect to the hosted checkout on mobile. |
+| `'always'` / `true` | Always redirect to the hosted checkout. |
+| `'never'` / `false` | Always use the overlay. |
+
+The overlay keeps buyers on your page, but it cannot show Apple Pay or Google Pay.
+Those wallets require the *top-level* page's domain to be a registered payment-method
+domain, and for an embedded storefront that is your own site, not Moonbase's — no
+amount of configuration on our side changes that. Redirecting makes the hosted
+checkout the top-level document, so the wallets appear. `'auto'` takes that trade only
+on mobile, where wallet usage concentrates, and keeps the overlay everywhere else.
+Phones redirect; tablets and desktops get the overlay.
+
+A redirected buyer is always brought back to your page once they've paid, so
+`checkout-completed` fires and the cart clears exactly as it does with the overlay.
+The hosted checkout stays anonymous for the trip — it prefills from the order rather
+than signing the buyer into a Moonbase account, matching the overlay's behavior.
+
 `pricing.trailingZeros` controls how whole prices render. The default `'auto'`
 drops the decimals — a $10.00 product shows as `$10`. Set it to `'always'` to keep
 the currency's own fraction digits instead (`$10.00`, and still `¥1000` for
@@ -156,6 +180,36 @@ shows in the totals, the nudge does not. With no cart-wide offer configured on y
 storefront, the meter never renders either way. `savingLabel` names the saving row
 in the cart totals.
 
+Offers keyed off a single product work the other way round: the widget surfaces one
+as a card in the cart, and the buyer presses it to take the offer. That card is
+hidden once the offer's product is already in the cart, so a buyer who adds that
+product *before* the one that qualifies them for the offer never gets a chance to
+claim it. `cart.offers.autoApply` closes that gap.
+
+```ts
+Moonbase.configure({
+  cart: {
+    offers: {
+      autoApply: true,
+    },
+  },
+})
+```
+
+With it on, the cart applies an eligible offer to the product it discounts by
+itself, once every product that offer names is in the cart. It never adds anything
+to the cart on the buyer's behalf, and it never takes an offer the cart is still
+selling: an offer naming a product they have not added keeps showing as a card and
+still takes a press, since an offer is good for one line only and applying it early
+would take that card away. It never replaces an offer already on a line either. Off
+by default.
+
+That governs when an offer is taken rather than where it stays: remove one of the
+products that qualified an offer and it stays on the line it landed on, just as an
+offer claimed from a card does. A buyer can already put a multi-target offer on one
+product and never add the other, so nothing here is a cart they couldn't have built
+by hand.
+
 You can also control where the widget mounts by providing `target`.
 
 ## Promotions

package/dist/moonbase.d.ts

@@ -1,5 +1,6 @@
 import { ActivationRequestFulfillmentType } from '@moonbase.sh/vue';
 import { CartItem } from '@moonbase.sh/vue';
+import { CheckoutRedirectMode } from '@moonbase.sh/vue';
 import { Download } from '@moonbase.sh/vue';
 import { InjectionKey } from 'vue';
 import { MarketingConsentType } from '@moonbase.sh/vue';
@@ -346,7 +347,18 @@ export declare interface MoonbaseOptions {
         };
     };
     checkout: {
-        redirect: boolean;
+        /**
+         * Where checkout happens.
+         *
+         * - `'auto'` (default) — overlay on desktop, full-page redirect on mobile.
+         *   The redirect is what makes Apple Pay and Google Pay available: those
+         *   wallets require the *top-level* domain to be a registered payment-method
+         *   domain, which it never is when checkout runs in an iframe on the host's
+         *   own site.
+         * - `'always'` / `true` — always redirect to the hosted checkout.
+         * - `'never'` / `false` — always use the overlay, wallets included in the cost.
+         */
+        redirect: boolean | CheckoutRedirectMode;
     };
     cart: {
         quantity: 'selectable' | 'single';
@@ -356,6 +368,29 @@ export declare interface MoonbaseOptions {
         };
         offers: {
             label: string;
+            /**
+             * Apply an eligible offer to the cart line it targets without waiting for the buyer to press
+             * its upsell card. Applies to offers keyed off a single product; offers keyed off the cart as a
+             * whole have always applied themselves; see `cartWide` below.
+             *
+             * Off by default: an offer is a merchant's to give, and applying one unasked discounts a cart
+             * the buyer never asked to have discounted. Turn it on to close the one case the upsell cannot
+             * reach. The card is hidden once the offer's targets are in the cart, so a cart assembled in
+             * that order (target first, then the item that satisfies the offer's condition) leaves a real
+             * discount with no way of being claimed.
+             *
+             * Never adds anything to the cart, and never takes an offer the cart is still selling: an offer
+             * that names a product the buyer has not added keeps showing as a card and still takes a press,
+             * since an offer is good for one line only and spending it early would remove that card. Nor
+             * does it replace an offer a line already carries.
+             *
+             * That last part governs when an offer is taken, not where it stays. Remove one of the products
+             * that qualified an offer and it stays on the line it landed on, exactly as an offer claimed
+             * from the card would. A buyer can put a multi-target offer on one product and never add the
+             * other, so this is a cart they could have built by hand. Losing the discount because of an
+             * unrelated removal would be the surprising behaviour, not keeping it.
+             */
+            autoApply: boolean;
             /**
              * Offers keyed off the cart as a whole, such as "10% off orders over $50", rather than off a single
              * product. They apply themselves the moment the cart qualifies; there is nothing for the buyer