Stripe Dynamic Payment Methods

Turning a payment method on stops being a deploy

The practical difference is where the list of accepted payment methods lives.

On a manual integration you enumerate them in code. Stripe’s migration instruction is the clearest statement of the switch: if you list payment methods manually and want to manage them in the Dashboard instead, you "remove payment_method_types from your integration code". For integrations on an API version before 2023-08-16, Stripe says you "must replace payment_method_types with automatic_payment_methods", which is where the second name for this feature comes from.

After that, the Dashboard is the control surface. Stripe lists what the mode buys you: turn on and manage most payment methods in the Dashboard, "eliminate the need to specify eligibility requirements for individual payment methods", set rules for when methods are shown, exclude methods for specific transactions, and run A/B tests on new methods before rolling them out.

That middle item is the one that matters most and gets the least attention. The eligibility rules are real and numerous, and on a manual integration they were yours to encode and keep current.

What actually decides whether a customer sees a method

Stripe documents the criteria it applies, and frames them as the troubleshooting list: if a payment method is not appearing in your payment flow, one or more of these was not met. They run roughly in this order, and all of them come before ranking.

**Dashboard settings.** Only methods you enabled can be shown at all. If a method is not even listed for you, Stripe says it is "either not supported by Stripe or not supported in the country where your account is registered", giving PayNow, available only to Stripe accounts in Singapore, as the example.

**Product support.** Not every method works in every Stripe product. Stripe’s examples are Bacs Direct Debit, which is not available in the Mobile Payment Element, and Swish, which does not support recurring payments.

**Presentment currency.** Most methods cover a subset of Stripe’s 135-plus presentment currencies. ACH Direct Debit is USD only.

**Charge amount.** Methods carry their own minimums and maximums on top of Stripe’s. SEPA Direct Debit is only available below 10,000 EUR. Stripe is specific that "the final amount, including tax and discounts, is the amount used to determine available payment methods", so a discount code can change the options.

**API parameters.** Setting setup_future_usage filters out methods that cannot be saved for later, such as TWINT. Setting capture_method to manual filters out methods that do not support holds, such as iDEAL.

**The customer’s country.** Most methods are available in a fixed set of countries. BLIK is Poland only.

Note what this list does not include: anything about the customer’s individual history with you. These are structural filters, and they produce the eligible set. Choosing among that set is a separate step.

Stripe ranks the survivors, and you can still put a thumb on it

Once the eligible set exists, ordering is Stripe’s job. Stripe says the AI models in its Optimized Checkout Suite determine how eligible payment methods are displayed, including their order, for every checkout session. The models draw on more than 100 on-session signals, Stripe’s examples being real-time payment method uptime and popularity among similar customers, alongside broader network signals such as the methods preferred by similar businesses. Stripe describes the approach as an exploration-exploitation framework, which is a direct admission that some sessions are being used to test rather than to exploit what already works.

You are not locked out of the decision. Four Dashboard-level controls sit on top of the mode:

[Payment method configurations](/glossary/stripe-payment-method-configuration) create named sets of methods for different checkout scenarios, such as one set for one-time purchases and another for subscriptions. Payment method rules show or hide a method based on conditions like amount or customer location. A/B testing turns a method on for a percentage of traffic and reports the effect on conversion, average order value and volume shifted from other methods. An embeddable settings component lets platforms hand the controls to their users.

For a single transaction there is also the excluded_payment_method_types parameter, available on PaymentIntents, SetupIntents, Checkout and the Payment Element. One documented gap: Stripe says wallets are not excludable this way, and excluding apple_pay, google_pay or link through that parameter "generates an error". Use the per-integration wallets parameters instead.

On a Connect platform, someone else’s settings can decide

The rule is short and it surprises platforms that assume their own Dashboard is authoritative.

Stripe states that when using Connect with direct charges or on_behalf_of, "the settings of the connected account determines the available payment methods". The platform’s own enabled methods are not what the buyer is filtered against on those charges. That mirrors the merchant-of-record logic that governs which [payment method configuration](/glossary/stripe-payment-method-configuration) set applies, and it is the same underlying question asked twice.

So on a platform, a seller reporting that a method never appears may have nothing wrong with the platform integration. The method may be off, ineligible or blocked on their own account, and that is where to look first.