/**
 * RazorpayMagicCheckoutAdapter — emits `checkout_completed` for merchants on
 * Razorpay Magic Checkout, where Shopify's native checkout flow is bypassed.
 *
 * **Why this exists.** The Shopify Web Pixel (PR #1998) only fires inside
 * Shopify's checkout sandbox. Razorpay Magic Checkout replaces that flow
 * entirely — the order is created by Razorpay's server via the Shopify Order
 * API after a Razorpay-hosted payment, and the Shopify Web Pixel's
 * `checkout_completed` event is never emitted. Without an alternative
 * attribution path, every Magic Checkout merchant has cart-side data and a
 * post-cart blackhole.
 *
 * **What this does — two complementary detection paths:**
 *
 * 1. **Constructor wrap.** Wraps `window.Razorpay` so every `new Razorpay(opts)`
 *    call has `opts.handler` intercepted. When Razorpay invokes the handler on
 *    payment success (the documented public completion API — see
 *    https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/build-integration/),
 *    we emit `checkout_completed` then forward to the merchant's handler
 *    unchanged.
 *
 * 2. **URL watcher.** Razorpay Magic Checkout also signals completion by
 *    redirecting the parent window to `/cart?__rzp_checkout_complete=1&__rzp_response=<urlencoded JSON>`
 *    (full prepaid flow) or `/cart?magic_order_id=<id>` (COD / pending order).
 *    The merchant's continuation script typically strips these query params
 *    within milliseconds via `history.replaceState`, but the post-redirect
 *    page reload runs our SDK init *before* the strip in practice (verified on
 *    neinative.com PostHog data 2026-05-11 capture). We read `location.search`
 *    at install time and emit if a completion param is present; we also
 *    listen for `popstate` to catch back-button revisits.
 *
 * **Why both?** Real-world telemetry from neinative.com over 30 days showed
 * 0 successful handler-callback emits and only 1 captured redirect URL,
 * suggesting `options.handler` may not fire reliably across all Magic
 * Checkout configurations. The redirect is the universal completion signal
 * — even Razorpay's own continuation flow (`id(t,e)` in `magic-shopify.js`)
 * goes through it. Belt and suspenders: handler wrap catches the in-page
 * path before redirect, URL watcher catches the post-redirect page load.
 * Both dedupe through the same `emittedIds` set keyed by payment_id or
 * order_id so we never double-emit the same payment.
 *
 * **Why not postMessage?** An earlier implementation listened for
 * `{event: 'payment.success'}` postMessages from `*.razorpay.com` origins —
 * that wire shape was mocked in unit tests but Razorpay never actually
 * emits it (verified by grepping `magic-checkout.js` and `magic-shopify.js`).
 * Dropped in favor of the documented public APIs above.
 *
 * **Identity.** No special handling required — the SDK runs in the storefront
 * parent window with PostHog already initialized under the user's
 * `distinct_id`. PostHog auto-attaches identity.
 *
 * **Safety.**
 * - Constructor wrap copies own-property descriptors; static methods like
 *   `triggerShopifyCheckoutBtnClickEvent` continue to work for Magic Checkout's
 *   own glue code.
 * - Merchant options are shallow-cloned before we replace `handler` — caller's
 *   reference is never mutated.
 * - Merchant's original `handler` is still invoked, even if our adapter emit
 *   throws. Wrapped in try/catch so merchant exceptions never break our emit.
 * - Dedupe by `razorpay_payment_id` — Razorpay can invoke the handler more
 *   than once on retry; we only emit once per payment.
 * - All error paths warn via `console.warn`; never throw into the host page.
 * - SSR-safe (`typeof window !== 'undefined'` guard).
 * - No-op when telemetry is null (consent gating).
 * - Idempotent install.
 */
import type { TelemetryClient } from '../telemetry/types';
interface RazorpayAdapterOptions {
    telemetry: TelemetryClient | null;
}
export declare class RazorpayMagicCheckoutAdapter {
    private readonly telemetry;
    private readonly capturedSearch;
    private installed;
    private destroyed;
    private urlWatcherInstalled;
    private originalRazorpay;
    private wrappedRazorpay;
    private emittedIds;
    private deferredTeardown;
    private popstateListener;
    constructor(options: RazorpayAdapterOptions);
    /** Synchronously detect whether Razorpay Magic Checkout is loaded on the page. */
    detect(): boolean;
    /** Install constructor wrap + URL watcher. Idempotent; no-op if telemetry is null. */
    install(): void;
    /** Remove the wrap, restore window.Razorpay, detach the URL watcher. */
    destroy(): void;
    private installConstructorWrap;
    /**
     * SDK loads before Razorpay on Shopify storefronts (async vs defer).
     * Trap `window.Razorpay` assignment so we install the moment it appears.
     */
    private installDeferredDetection;
    private handlePaymentSuccess;
    /**
     * Watch for Razorpay's post-payment redirect URL. The merchant's
     * continuation script strips these params within milliseconds via
     * `history.replaceState`, but the module-load snapshot in
     * `EARLY_LOCATION_SEARCH` captures the URL before any user code runs.
     * `install()` also listens for `popstate` to catch back-button revisits.
     *
     * Idempotent: safe to call multiple times (deferred-detection state can
     * cause repeated `install()` invocations).
     */
    private installUrlWatcher;
    private checkCompletionUrl;
}
export {};
