@mohasinac/appkit 4.62.0 → 4.63.0

package/dist/_internal/shared/features/shipping/parcel.d.ts

@@ -79,6 +79,129 @@ export declare function normaliseDimensions(d: ParcelSource["dimensionsCm"]): Pa
  * whichever tier won on weight would discard information that exists.
  */
 export declare function resolveParcel(shipment: ParcelSource | null | undefined, product: ParcelSource | null | undefined, category: ParcelSource | null | undefined): Parcel | null;
+/**
+ * Divisors, by service class.
+ *
+ * A carrier sells space, not mass, so it bills the greater of actual weight and
+ * `l × w × h ÷ divisor`. The divisor is the whole ballgame on this catalogue:
+ * collectible packaging is mostly air, so for a stadium box the volumetric
+ * figure is ~5× the actual and no per-kilo negotiation touches it.
+ *
+ * 🛑 `surfaceTight` is not a typo. Some Indian surface B2C plans quote ÷4000,
+ * which is a silent 25% increase over ÷5000 on every bulky parcel and is
+ * never the number on the front of the rate card. Read the contract, then set
+ * this per carrier — do not assume 5000 because it is the common default.
+ *
+ * Air uses a LARGER divisor, which means a very light bulky box can genuinely
+ * cost less by air than by surface. That is counter-intuitive and real.
+ */
+export declare const VOLUMETRIC_DIVISORS: {
+    readonly surfaceTight: 4000;
+    readonly standard: 5000;
+    readonly air: 6000;
+};
+export declare const DEFAULT_VOLUMETRIC_DIVISOR: 5000;
+/**
+ * Where a parcel sits against the two thresholds, and therefore which carrier
+ * class is cheaper. See `carrierClassFor` for why these numbers.
+ */
+export declare const VOLUMETRIC_RATIO_THRESHOLDS: {
+    /** Below this the two weights are close enough that the rate card decides. */
+    readonly private: 1.5;
+    /** At or above this the box is mostly air and a postal service wins. */
+    readonly postal: 2;
+};
+/**
+ * The first billing slab, in grams — the region where R means nothing.
+ *
+ * 🛑 This guard exists because the ratio rule is WRONG below it, and the error
+ * was caught by checking the rule against real tariffs instead of trusting it.
+ *
+ * A single boxed bey is 250 g actual / 448 g volumetric — R 1.79, which the
+ * thresholds above call `"either"`. The real bill at >2000 km is ₹106 by Speed
+ * Post against ₹50 by private courier: private wins by 2×, not "either".
+ *
+ * The reason is that both figures land inside each carrier's MINIMUM charge, so
+ * the comparison is floor against floor and the ratio describes nothing. India
+ * Post's 201–500 g floor is ₹90; a private first slab is around ₹42. Whenever
+ * both weights sit in that first slab, the lower floor wins and that is private.
+ */
+export declare const FIRST_SLAB_G = 500;
+export interface ChargeableWeight {
+    actualG: number;
+    /**
+     * `null` when the dimension triple is unknown — NEVER 0.
+     *
+     * A carrier with no dimensions bills actual weight, so `chargeableG` is still
+     * correct in that case. But a `0` here would read as "this box has no volume",
+     * and `ratio` would compute to 0, which routes a stadium to the private
+     * carrier that bills it at 7.3 kg. Unknown has to stay distinguishable from
+     * dense — same discipline as `resolveParcel` refusing to return weight 0.
+     */
+    volumetricG: number | null;
+    /** `max(actual, volumetric)` — what you are billed for. */
+    chargeableG: number;
+    divisor: number;
+    billedOn: "actual" | "volumetric";
+    /**
+     * **The R value**: volumetric ÷ actual, 2dp. `null` without dimensions.
+     *
+     * 1 means the box is exactly at the divisor's break-even density. Above 1 you
+     * are paying for air; below 1 the volume is free and actual weight bills.
+     */
+    ratio: number | null;
+    /** Packed density in kg/m³. `null` without dimensions. */
+    densityKgM3: number | null;
+    /**
+     * The density at which volumetric starts to bite, derived from the divisor
+     * rather than hardcoded: `1e6 / divisor`. 200 kg/m³ at ÷5000, 250 at ÷4000,
+     * ~167 at ÷6000. A parcel below this is billed on volume.
+     */
+    breakEvenKgM3: number;
+}
+/** Volumetric weight in grams. `l × w × h ÷ divisor` is kilos, hence ×1000. */
+export declare function volumetricWeightG(d: ParcelDimensionsCm, divisor?: number): number;
+/**
+ * What this parcel is billed at, and by how much volume beats mass.
+ *
+ * Pure arithmetic — it reports, it does not decide. `carrierClassFor` turns the
+ * result into a routing opinion, deliberately as a separate step so a surface
+ * can show the numbers without adopting the recommendation.
+ */
+export declare function chargeableWeight(parcel: Pick<Parcel, "weightG" | "dimensionsCm">, divisor?: number): ChargeableWeight;
+/**
+ * Which carrier class is cheaper for this parcel, on freight alone.
+ *
+ * India Post Speed Post bills ACTUAL weight and applies no volumetric
+ * calculation; every private carrier bills the greater of the two. So the
+ * freight comparison reduces to the R value:
+ *
+ *   R < 1.5   the two weights are close; the rate card decides, and a private
+ *             card is usually cheaper at low weight → `"private"`
+ *   1.5 ≤ R < 2   genuinely close; decide on pincode serviceability and
+ *             whether the item needs insurance → `"either"`
+ *   R ≥ 2     the box is mostly air and postal is materially cheaper → `"postal"`
+ *
+ * 🛑 `"unknown"` when dimensions are missing, and callers must not collapse it
+ * into a default. Defaulting to `"private"` is precisely the wrong way round:
+ * the parcels whose dimensions nobody recorded are disproportionately the big
+ * awkward ones, which are the parcels this function exists to divert.
+ *
+ * 🛑 This is a FREIGHT opinion and nothing more. Above roughly ₹8,000 of order
+ * value the decision stops being about freight — the delta is a few hundred
+ * rupees against an uninsured loss of the whole item — so an order-value test
+ * and serviceability both outrank this. It answers "which is cheaper", never
+ * "which should we book".
+ *
+ * ## Where it is weakest, stated rather than hidden
+ *
+ * At HIGH weight the per-additional-slab rates start to matter more than the
+ * ratio, and those are negotiated. A 8 kg / 14 kg parcel is R 1.75 → `"either"`,
+ * while one representative card puts it at ₹991 postal against ₹1,197 private —
+ * a real 21% gap the ratio does not see. `"either"` is the honest answer there:
+ * it means your own card decides, not that the two are equal.
+ */
+export declare function carrierClassFor(c: Pick<ChargeableWeight, "ratio" | "actualG" | "volumetricG">): "private" | "either" | "postal" | "unknown";
 /**
  * The weight of a whole order group — what a single shipment actually carries.
  *

package/dist/_internal/shared/features/shipping/parcel.js

@@ -88,6 +88,145 @@ export function resolveParcel(shipment, product, category) {
     }
     return { weightG, source, ...(dimensionsCm ? { dimensionsCm } : {}) };
 }
+/* ── Volumetric weight — what the carrier actually bills ──────────────────── */
+/**
+ * Divisors, by service class.
+ *
+ * A carrier sells space, not mass, so it bills the greater of actual weight and
+ * `l × w × h ÷ divisor`. The divisor is the whole ballgame on this catalogue:
+ * collectible packaging is mostly air, so for a stadium box the volumetric
+ * figure is ~5× the actual and no per-kilo negotiation touches it.
+ *
+ * 🛑 `surfaceTight` is not a typo. Some Indian surface B2C plans quote ÷4000,
+ * which is a silent 25% increase over ÷5000 on every bulky parcel and is
+ * never the number on the front of the rate card. Read the contract, then set
+ * this per carrier — do not assume 5000 because it is the common default.
+ *
+ * Air uses a LARGER divisor, which means a very light bulky box can genuinely
+ * cost less by air than by surface. That is counter-intuitive and real.
+ */
+export const VOLUMETRIC_DIVISORS = {
+    surfaceTight: 4000,
+    standard: 5000,
+    air: 6000,
+};
+export const DEFAULT_VOLUMETRIC_DIVISOR = VOLUMETRIC_DIVISORS.standard;
+/**
+ * Where a parcel sits against the two thresholds, and therefore which carrier
+ * class is cheaper. See `carrierClassFor` for why these numbers.
+ */
+export const VOLUMETRIC_RATIO_THRESHOLDS = {
+    /** Below this the two weights are close enough that the rate card decides. */
+    private: 1.5,
+    /** At or above this the box is mostly air and a postal service wins. */
+    postal: 2,
+};
+/**
+ * The first billing slab, in grams — the region where R means nothing.
+ *
+ * 🛑 This guard exists because the ratio rule is WRONG below it, and the error
+ * was caught by checking the rule against real tariffs instead of trusting it.
+ *
+ * A single boxed bey is 250 g actual / 448 g volumetric — R 1.79, which the
+ * thresholds above call `"either"`. The real bill at >2000 km is ₹106 by Speed
+ * Post against ₹50 by private courier: private wins by 2×, not "either".
+ *
+ * The reason is that both figures land inside each carrier's MINIMUM charge, so
+ * the comparison is floor against floor and the ratio describes nothing. India
+ * Post's 201–500 g floor is ₹90; a private first slab is around ₹42. Whenever
+ * both weights sit in that first slab, the lower floor wins and that is private.
+ */
+export const FIRST_SLAB_G = 500;
+/** Volumetric weight in grams. `l × w × h ÷ divisor` is kilos, hence ×1000. */
+export function volumetricWeightG(d, divisor = DEFAULT_VOLUMETRIC_DIVISOR) {
+    if (!(divisor > 0)) {
+        throw new RangeError(`volumetricWeightG: divisor must be > 0, got ${divisor}`);
+    }
+    return Math.round(((d.l * d.w * d.h) / divisor) * 1000);
+}
+/**
+ * What this parcel is billed at, and by how much volume beats mass.
+ *
+ * Pure arithmetic — it reports, it does not decide. `carrierClassFor` turns the
+ * result into a routing opinion, deliberately as a separate step so a surface
+ * can show the numbers without adopting the recommendation.
+ */
+export function chargeableWeight(parcel, divisor = DEFAULT_VOLUMETRIC_DIVISOR) {
+    const actualG = parcel.weightG;
+    const breakEvenKgM3 = Math.round((1000000 / divisor) * 10) / 10;
+    const d = parcel.dimensionsCm;
+    if (!d) {
+        return {
+            actualG,
+            volumetricG: null,
+            chargeableG: actualG,
+            divisor,
+            billedOn: "actual",
+            ratio: null,
+            densityKgM3: null,
+            breakEvenKgM3,
+        };
+    }
+    const volumetricG = volumetricWeightG(d, divisor);
+    const cm3 = d.l * d.w * d.h;
+    return {
+        actualG,
+        volumetricG,
+        chargeableG: Math.max(actualG, volumetricG),
+        divisor,
+        billedOn: volumetricG > actualG ? "volumetric" : "actual",
+        ratio: actualG > 0 ? Math.round((volumetricG / actualG) * 100) / 100 : null,
+        densityKgM3: cm3 > 0 ? Math.round(((actualG * 1000) / cm3) * 10) / 10 : null,
+        breakEvenKgM3,
+    };
+}
+/**
+ * Which carrier class is cheaper for this parcel, on freight alone.
+ *
+ * India Post Speed Post bills ACTUAL weight and applies no volumetric
+ * calculation; every private carrier bills the greater of the two. So the
+ * freight comparison reduces to the R value:
+ *
+ *   R < 1.5   the two weights are close; the rate card decides, and a private
+ *             card is usually cheaper at low weight → `"private"`
+ *   1.5 ≤ R < 2   genuinely close; decide on pincode serviceability and
+ *             whether the item needs insurance → `"either"`
+ *   R ≥ 2     the box is mostly air and postal is materially cheaper → `"postal"`
+ *
+ * 🛑 `"unknown"` when dimensions are missing, and callers must not collapse it
+ * into a default. Defaulting to `"private"` is precisely the wrong way round:
+ * the parcels whose dimensions nobody recorded are disproportionately the big
+ * awkward ones, which are the parcels this function exists to divert.
+ *
+ * 🛑 This is a FREIGHT opinion and nothing more. Above roughly ₹8,000 of order
+ * value the decision stops being about freight — the delta is a few hundred
+ * rupees against an uninsured loss of the whole item — so an order-value test
+ * and serviceability both outrank this. It answers "which is cheaper", never
+ * "which should we book".
+ *
+ * ## Where it is weakest, stated rather than hidden
+ *
+ * At HIGH weight the per-additional-slab rates start to matter more than the
+ * ratio, and those are negotiated. A 8 kg / 14 kg parcel is R 1.75 → `"either"`,
+ * while one representative card puts it at ₹991 postal against ₹1,197 private —
+ * a real 21% gap the ratio does not see. `"either"` is the honest answer there:
+ * it means your own card decides, not that the two are equal.
+ */
+export function carrierClassFor(c) {
+    if (c.ratio == null)
+        return "unknown";
+    // Both weights inside the first slab → floor vs floor; see FIRST_SLAB_G.
+    if (c.actualG <= FIRST_SLAB_G &&
+        c.volumetricG != null &&
+        c.volumetricG <= FIRST_SLAB_G) {
+        return "private";
+    }
+    if (c.ratio >= VOLUMETRIC_RATIO_THRESHOLDS.postal)
+        return "postal";
+    if (c.ratio >= VOLUMETRIC_RATIO_THRESHOLDS.private)
+        return "either";
+    return "private";
+}
 /**
  * The weight of a whole order group — what a single shipment actually carries.
  *

package/dist/_internal/shared/features/shipping/shared-purchase.d.ts

@@ -0,0 +1,91 @@
+/**
+ * Shared purchase, S5a — one payer, N destinations.
+ *
+ * ## What this is, and what it deliberately is not
+ *
+ * The coordinator buys everything and assigns a destination per item, so one
+ * paid order becomes N parcels. That is **~20% of the shared-purchase work for
+ * most of its value** (the plan's own assessment), because it needs none of
+ * the hard parts: no multi-party payment, no coordinator deposit, no approval
+ * cascade, no per-buyer invoicing, no per-buyer GST, and no stock-reservation
+ * primitive.
+ *
+ * 🛑 It is NOT S5b. There is exactly ONE payer and ONE place of supply, which
+ * is what keeps the tax, the invoice and the refund path unchanged. The moment
+ * a second person pays, every one of those becomes per-buyer and the design is
+ * a different design.
+ *
+ * ## 🛑 Why the fees are SNAPSHOTTED, and the precedent that proves it
+ *
+ * A coordinator commits to a quoted total. If the handling fee or the
+ * per-destination shipping is re-read at settle, a seller can raise it after
+ * the quote and the coordinator absorbs the difference.
+ *
+ * The codebase already has this exact hole and this exact fix: the refund path
+ * reads `finalSale` from the ORDER snapshot rather than the live product,
+ * because — in its own words — "re-reading the live product would let a seller
+ * flip the switch afterwards". D61 generalises it: *any agreement with a gap
+ * between "terms agreed" and "money taken" must snapshot its terms at
+ * agreement.*
+ *
+ * So `quoteSharedPurchase` takes the rates as ARGUMENTS and the caller
+ * snapshots the result onto the order. There is no settings read in here.
+ */
+/** The two rates, read from the store document at quote time. */
+export interface SharedPurchaseRates {
+    allowSharedPurchase?: boolean;
+    sharedPurchaseHandlingFee?: number;
+    sharedPurchaseExtraShippingPerDestination?: number;
+}
+export interface SharedPurchaseQuoteInput {
+    /**
+     * Distinct destinations in this order group, INCLUDING the first.
+     *
+     * 🛑 A count of DISTINCT addresses, not of items. Three items to one address
+     * is one parcel and no extra leg; two items to two addresses is two. Passing
+     * an item count would charge a coordinator for splitting an order they did
+     * not split.
+     */
+    destinationCount: number;
+    /** The store's snapshotted rates. */
+    rates: SharedPurchaseRates;
+}
+export interface SharedPurchaseQuote {
+    /** True when this is actually a multi-destination order. */
+    isShared: boolean;
+    /** Flat handling fee, or 0. */
+    handlingFee: number;
+    /** Extra shipping for destinations beyond the first, or 0. */
+    extraShippingFee: number;
+    /** `handlingFee + extraShippingFee`, the figure added to the order total. */
+    total: number;
+    /**
+     * Set when the arrangement cannot be priced — the seller allows it but has
+     * not configured a rate.
+     *
+     * 🛑 The caller MUST act on this rather than treating the fee as ₹0. That is
+     * D44 exactly: `shippingUnavailable` existed with its own docstring saying
+     * "the caller MUST act on this rather than trusting `shippingFee: 0`", had
+     * ZERO consumers, and an `estimate`-mode store shipped free on every path as
+     * a result. An unpriced arrangement must be refused, not given away.
+     */
+    unpriced?: "handling" | "extra-shipping";
+}
+/**
+ * Price a shared-purchase arrangement for ONE order group.
+ *
+ * Pure: no settings read, no Firestore, no clock. The rates come in, the
+ * figure comes out, and the caller snapshots it.
+ */
+export declare function quoteSharedPurchase(input: SharedPurchaseQuoteInput): SharedPurchaseQuote;
+/**
+ * Distinct destinations across a set of lines.
+ *
+ * 🛑 Lines with NO `destinationAddressId` collapse into one bucket — the
+ * order's own address — rather than counting as a destination each. Otherwise
+ * an ordinary three-item order would look like three destinations and be
+ * charged two extra legs.
+ */
+export declare function countDestinations(lines: readonly {
+    destinationAddressId?: string;
+}[]): number;

package/dist/_internal/shared/features/shipping/shared-purchase.js

@@ -0,0 +1,108 @@
+/**
+ * Shared purchase, S5a — one payer, N destinations.
+ *
+ * ## What this is, and what it deliberately is not
+ *
+ * The coordinator buys everything and assigns a destination per item, so one
+ * paid order becomes N parcels. That is **~20% of the shared-purchase work for
+ * most of its value** (the plan's own assessment), because it needs none of
+ * the hard parts: no multi-party payment, no coordinator deposit, no approval
+ * cascade, no per-buyer invoicing, no per-buyer GST, and no stock-reservation
+ * primitive.
+ *
+ * 🛑 It is NOT S5b. There is exactly ONE payer and ONE place of supply, which
+ * is what keeps the tax, the invoice and the refund path unchanged. The moment
+ * a second person pays, every one of those becomes per-buyer and the design is
+ * a different design.
+ *
+ * ## 🛑 Why the fees are SNAPSHOTTED, and the precedent that proves it
+ *
+ * A coordinator commits to a quoted total. If the handling fee or the
+ * per-destination shipping is re-read at settle, a seller can raise it after
+ * the quote and the coordinator absorbs the difference.
+ *
+ * The codebase already has this exact hole and this exact fix: the refund path
+ * reads `finalSale` from the ORDER snapshot rather than the live product,
+ * because — in its own words — "re-reading the live product would let a seller
+ * flip the switch afterwards". D61 generalises it: *any agreement with a gap
+ * between "terms agreed" and "money taken" must snapshot its terms at
+ * agreement.*
+ *
+ * So `quoteSharedPurchase` takes the rates as ARGUMENTS and the caller
+ * snapshots the result onto the order. There is no settings read in here.
+ */
+import { roundRupees } from "../../../../utils/number.formatter.js";
+/**
+ * Price a shared-purchase arrangement for ONE order group.
+ *
+ * Pure: no settings read, no Firestore, no clock. The rates come in, the
+ * figure comes out, and the caller snapshots it.
+ */
+export function quoteSharedPurchase(input) {
+    const none = {
+        isShared: false,
+        handlingFee: 0,
+        extraShippingFee: 0,
+        total: 0,
+    };
+    /*
+     * One destination is an ordinary order. Checked BEFORE the allow flag, so a
+     * seller who has not opted in is unaffected by this code path entirely —
+     * rather than being refused an order they were always able to take.
+     */
+    const destinations = Math.max(1, Math.floor(input.destinationCount));
+    if (destinations <= 1)
+        return none;
+    if (input.rates.allowSharedPurchase !== true) {
+        /*
+         * 🛑 Returns `isShared: false` rather than throwing, and the CALLER
+         * refuses. This function prices; it does not authorise. A thrown error
+         * here would be caught by a preview path and rendered as a broken page,
+         * where the correct behaviour is to tell the buyer this seller does not
+         * split orders.
+         */
+        return none;
+    }
+    const handling = input.rates.sharedPurchaseHandlingFee;
+    const perExtra = input.rates.sharedPurchaseExtraShippingPerDestination;
+    /*
+     * 🛑 `undefined` is UNPRICED, not zero — see the `unpriced` field. A seller
+     * who opted in without setting a rate has not agreed to do it for free, and
+     * charging ₹0 would hand them the extra labour at their own cost silently.
+     */
+    if (typeof handling !== "number" || !Number.isFinite(handling)) {
+        return { ...none, isShared: true, unpriced: "handling" };
+    }
+    if (typeof perExtra !== "number" || !Number.isFinite(perExtra)) {
+        return { ...none, isShared: true, unpriced: "extra-shipping" };
+    }
+    const handlingFee = roundRupees(Math.max(0, handling));
+    // BEYOND THE FIRST: the first destination's shipping is what the order would
+    // have paid anyway, so only the marginal legs are charged here.
+    const extraShippingFee = roundRupees(Math.max(0, perExtra) * (destinations - 1));
+    return {
+        isShared: true,
+        handlingFee,
+        extraShippingFee,
+        total: roundRupees(handlingFee + extraShippingFee),
+    };
+}
+/**
+ * Distinct destinations across a set of lines.
+ *
+ * 🛑 Lines with NO `destinationAddressId` collapse into one bucket — the
+ * order's own address — rather than counting as a destination each. Otherwise
+ * an ordinary three-item order would look like three destinations and be
+ * charged two extra legs.
+ */
+export function countDestinations(lines) {
+    const ids = new Set();
+    let usesOrderAddress = false;
+    for (const line of lines) {
+        if (line.destinationAddressId)
+            ids.add(line.destinationAddressId);
+        else
+            usesOrderAddress = true;
+    }
+    return ids.size + (usesOrderAddress ? 1 : 0);
+}

package/dist/_internal/shared/features/site-settings/fees.d.ts

@@ -38,17 +38,25 @@ export interface BuyerFacingFees {
     codHandlingFeeCap?: number;
     codHandlingFeePercent?: number;
     codDepositPercent?: number;
+    /** Commission rate applied to the cart subtotal, before the cap. */
+    platformFeePercent?: number;
+    /** Rupee ceiling on the commission — the reason a ₹39,500 order pays ₹10. */
+    platformFeeMax?: number;
+    /** GST rate levied on the commission actually charged (never on the uncapped figure). */
+    gstPercent?: number;
+    /** Rupee floor on `platformFee + gstOnFee` combined. */
+    minimumTransactionFee?: number;
 }
 /**
- * Withheld on purpose (15 of 25): platformFeePercent, gstPercent,
- * minimumTransactionFee, platformFeeMax, gatewayFeePercent,
- * sellerShippingFixed, platformShippingPercent, platformShippingFixedMin,
- * autoPayoutWindowDays, payoutHoldDays, minPayoutAmount, auctionListingFee,
- * preOrderListingFee, featuredSlotFee, promotedSlotFee.
+ * Withheld on purpose (11 of 25): gatewayFeePercent, sellerShippingFixed,
+ * platformShippingPercent, platformShippingFixedMin, autoPayoutWindowDays,
+ * payoutHoldDays, minPayoutAmount, auctionListingFee, preOrderListingFee,
+ * featuredSlotFee, promotedSlotFee — plus `surchargeSellerSharePercent`, which
+ * lives on the EMI block and is excluded by `BuyerEmiSettings` below.
  *
- * The buyer still SEES the platform fee and GST — as computed amounts in the
- * server pricing preview (`CartPriceBreakdownData`), never as the rates that
- * produced them.
+ * Every one of those prices something between us and a seller or a gateway.
+ * None of them changes what the buyer is asked to pay, so none of them has a
+ * reader in a browser.
  */
 export declare function toBuyerFacingFees(commissions: SiteSettingsDocument["commissions"] | null | undefined): BuyerFacingFees | null;
 /**

package/dist/_internal/shared/features/site-settings/fees.js

@@ -1,13 +1,13 @@
 /**
- * Withheld on purpose (15 of 25): platformFeePercent, gstPercent,
- * minimumTransactionFee, platformFeeMax, gatewayFeePercent,
- * sellerShippingFixed, platformShippingPercent, platformShippingFixedMin,
- * autoPayoutWindowDays, payoutHoldDays, minPayoutAmount, auctionListingFee,
- * preOrderListingFee, featuredSlotFee, promotedSlotFee.
+ * Withheld on purpose (11 of 25): gatewayFeePercent, sellerShippingFixed,
+ * platformShippingPercent, platformShippingFixedMin, autoPayoutWindowDays,
+ * payoutHoldDays, minPayoutAmount, auctionListingFee, preOrderListingFee,
+ * featuredSlotFee, promotedSlotFee — plus `surchargeSellerSharePercent`, which
+ * lives on the EMI block and is excluded by `BuyerEmiSettings` below.
  *
- * The buyer still SEES the platform fee and GST — as computed amounts in the
- * server pricing preview (`CartPriceBreakdownData`), never as the rates that
- * produced them.
+ * Every one of those prices something between us and a seller or a gateway.
+ * None of them changes what the buyer is asked to pay, so none of them has a
+ * reader in a browser.
  */
 export function toBuyerFacingFees(commissions) {
     if (!commissions)
@@ -24,6 +24,10 @@ export function toBuyerFacingFees(commissions) {
         codHandlingFeeCap: commissions.codHandlingFeeCap,
         codHandlingFeePercent: commissions.codHandlingFeePercent,
         codDepositPercent: commissions.codDepositPercent,
+        platformFeePercent: commissions.platformFeePercent,
+        platformFeeMax: commissions.platformFeeMax,
+        gstPercent: commissions.gstPercent,
+        minimumTransactionFee: commissions.minimumTransactionFee,
     };
 }
 export function toBuyerEmiSettings(emi) {

package/dist/_internal/shared/features/site-settings/types.d.ts

@@ -42,6 +42,17 @@ export interface PublicSiteSettings {
     chat?: {
         enabled: boolean;
     };
+    /**
+     * Is the support desk reachable — read by `UserLayoutClient`, a client
+     * component. Narrowed to the one boolean rather than passed by reference,
+     * so a field added to the document's `support` group later is not published
+     * by accident; `PUBLIC_SITE_SETTINGS_FIELDS` carries the same caveat beside
+     * its entry. Optional here because the group is absent on a settings
+     * document written before it existed.
+     */
+    support?: {
+        enabled: boolean;
+    };
     /**
      * The browser-side search index kill switch. **ON by default** — the
      * projection emits `indexEnabled: doc.search?.indexEnabled !== false`, so

package/dist/_internal/shared/fees/calculator.d.ts

@@ -79,6 +79,17 @@ export interface PayoutDeduction {
      * plus ₹80 postage" is a sentence; one net figure is not.
      */
     shippingReimbursement: number;
+    /**
+     * Rupee value of buyer points this order was settled with, deducted from
+     * `netAmount` (D46/D47, decisions 3 and 17 — the accepting store funds the
+     * redemption).
+     *
+     * Returned as its own figure rather than folded into `totalDeduction` for the
+     * same reason `shippingReimbursement` is: *"'₹900 less ₹30 commission plus
+     * ₹80 postage' is a sentence; one net figure is not."* A seller looking at a
+     * short payout needs to see which of the four terms shortened it.
+     */
+    pointsFunded: number;
 }
 /**
  * What a seller is actually paid.
@@ -101,8 +112,29 @@ export interface PayoutDeduction {
  *
  * Defaulted to 0, so the three call sites that do not yet pass it keep their
  * current behaviour exactly rather than silently gaining a term.
+ *
+ * ## 🛑 `pointsFunded` is the mirror of that, and it is a DEDUCTION
+ *
+ * Decisions 3 and 17: the programme is seller-funded at both ends — the
+ * accepting store absorbs the redemption, the originating store bears the
+ * earn — and the platform funds neither. So points spent on an order reduce
+ * that order's payout by the rupee value spent.
+ *
+ * It sits in the SAME position as postage and for the inverse reason: outside
+ * the commission and gateway bases. The seller agreed to fund a discount, not
+ * to pay us a commission on the discount they funded, and a gateway percentage
+ * on money no gateway touched is not a card fee at all.
+ *
+ * 🛑 So `grossAmount` is untouched and the fee figures are IDENTICAL whether
+ * points were used or not. That is what keeps the commission the seller is
+ * charged a function of the sale rather than of how the buyer chose to settle
+ * it — and it is why this cannot be implemented by passing a smaller
+ * `grossAmount`, which is the obvious shortcut and silently reduces our own
+ * commission by 2% of every redemption.
+ *
+ * Also defaulted to 0, for the same reason.
  */
-export declare function computePayoutDeduction(grossAmount: number, commissions: FeeCommissionRates, shippingReimbursement?: number): PayoutDeduction;
+export declare function computePayoutDeduction(grossAmount: number, commissions: FeeCommissionRates, shippingReimbursement?: number, pointsFunded?: number): PayoutDeduction;
 export interface CodHandlingFeeRates {
     /**
      * Rupee CEILING on the COD handling fee. Optional so a `siteSettings`

package/dist/_internal/shared/fees/calculator.js

@@ -114,8 +114,29 @@ export function allocateCheckoutFees(groupSubtotals, fees) {
  *
  * Defaulted to 0, so the three call sites that do not yet pass it keep their
  * current behaviour exactly rather than silently gaining a term.
+ *
+ * ## 🛑 `pointsFunded` is the mirror of that, and it is a DEDUCTION
+ *
+ * Decisions 3 and 17: the programme is seller-funded at both ends — the
+ * accepting store absorbs the redemption, the originating store bears the
+ * earn — and the platform funds neither. So points spent on an order reduce
+ * that order's payout by the rupee value spent.
+ *
+ * It sits in the SAME position as postage and for the inverse reason: outside
+ * the commission and gateway bases. The seller agreed to fund a discount, not
+ * to pay us a commission on the discount they funded, and a gateway percentage
+ * on money no gateway touched is not a card fee at all.
+ *
+ * 🛑 So `grossAmount` is untouched and the fee figures are IDENTICAL whether
+ * points were used or not. That is what keeps the commission the seller is
+ * charged a function of the sale rather than of how the buyer chose to settle
+ * it — and it is why this cannot be implemented by passing a smaller
+ * `grossAmount`, which is the obvious shortcut and silently reduces our own
+ * commission by 2% of every redemption.
+ *
+ * Also defaulted to 0, for the same reason.
  */
-export function computePayoutDeduction(grossAmount, commissions, shippingReimbursement = 0) {
+export function computePayoutDeduction(grossAmount, commissions, shippingReimbursement = 0, pointsFunded = 0) {
     const platformFee = roundRupees(grossAmount * (commissions.platformFeePercent / 100));
     const gatewayFee = roundRupees(grossAmount * ((commissions.gatewayFeePercent ?? 0) / 100));
     const gstOnFee = roundRupees(platformFee * (commissions.gstPercent / 100));
@@ -123,7 +144,15 @@ export function computePayoutDeduction(grossAmount, commissions, shippingReimbur
     const postage = Number.isFinite(shippingReimbursement)
         ? Math.max(0, shippingReimbursement)
         : 0;
-    const netAmount = Math.max(0, roundRupees(grossAmount - totalDeduction + postage));
+    const points = Number.isFinite(pointsFunded) ? Math.max(0, pointsFunded) : 0;
+    /*
+     * Clamped at zero, as it already was. A redemption cannot exceed 50% of the
+     * order total, so it cannot plausibly exceed the net — but a floor here means
+     * no caller can ever hand a seller a negative payout, which would be written
+     * to a `PayoutDocument.amount` that every downstream sum then treats as a
+     * credit against the platform.
+     */
+    const netAmount = Math.max(0, roundRupees(grossAmount - totalDeduction + postage - points));
     return {
         platformFee,
         gatewayFee,
@@ -131,6 +160,7 @@ export function computePayoutDeduction(grossAmount, commissions, shippingReimbur
         totalDeduction,
         netAmount,
         shippingReimbursement: roundRupees(postage),
+        pointsFunded: roundRupees(points),
     };
 }
 /** Buyer-facing COD handling ceiling, in decimal rupees. */