Payment method configuration without the code churn

The payments landscape has shifted quickly. Buy now, pay later methods now process over $300 billion in transactions worldwide, and mobile wallets recently handled roughly half of all global ecommerce payments. At Stripe, we try to keep pace with those trends—but we know most developers don't want to rewrite their integrations every time a new method gains traction. The question we've been working on is how to let you continuously offer the payment methods your customers want without turning that into an engineering project.

The problem with hard-coded payment configuration

A typical payments integration requires you to account for three kinds of properties:

  • Capabilities of your integration, such as whether it supports redirects.
  • Variable properties of a given payment, like amount and currency.
  • Configurable properties, like not showing Affirm for transactions under $50.

That last category tends to end up hard-coded in a parameter like payment_method_types, and it can be a source of payment failures that are difficult to debug. Payment methods come with nuanced limitations—transaction minimums and maximums, currency restrictions, merchant category constraints, differences in recurring support—and to add a new one you need to (1) know every limitation and (2) encode logic that conditionally hides or shows the method for each transaction. Get either step wrong, and you're dealing with failed payments and disputes.

Dynamic payment methods become the default

Requiring a code change for every configurable tweak is the kind of high-toil work we've heard you want to eliminate. Starting now, the default behavior of the PaymentIntents and SetupIntents API changes: rather than specifying payment_method_types in code, you configure payment method settings in the Dashboard instead. We call this integration path dynamic payment methods.

With dynamic payment methods, our prebuilt UIs—the Payment Element or Checkout—handle the display logic for eligible methods per transaction. Stripe then orders those methods to maximize conversion, factoring in the customer's device, location, and local currency. If you later want to change the methods offered for one-time versus recurring flows, or to suppress high-risk methods on high-value orders, you can do that through Dashboard rules rather than touching code. The integration gets simpler, safer, and easier to evolve.

Here's what the old pattern looked like:

  

    ~

And here's the new default:

  

    ~

Visibility into eligibility

We've paired the API change with tooling to help you verify your integration works and understand why a particular method wasn't available for a given transaction. In the Dashboard, you can enter a PaymentIntent ID or Checkout Session to see which payment methods were enabled and why others weren't eligible. You can also simulate payment method display while adjusting factors like amount, currency, capture method, and future usage.

Because payment method configuration no longer requires a code change, Stripe can take on checkout optimizations that previously demanded significant engineering effort. Dashboard controls now support A/B testing payment methods, configuring methods for different checkout scenarios, and setting custom targeting rules. To use these features, upgrade to the latest API version.