/** A method's key on the configuration object, e.g. `card`, `link`, `apple_pay`. */
type MethodKey = string;
export interface PaymentMethodConfigOptions {
    /**
     * Stable name, and the idempotency key: an existing ACTIVE configuration with
     * this name is reused rather than a second one created.
     */
    name: string;
    /**
     * Force these off; every other method follows the account's default
     * configuration. Use this to remove one method without listing all the others,
     * so a method enabled in the Dashboard later still reaches checkout.
     */
    disable?: readonly MethodKey[];
    /**
     * Force these ON, on top of the account's defaults. For a method that must be
     * available whether or not someone remembered to tick it in the Dashboard —
     * the wallets, typically, which cost the customer a tap and cost the account
     * nothing.
     */
    enable?: readonly MethodKey[];
    /**
     * Only these on, everything else off. Wins over `enable` and `disable`. Use it
     * for a form that must offer exactly one kind of thing — saving a card for
     * later, say, where offering Klarna would be nonsense.
     */
    only?: readonly MethodKey[];
}
/**
 * Create (or reuse) a payment-method configuration and return its id.
 *
 * Idempotent by `name`. Pass the result as `payment_method_configuration` on a
 * SetupIntent, PaymentIntent or Checkout Session.
 */
export declare function ensurePaymentMethodConfig(opts: PaymentMethodConfigOptions): Promise<string>;
/**
 * The configuration a payment form gets when the app names none — i.e. the
 * library's default answer to "what does this form offer".
 *
 * Card and the two wallets, for BOTH kinds, and nothing else.
 *
 * The alternative was tried and reverted: for `payment` this used to inherit
 * every method the account had enabled (`enable` the wallets, `disable` Link) on
 * the reasoning that a charge should offer whatever the Dashboard offers. What
 * that produced on a subscription checkout was a row of tabs — Carta, Klarna,
 * Amazon Pay, Satispay — where the app had always shown one. A method reaches a
 * customer because someone chose to sell that way; inheriting it from a
 * Dashboard toggle is not that choice, and a tab row is a question asked of
 * every customer forever.
 *
 * So the default is the narrow, explicable one. An account that deliberately
 * sells via SEPA or iDEAL passes its own `paymentMethodConfiguration` (or an
 * explicit `paymentMethods` list on checkout), which is the same amount of work
 * as before and now says so out loud.
 *
 * Wallets stay in because they are not another way to pay: Apple Pay and Google
 * Pay ARE the card, with the typing removed. They also cost a tap and cost the
 * account nothing, so they should not depend on remembering a Dashboard toggle —
 * which is why they are forced on rather than inherited.
 *
 * Link is out because it cannot be removed anywhere else — see
 * `BillingConfig.paymentMethods.link`. Pass `link: true` and this returns
 * undefined, leaving Stripe's own behaviour untouched.
 *
 * NEVER throws: a restricted key that cannot read or write payment-method
 * configurations returns undefined and the form renders with the account
 * default. A missing permission must not take down checkout.
 */
export declare function defaultPaymentMethodConfig(kind: "setup" | "payment", config?: {
    paymentMethods?: {
        link?: boolean;
    };
}): Promise<string | undefined>;
/** Forget resolved configurations — for a test, or after editing one. */
export declare function invalidatePaymentMethodConfigs(): void;
export {};
//# sourceMappingURL=payment-method-config.d.ts.map