import { type CheckoutChallenge, type CheckoutPageDriver } from './checkout-page.js';
/**
 * The part of a card-material guard this adapter can see.
 *
 * Both `CardMaterialRedactor` (payments) and `CardFieldGuard` (browser) satisfy
 * it, which is the point: the identity check compares two references the two
 * layers each describe in their own terms.
 */
export interface CheckoutGuardHandle {
    hasLiveMaterial(sessionId: string, pageId: string): boolean;
}
/** Which session and page an engine operation acts on. */
export interface CheckoutEngineTarget {
    readonly sessionId?: string | undefined;
    readonly pageId?: string | undefined;
}
/**
 * The engine operations a purchase needs, described structurally so that
 * `BrowserEngine` satisfies this without either module importing the other.
 *
 * Every one of them answers with the engine's open record. This adapter reads
 * only `url`/`filled`/`failedRef` out of those records and never forwards a
 * whole one, so nothing a page wrote reaches the checkout flow through here.
 *
 * Every member is written in PROPERTY position (`foo: (args) => Ret`), not
 * method-shorthand (`foo(args): Ret`). TypeScript checks method-shorthand
 * parameters bivariantly even under `strictFunctionTypes`, so a real engine
 * method whose parameter type quietly narrowed or widened would still satisfy
 * this interface with no compile error. Property position is checked
 * contravariantly, which is what makes a real signature drift here a build
 * failure instead of a silent one.
 */
export interface CheckoutBrowserEngine {
    cardFieldGuard: () => CheckoutGuardHandle | null;
    tabs: (target: CheckoutEngineTarget) => Promise<Record<string, unknown>>;
    type: (target: CheckoutEngineTarget, args: {
        readonly ref: string;
        readonly text: string;
    }) => Promise<Record<string, unknown>>;
    fillSecretBatch: (target: CheckoutEngineTarget, args: {
        readonly fills: readonly {
            readonly ref: string;
            readonly value: string;
        }[];
    }) => Promise<Record<string, unknown>>;
    select: (target: CheckoutEngineTarget, args: {
        readonly ref: string;
        readonly values: readonly string[];
    }) => Promise<Record<string, unknown>>;
    click: (target: CheckoutEngineTarget, args: {
        readonly ref: string;
    }) => Promise<Record<string, unknown>>;
}
/** What the driver landed on after the one outward act, before it is described. */
export interface CheckoutSubmission {
    readonly url: string;
    readonly navigated: boolean;
}
/**
 * A merchant-order reading, when the composition has one.
 *
 * `verified` on the submission this produces is evidence-based: it is true
 * only when this description carries something the composition actually
 * looked at and found, an order id, a challenge, or `confirmed: true`. A
 * composition that ran and saw nothing, a declined card, a spinner, a page it
 * did not recognise, returns all three empty/false/null, and the submission is
 * `verified: false` exactly as if `describeSubmission` had never been wired.
 * Being CALLED is not evidence; what it returns is.
 */
export interface CheckoutSubmissionDescription {
    readonly orderId: string | null;
    readonly challenge: CheckoutChallenge | null;
    /**
     * Set when the composition positively confirmed the order without a
     * merchant order number to point to, a "thank you" / order-confirmed marker
     * it recognised on the landing page. Absent or false is not evidence of
     * anything, it is simply the common case where nothing more specific was
     * found.
     */
    readonly confirmed?: boolean | undefined;
}
export interface BrowserCheckoutDriverDeps {
    /**
     * The engine, resolved on first use.
     *
     * A function rather than an instance because the daemon builds its browser
     * lazily: registering the verbs must not download a driver or start a
     * process, so the driver factory has to exist before the engine does.
     */
    readonly engineFor: () => Promise<CheckoutBrowserEngine>;
    /**
     * The guard the payments service arms. Must be the same object the engine was
     * constructed with; see the two checks in this module's header.
     */
    readonly cardFieldGuard: CheckoutGuardHandle;
    /** Reads a merchant order id or a verification step off the landing page. */
    readonly describeSubmission?: ((submission: CheckoutSubmission) => Promise<CheckoutSubmissionDescription>) | undefined;
}
/**
 * A refusal from the driver itself, as opposed to a page that would not accept
 * input.
 *
 * Carries no card material: every message below names a field, a page or a
 * missing guard, and never a value. The `fix` is what the operator has to
 * change in the composition, because every one of these is a wiring fault
 * rather than something a retry would clear.
 */
export declare class CheckoutDriverRefusal extends Error {
    readonly fix: string;
    constructor(message: string, fix: string);
}
/**
 * The factory `PaymentsServiceDeps.driverFor` wants.
 *
 * Synchronous, because the payments service resolves a driver per verb call and
 * the engine behind it may not exist yet. Nothing is opened until the first page
 * operation runs.
 */
export declare function createBrowserCheckoutDriverFactory(deps: BrowserCheckoutDriverDeps): (sessionId: string, pageId: string) => CheckoutPageDriver;
//# sourceMappingURL=browser-checkout-driver.d.ts.map