@mohasinac/appkit 4.70.0 → 4.71.2

package/dist/_internal/shared/checkout/policy-consent.js

@@ -0,0 +1,214 @@
+/**
+ * Buyer policy agreement at checkout — the CLAUSE MODEL (item 1.39).
+ *
+ * ## Why this exists
+ *
+ * The platform ships a no-cancel-after-reveal and no-refund-after-ship
+ * mechanic. Those terms remove rights the buyer would otherwise have, so they
+ * have to be accepted **knowingly, per purchase**, and the acceptance has to be
+ * provable afterwards. A boolean `termsAccepted: true` on an order is not a
+ * consent record — it says somebody ticked something, not WHAT they were
+ * shown. This module owns the "what".
+ *
+ * ## 🛑 Capability-driven, never type-driven
+ *
+ * Which clauses apply to a cart is decided by reading the listing-type
+ * CAPABILITY REGISTRY, never by `if (listingType === "clearance")`. A clause
+ * declares the capability it is a consequence of:
+ *
+ *   `supportsSurpriseReveal`    → "no cancellation once you reveal"
+ *   `supportsShipping`          → "no refund once it ships"
+ *   `hasInstantFulfillment`     → "delivered instantly, not returnable"
+ *   `requiresJurisdictionCheck` → "you confirm it is legal where you are"
+ *
+ * So the day the owner enables the reveal mechanic on stickers, the reveal
+ * clause starts appearing on sticker checkouts with **no code change** — one
+ * row in `LISTING_TYPE_CAPABILITIES` flips and this resolver follows it. That
+ * is the governing principle of the rework applied to the consent step.
+ *
+ * ## The clause set is DATA
+ *
+ * `siteSettings.checkoutPolicies.clauses` is the editable copy, so an admin
+ * rewords a consequence without a deploy and a different client in a different
+ * vertical writes their own. `DEFAULT_CHECKOUT_POLICY_CLAUSES` below is the
+ * FAIL-CLOSED fallback used when settings carry nothing: an install that has
+ * never configured policies still blocks checkout behind a consent step rather
+ * than silently waiving it.
+ *
+ * ## What is NOT here
+ *
+ * Hashing and persistence are server-only and live in
+ * `_internal/server/payments/policy-consent.ts`. This module is isomorphic on
+ * purpose — the checkout UI renders the same clause objects the gate judges, so
+ * the text the buyer reads and the text that gets hashed cannot drift.
+ */
+import { capabilityFor } from "../listing-types/capabilities.js";
+/**
+ * FAIL-CLOSED defaults. Used whenever settings carry no clause list.
+ *
+ * 🛑 Every entry's `appliesWhen` is a capability, not a listing type. Grep for
+ * `listingType ===` in this file: zero, and that is the acceptance test for the
+ * whole rework.
+ */
+export const DEFAULT_CHECKOUT_POLICY_CLAUSES = [
+    {
+        id: "baseline-terms",
+        appliesWhen: "always",
+        text: "I have read and accept the Terms of Service, the Refund Policy and the Cancellation Policy that apply to the items in this order.",
+    },
+    {
+        id: "no-cancel-after-reveal",
+        appliesWhen: "supportsSurpriseReveal",
+        text: "This order contains a concealed item. Once its contents are revealed to me — including a reveal that happens automatically when the seller ships it — the order can no longer be cancelled, and the allocation I received is final.",
+    },
+    /*
+     * ── These two replaced a single `no-refund-after-ship` clause ────────────
+     *
+     * 🛑 That clause was WRONG IN BOTH DIRECTIONS, which is the worst outcome
+     * available for a document whose only purpose is to be relied on in a
+     * dispute. It read "once dispatched it can no longer be refunded on request",
+     * and the code says otherwise on both halves (verified 2026-11-07, by reading
+     * the rules rather than assuming them):
+     *
+     *   · TOO GENEROUS about cancellation. `TERMINAL_OR_IN_FLIGHT` in the order
+     *     workflow registry includes `processing`, so buyer cancellation closes
+     *     when the SELLER STARTS PREPARING the order — one status BEFORE
+     *     dispatch. A buyer who read the old clause would have believed they
+     *     could cancel right up to dispatch, and the consent record would have
+     *     proved they agreed to a weaker restriction than the one actually
+     *     applied to them.
+     *
+     *   · TOO RESTRICTIVE about returns. `requestReturnAction` →
+     *     `assertReturnWindowOpen` gives the buyer a self-service return request
+     *     once the order is `delivered`, inside `siteSettings.returns.windowDays`.
+     *     So "no refund on request after dispatch" asserted a waiver of a right
+     *     the buyer does in fact keep — and a consent record over-claiming a
+     *     waiver is exactly the kind of clause that gets struck and takes the
+     *     rest of the document's credibility with it. (A10 already flags that
+     *     consent does not override statutory consumer rights regardless.)
+     *
+     * Split in two because they are two different facts about two different
+     * windows, and one sentence covering both is how the original got both wrong.
+     */
+    {
+        id: "cancel-window-closes-at-processing",
+        appliesWhen: "supportsShipping",
+        text: "I can cancel this order myself only until the seller starts preparing it. Once it moves to processing — which can happen quickly, and before anything is dispatched — self-service cancellation is no longer available to me.",
+    },
+    {
+        id: "returns-after-delivery",
+        appliesWhen: "supportsShipping",
+        /*
+         * The window is deliberately described rather than numbered.
+         * `siteSettings.returns.windowDays` is config (7 today), and baking "7
+         * days" into a clause would make the stored consent text disagree with the
+         * live rule the day an admin changes it — the same two-owners defect, in a
+         * legal document. An admin who wants the number stated edits this clause in
+         * Site Settings, where both values are in front of them.
+         */
+        text: "After delivery I may request a return within the published returns window, and a refund is issued after review rather than automatically. Between dispatch and delivery I have no self-service cancellation or refund — my route then is to raise a dispute.",
+    },
+    {
+        id: "instant-fulfilment-final",
+        appliesWhen: "hasInstantFulfillment",
+        text: "This order is fulfilled the moment payment succeeds. Because it is delivered to me immediately and cannot be returned, it is not refundable once delivered.",
+    },
+    {
+        id: "jurisdiction-self-declaration",
+        appliesWhen: "requiresJurisdictionCheck",
+        text: "This order contains a restricted item. I confirm I am legally permitted to receive it at my delivery address, and I accept that the order will be cancelled if that turns out not to be the case.",
+    },
+];
+/**
+ * 2, not 1 — bumped when `no-refund-after-ship` was split into the
+ * cancellation-window and returns-window clauses above.
+ *
+ * 🛑 Bumping is not cosmetic and is not optional on a wording change. The hash
+ * proves WHAT was accepted; the version is the handle a human uses to talk
+ * about it ("they accepted policy v1, which said the wrong thing about
+ * cancellation"). Leaving it at 1 across a material rewrite would make two
+ * genuinely different documents indistinguishable by name, and the only way to
+ * tell them apart would be to re-derive a hash from an old settings snapshot
+ * nobody kept.
+ */
+export const DEFAULT_CHECKOUT_POLICY_VERSION = 2;
+/**
+ * Does any listing type present in this checkout carry the capability the
+ * clause hangs off?
+ *
+ * ANY, not ALL — deliberately. A cart with one concealed item and three
+ * ordinary ones still forfeits cancellation on the concealed one, so the buyer
+ * must be told. Requiring every line to carry the capability would silently
+ * drop the clause from exactly the mixed carts that need it most.
+ */
+function clauseApplies(clause, listingTypes) {
+    if (clause.appliesWhen === "always")
+        return true;
+    const key = clause.appliesWhen;
+    const present = listingTypes.some((type) => {
+        const capability = capabilityFor(type);
+        /*
+         * An unknown type — data written before a type was removed from the union
+         * — resolves to `undefined` here rather than throwing. Treated as NOT
+         * carrying the capability, which is the only reading that cannot
+         * accidentally assert a consequence about an item we do not understand.
+         */
+        return capability ? capability[key] === true : false;
+    });
+    return clause.negate ? !present : present;
+}
+/**
+ * The clause set for THIS checkout, in declaration order.
+ *
+ * Caller supplies the listing types actually in the cart. Resolution is pure,
+ * so the UI and the server gate run the identical function over the identical
+ * settings and cannot disagree about what was required.
+ */
+export function resolveCheckoutPolicyClauses(settings, listingTypes) {
+    const configured = settings?.clauses && settings.clauses.length > 0
+        ? settings.clauses
+        : DEFAULT_CHECKOUT_POLICY_CLAUSES;
+    return configured.filter((clause) => clauseApplies(clause, listingTypes));
+}
+export function resolveCheckoutPolicyVersion(settings) {
+    return typeof settings?.version === "number" && settings.version > 0
+        ? settings.version
+        : DEFAULT_CHECKOUT_POLICY_VERSION;
+}
+/*
+ * U+001F (unit separator) joins the fields of one clause; U+001E (record
+ * separator) joins clauses. Written as escapes rather than literal control
+ * bytes so the delimiters survive any editor or copy-paste.
+ *
+ * 🛑 Why not `|`: a single-character printable delimiter lets one clause
+ * reading "A|B" hash identically to two clauses "A" and "B". Neither
+ * separator below can appear in admin-authored policy text, so no clause can
+ * forge a boundary.
+ */
+const FIELD_SEP = "\u001f";
+const CLAUSE_SEP = "\u001e";
+/**
+ * The exact bytes the hash is taken over.
+ *
+ * 🛑 Canonical and explicit, never `JSON.stringify(clauses)`. Key order in a
+ * stringified object is an implementation detail, and a hash that changed
+ * because a field moved would invalidate every buyer's acceptance on a no-op
+ * edit. Only `id` and `text` participate: those are what the buyer actually
+ * read. The predicate is how we DECIDED to show it, which is our business and
+ * not part of what they agreed to.
+ */
+export function canonicalisePolicyClauses(
+/*
+ * Only `id` and `text` are required, not a whole `CheckoutPolicyClause` —
+ * so the STORED snapshot on an order (which keeps those two fields and
+ * drops the predicate) re-hashes to the identical digest as the live
+ * resolution it came from. Demanding the full shape here would mean the
+ * hash could only ever be verified against settings, i.e. against
+ * whatever the policy says today, which is precisely what the stored
+ * snapshot exists to avoid.
+ */
+clauses) {
+    return clauses
+        .map((clause) => `${clause.id}${FIELD_SEP}${clause.text}`)
+        .join(CLAUSE_SEP);
+}

package/dist/_internal/shared/checkout/rules/_limits.d.ts

@@ -22,10 +22,41 @@ export declare const CHECKOUT_MAX_ORDERS_PER_TX = 20;
  * produces three orders: [3, 3, 1].  Each order has its own independent
  * reveal flow.
  */
-export declare const PRIZE_DRAW_MAX_REVEALS_PER_ORDER = 3;
+export declare const CLEARANCE_MAX_REVEALS_PER_ORDER = 3;
 /** Seller-facing prize-draw duration cap, in days — enforced by the Zod schema and the seller form. */
-export declare const PRIZE_DRAW_DURATION_DAYS_MIN = 1;
-export declare const PRIZE_DRAW_DURATION_DAYS_MAX = 15;
+export declare const CLEARANCE_DURATION_DAYS_MIN = 1;
+export declare const CLEARANCE_DURATION_DAYS_MAX = 15;
+/**
+ * How far ahead a pre-order may promise delivery, in days.
+ *
+ * 🛑 **45 IS A GATEWAY CEILING, NOT A TASTE DECISION. Do not round it up.**
+ *
+ * Cashfree Easy Split will not hold a settlement beyond **45 days from the
+ * transaction**. Split settlement is the only lawful money shape here — buyer
+ * → PA escrow → seller, with the proprietorship never touching the funds —
+ * because a marketplace cannot be a payment aggregator and cannot commingle
+ * buyer money with its own (RBI; see `project_listing_type_payment_compliance`).
+ * So a pre-order promising delivery on day 46 cannot be split-settled at all,
+ * and the only remaining way to pay the seller would be a payout from the
+ * platform's own account — which is the exact trap the whole split-settlement
+ * design exists to avoid.
+ *
+ * Raising this number therefore does not extend a deadline; it creates orders
+ * whose money has nowhere legal to go. If the ceiling ever moves, it moves
+ * because the GATEWAY moved — confirm it against Cashfree's live docs, not
+ * against what would be convenient for a seller.
+ *
+ * The matching cancellation half already exists: the `preorder-deliver`
+ * obligation (`features/obligations/constants/policies.ts`) is anchored on
+ * `order.sourceContext.expectedDeliveryDate`, so a pre-order that misses its
+ * promised date is cancelled and refunded. This constant is the WRITE-side cap
+ * that stops a non-compliant pre-order being created in the first place.
+ *
+ * Predicates and buyer-facing messages derive from it in
+ * `_internal/shared/features/products/preorder-window.ts` — never re-derive the
+ * window at a call site.
+ */
+export declare const PREORDER_MAX_DELIVERY_DAYS = 45;
 /** Maximum qty per bundle purchase (bundles are always single-shot direct buys). */
 export declare const BUNDLE_MAX_QTY_PER_TX = 1;
 /**
@@ -37,7 +68,7 @@ export declare const BUNDLE_MAX_QTY_PER_TX = 1;
  * was a magic number in four places. The cart schemas import it.
  *
  * Its other reader, `ListingCheckoutRule.maxQuantityPerLine`, was DELETED in
- * the same change: that field was set by auction, offer and prize-draw and read
+ * the same change: that field was set by collector drop, offer and prize-draw and read
  * by nothing at all, and it contradicted the feature it appeared to govern —
  * prize-draw set it to 1 while `splitMultipleOrders` right beside it existed
  * only to chunk a quantity of 7 into [3,3,1].

package/dist/_internal/shared/checkout/rules/_limits.js

@@ -22,10 +22,41 @@ export const CHECKOUT_MAX_ORDERS_PER_TX = 20;
  * produces three orders: [3, 3, 1].  Each order has its own independent
  * reveal flow.
  */
-export const PRIZE_DRAW_MAX_REVEALS_PER_ORDER = 3;
+export const CLEARANCE_MAX_REVEALS_PER_ORDER = 3;
 /** Seller-facing prize-draw duration cap, in days — enforced by the Zod schema and the seller form. */
-export const PRIZE_DRAW_DURATION_DAYS_MIN = 1;
-export const PRIZE_DRAW_DURATION_DAYS_MAX = 15;
+export const CLEARANCE_DURATION_DAYS_MIN = 1;
+export const CLEARANCE_DURATION_DAYS_MAX = 15;
+/**
+ * How far ahead a pre-order may promise delivery, in days.
+ *
+ * 🛑 **45 IS A GATEWAY CEILING, NOT A TASTE DECISION. Do not round it up.**
+ *
+ * Cashfree Easy Split will not hold a settlement beyond **45 days from the
+ * transaction**. Split settlement is the only lawful money shape here — buyer
+ * → PA escrow → seller, with the proprietorship never touching the funds —
+ * because a marketplace cannot be a payment aggregator and cannot commingle
+ * buyer money with its own (RBI; see `project_listing_type_payment_compliance`).
+ * So a pre-order promising delivery on day 46 cannot be split-settled at all,
+ * and the only remaining way to pay the seller would be a payout from the
+ * platform's own account — which is the exact trap the whole split-settlement
+ * design exists to avoid.
+ *
+ * Raising this number therefore does not extend a deadline; it creates orders
+ * whose money has nowhere legal to go. If the ceiling ever moves, it moves
+ * because the GATEWAY moved — confirm it against Cashfree's live docs, not
+ * against what would be convenient for a seller.
+ *
+ * The matching cancellation half already exists: the `preorder-deliver`
+ * obligation (`features/obligations/constants/policies.ts`) is anchored on
+ * `order.sourceContext.expectedDeliveryDate`, so a pre-order that misses its
+ * promised date is cancelled and refunded. This constant is the WRITE-side cap
+ * that stops a non-compliant pre-order being created in the first place.
+ *
+ * Predicates and buyer-facing messages derive from it in
+ * `_internal/shared/features/products/preorder-window.ts` — never re-derive the
+ * window at a call site.
+ */
+export const PREORDER_MAX_DELIVERY_DAYS = 45;
 /** Maximum qty per bundle purchase (bundles are always single-shot direct buys). */
 export const BUNDLE_MAX_QTY_PER_TX = 1;
 /**
@@ -37,7 +68,7 @@ export const BUNDLE_MAX_QTY_PER_TX = 1;
  * was a magic number in four places. The cart schemas import it.
  *
  * Its other reader, `ListingCheckoutRule.maxQuantityPerLine`, was DELETED in
- * the same change: that field was set by auction, offer and prize-draw and read
+ * the same change: that field was set by collector drop, offer and prize-draw and read
  * by nothing at all, and it contradicted the feature it appeared to govern —
  * prize-draw set it to 1 while `splitMultipleOrders` right beside it existed
  * only to chunk a quantity of 7 into [3,3,1].

package/dist/_internal/shared/checkout/rules/_registry.js

@@ -10,27 +10,25 @@
  */
 import { isMultiMemberLine } from "../line-members.js";
 import { standardRule } from "./standard.rule.js";
-import { auctionRule } from "./auction.rule.js";
+import { collectorDropRule } from "./collector-drop.rule.js";
 import { preOrderRule } from "./preorder.rule.js";
-import { prizeDrawRule } from "./prize-draw.rule.js";
+import { clearanceRule } from "./clearance.rule.js";
 import { offerRule } from "./offer.rule.js";
 import { bundleRule } from "./bundle.rule.js";
 import { classifiedRule } from "./classified.rule.js";
 import { digitalCodeRule } from "./digital-code.rule.js";
 import { liveRule } from "./live.rule.js";
-import { artRule } from "./art.rule.js";
-import { stickersRule } from "./stickers.rule.js";
+import { artAndStickersRule } from "./art-and-stickers.rule.js";
 import { sparesRule } from "./spares.rule.js";
 export const CHECKOUT_RULES = {
     standard: standardRule,
-    auction: auctionRule,
+    "collector-drop": collectorDropRule,
     "pre-order": preOrderRule,
-    "prize-draw": prizeDrawRule,
+    "clearance": clearanceRule,
     classified: classifiedRule,
     "digital-code": digitalCodeRule,
     live: liveRule,
-    art: artRule,
-    stickers: stickersRule,
+    "art-and-stickers": artAndStickersRule,
     spares: sparesRule,
 };
 export const CATEGORY_CHECKOUT_RULES = {

package/dist/_internal/shared/checkout/rules/art-and-stickers.rule.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Art & Stickers listing rule — printed-only artwork, prints and sticker
+ * sheets/packs; standard-like checkout.
+ *
+ * No bespoke checkout behavior: cart/order grouping, stock decrement, and
+ * refund policy all follow the standard defaults. The listing type only
+ * changes presentation (PDP badges, seller form fields) via `pluginFor()`.
+ *
+ * 🛑 This file is the merge of the former `art.rule.ts` and
+ * `stickers.rule.ts`, which were byte-identical apart from their doc comment.
+ */
+import type { ListingCheckoutRule } from "./types";
+export declare const artAndStickersRule: ListingCheckoutRule;

package/dist/_internal/shared/checkout/rules/art-and-stickers.rule.js

@@ -0,0 +1,5 @@
+import { DEFAULT_LISTING_RULE } from "./_defaults.js";
+export const artAndStickersRule = {
+    ...DEFAULT_LISTING_RULE,
+    orderType: "standard",
+};

package/dist/_internal/shared/checkout/rules/bundle.rule.d.ts

@@ -1,11 +1,29 @@
 /**
- * Bundle CategoryCheckoutRule — bundles are always direct-checkout-only.
+ * Bundle CategoryCheckoutRule — `categoryType:"bundle"`.
  *
- * Bundles (categoryType:"bundle") never enter the cart. The buyer clicks
- * "Buy bundle" on the bundle PDP which calls directBundleCheckoutAction,
- * bypassing the cart pipeline entirely.  This rule conveys that intent to the
- * cart-add gate (cartEligible: false) and informs the checkout CART-UI which
- * replaces "Add to cart" with "Buy now".
+ * A bundle is the `derived`-stock composite: one price of its own, set below the
+ * sum of its members, assembled from their loose stock when ordered. The
+ * `independent` case — a separately boxed item with its own count — is a
+ * LISTING with `components[]`, not a bundle; see
+ * `_internal/shared/features/products/composite.ts`.
+ *
+ * ## 🛑 `cartEligible: false` does NOT mean bundles never reach the cart
+ *
+ * The previous docstring claimed "bundles never enter the cart" and that
+ * "addBundleToCart has been removed". Both were false when written and are
+ * false now: `addBundleToCartAction` is live in
+ * `_internal/server/features/bundles/actions.ts`, exported from `server.ts`, and
+ * called twice from the host (`src/actions/bundle.actions.ts`). It writes a real
+ * cart line with `lineKind: "bundle"`.
+ *
+ * What this flag actually does is keep a bundle out of the GENERIC
+ * `addItemToCart` capability gate, which a bundle cannot satisfy — its
+ * `listingType: "standard"` is a placeholder, not a fact. The bundle path
+ * deliberately bypasses that gate and re-asserts the lane check itself.
+ *
+ * Corrected rather than deleted because a comment that misdescribes a live
+ * money path is worse than no comment: the next reader reasonably concludes the
+ * cart cannot hold a bundle and writes code on that assumption.
  */
 import type { CategoryCheckoutRule } from "./types";
 export declare const bundleRule: CategoryCheckoutRule;

package/dist/_internal/shared/checkout/rules/bundle.rule.js

@@ -1,6 +1,9 @@
 export const bundleRule = {
     purchaseable: true,
-    cartEligible: false, // direct-checkout-only; addBundleToCart has been removed
+    // Keeps a bundle out of the GENERIC addItemToCart capability gate, which it
+    // cannot satisfy. `addBundleToCartAction` is the bundle's own entry point and
+    // is very much alive — see the header.
+    cartEligible: false,
     orderType: "standard", // bundle orders resolve to standard orderType
     requiresShippingAddress: true,
     /*

package/dist/_internal/shared/checkout/rules/clearance.rule.d.ts

@@ -0,0 +1,2 @@
+import type { ListingCheckoutRule } from "./types";
+export declare const clearanceRule: ListingCheckoutRule;

package/dist/_internal/shared/checkout/rules/clearance.rule.js

@@ -0,0 +1,148 @@
+import { ValidationError } from "../../../../errors/index.js";
+import { DEFAULT_LISTING_RULE } from "./_defaults.js";
+import { CLEARANCE_MAX_REVEALS_PER_ORDER } from "./_limits.js";
+/**
+ * 🛑 THE GATEWAY IS PROHIBITED HERE — `online` joined this list 2026-10-28,
+ * and `cash` left it.
+ *
+ * A clearance draw is a game of chance, which is on the prohibited-merchant lists
+ * Indian payment gateways inherit from the card networks — the same lists that
+ * carry giveaways and collector drops. Routing entry payments through a standard
+ * e-commerce MID is a terms breach, and the penalty is the merchant account
+ * frozen with the settlement balance held, not a declined charge. One category
+ * can cost every other category its ability to take money.
+ *
+ * 🛑 This REPLACES the original reasoning rather than extending it, and the
+ * original is worth keeping in view because it is still true and no longer
+ * decisive: deferred methods were blocked because instant-mode winner
+ * assignment triggers on confirmed payment, which `cod`/`cash`/`emi` do not
+ * guarantee happens promptly. By that logic `online` was the SAFEST method
+ * available and `cash` the worst.
+ *
+ * The acquirer's rules invert it. `online` and `emi` both settle through the
+ * gateway and are out; `cash` is in, because the owner is the seller and
+ * confirms the payment themselves before the draw. The timing concern becomes
+ * an operational one — do not run the draw until payment is confirmed — which
+ * `upi_manual` already required and the reveal flow already handles.
+ *
+ * `admin_bypass` stays usable for QA regardless.
+ */
+/*
+ * 🛑 `online` MOVED OUT of this list on 2026-10-31, to
+ * `requiresGatewayPermission` on the rule. Everything above remains true of
+ * Razorpay and PhonePe — but it was a statement about WHO IS COLLECTING
+ * wearing the shape of a statement about the listing.
+ *
+ * The owner's framing is what reopens it: a clearance is **a booster box**.
+ * Every numbered slot is a named prize with an image
+ * (`giveawaySlotWriteSchema`), so every buyer receives a real item and nobody
+ * pays for nothing — consideration buying A GOOD, NOT A CHANCE. That is a
+ * product sale and sits outside the gambling clause Cashfree's terms do name.
+ * The `reveal` mode is the same mechanic with the slot chosen for you.
+ *
+ * `cod` and `emi` stay for the original reason, which the acquirer question
+ * does not touch: winner assignment triggers on CONFIRMED payment, and a
+ * pay-later method does not guarantee that happens before the draw.
+ */
+const CLEARANCE_BLOCKED_PAYMENT_METHODS = ["cod", "emi"];
+/**
+ * The refusal, kept VERBATIM when this check moved out of `preflightChecks`
+ * into `assertPaymentMethodAllowed`.
+ *
+ * 🛑 The gate can generate a correct sentence on its own, and a generated one
+ * would have been a regression here: this wording names the REASON (winner
+ * assignment waits on confirmed payment) rather than just the refusal, and the
+ * reason is the thing a buyer needs in order to pick a different method rather
+ * than abandon the entry.
+ */
+const CLEARANCE_BLOCKED_PAYMENT_MESSAGE = "A clearance is paid for up front — winner assignment waits on confirmed payment, so pay-later methods are not available for clearance.";
+export const clearanceRule = {
+    ...DEFAULT_LISTING_RULE,
+    orderType: "clearance",
+    nonRefundable: true,
+    canMergeWithSameProduct: false,
+    maxLinesPerOrder: CLEARANCE_MAX_REVEALS_PER_ORDER,
+    refundPolicy: { full: false, partial: false, partialGranularity: "none" },
+    blockedPaymentMethods: CLEARANCE_BLOCKED_PAYMENT_METHODS,
+    requiresGatewayPermission: true,
+    blockedPaymentMessage: CLEARANCE_BLOCKED_PAYMENT_MESSAGE,
+    splitKey: (item) => `clearance:${item.itemId}`,
+    /**
+     * Slice a high-quantity clearance entry into chunks of
+     * CLEARANCE_MAX_REVEALS_PER_ORDER so each resulting order has at most
+     * that many reveal slots.  Buying 7 entries → [3, 3, 1].
+     */
+    splitMultipleOrders: (item) => {
+        if (item.quantity <= CLEARANCE_MAX_REVEALS_PER_ORDER)
+            return [item];
+        const chunks = [];
+        let remaining = item.quantity;
+        let batchIndex = 0;
+        while (remaining > 0) {
+            const batchQty = Math.min(remaining, CLEARANCE_MAX_REVEALS_PER_ORDER);
+            chunks.push({
+                ...item,
+                quantity: batchQty,
+                itemId: `${item.itemId}-batch-${batchIndex}`,
+            });
+            remaining -= batchQty;
+            batchIndex++;
+        }
+        return chunks;
+    },
+    preflightChecks: (pairs) => {
+        /*
+         * The payment-method check USED to live here and is now in
+         * `assertPaymentMethodAllowed`, which runs cart-wide before the
+         * transaction.
+         *
+         * 🛑 This is not a tidy-up. The copy here could only ever see
+         * single-member lines — `runSyncPreflight` skips a bundle or grouped line,
+         * and its online call site reduces each line to its FIRST member — so a
+         * prize-draw entry reachable through a grouped selection was never
+         * checked. Re-adding a copy here would be a second answer to one question
+         * (Root Cause #75), and the one that is easier to find is the one that
+         * cannot see every line.
+         *
+         * `blockedPaymentMethods` + `blockedPaymentMessage` on this rule are what
+         * the gate reads, so the wording is unchanged.
+         */
+        for (const { item, product } of pairs) {
+            if (product.listingType !== "clearance")
+                continue;
+            const max = product.prizeMaxEntries ?? 0;
+            if (max <= 0)
+                continue;
+            const current = product.prizeCurrentEntries ?? 0;
+            if (current + item.quantity > max) {
+                throw Object.assign(new ValidationError(`Draw is full for "${product.title}". ${current}/${max} entries already in.`), { code: "PRIZE_POOL_FULL", productId: product.id });
+            }
+        }
+    },
+    stockDecrementExtras: (product, quantity) => {
+        if (product.listingType !== "clearance")
+            return {};
+        return {
+            prizeCurrentEntries: (product.prizeCurrentEntries ?? 0) + quantity,
+        };
+    },
+    stockIncrementExtras: (product, quantity) => {
+        if (product.listingType !== "clearance")
+            return {};
+        return {
+            prizeCurrentEntries: Math.max(0, (product.prizeCurrentEntries ?? 0) - quantity),
+        };
+    },
+    decorateOrderItem: (line, product) => ({
+        ...line,
+        listingType: "clearance",
+        prizeRevealStatus: product.prizeRevealStatus === "open" ? "open" : "pending",
+    }),
+    decorateOrderDoc: (_groupFirstItem, groupFirstProduct) => ({
+        prizeDrawProductId: groupFirstProduct.id,
+        isNonRefundable: true,
+        ...(groupFirstProduct.prizeRevealMode
+            ? { prizeRevealMode: groupFirstProduct.prizeRevealMode }
+            : {}),
+    }),
+};

package/dist/_internal/shared/checkout/rules/collector-drop.rule.d.ts

@@ -0,0 +1,2 @@
+import type { ListingCheckoutRule } from "./types";
+export declare const collectorDropRule: ListingCheckoutRule;

package/dist/_internal/shared/checkout/rules/collector-drop.rule.js

@@ -0,0 +1,50 @@
+import { DEFAULT_LISTING_RULE } from "./_defaults.js";
+export const collectorDropRule = {
+    ...DEFAULT_LISTING_RULE,
+    orderType: "collector-drop",
+    cartEligible: false, // bid-only; add-to-cart is blocked at the action layer
+    cartIneligibleHint: "Place a bid on the collector drop page instead.",
+    /*
+     * 🛑 THE GATEWAY IS PROHIBITED HERE, and this list was INVERTED until
+     * 2026-10-28 — it blocked `cod` and `cash` while leaving `online` open, so
+     * every collector drop win was payable by card.
+     *
+     * The reason is the acquirer's, not ours. Collector Drop and bidding businesses sit
+     * on the prohibited-merchant lists Indian PGs inherit from the card networks,
+     * alongside giveaways and games of chance. Settling collector drop wins through a
+     * standard e-commerce MID is a terms breach, and the penalty is not a
+     * declined transaction — it is the whole merchant account frozen with the
+     * settlement balance held. One category of order can cost every other
+     * category its ability to take money at all.
+     *
+     * So: manual bank/UPI transfer, or cash on pickup. Both land in the owner's
+     * own account with no acquirer in the path.
+     *
+     * 🛑 `cash` is now ALLOWED, reversing the rule below it. The old comment is
+     * kept because its reasoning is still sound — a pay-later method on a unique
+     * lot has no second-highest bidder to fall back on — but it was weighing
+     * seller risk against buyer convenience, and that trade is not what decides
+     * this. The storefront is single-vendor and the owner is the seller: they
+     * accept the non-payment risk on their own lots, and they do not get to
+     * accept the risk of losing the merchant account. `emi` goes for the same
+     * reason as `online` — it settles through the same acquirer.
+     *
+     * 🛑 `online` MOVED OUT of this list on 2026-10-31, to
+     * `requiresGatewayPermission` below. Everything above is still true of
+     * Razorpay and PhonePe and is kept for that reason — but it was never true
+     * of every acquirer, only of the ones whose terms name bidding. Cashfree's
+     * published terms do not, so "online is prohibited here" was being stated
+     * as a property of the LISTING when it is a property of WHO IS COLLECTING.
+     *
+     * `cod` and `emi` stay, and the distinction is the point: those are about
+     * the unique lot (no second-highest bidder behind a pay-later default, and
+     * EMI settles through an acquirer anyway), so they hold whatever gateway is
+     * registered.
+     */
+    blockedPaymentMethods: ["cod", "emi"],
+    requiresGatewayPermission: true,
+    blockedPaymentMessage: "A collector drop win is settled by direct bank/UPI transfer or cash on pickup — pay-later methods are not available for collector drops.",
+    canMergeWithSameProduct: false,
+    refundPolicy: { full: true, partial: false, partialGranularity: "none" },
+    splitKey: (item) => `collectorDrop:${item.itemId}`,
+};

package/dist/_internal/shared/checkout/rules/index.d.ts

@@ -1,16 +1,15 @@
 export type { ListingCheckoutRule, CategoryCheckoutRule, CartItemProductPair, OrderItemInput, RefundPolicy, } from "./types";
 export { CHECKOUT_RULES, CATEGORY_CHECKOUT_RULES, getListingRule, getCategoryRule, pickOrderType, getSplitKey, runSyncPreflight, } from "./_registry";
 export { assertPaymentMethodAllowed, assertEmiOptInAllowed, blockedMethodsForCart, type BlockedMethod, } from "./payment-gate";
-export { CART_MAX_ITEMS, CHECKOUT_MAX_ORDERS_PER_TX, PRIZE_DRAW_MAX_REVEALS_PER_ORDER, PRIZE_DRAW_DURATION_DAYS_MIN, PRIZE_DRAW_DURATION_DAYS_MAX, BUNDLE_MAX_QTY_PER_TX, STANDARD_MAX_QTY_PER_LINE, } from "./_limits";
+export { CART_MAX_ITEMS, CHECKOUT_MAX_ORDERS_PER_TX, CLEARANCE_MAX_REVEALS_PER_ORDER, CLEARANCE_DURATION_DAYS_MIN, CLEARANCE_DURATION_DAYS_MAX, BUNDLE_MAX_QTY_PER_TX, STANDARD_MAX_QTY_PER_LINE, } from "./_limits";
 export { standardRule } from "./standard.rule";
-export { auctionRule } from "./auction.rule";
+export { collectorDropRule } from "./collector-drop.rule";
 export { preOrderRule } from "./preorder.rule";
-export { prizeDrawRule } from "./prize-draw.rule";
+export { clearanceRule } from "./clearance.rule";
 export { offerRule } from "./offer.rule";
 export { bundleRule } from "./bundle.rule";
 export { classifiedRule } from "./classified.rule";
 export { digitalCodeRule } from "./digital-code.rule";
 export { liveRule } from "./live.rule";
-export { artRule } from "./art.rule";
-export { stickersRule } from "./stickers.rule";
+export { artAndStickersRule } from "./art-and-stickers.rule";
 export { sparesRule } from "./spares.rule";