@glomopay/react-native-sdk 4.1.0 → 5.0.0

package/lib/bridge/file-save-handler.js

@@ -0,0 +1,92 @@
+"use strict";
+/** The `file.save` bridge message, wired once and registered on every WebView that can receive it */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.createFileSaveHandler = createFileSaveHandler;
+const file_saver_1 = require("../services/file-saver");
+const file_metadata_1 = require("../utils/file-metadata");
+const analytics_1 = require("../utils/analytics");
+const validation_1 = require("../utils/validation");
+/**
+ * Correlates the request/completion pair when the page supplies no id.
+ *
+ * Module scope rather than per handler, because the same SDK session registers this on the main and
+ * flow WebViews and a per-handler counter would have both minting `sdk-1`. Saves are not serialised
+ * either - the agreements screen has three download controls, so two taps in quick succession
+ * interleave and would otherwise be indistinguishable in telemetry.
+ */
+let fallbackSaveId = 0;
+/** Prefers the page's requestId so one id spans both sides' telemetry. */
+function resolveSaveId(message) {
+    const supplied = message.requestId;
+    if (typeof supplied === "string" && supplied.length > 0) {
+        return supplied;
+    }
+    return `sdk-${++fallbackSaveId}`;
+}
+/**
+ * Builds the handler for `file.save`.
+ *
+ * Fire-and-forget by contract - the page gets no acknowledgement and must not wait for one. Once
+ * past the guard below, every outcome lands on `File Save Completed`, and a failure additionally
+ * reaches the host's onSdkError without ending the checkout.
+ *
+ * The handler itself is synchronous because the router's handlers are; the save runs detached and
+ * reports through telemetry rather than a return value, which is the same shape the contract
+ * describes on the page side.
+ */
+function createFileSaveHandler({ flowType, orderId, publicKey, checkoutUrl, mockMode, devMode, onSdkError, }) {
+    return (message) => {
+        const saveId = resolveSaveId(message);
+        const report = (result) => {
+            if (devMode) {
+                console.log(`[Glomo-RN-SDK] file.save ${saveId} completed: ${result.outcome}`);
+            }
+            (0, analytics_1.trackFileSaveCompleted)(saveId, (0, file_saver_1.toFileSaveEventData)(result), orderId, publicKey, devMode, mockMode, checkoutUrl, flowType);
+            if ((0, file_saver_1.isFileSaveFailure)(result)) {
+                (0, validation_1.safeCallback)(onSdkError, [[(0, file_saver_1.toFileSaveSdkError)(result)]], "onSdkError", devMode);
+            }
+        };
+        if (devMode) {
+            console.log(`[Glomo-RN-SDK] file.save ${saveId} requested`);
+        }
+        (0, analytics_1.trackFileSaveRequested)(saveId, orderId, publicKey, devMode, mockMode, checkoutUrl, flowType);
+        const url = message.url;
+        if (typeof url !== "string" || url.length === 0) {
+            /**
+             * Reported rather than dropped. The Flutter SDK returns here without emitting anything
+             * and relies on its error tracker to surface it; RN has none yet, so silence would make
+             * a malformed message invisible. Completing the pair keeps the "every request has an
+             * outcome" invariant that makes a missing completion mean the handler died.
+             */
+            report({
+                outcome: file_saver_1.FILE_SAVE_OUTCOMES.REJECTED,
+                fileExtension: file_metadata_1.EXTENSION_EXTRACTION_FAILED,
+                fileSize: file_metadata_1.SIZE_UNAVAILABLE,
+                failureType: "missing_url",
+            });
+            return;
+        }
+        void (0, file_saver_1.saveDocumentToDevice)({
+            url,
+            filename: typeof message.filename === "string" ? message.filename : undefined,
+            devMode,
+        })
+            .then(report)
+            .catch((error) => {
+            /**
+             * saveDocumentToDevice is documented never to throw, so this is the case where that
+             * promise is broken. It still has to close the pair - and only the failure type
+             * leaves here, never the message that produced it.
+             */
+            if (devMode) {
+                console.error("[Glomo-RN-SDK] file.save handler failed:", error);
+            }
+            report({
+                outcome: file_saver_1.FILE_SAVE_OUTCOMES.SAVE_FAILED,
+                fileExtension: file_metadata_1.EXTENSION_EXTRACTION_FAILED,
+                fileSize: file_metadata_1.SIZE_UNAVAILABLE,
+                failureType: "handler_threw",
+            });
+        });
+    };
+}

package/lib/bridge/message-router.d.ts

@@ -0,0 +1,44 @@
+/** Shared WebView message routing for every GlomoPay checkout flow */
+import { type WebViewMessageEvent } from "react-native-webview";
+/**
+ * A parsed bridge message.
+ *
+ * Deliberately loose: the page and our own injection scripts both post here, and the
+ * shapes differ per type. Handlers narrow what they need.
+ */
+export interface WebViewMessage {
+    type?: string;
+    [key: string]: unknown;
+}
+/** Handles one message type. Registered by the flow that cares about it. */
+export type WebViewMessageHandler = (message: WebViewMessage) => void;
+/** The options for createMessageRouter */
+export interface CreateMessageRouterOptions {
+    /** Log prefix of the calling flow, e.g. "[Glomo-RN-SDK LRS]" */
+    logPrefix: string;
+    /** Which WebView this router serves. Appears in logs only. */
+    source: string;
+    /**
+     * Called when the event carries no usable string payload, before the router gives up.
+     * The caller reports it, because the tracker needs flow-level context the router has no
+     * business knowing.
+     */
+    onInvalidMessage?: (data: unknown) => void;
+    /**
+     * Message type to handler. A type with no handler is ignored silently, which is what
+     * the open-coded switches did by falling through. Inherited keys are not handlers.
+     */
+    handlers: Record<string, WebViewMessageHandler>;
+    devMode?: boolean;
+}
+/**
+ * Builds the onMessage handler for a WebView.
+ *
+ * Exists because all four message handlers opened with the same twenty-five lines - guard the
+ * payload, parse it, log it, then dispatch on `message.type`. Only the dispatch differed. New
+ * message types now register in one place per flow instead of being added to each switch, which
+ * is what let `file.input` telemetry and the education carousel's invalid-message tracking go
+ * missing on some WebViews and not others.
+ */
+export declare function createMessageRouter({ logPrefix, source, onInvalidMessage, handlers, devMode, }: CreateMessageRouterOptions): (event: WebViewMessageEvent) => void;
+//# sourceMappingURL=message-router.d.ts.map

package/lib/bridge/message-router.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"message-router.d.ts","sourceRoot":"","sources":["../../src/bridge/message-router.ts"],"names":[],"mappings":"AAAA,sEAAsE;AAEtE,OAAO,EAAE,KAAK,mBAAmB,EAAE,MAAM,sBAAsB,CAAC;AAEhE;;;;;GAKG;AACH,MAAM,WAAW,cAAc;IAC3B,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC;CAC1B;AAED,4EAA4E;AAC5E,MAAM,MAAM,qBAAqB,GAAG,CAAC,OAAO,EAAE,cAAc,KAAK,IAAI,CAAC;AAEtE,0CAA0C;AAC1C,MAAM,WAAW,0BAA0B;IACvC,gEAAgE;IAChE,SAAS,EAAE,MAAM,CAAC;IAElB,8DAA8D;IAC9D,MAAM,EAAE,MAAM,CAAC;IAEf;;;;OAIG;IACH,gBAAgB,CAAC,EAAE,CAAC,IAAI,EAAE,OAAO,KAAK,IAAI,CAAC;IAE3C;;;OAGG;IACH,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,qBAAqB,CAAC,CAAC;IAEhD,OAAO,CAAC,EAAE,OAAO,CAAC;CACrB;AAED;;;;;;;;GAQG;AACH,wBAAgB,mBAAmB,CAAC,EAChC,SAAS,EACT,MAAM,EACN,gBAAgB,EAChB,QAAQ,EACR,OAAe,GAClB,EAAE,0BAA0B,IACjB,OAAO,mBAAmB,KAAG,IAAI,CAiC5C"}

package/lib/bridge/message-router.js

@@ -0,0 +1,48 @@
+"use strict";
+/** Shared WebView message routing for every GlomoPay checkout flow */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.createMessageRouter = createMessageRouter;
+/**
+ * Builds the onMessage handler for a WebView.
+ *
+ * Exists because all four message handlers opened with the same twenty-five lines - guard the
+ * payload, parse it, log it, then dispatch on `message.type`. Only the dispatch differed. New
+ * message types now register in one place per flow instead of being added to each switch, which
+ * is what let `file.input` telemetry and the education carousel's invalid-message tracking go
+ * missing on some WebViews and not others.
+ */
+function createMessageRouter({ logPrefix, source, onInvalidMessage, handlers, devMode = false, }) {
+    return (event) => {
+        var _a;
+        try {
+            const data = (_a = event.nativeEvent) === null || _a === void 0 ? void 0 : _a.data;
+            if (!data || typeof data !== "string") {
+                if (devMode) {
+                    console.warn(`${logPrefix} Invalid message data from ${source}`);
+                }
+                onInvalidMessage === null || onInvalidMessage === void 0 ? void 0 : onInvalidMessage(data);
+                return;
+            }
+            const message = JSON.parse(data);
+            if (devMode) {
+                console.log(`${logPrefix} ${source} Message received:`, message.type, message);
+            }
+            /**
+             * Own-property lookup, not a bare index. `message.type` is page-controlled, and this is
+             * now the single dispatch point for every flow - a bare index resolves `__proto__` to
+             * `Object.prototype` and throws into the catch below, and `constructor`/`toString` to
+             * real functions that then get called. The switches this replaced had neither case.
+             */
+            const type = message.type;
+            const handler = type && Object.prototype.hasOwnProperty.call(handlers, type) ? handlers[type] : undefined;
+            if (typeof handler === "function") {
+                handler(message);
+            }
+        }
+        catch (error) {
+            if (devMode) {
+                console.error(`${logPrefix} Error parsing ${source} message:`, error);
+            }
+        }
+    };
+}

package/lib/bridge/payment-payload.d.ts

@@ -0,0 +1,18 @@
+/** What the SDK says about a payment payload it could not use */
+import { type SdkError } from "../utils/analytics";
+/**
+ * The key names on a bridge payload, for telemetry.
+ *
+ * Names only. The values are payment identifiers and a signature, which is why the dropped-payload
+ * event reports the shape of what arrived rather than what it contained.
+ */
+export declare function payloadKeysOf(payload: unknown): string[];
+/**
+ * The host-facing form of a payment payload the SDK could not route.
+ *
+ * Surfaced rather than swallowed: the page reported a terminal outcome and the merchant would
+ * otherwise never learn that one happened. `generatedCheckoutUrl` is the nearest existing `field`
+ * value - this is a fault in what the checkout page sent, not in anything the merchant configured.
+ */
+export declare function droppedPayloadSdkError(event: string): SdkError;
+//# sourceMappingURL=payment-payload.d.ts.map

package/lib/bridge/payment-payload.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"payment-payload.d.ts","sourceRoot":"","sources":["../../src/bridge/payment-payload.ts"],"names":[],"mappings":"AAAA,iEAAiE;AAEjE,OAAO,EAAE,KAAK,QAAQ,EAAE,MAAM,oBAAoB,CAAC;AAEnD;;;;;GAKG;AACH,wBAAgB,aAAa,CAAC,OAAO,EAAE,OAAO,GAAG,MAAM,EAAE,CAKxD;AAED;;;;;;GAMG;AACH,wBAAgB,sBAAsB,CAAC,KAAK,EAAE,MAAM,GAAG,QAAQ,CAM9D"}

package/lib/bridge/payment-payload.js

@@ -0,0 +1,31 @@
+"use strict";
+/** What the SDK says about a payment payload it could not use */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.payloadKeysOf = payloadKeysOf;
+exports.droppedPayloadSdkError = droppedPayloadSdkError;
+/**
+ * The key names on a bridge payload, for telemetry.
+ *
+ * Names only. The values are payment identifiers and a signature, which is why the dropped-payload
+ * event reports the shape of what arrived rather than what it contained.
+ */
+function payloadKeysOf(payload) {
+    if (!payload || typeof payload !== "object") {
+        return [];
+    }
+    return Object.keys(payload);
+}
+/**
+ * The host-facing form of a payment payload the SDK could not route.
+ *
+ * Surfaced rather than swallowed: the page reported a terminal outcome and the merchant would
+ * otherwise never learn that one happened. `generatedCheckoutUrl` is the nearest existing `field`
+ * value - this is a fault in what the checkout page sent, not in anything the merchant configured.
+ */
+function droppedPayloadSdkError(event) {
+    return {
+        type: "validation_error",
+        message: `Received a ${event} event with a payload the SDK could not route. The payment outcome was not reported.`,
+        field: "generatedCheckoutUrl",
+    };
+}

package/lib/capabilities/file-save.d.ts

@@ -0,0 +1,40 @@
+/** Loads the optional dependencies that back document saving, and reports whether they are there */
+/**
+ * The picker surface this SDK uses, as a type only.
+ *
+ * `typeof import(...)` is erased at compile time, so this gives full typechecking against the real
+ * package without emitting an import that would make an optional dependency mandatory.
+ */
+type DocumentPickerModule = {
+    saveDocuments: typeof import("@react-native-documents/picker").saveDocuments;
+    errorCodes: typeof import("@react-native-documents/picker").errorCodes;
+    isErrorWithCode: typeof import("@react-native-documents/picker").isErrorWithCode;
+};
+type BlobUtilModule = import("react-native-blob-util").ReactNativeBlobUtil;
+/** Package names, so a missing one can be named in a warning and in telemetry */
+export declare const FILE_SAVE_PACKAGES: readonly ["react-native-blob-util", "@react-native-documents/picker"];
+/** What the probe found. Shared by the capability list, the start() warning and telemetry. */
+export interface FileSaveAvailability {
+    /** True only when every package loaded */
+    available: boolean;
+    /** Packages that could not be loaded, in FILE_SAVE_PACKAGES order */
+    missing: string[];
+}
+export declare function loadBlobUtil(): BlobUtilModule | null;
+export declare function loadDocumentPicker(): DocumentPickerModule | null;
+/**
+ * Whether the SDK can put a document on the device.
+ *
+ * Both packages are needed and neither substitutes for the other - blob-util streams the download
+ * to a temp file, the picker presents the system save dialog for the user to choose a destination.
+ * A build missing either one cannot complete a save, so the capability is not advertised and the
+ * checkout page keeps its own download path.
+ *
+ * Reads through the same loaders the saver calls, so the answer here and the behaviour there cannot
+ * disagree. Both resolved once at module init and returned from there - see loadBlobUtil on why that
+ * is required rather than an optimisation. Safe regardless, since a native module cannot appear
+ * mid-session.
+ */
+export declare function resolveFileSaveAvailability(): FileSaveAvailability;
+export {};
+//# sourceMappingURL=file-save.d.ts.map

package/lib/capabilities/file-save.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"file-save.d.ts","sourceRoot":"","sources":["../../src/capabilities/file-save.ts"],"names":[],"mappings":"AAAA,oGAAoG;AAEpG;;;;;GAKG;AACH,KAAK,oBAAoB,GAAG;IACxB,aAAa,EAAE,cAAc,gCAAgC,EAAE,aAAa,CAAC;IAC7E,UAAU,EAAE,cAAc,gCAAgC,EAAE,UAAU,CAAC;IACvE,eAAe,EAAE,cAAc,gCAAgC,EAAE,eAAe,CAAC;CACpF,CAAC;AAEF,KAAK,cAAc,GAAG,OAAO,wBAAwB,EAAE,mBAAmB,CAAC;AAE3E,iFAAiF;AACjF,eAAO,MAAM,kBAAkB,uEAAwE,CAAC;AAExG,8FAA8F;AAC9F,MAAM,WAAW,oBAAoB;IACjC,0CAA0C;IAC1C,SAAS,EAAE,OAAO,CAAC;IAEnB,qEAAqE;IACrE,OAAO,EAAE,MAAM,EAAE,CAAC;CACrB;AAwDD,wBAAgB,YAAY,IAAI,cAAc,GAAG,IAAI,CAEpD;AAWD,wBAAgB,kBAAkB,IAAI,oBAAoB,GAAG,IAAI,CAEhE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,2BAA2B,IAAI,oBAAoB,CAWlE"}

package/lib/capabilities/file-save.js

@@ -0,0 +1,101 @@
+"use strict";
+/** Loads the optional dependencies that back document saving, and reports whether they are there */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FILE_SAVE_PACKAGES = void 0;
+exports.loadBlobUtil = loadBlobUtil;
+exports.loadDocumentPicker = loadDocumentPicker;
+exports.resolveFileSaveAvailability = resolveFileSaveAvailability;
+/** Package names, so a missing one can be named in a warning and in telemetry */
+exports.FILE_SAVE_PACKAGES = ["react-native-blob-util", "@react-native-documents/picker"];
+/**
+ * Metro's interop puts an ES default export on `.default`; the picker uses named exports.
+ *
+ * Widened rather than narrowed because these two packages are loaded through the same seam and
+ * disagree on export style.
+ */
+function unwrap(loaded) {
+    var _a, _b;
+    const module = loaded;
+    return (_b = (_a = module === null || module === void 0 ? void 0 : module.default) !== null && _a !== void 0 ? _a : module) !== null && _b !== void 0 ? _b : null;
+}
+/**
+ * Streams a document to disk. Null when the package is absent or its native module is not linked.
+ *
+ * Metro requires a string literal here, and requires the call to sit directly inside a `try` block.
+ *
+ * Both halves are load-bearing and neither is obvious:
+ *
+ * - A `require()` whose argument Metro cannot evaluate statically is rejected at bundle time in
+ *   project code, and compiled to a runtime throw inside `node_modules` - which is where this file
+ *   lives in a merchant app. So a loop over FILE_SAVE_PACKAGES calling `require(name)` would not
+ *   fail loudly; it would report every package missing in every merchant build and silently
+ *   withdraw the capability.
+ * - Metro only tolerates an unresolvable literal when the call is lexically inside a `try` block
+ *   (`collectDependencies.isOptionalDependency`), and only when `allowOptionalDependencies` is on.
+ *   `@react-native/metro-config` sets it, which is what makes the optional-peer-dependency pattern
+ *   work at all - the same mechanism the existing `jail-monkey` require in utils/device-compliance
+ *   already depends on.
+ *
+ * - The require must run while this module is still initialising, which is why it sits in an IIFE
+ *   at module scope rather than inside the exported function. Metro's `guardedLoadModule` reports a
+ *   failed module load through `ErrorUtils.reportFatalError` and then swallows it, but only when it
+ *   is not already loading something (`inGuard`). A lazy first `require` - from a hook, a render, or
+ *   anything after startup - is outside that guard, so an absent package is reported as a *fatal*
+ *   error and raises a full-screen LogBox in every dev build, even though our `catch` here means the
+ *   capability degrades correctly and nothing actually breaks. Resolving at module init keeps the
+ *   throw inside the guard, where it propagates to our `catch` silently.
+ *
+ * The consequence for structure: these two loaders cannot be collapsed into one parameterised
+ * helper, the `try` cannot be hoisted into a caller, and the resolution cannot be made lazy.
+ *
+ * Deliberately treats "not installed" and "installed but will not load" alike. Both packages ship
+ * native modules, so a merchant who installs them without rebuilding the app has them present in
+ * node_modules and still unusable - and either way the SDK cannot save a file. The distinction
+ * matters only to the warning text, which names both causes rather than guessing between them.
+ */
+const blobUtilModule = (() => {
+    try {
+        return unwrap(require("react-native-blob-util"));
+    }
+    catch (_a) {
+        return null;
+    }
+})();
+function loadBlobUtil() {
+    return blobUtilModule;
+}
+/** Presents the system save dialog. Null, and shaped, on the same terms as loadBlobUtil above. */
+const documentPickerModule = (() => {
+    try {
+        return unwrap(require("@react-native-documents/picker"));
+    }
+    catch (_a) {
+        return null;
+    }
+})();
+function loadDocumentPicker() {
+    return documentPickerModule;
+}
+/**
+ * Whether the SDK can put a document on the device.
+ *
+ * Both packages are needed and neither substitutes for the other - blob-util streams the download
+ * to a temp file, the picker presents the system save dialog for the user to choose a destination.
+ * A build missing either one cannot complete a save, so the capability is not advertised and the
+ * checkout page keeps its own download path.
+ *
+ * Reads through the same loaders the saver calls, so the answer here and the behaviour there cannot
+ * disagree. Both resolved once at module init and returned from there - see loadBlobUtil on why that
+ * is required rather than an optimisation. Safe regardless, since a native module cannot appear
+ * mid-session.
+ */
+function resolveFileSaveAvailability() {
+    const missing = [];
+    if (!loadBlobUtil()) {
+        missing.push(exports.FILE_SAVE_PACKAGES[0]);
+    }
+    if (!loadDocumentPicker()) {
+        missing.push(exports.FILE_SAVE_PACKAGES[1]);
+    }
+    return { available: missing.length === 0, missing };
+}

package/lib/capabilities/index.d.ts

@@ -0,0 +1,22 @@
+/** What this SDK build can do, resolved at runtime */
+/**
+ * Capability strings the checkout page gates on.
+ *
+ * The page reads these from `window.__glomoSdkCapabilities__` at the moment it needs one, and
+ * falls back to its own behaviour when a string is absent. It deliberately does not infer support
+ * from the bridge existing - every Glomo SDK has a bridge, so a build without the handler would
+ * take delivery of the message into a router that ignores it, and the user's tap would vanish.
+ */
+export declare const CAPABILITIES: {
+    readonly FILE_SAVE: "file.save";
+};
+/**
+ * The capabilities this build can honour.
+ *
+ * Append only, and only when the handler actually exists in this build - removing a string
+ * silently reverts the page to its own path, which is the correct degradation but a confusing
+ * one to debug if it happens by accident.
+ */
+export declare function resolveCapabilities(): string[];
+export { resolveFileSaveAvailability, FILE_SAVE_PACKAGES, type FileSaveAvailability } from "./file-save";
+//# sourceMappingURL=index.d.ts.map

package/lib/capabilities/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/capabilities/index.ts"],"names":[],"mappings":"AAAA,sDAAsD;AAItD;;;;;;;GAOG;AACH,eAAO,MAAM,YAAY;;CAEf,CAAC;AAEX;;;;;;GAMG;AACH,wBAAgB,mBAAmB,IAAI,MAAM,EAAE,CAQ9C;AAED,OAAO,EAAE,2BAA2B,EAAE,kBAAkB,EAAE,KAAK,oBAAoB,EAAE,MAAM,aAAa,CAAC"}

package/lib/capabilities/index.js

@@ -0,0 +1,34 @@
+"use strict";
+/** What this SDK build can do, resolved at runtime */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FILE_SAVE_PACKAGES = exports.resolveFileSaveAvailability = exports.CAPABILITIES = void 0;
+exports.resolveCapabilities = resolveCapabilities;
+const file_save_1 = require("./file-save");
+/**
+ * Capability strings the checkout page gates on.
+ *
+ * The page reads these from `window.__glomoSdkCapabilities__` at the moment it needs one, and
+ * falls back to its own behaviour when a string is absent. It deliberately does not infer support
+ * from the bridge existing - every Glomo SDK has a bridge, so a build without the handler would
+ * take delivery of the message into a router that ignores it, and the user's tap would vanish.
+ */
+exports.CAPABILITIES = {
+    FILE_SAVE: "file.save",
+};
+/**
+ * The capabilities this build can honour.
+ *
+ * Append only, and only when the handler actually exists in this build - removing a string
+ * silently reverts the page to its own path, which is the correct degradation but a confusing
+ * one to debug if it happens by accident.
+ */
+function resolveCapabilities() {
+    const capabilities = [];
+    if ((0, file_save_1.resolveFileSaveAvailability)().available) {
+        capabilities.push(exports.CAPABILITIES.FILE_SAVE);
+    }
+    return capabilities;
+}
+var file_save_2 = require("./file-save");
+Object.defineProperty(exports, "resolveFileSaveAvailability", { enumerable: true, get: function () { return file_save_2.resolveFileSaveAvailability; } });
+Object.defineProperty(exports, "FILE_SAVE_PACKAGES", { enumerable: true, get: function () { return file_save_2.FILE_SAVE_PACKAGES; } });

package/lib/capabilities/use-capability-reporting.d.ts

@@ -0,0 +1,24 @@
+/** Tells the host, once per mount, about capabilities this build cannot offer */
+import { type SdkError } from "../utils/analytics";
+/** The options for useCapabilityReporting */
+export interface UseCapabilityReportingOptions {
+    onSdkError: (errors: Array<SdkError>) => void;
+    devMode?: boolean;
+}
+/**
+ * Reports missing optional dependencies to the host on mount.
+ *
+ * Paired with the ungated `console.warn` in `start()`, and deliberately not merged with it: the
+ * warning reaches a developer watching a console, this reaches a merchant's error handling, and a
+ * merchant who has wired up logging should not have to read logs to discover that a feature they
+ * were told exists is inert in their build.
+ *
+ * Not an error the SDK raises about itself - the checkout still works, and the page falls back to
+ * its own download path. `field` is set so it can be filtered apart from a configuration fault on
+ * the same callback.
+ *
+ * Fires once per mounted component rather than once per process, and never on a build where the
+ * dependencies are present.
+ */
+export declare function useCapabilityReporting({ onSdkError, devMode }: UseCapabilityReportingOptions): void;
+//# sourceMappingURL=use-capability-reporting.d.ts.map

package/lib/capabilities/use-capability-reporting.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"use-capability-reporting.d.ts","sourceRoot":"","sources":["../../src/capabilities/use-capability-reporting.ts"],"names":[],"mappings":"AAAA,iFAAiF;AAMjF,OAAO,EAAE,KAAK,QAAQ,EAAE,MAAM,oBAAoB,CAAC;AAEnD,6CAA6C;AAC7C,MAAM,WAAW,6BAA6B;IAC1C,UAAU,EAAE,CAAC,MAAM,EAAE,KAAK,CAAC,QAAQ,CAAC,KAAK,IAAI,CAAC;IAC9C,OAAO,CAAC,EAAE,OAAO,CAAC;CACrB;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,sBAAsB,CAAC,EAAE,UAAU,EAAE,OAAe,EAAE,EAAE,6BAA6B,GAAG,IAAI,CAyB3G"}

package/lib/capabilities/use-capability-reporting.js

@@ -0,0 +1,44 @@
+"use strict";
+/** Tells the host, once per mount, about capabilities this build cannot offer */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.useCapabilityReporting = useCapabilityReporting;
+const react_1 = require("react");
+const file_save_1 = require("./file-save");
+const validation_1 = require("../utils/validation");
+/**
+ * Reports missing optional dependencies to the host on mount.
+ *
+ * Paired with the ungated `console.warn` in `start()`, and deliberately not merged with it: the
+ * warning reaches a developer watching a console, this reaches a merchant's error handling, and a
+ * merchant who has wired up logging should not have to read logs to discover that a feature they
+ * were told exists is inert in their build.
+ *
+ * Not an error the SDK raises about itself - the checkout still works, and the page falls back to
+ * its own download path. `field` is set so it can be filtered apart from a configuration fault on
+ * the same callback.
+ *
+ * Fires once per mounted component rather than once per process, and never on a build where the
+ * dependencies are present.
+ */
+function useCapabilityReporting({ onSdkError, devMode = false }) {
+    const reportedRef = (0, react_1.useRef)(false);
+    (0, react_1.useEffect)(() => {
+        if (reportedRef.current) {
+            return;
+        }
+        reportedRef.current = true;
+        const fileSave = (0, file_save_1.resolveFileSaveAvailability)();
+        if (fileSave.available) {
+            return;
+        }
+        const errors = [
+            {
+                type: "validation_error",
+                message: `Document downloads are unavailable: ${fileSave.missing.join(" and ")} could not be loaded. ` +
+                    "Install the package(s) and rebuild the app to enable them.",
+                field: "file.save",
+            },
+        ];
+        (0, validation_1.safeCallback)(onSdkError, [errors], "onSdkError", devMode);
+    }, [onSdkError, devMode]);
+}

package/lib/config/base.d.ts

@@ -19,6 +19,18 @@ export interface GlomoServerConfig {
 }
 export declare const DEFAULT_SERVER: InternalGlomoServer;
 export declare const SERVER_CONFIGS: Record<InternalGlomoServer, GlomoServerConfig>;
+/**
+ * Identifies this SDK to the checkout page, which forwards both onto the order it creates.
+ *
+ * Exists because nothing in `payments`, `payment_sessions`, `terminals` or `api_audits` carries a
+ * surface dimension, so an SDK-originated order is indistinguishable from a dashboard one
+ * (KAN-6551). The Flutter SDK sends the analogous pair (`checkout-flutter-sdk` / `flutter`).
+ *
+ * Inert until the checkout page is redeployed to read them - neither `apps/checkout` nor
+ * `lrs-checkout-page` allow-lists query params, so unknown ones are ignored rather than rejected.
+ */
+export declare const ANALYTICS_PRODUCT = "checkout-react-native-sdk";
+export declare const ANALYTICS_SURFACE = "react_native";
 /** Returns the full server config for the given environment, falling back to prod */
 export declare function resolveServerConfig(server?: InternalGlomoServer): GlomoServerConfig;
 export {};

package/lib/config/base.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../src/config/base.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,yEAAyE;AACzE,MAAM,MAAM,WAAW,GAAG,MAAM,GAAG,SAAS,CAAC;AAE7C,8EAA8E;AAC9E,KAAK,mBAAmB,GAAG,WAAW,GAAG,OAAO,CAAC;AAEjD,+CAA+C;AAC/C,MAAM,WAAW,mBAAmB;IAChC,WAAW,EAAE,MAAM,CAAC;IACpB,gBAAgB,EAAE,MAAM,CAAC;IACzB,oBAAoB,EAAE,MAAM,CAAC;IAC7B,GAAG,EAAE,MAAM,CAAC;CACf;AAED,0CAA0C;AAC1C,MAAM,WAAW,iBAAiB;IAC9B,OAAO,EAAE,mBAAmB,CAAC;CAChC;AAED,eAAO,MAAM,cAAc,EAAE,mBAA4B,CAAC;AAE1D,eAAO,MAAM,cAAc,EAAE,MAAM,CAAC,mBAAmB,EAAE,iBAAiB,CAyBzE,CAAC;AAEF,qFAAqF;AACrF,wBAAgB,mBAAmB,CAAC,MAAM,CAAC,EAAE,mBAAmB,GAAG,iBAAiB,CAInF"}
+{"version":3,"file":"base.d.ts","sourceRoot":"","sources":["../../src/config/base.ts"],"names":[],"mappings":"AAAA;;;GAGG;AAEH,yEAAyE;AACzE,MAAM,MAAM,WAAW,GAAG,MAAM,GAAG,SAAS,CAAC;AAE7C,8EAA8E;AAC9E,KAAK,mBAAmB,GAAG,WAAW,GAAG,OAAO,CAAC;AAEjD,+CAA+C;AAC/C,MAAM,WAAW,mBAAmB;IAChC,WAAW,EAAE,MAAM,CAAC;IACpB,gBAAgB,EAAE,MAAM,CAAC;IACzB,oBAAoB,EAAE,MAAM,CAAC;IAC7B,GAAG,EAAE,MAAM,CAAC;CACf;AAED,0CAA0C;AAC1C,MAAM,WAAW,iBAAiB;IAC9B,OAAO,EAAE,mBAAmB,CAAC;CAChC;AAED,eAAO,MAAM,cAAc,EAAE,mBAA4B,CAAC;AAE1D,eAAO,MAAM,cAAc,EAAE,MAAM,CAAC,mBAAmB,EAAE,iBAAiB,CAyBzE,CAAC;AAEF;;;;;;;;;GASG;AACH,eAAO,MAAM,iBAAiB,8BAA8B,CAAC;AAC7D,eAAO,MAAM,iBAAiB,iBAAiB,CAAC;AAEhD,qFAAqF;AACrF,wBAAgB,mBAAmB,CAAC,MAAM,CAAC,EAAE,mBAAmB,GAAG,iBAAiB,CAInF"}

package/lib/config/base.js

@@ -4,7 +4,7 @@
  * This file contains the default base configuration variables for the GlomoPay RN SDK.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.SERVER_CONFIGS = exports.DEFAULT_SERVER = void 0;
+exports.ANALYTICS_SURFACE = exports.ANALYTICS_PRODUCT = exports.SERVER_CONFIGS = exports.DEFAULT_SERVER = void 0;
 exports.resolveServerConfig = resolveServerConfig;
 exports.DEFAULT_SERVER = "prod";
 exports.SERVER_CONFIGS = {
@@ -33,6 +33,18 @@ exports.SERVER_CONFIGS = {
         },
     },
 };
+/**
+ * Identifies this SDK to the checkout page, which forwards both onto the order it creates.
+ *
+ * Exists because nothing in `payments`, `payment_sessions`, `terminals` or `api_audits` carries a
+ * surface dimension, so an SDK-originated order is indistinguishable from a dashboard one
+ * (KAN-6551). The Flutter SDK sends the analogous pair (`checkout-flutter-sdk` / `flutter`).
+ *
+ * Inert until the checkout page is redeployed to read them - neither `apps/checkout` nor
+ * `lrs-checkout-page` allow-lists query params, so unknown ones are ignored rather than rejected.
+ */
+exports.ANALYTICS_PRODUCT = "checkout-react-native-sdk";
+exports.ANALYTICS_SURFACE = "react_native";
 /** Returns the full server config for the given environment, falling back to prod */
 function resolveServerConfig(server) {
     const resolvedServer = server && server in exports.SERVER_CONFIGS ? server : exports.DEFAULT_SERVER;

package/lib/glomo-checkout.d.ts

@@ -1,7 +1,12 @@
 /**
- * The unified GlomoPay Checkout Component (v4).
+ * The unified GlomoPay Checkout Component.
  * Detects order type (LRS vs Standard) and delegates rendering to the appropriate inner component.
  * Enforces error handling via `onSdkError()` as a mandatory prop.
+ *
+ * Its props are a union over both flows, so a prop that only one flow uses is still accepted here.
+ * `onUserJourneyCompleted` is the one case where that matters: it is forwarded to the standard and
+ * subscriptions flows and silently ignored on LRS orders, because LRS never produces an
+ * asynchronous journey for it to report. Every other callback reaches every flow.
  */
 import React from "react";
 import { type GlomoCheckoutRef, type GlomoCheckoutProps } from "./types/checkout";

package/lib/glomo-checkout.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"glomo-checkout.d.ts","sourceRoot":"","sources":["../src/glomo-checkout.tsx"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,OAAO,KAAsE,MAAM,OAAO,CAAC;AAG3F,OAAO,EAAE,KAAK,gBAAgB,EAAE,KAAK,kBAAkB,EAAmC,MAAM,kBAAkB,CAAC;AA6HnH;;GAEG;AACH,eAAO,MAAM,aAAa,EAAyC,KAAK,CAAC,yBAAyB,CAC9F,kBAAkB,GAAG,KAAK,CAAC,aAAa,CAAC,gBAAgB,CAAC,CAC7D,CAAC"}
+{"version":3,"file":"glomo-checkout.d.ts","sourceRoot":"","sources":["../src/glomo-checkout.tsx"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAsE,MAAM,OAAO,CAAC;AAG3F,OAAO,EAAE,KAAK,gBAAgB,EAAE,KAAK,kBAAkB,EAAmC,MAAM,kBAAkB,CAAC;AA4HnH;;GAEG;AACH,eAAO,MAAM,aAAa,EAAyC,KAAK,CAAC,yBAAyB,CAC9F,kBAAkB,GAAG,KAAK,CAAC,aAAa,CAAC,gBAAgB,CAAC,CAC7D,CAAC"}