@mohasinac/appkit 4.71.0 → 4.72.0

package/dist/providers/auth-firebase/claims.js

@@ -0,0 +1,116 @@
+/**
+ * ═══════════════════════════════════════════════════════════════════════════
+ * Role claims sync — THE only writer of role custom claims (reviewer R1-F5)
+ * ═══════════════════════════════════════════════════════════════════════════
+ *
+ * 🛑 `setCustomUserClaims` REPLACES the entire claims object. It does not
+ * merge. Firebase documents this, and six call sites across this codebase
+ * ignored it:
+ *
+ *   src/app/api/auth/login/route.ts      setCustomUserClaims(uid, { role })
+ *   src/app/api/auth/me/route.ts         setCustomUserClaims(uid, { role })
+ *   src/app/api/auth/session/route.ts    setCustomUserClaims(uid, { role })  ×2
+ *   providers/auth-firebase/provider.ts  setCustomUserClaims(uid, { role })  ×2
+ *
+ * Each one wrote a bare `{ role }` object, so **every other claim the account
+ * held was silently dropped** on the next login, profile update or
+ * `/api/auth/me` round-trip.
+ *
+ * Under a role SET that becomes a lockout, not just data loss. The chain the
+ * reviewer traced:
+ *
+ *   1. `/api/auth/me` writes `{ role }` — one role, the rest of the set gone.
+ *   2. `src/lib/edge/session-role.ts` decodes a single `role` from the token.
+ *   3. `src/proxy.ts` gates `/admin` on that single decoded role.
+ *
+ * Net effect: **a multi-role admin was silently locked out of `/admin`** after
+ * any request that touched `/api/auth/me`. The repository dual-read does not
+ * help — the token is a SEPARATE read path, and it is the one that gates
+ * access.
+ *
+ * So: one function, it MERGES, and it writes the whole set.
+ */
+import { getAdminAuthLite } from "../db-firebase/admin-auth-lite.js";
+import { normalizeError } from "../../errors/normalize.js";
+import { rolesOf } from "../../features/auth/role-predicates.js";
+import { primaryRoleOf } from "../../features/auth/auth-helpers.js";
+/**
+ * Resolve a role carrier to the claims that should be on its token.
+ *
+ * Pure — exported so a caller can diff against the current claims without a
+ * write, and so this rule has one definition rather than one per route.
+ */
+export function roleClaimsFor(carrier) {
+    const held = rolesOf(carrier);
+    return {
+        roles: held,
+        // Same "highest rank wins" rule the repository applies to the scalar.
+        role: held.reduce((best, r) => (RANK[r] > RANK[best] ? r : best), held[0]),
+        primaryRole: primaryRoleOf(carrier),
+    };
+}
+/*
+ * A local rank table rather than importing ROLE_HIERARCHY: this module is
+ * loaded on the auth hot path and `security/authorization` pulls in the error
+ * classes and message catalogue. The two must agree — if a role is added to
+ * ROLE_HIERARCHY and not here it ranks 0 and the scalar degrades to "lowest
+ * wins", which under-grants rather than over-grants. Checked by
+ * `roleClaimsFor`'s unit expectations.
+ */
+const RANK = {
+    admin: 5,
+    moderator: 3,
+    employee: 3,
+    seller: 2,
+    tester: 2,
+    user: 1,
+};
+/**
+ * Write this user's role set into their custom claims, **merging** with the
+ * claims already there.
+ *
+ * Costs one extra `getUser` read, and that read is the entire point: without
+ * it there is nothing to merge with and the write is a clobber. Returns the
+ * claims that were written.
+ *
+ * @param carrier Anything with `roles` / `role` / `primaryRole` — a
+ *                `UserDocument`, a session user, or `{ role }` from a legacy
+ *                caller.
+ */
+export async function syncRoleClaims(uid, carrier) {
+    const next = roleClaimsFor(carrier);
+    const auth = getAdminAuthLite();
+    let existing = {};
+    try {
+        const record = await auth.getUser(uid);
+        existing = (record.customClaims ?? {});
+    }
+    catch (err) {
+        /*
+         * A failed read must not escalate into a clobber. Falling through with an
+         * empty `existing` would write `{ roles, role, primaryRole }` and drop
+         * whatever the account held — the exact bug this function exists to fix.
+         * So the error propagates and the caller decides.
+         */
+        void normalizeError(err);
+        throw err;
+    }
+    await auth.setCustomUserClaims(uid, { ...existing, ...next });
+    return next;
+}
+/**
+ * True when the token's claims already match `carrier`'s role set — so a
+ * caller can skip a write (and the token refresh it forces) on the common
+ * case where nothing changed.
+ */
+export function roleClaimsAreCurrent(claims, carrier) {
+    const next = roleClaimsFor(carrier);
+    const current = Array.isArray(claims?.roles)
+        ? claims.roles.filter((r) => typeof r === "string")
+        : claims?.role
+            ? [String(claims.role)]
+            : [];
+    if (current.length !== next.roles.length)
+        return false;
+    return next.roles.every((r) => current.includes(r));
+}

package/dist/providers/auth-firebase/helpers.d.ts

@@ -76,7 +76,12 @@ export declare function requireAuthFromRequest<T = unknown>(request: Request, fi
 /**
  * Require a specific role from a request.
  */
-export declare function requireRoleFromRequest<T = unknown>(request: Request, findById: (uid: string) => Promise<T | null>, roles: string | string[], getRole: (user: T) => string): Promise<T>;
+export declare function requireRoleFromRequest<T = unknown>(request: Request, findById: (uid: string) => Promise<T | null>, roles: string | string[], 
+/**
+ * @deprecated Kept so the 18 host call sites compile unchanged, but it is
+ * NOT what decides access any more — see the role-SET note below.
+ */
+getRole: (user: T) => string): Promise<T>;
 /**
  * Revoke all refresh tokens for a Firebase user (server-side).
  */

package/dist/providers/auth-firebase/helpers.js

@@ -1,6 +1,7 @@
 import { normalizeError } from "../../errors/normalize.js";
 import { getAdminAuthLite } from "../db-firebase/admin-auth-lite.js";
 import { createSessionCookieFromToken } from "./session.js";
+import { holdsAnyRole } from "../../features/auth/role-predicates.js";
 export { createSessionCookieFromToken };
 const EXPECTED_AUTH_CODES = new Set([
     "auth/argument-error",
@@ -187,10 +188,33 @@ export async function requireAuthFromRequest(request, findById, isDisabled) {
 /**
  * Require a specific role from a request.
  */
-export async function requireRoleFromRequest(request, findById, roles, getRole) {
+export async function requireRoleFromRequest(request, findById, roles, 
+/**
+ * @deprecated Kept so the 18 host call sites compile unchanged, but it is
+ * NOT what decides access any more — see the role-SET note below.
+ */
+getRole) {
     const user = await requireAuthFromRequest(request, findById);
     const allowed = Array.isArray(roles) ? roles : [roles];
-    if (!allowed.includes(getRole(user))) {
+    /*
+     * ── Intersect the role SET, not one scalar (1.43) ───────────────────────
+     *
+     * 🛑 Was `allowed.includes(getRole(user))`. `getRole` is supplied by the
+     * consumer as `(u) => u.role`, and `UserRepository.mapDoc` resolves that
+     * scalar to the HIGHEST-RANKED held role — so a seller who also holds
+     * `employee` produced `"employee"`, and every `requireRoleFromRequest(req,
+     * ["seller"])` route 403'd them off their own store. Exact-match gates are
+     * the case where "highest rank wins" is not a safe approximation, which is
+     * why this had to be converted rather than left to the derived scalar.
+     *
+     * `holdsAnyRole` reads `roles[]` with the scalar as fallback and folds
+     * `moderator` → `employee`. `getRole` is still consulted as a last-resort
+     * carrier for a consumer whose document shape this cannot see.
+     */
+    const carrier = user;
+    const held = holdsAnyRole(carrier, allowed);
+    const legacyMatch = allowed.includes(getRole(user));
+    if (!held && !legacyMatch) {
         throw Object.assign(new Error(`Forbidden — requires role: ${allowed.join(" | ")}`), { statusCode: 403 });
     }
     return user;

package/dist/providers/auth-firebase/provider.js

@@ -6,6 +6,7 @@
  */
 import { getAdminAuthLite } from "../db-firebase/admin-auth-lite.js";
 import { normalizeError } from "../../errors/normalize.js";
+import { syncRoleClaims } from "./claims.js";
 /** Firebase error codes that represent a normal "not authenticated" state. */
 const EXPECTED_AUTH_CODES = new Set([
     "auth/argument-error",
@@ -88,9 +89,8 @@ export const firebaseAuthProvider = {
             emailVerified: data.emailVerified ?? false,
         });
         if (data.role) {
-            await getAdminAuthLite().setCustomUserClaims(record.uid, {
-                role: data.role,
-            });
+            // MERGE, never replace — see `./claims` for the whole R1-F5 writeup.
+            await syncRoleClaims(record.uid, { role: data.role });
             // Re-fetch to get updated claims
             const updated = await getAdminAuthLite().getUser(record.uid);
             return toAuthUser(updated);
@@ -106,7 +106,12 @@ export const firebaseAuthProvider = {
             emailVerified: data.emailVerified,
         });
         if (data.role !== undefined) {
-            await getAdminAuthLite().setCustomUserClaims(uid, { role: data.role });
+            /*
+             * 🛑 This was the worst of the six: a plain `updateUser({ displayName })`
+             * that happened to also carry `role` wiped every other claim on the
+             * account. Merging writer now.
+             */
+            await syncRoleClaims(uid, { role: data.role });
         }
         const updated = await getAdminAuthLite().getUser(record.uid);
         return toAuthUser(updated);

package/dist/providers/auth-firebase/session.js

@@ -8,6 +8,7 @@
  */
 import { getAdminAuthLite } from "../db-firebase/admin-auth-lite.js";
 import { normalizeError } from "../../errors/normalize.js";
+import { roleClaimsFor } from "./claims.js";
 /** Default session duration: 5 days (in milliseconds). */
 const DEFAULT_EXPIRES_IN_MS = 60 * 60 * 24 * 5 * 1000;
 const EXPECTED_SESSION_CODES = new Set([
@@ -38,10 +39,29 @@ export const firebaseSessionProvider = {
     async verifySession(cookie) {
         try {
             const decoded = await getAdminAuthLite().verifySessionCookie(cookie, true);
+            /*
+             * ── Surface the role SET off the token (1.43 / R1-F5) ───────────────
+             *
+             * `rolesOf` applies the dual-read: `roles[]` when the claim is present,
+             * the legacy `role` scalar otherwise. That fallback is what keeps every
+             * session cookie minted before this change working — they carry only
+             * `role`, and the cookie TTL is 5 days.
+             *
+             * The scalar handed back is re-derived from the set, so a consumer still
+             * reading `payload.role` sees the highest-ranked held role rather than
+             * whatever single value happened to be written last.
+             */
+            const roleClaims = roleClaimsFor({
+                role: decoded.role,
+                roles: Array.isArray(decoded.roles)
+                    ? decoded.roles.filter((r) => typeof r === "string")
+                    : null,
+                primaryRole: decoded.primaryRole,
+            });
             return {
                 uid: decoded.uid,
                 email: decoded.email ?? null,
-                role: decoded.role ?? "user",
+                ...roleClaims,
                 emailVerified: decoded.email_verified ?? false,
                 claims: Object.fromEntries(Object.entries(decoded).filter(([k]) => ![
                     "uid",
@@ -54,6 +74,17 @@ export const firebaseSessionProvider = {
                     "sub",
                     "auth_time",
                     "firebase",
+                    /*
+                     * 🛑 The three role keys are EXCLUDED from the generic claims
+                     * bag, and that is load-bearing. `createRouteHandler` builds
+                     * its `RouteUser` as `{ uid, email, role, ..., ...claims }` —
+                     * claims spread LAST. Leaving `role` in the bag meant the raw
+                     * token value overwrote the derived one, so the whole
+                     * derivation above would have been silently discarded.
+                     */
+                    "role",
+                    "roles",
+                    "primaryRole",
                 ].includes(k))),
             };
         }

package/dist/providers/db-firebase/admin.d.ts

@@ -21,12 +21,37 @@ declare global {
     var __mohasinac_firebase_admin_app__: App | null | undefined;
     var __mohasinac_firebase_admin_auth__: Auth | null | undefined;
     var __mohasinac_firebase_admin_db__: Firestore | null | undefined;
+    var __mohasinac_firebase_admin_db_wiki__: Firestore | null | undefined;
     var __mohasinac_firebase_admin_storage__: Storage | null | undefined;
     var __mohasinac_firebase_admin_rtdb__: Database | null | undefined;
 }
 export declare function getAdminApp(): App;
 export declare function getAdminAuth(): Auth;
-export declare function getAdminDb(): Firestore;
+/**
+ * A named Firestore database in the same project.
+ *
+ * Owner decision 2026-11-08: the wiki is *"purely read"* and does not belong on
+ * the shop database, so it gets its own. Tools shares it — *"they can be on 1"*.
+ *
+ * 🛑 A Firestore TRANSACTION CANNOT SPAN DATABASES. That is why the split stops
+ * here and why the earlier proposal to also move users/orders/shipments onto
+ * their own database was dropped: `core/unit-of-work.ts` coordinates ONE
+ * transaction across 15 repositories — orders, products, cart, coupons, payout,
+ * addresses and more — so splitting them would make order creation,
+ * stock holds, coupon redemption and the ledger write stop being atomic.
+ *
+ * The wiki data has no such coupling: the shop READS specs and never writes
+ * them, and nothing in the unit of work touches those collections.
+ *
+ * For durability of orders/users the answer is PITR + scheduled exports, not a
+ * second database — a second database is a split, not a copy.
+ */
+export type DatabaseTarget = "shop" | "wiki";
+/** Which database this process is actually talking to, for logs and guards. */
+export declare function resolvedDatabaseId(target?: DatabaseTarget): string;
+export declare function getAdminDb(target?: DatabaseTarget): Firestore;
+/** The read-only wiki/tools database. Never used by the money path. */
+export declare function getWikiDb(): Firestore;
 export declare function getAdminStorage(): Storage;
 export declare function getAdminRealtimeDb(): Database;
 /** Reset all singletons — useful in tests. */

package/dist/providers/db-firebase/admin.js

@@ -157,13 +157,56 @@ export function getAdminAuth() {
     set("__mohasinac_firebase_admin_auth__", auth);
     return auth;
 }
-// --- Firestore ----------------------------------------------------------------
-export function getAdminDb() {
-    const cached = get("__mohasinac_firebase_admin_db__");
+/**
+ * `undefined` means the `(default)` database.
+ *
+ * 🛑 THE SHOP TARGET IS ENV-DRIVEN, and that is the whole point of this table.
+ *
+ * Owner, 2026-11-08: seeding and local work must not touch the live data —
+ * *"make the seeds be in the new db … and use that for local and testing while
+ * the live site still works on the original db"*.
+ *
+ * So production sets nothing and gets `(default)`; a developer or the seed CLI
+ * sets `FIREBASE_SHOP_DATABASE_ID=dev-db` in `.env.local` and every read and
+ * write in the process follows, because this is the ONE place a Firestore
+ * handle is constructed. There is no per-call database argument to forget.
+ *
+ * 🛑 `.env.local` is gitignored, so an unset variable means PRODUCTION. That is
+ * deliberate — the safe default for a deploy is the real database, and the
+ * dangerous direction (a developer silently writing to live) is the one that
+ * requires no action. Check this value before any destructive seed command;
+ * `seed-cli` prints the resolved database for exactly that reason.
+ */
+const DATABASE_IDS = {
+    shop: process.env.FIREBASE_SHOP_DATABASE_ID || undefined,
+    wiki: process.env.FIREBASE_WIKI_DATABASE_ID || "wiki-db",
+};
+/** Which database this process is actually talking to, for logs and guards. */
+export function resolvedDatabaseId(target = "shop") {
+    return DATABASE_IDS[target] ?? "(default)";
+}
+/*
+ * The global cache keys are a typed literal union, so these are spelled out
+ * rather than built with a template — a computed key would not type-check and,
+ * more usefully, a new target now has to be declared in one visible place.
+ */
+const DATABASE_CACHE_KEYS = {
+    shop: "__mohasinac_firebase_admin_db__",
+    wiki: "__mohasinac_firebase_admin_db_wiki__",
+};
+export function getAdminDb(target = "shop") {
+    const cacheKey = DATABASE_CACHE_KEYS[target];
+    const cached = get(cacheKey);
     if (cached)
         return cached;
     const { getFirestore } = loadFirestore();
-    const db = getFirestore(getAdminApp());
+    const databaseId = DATABASE_IDS[target];
+    /*
+     * The one-argument form is NOT the same as passing `undefined` explicitly in
+     * every firebase-admin version, so the default path keeps its original call
+     * shape exactly. Only a named target takes the two-argument overload.
+     */
+    const db = databaseId ? getFirestore(getAdminApp(), databaseId) : getFirestore(getAdminApp());
     try {
         // settings() can only be called once per Firestore instance — guard for
         // HMR reloads and duplicate module instances.
@@ -176,9 +219,13 @@ export function getAdminDb() {
         // fully usable either way, so there is nothing degraded to report.
         void normalizeError(_err);
     }
-    set("__mohasinac_firebase_admin_db__", db);
+    set(cacheKey, db);
     return db;
 }
+/** The read-only wiki/tools database. Never used by the money path. */
+export function getWikiDb() {
+    return getAdminDb("wiki");
+}
 // --- Cloud Storage ------------------------------------------------------------
 export function getAdminStorage() {
     const cached = get("__mohasinac_firebase_admin_storage__");

package/dist/providers/db-firebase/base.repository.d.ts

@@ -1,5 +1,5 @@
 import type { Plaintext } from "../../security/encrypted";
-import type { FirestoreDocument } from "@mohasinac/appkit";
+import type { FirestoreDocument } from "../../schemas/types";
 import type { CollectionReference, DocumentData, DocumentReference, DocumentSnapshot, Firestore, Query, Transaction, WriteBatch } from "firebase-admin/firestore";
 import { type FirebaseSieveFields, type FirebaseSieveOptions, type FirebaseSieveResult, type SieveModel } from "./sieve";
 import type { JsonValue } from "../../schemas/types";

package/dist/providers/db-firebase/filter-aliases.d.ts

@@ -1,6 +1,6 @@
 /**
- * Virtual filter aliases — a clause like `scope==publicAuctions` is expanded
- * into one or more real Sieve clauses (`status==published,listingType==auction`)
+ * Virtual filter aliases — a clause like `scope==publicCollectorDrops` is expanded
+ * into one or more real Sieve clauses (`status==published,listingType==collector-drop`)
  * before the model reaches the underlying Sieve processor.
  *
  * Pure (no firebase-admin or runtime deps) so this module is safe to import

package/dist/providers/db-firebase/rtdb-url.js

@@ -31,7 +31,7 @@ export function resolveRtdbUrl() {
     // time and NOTHING ever connected to it. Client writes were shielded only
     // because every rule is `.write: false`; server writes use the Admin SDK and
     // bypass rules entirely — so `npm run dev` wrote to PRODUCTION. A local bid
-    // overwrote the prod `auction-bids` node that live auction pages subscribe to,
+    // overwrote the prod `collector-drop-bids` node that live collector drop pages subscribe to,
     // and a local message send wrote prod `chats/**`.
     //
     // `FIREBASE_DATABASE_EMULATOR_HOST` is the standard variable the Firebase CLI

package/dist/providers/db-firebase/sieve.js

@@ -148,7 +148,7 @@ function withAliasesExpanded(model, aliases) {
  * Extracted so the count-only path and the full list path apply the SAME
  * filter pipeline — alias expansion included. Hand-building a Firestore query
  * for a "just give me the total" call would skip `expandFilterAliases`, and a
- * same-field OR group like `listingType==art|stickers` would silently vanish
+ * same-field OR group like `listingType==standard|spares` would silently vanish
  * (Root Cause #58). Never reimplement this; call it.
  */
 function buildFilteredSieveQuery(baseQuery, model, fields, merged, aliases) {
@@ -174,7 +174,7 @@ function buildFilteredSieveQuery(baseQuery, model, fields, merged, aliases) {
         // `BaseRepository.sieveQuery` delegates to, so it is what ProductRepository
         // and most other repositories actually run — only `FirebaseSieveRepository`
         // used the enhanced adapter, and nothing extends that. With the stock
-        // adapter a same-field OR group (`listingType==art|stickers`, i.e. every
+        // adapter a same-field OR group (`listingType==standard|spares`, i.e. every
         // multi-select facet in the app) became a `whereOr` call the Admin SDK does
         // not implement; `throwExceptions: false` then swallowed it and the clause
         // vanished, returning the ENTIRE collection instead of the selected subset.

package/dist/providers/payment-cashfree/easy-split.d.ts

@@ -0,0 +1,119 @@
+import type { SettlementVendorInput, SettlementVendorOutcome, SplitInstruction } from "../../contracts";
+/**
+ * The Easy Split vendor entity, naming only what is mapped.
+ *
+ * 🛑 `status` is read as an opaque string and narrowed by
+ * `mapCashfreeVendorStatus`, never exhaustively switched. The value set belongs
+ * to Cashfree and an unrecognised one must resolve to "do not split yet"
+ * rather than to a guess — see that function.
+ */
+export interface CashfreeVendorEntity {
+    vendor_id?: string;
+    status?: string;
+    /** Present on some error shapes; carried into the result message when it is. */
+    message?: string;
+}
+/** Confirmed against Cashfree's own Create Vendor API reference, 2026-11-05. */
+export declare const EASY_SPLIT_VENDORS_PATH = "/easy-split/vendors";
+/** Confirmed against Cashfree's own Create Order OpenAPI schema, 2026-11-05 — each entry `{vendor_id, amount}`. */
+export declare const ORDER_SPLITS_FIELD = "order_splits";
+/**
+ * Confirmed against Cashfree's own Easy Split FAQ, 2026-11-05: "You can
+ * split a single transaction among a maximum of 5 vendors."
+ *
+ * A multi-vendor cart in this codebase produces ONE payment across SEVERAL
+ * orders (`createPhonePeGroupOrder` is called once per seller group off a
+ * single capture), so this is the real ceiling the adapter refuses above —
+ * see `createOrderWithSplit`'s own check. Never truncates: dropping the
+ * last vendor's split would collect their share into the platform's account
+ * and look like a success: a cart needing a 6th seller settled gets a loud,
+ * buyer-visible refusal instead.
+ */
+export declare const MAX_SPLIT_VENDORS_PER_ORDER: number;
+/**
+ * Cashfree's vendor status → the contract's outcome.
+ *
+ * 🛑 FAILS CLOSED, and "closed" here means **`pending`, not `rejected`**. An
+ * unrecognised status must not become `active` (that would let a split be built
+ * against a vendor Cashfree has not approved) and must not become `rejected`
+ * either — a refusal is a statement about the seller that sends an operator to
+ * contact them, and we would be making it up. `pending` is the only honest
+ * answer to "Cashfree said something we do not recognise": the split path
+ * refuses to settle to a non-`active` vendor, so nothing is collected wrongly,
+ * and the raw value is carried in the message so a human can read it.
+ */
+export declare function mapCashfreeVendorStatus(status: string | undefined): SettlementVendorOutcome;
+/**
+ * Our vendor shape → Cashfree's.
+ *
+ * 🛑 See the block at the top of this section, point 1: every key below is
+ * ASSUMED. The mapping is written structurally so it can be checked against the
+ * docs by eye, and it is one function so correcting it is one edit.
+ *
+ * 🛑 EXACTLY ONE destination is sent. The input type already says bank and UPI
+ * are mutually exclusive; this is where it is enforced, because sending both
+ * would let Cashfree choose where real money lands.
+ *
+ * 🛑 `verify_account: true` asks Cashfree to run its OWN account verification —
+ * which is the entire reason `SellerPayoutDetails.verificationStatus` exists
+ * and the only verification in this system that is not a self-assertion. We
+ * hold no banking licence and have no penny-drop; this is the check.
+ *
+ * 🛑 `dashboard_access: false`. A vendor login would be a second place a seller
+ * can change where their money goes, outside this platform's own audit trail.
+ */
+/**
+ * The wire shape of a Cashfree vendor registration.
+ *
+ * 🛑 Declared rather than returned as `Record<string, unknown>`, which accepts
+ * ANY key and so would have made a typo'd `account_ifsc` compile — and a
+ * destination field the gateway silently ignores is a vendor registered
+ * against the wrong account. `audit-unknown-leakage` blocks the bag-of-unknown
+ * shape for exactly this reason.
+ *
+ * Still an assumption about Cashfree's API, like everything else in this file;
+ * what the type buys is that OUR side is consistent with itself.
+ */
+interface CashfreeVendorPayload {
+    vendor_id: string;
+    status: "ACTIVE";
+    name: string;
+    email: string;
+    phone: string;
+    /** Asks Cashfree to run its own account verification — see below. */
+    verify_account: true;
+    dashboard_access: false;
+    bank?: {
+        account_number: string;
+        account_holder: string;
+        ifsc: string;
+    };
+    upi?: {
+        vpa: string;
+        account_holder: string;
+    };
+    kyc_details: {
+        business_type: string;
+        pan?: string;
+        gst?: string;
+    };
+}
+export declare function cashfreeVendorPayload(input: SettlementVendorInput): CashfreeVendorPayload;
+/**
+ * Split instructions → Cashfree's `order_splits`.
+ *
+ * 🛑 DECIMAL RUPEES, like `order_amount`. Every caller passes the smallest
+ * unit; the conversion happens here, at the boundary, exactly once. A split in
+ * the wrong unit is indistinguishable from a correct one until a seller is paid
+ * 100× too much.
+ *
+ * 🛑 Refuses a zero or negative share rather than sending it. A ₹0 split is at
+ * best a no-op and at worst a 400 that fails the whole capture; either way the
+ * caller computed something it did not mean, and the correct response is to say
+ * so rather than to quietly drop a vendor from a settlement.
+ */
+export declare function toOrderSplits(splits: readonly SplitInstruction[]): Array<{
+    vendor_id: string;
+    amount: number;
+}>;
+export {};