import type { UntrustedContentPort } from '../../browser/index.js';
import { CardMaterialRedactor } from '../../payments/card-redaction.js';
import type { CheckoutSubmission, CheckoutSubmissionDescription } from '../../payments/browser-checkout-driver.js';
import type { CheckoutPageDriver } from '../../payments/checkout-page.js';
import type { OwnerApproval } from '../../browser/index.js';
import type { BrowserGatewayService } from './browser.js';
/** The slice of the verb-group deps this composition needs. */
export interface BrowserCompositionDeps {
    /** Absent in narrow compositions; the browser needs a real storage root. */
    readonly homeDirectory?: string | undefined;
    /** Test seam: overrides the whole service, so no driver or process is touched. */
    readonly browserGateway?: DaemonBrowserGatewayService | undefined;
    /**
     * Test seam: the untrusted-content port the engine records into. Absent,
     * the daemon's own case, the port is bound to the process-wide ledger the
     * mail verbs also write to.
     */
    readonly browserUntrusted?: UntrustedContentPort | undefined;
    /**
     * Receives the checkout seam, once, at composition time.
     *
     * Present: the engine is built WITH a card-material guard this function mints,
     * and the same object is handed back alongside a page-driver factory over that
     * same engine. That is the whole reason the callback exists rather than a
     * `cardFieldGuard` input. A consumer cannot supply a guard, so it cannot supply
     * a different one than the engine holds; the only object that works is the one
     * it is given, and the driver refuses if the payments service ever arms
     * another (see payments/browser-checkout-driver.ts).
     *
     * Absent: no guard is minted and the engine is exactly what it was before,
     * which is what every browser-only composition should get. A browser used for
     * ordinary automation needs no card redaction, and building one with a guard
     * nothing arms would only make `cardFieldGuardInstalled()` lie.
     */
    readonly onBrowserCheckout?: ((seam: BrowserCheckoutSeam) => void) | undefined;
    /**
     * Reads a merchant order id or a verification step off a submitted
     * checkout's landing page.
     *
     * Absent by default, which is honest: reading a merchant's own confirmation
     * page is site-specific knowledge this SDK does not carry. Without it, a
     * submitted purchase is recorded and reported as unverified rather than as
     * an indistinguishable-from-confirmed "purchased", see checkout-flow.ts and
     * browser-checkout-driver.ts's header for what that changes.
     */
    readonly describeSubmission?: ((submission: CheckoutSubmission) => Promise<CheckoutSubmissionDescription>) | undefined;
}
/** The gateway slice plus the teardown the daemon's disposal scope runs. */
export interface DaemonBrowserGatewayService extends BrowserGatewayService {
    /**
     * Closes browsers this daemon launched. Attached browsers are untouched,
     * the session registry's shutdown only ends what it started.
     */
    shutdown(): Promise<void>;
}
/**
 * The two halves a checkout needs, minted together so they cannot come apart.
 *
 * `cardFieldGuard` is what `PaymentsGatewayServiceImpl` must be constructed
 * with, and `driverFor` is what its `driverFor` dependency must be. Both are
 * bound to ONE engine, which is the engine the `browser.*` verbs also drive, so
 * a page the model snapshotted is the page the purchase runs on.
 */
export interface BrowserCheckoutSeam {
    /** Hand this to `PaymentsServiceDeps.cardFieldGuard`, unchanged. */
    readonly cardFieldGuard: CardMaterialRedactor;
    /** Hand this to `PaymentsServiceDeps.driverFor`, unchanged. */
    driverFor(sessionId: string, pageId: string): CheckoutPageDriver;
    /**
     * Arms the owner's approval for ONE outward submit, directly on the engine
     * this seam's driver runs against.
     *
     * Composition-only, and deliberately so: this seam is handed to whoever
     * composes the daemon's browser, never to anything in `platform/payments/`,
     * so payments code has no path that could mint its own approval and spend
     * against it. See browser-checkout-driver.ts's header for when the
     * untrusted-effect guard actually needs one, most invocations clear it a
     * different way (the turn-boundary reset), and this exists as the honest
     * fallback for when they do not.
     */
    armSubmitApproval(approval: OwnerApproval | null): Promise<void>;
}
/**
 * Compose the daemon browser, and the checkout seam when one was asked for.
 *
 * This is the entry `registerGatewayVerbGroups` calls.
 * `createDaemonBrowserGatewayService` remains the browser-only entry and is
 * unchanged in signature and in behavior; a caller that passes no
 * `onBrowserCheckout` gets exactly the engine it got before.
 */
export declare function composeDaemonBrowser(deps: BrowserCompositionDeps): DaemonBrowserGatewayService | null;
/**
 * The name every pre-existing caller uses. One implementation, so a caller that
 * DID pass `onBrowserCheckout` here cannot silently get a browser with no seam.
 */
export declare function createDaemonBrowserGatewayService(deps: BrowserCompositionDeps): DaemonBrowserGatewayService | null;
//# sourceMappingURL=browser-composition.d.ts.map