Stripe Payment Method Configuration

The two sets a Connect platform actually has

Stripe splits the Payment methods page of a platform’s Connect settings into two groups, and the split follows the merchant of record.

The configurations "for your connected accounts" apply to direct charges and to indirect charges that have on_behalf_of set. Stripe says these "define the default availability of payment methods", and that "for certain payment methods, you can override these configurations for specific accounts or account countries".

The configurations "for your platform account" apply to indirect charges that do not set on_behalf_of, and to any charge on your platform unrelated to Connect.

The rule underneath both is about who is legally selling. Stripe states that for charges where the connected account is the merchant of record, "the payment method must be enabled on the connected account", and that for charges where the platform is the merchant of record, "the connected account’s enabled payment methods don’t matter. The payment method must be enabled on the platform." That is why on_behalf_of moves a charge from one set to the other: it is the parameter that makes the connected account the business of record.

Each set has its own default. Stripe notes that "each set includes a default configuration that’s used for any payments where you don’t specify a different configuration".

On by default, off by default, blocked

Within a configuration for connected accounts, most payment methods take one of three default statuses, and the third is the one worth understanding.

On by default means "your connected accounts accept this payment method during checkout". Off by default means they do not, but if you allow accounts with full Dashboard access to manage their own payment methods, "they can turn it on". Blocked means they do not accept it and "they can’t turn it on". Blocked is a ceiling rather than a starting point.

Some payment methods do not offer the dropdown at all. Stripe says those "can only be enabled for individual accounts" and display "Configured per account" instead. Others can be set per country: expanding the method shows a list of countries with their own On, Off or Blocked status, and changing the main default "also sets all of the country defaults".

The inheritance detail is the one that surprises people mid-migration. Changing a default "doesn’t affect connected accounts that have explicitly turned that payment method on or off. It only affects connected accounts that still use that method’s default setting." A default is a fallback for accounts that never expressed a preference, not a broadcast. Because a change here can move every account at once, Stripe makes saving one "requires you to review them in a confirmation dialog".

Dashboard for the defaults, API for the exceptions

This split catches platform engineers who reach for the API first.

For the configurations that govern your connected accounts, Stripe is explicit: "You must use the Dashboard to configure these payment method configurations on your platform. You can’t use the Payment Method Configurations API." The API is still available for the other direction, to "override these configurations for individual connected accounts".

Overriding one account is a deliberate act. On the account’s Payment methods tab you open the method and deselect "Inherit from platform settings" before you can set its status. That checkbox is the whole inheritance model in one control, and after you clear it the account no longer follows your default.

One consequence is easy to miss: if you enable a payment method that has a corresponding capability and it is not on by default, Stripe says you "must also request the capability for the connected account". Turning the method on in the configuration is not by itself enough.

Eligible is not the same as enabled

Stripe reports each connected account against a payment method in one of four states, and the middle two are where support tickets come from.

Missing info means the account "has outstanding requirements". Ineligible means it cannot accept the method at all, for reasons such as "a prohibited MCC or unsupported country". Eligible means the account could accept it "but doesn’t have it enabled". Enabled means it is eligible and switched on.

Ineligibility is not something either side can toggle away. Stripe lists the causes as unfulfilled verification requirements for the capability, a merchant category code the payment method prohibits, an account that "is a payee or recipient only, and doesn’t accept payments", and accounts Stripe "has flagged for fraud risk and has blocked its capabilities".

Behind most of this sits a capability. Stripe says "most payment methods have an associated capability that must be activated for a connected account before that account can enable the payment method", and that most carry "the same verification requirements as the card_payments capability, with some restrictions and exceptions". Setting a method to on by default makes Stripe request that capability automatically for eligible accounts that have already met its requirements, and for accounts that have not, requesting it "might cause the account to display (Restricted) in the Dashboard".

A second configuration, or a per-payment exclusion

There are two ways to present a narrower list, and Stripe draws the line by breadth.

Create another configuration when you "need to manage payment methods for broader categories of transactions", Stripe’s own example being one set for one-time purchases and another for subscriptions, where you want "consistent payment method offerings across similar transaction types".

Use the excluded_payment_method_types parameter when you "require more control over payment method combinations that would be impractical to implement with multiple payment method configurations", such as excluding a method based on which items are in the cart. The two compose, so an exclusion can trim a configuration on a single transaction.

The exclusion parameter has a documented gap. Stripe says you "can’t exclude Apple Pay, Google Pay, or Link on a per-transaction basis using excluded_payment_method_types", and points at the per-integration wallets parameters instead.