Glossary

Stripe Payment Method Rules

Stripe payment method rules are conditions set in the Dashboard that show or hide an individual non-card payment method based on the transaction amount or the customer’s location or currency, with no code involved.

Also called: payment method rules, customize availability, payment method overrides, payment method targeting

Start a free trial View Pricing

Definition

Dynamic payment methods hands the choice of what a customer sees to Stripe. Payment method rules is the mechanism that takes part of that choice back, and it is the only one of the three Dashboard controls that works by stating a condition rather than by listing a set.

Stripe describes them as letting you "set conditions on non-card payment methods directly from the Dashboard without any custom logic or code". There are two shapes. You can hide or show a method when the order amount is over or under a figure, and you can hide or show one for customers in certain countries or using certain currencies. Stripe’s own examples are a good guide to the intent: show Affirm only on transactions over 1,000 USD "to encourage higher-value purchases", and hide iDEAL for customers outside the Netherlands, "where it’s not commonly used".

One sentence in Stripe’s documentation decides whether this feature is useful to you at all, and it is easy to skim past: "Payment method rules only apply to non-card payment methods. Card payments and wallet payment methods, such as Apple Pay and Google Pay, aren’t currently supported." For most sellers cards carry the majority of volume, so rules are a tool for shaping the long tail of local and buy-now-pay-later options rather than a general control over checkout.

Key points

+A condition, not a set. A configuration lists which methods exist; a rule decides when one of them appears.
+Non-card only. Card payments and wallets such as Apple Pay and Google Pay are not supported.
+Two targeting parameters: the order amount, and the customer’s country or currency.
+Requires dynamic payment methods with the Payment Element, Express Checkout Element, Checkout or Payment Links.
+They do not apply to the hosted invoice page, or when one of those integrations creates a subscription.

The exclusion that catches subscription businesses

The limit most likely to surprise you is not the non-card one, because that is stated up front. It is this: Stripe says payment method rules "don’t apply to the hosted invoice page or when a Payment Element, Express Checkout Element, Checkout, or Payment Links integration creates a subscription".

Read that carefully, because it removes two of the places a recurring-revenue business does most of its collecting. A rule you set to keep a slow or expensive method away from small orders simply does not run when the thing being created is a subscription, and it does not run on the invoice page your customers pay from.

The practical consequence is that a rule can look correct in the Dashboard and be absent from a large share of your actual volume. If you set one up and then cannot find evidence of it working, check what kind of object your integration is creating before you conclude the rule is broken.

Setting one, and the name the Dashboard uses

The control is not labelled "rules" where you configure it. In Payment methods settings, you open the overflow menu on a supported method, Klarna for example, and select Customize availability. You set the condition there, a new minimum of 100 USD being Stripe’s worked example, and then select Apply Overrides.

There is a currency detail worth knowing before you set an amount threshold. Stripe states that "in your Dashboard, you configure transaction limits in a single currency", and that when it evaluates those limits on a transaction in a different currency, it "automatically calculates the equivalent limits using the current exchange rate". So a 100 USD floor is not a fixed figure in every other currency you sell in. It moves with the rate, which is the sensible behaviour and also means the threshold your finance team agreed is approximate outside your home currency.

Rules are also compatible with Stripe A/B Testing, which lets you test the targeting criteria themselves rather than only the on or off decision.

On a Connect platform the rules live somewhere else

Platforms have to set these in a different place from everyone else, and the place depends on the charge type.

For direct charges, Stripe tells platforms to configure payment method rules in the template config rather than in their direct payment methods settings. Rules set there "are inherited by all connected accounts", and Stripe is explicit that connected accounts "can’t override these rules". That makes the template config a policy surface rather than a default.

For destination charges the direction flips. Rules in the platform’s own direct payment methods settings apply, and Stripe says the connected accounts’ rules "don’t affect destination charges". The rule of thumb that keeps this straight is the same one that governs payment method configurations: follow the merchant of record, and set the rule on whichever account that is.

Testing a location rule without changing country

Location rules are awkward to verify, so Stripe publishes a way to fake the input. You pass a customer email with a suffix in the form plus location_XX in the local part, where XX is a two-letter ISO country code. An email like test+location_FR@example.com makes Checkout behave as it would for a customer in France.

For Checkout you pass it as customer_email when creating the session. For Payment Links you pass it as the prefilled_email or locked_prefilled_email URL parameter. Stripe test cards work as usual alongside it.

This is worth doing before a rule goes live rather than after, because the failure mode of a location rule is silent: the method simply does not appear, for a population you cannot see.

What this changes in QuickBooks, which is less than you might think

Acodei neither reads nor writes your payment method rules. A rule changes which options a customer is offered. What reaches your books is the transaction that resulted from the option they picked, and it arrives the same way whatever decided the menu.

The method itself can follow, but only as an optional field and only in one flow. Acodei documents an Enable Payment Method on Sales toggle that adds the payment method to each QuickBooks Sales Receipt, which is what you turn on if you want to report in QuickBooks by method. It works only in the sales receipt flow, so an account running Invoice Sync does not get it. A matching Enable Payment Method on Refund toggle does the same for Refund Receipts and has no effect on credit memos.

There is one reporting consequence worth anticipating. If you do report by payment method and you introduce a rule, the mix in your QuickBooks records will shift on the date the rule starts applying, for a reason that exists entirely on the Stripe side. That is a configuration change rather than a sync change, and it is worth writing down somewhere your future self will find it.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What are Stripe payment method rules?

Conditions you set in the Stripe Dashboard that show or hide an individual payment method. Stripe describes them as letting you "set conditions on non-card payment methods directly from the Dashboard without any custom logic or code", targeting either the order amount or the customer’s country or currency.

Do payment method rules work on card payments?

No. Stripe states that rules "only apply to non-card payment methods" and that "card payments and wallet payment methods, such as Apple Pay and Google Pay, aren’t currently supported". If your goal is to change how cards behave at checkout, this is not the feature.

Do payment method rules apply to subscriptions?

No. Stripe says rules do not apply to the hosted invoice page, or when a Payment Element, Express Checkout Element, Checkout or Payment Links integration creates a subscription. A rule can be configured correctly and still not run on a large share of a subscription business’s volume.

What is the difference between a payment method rule and a payment method configuration?

A configuration is a named set of payment methods you pass at checkout by ID. A rule is a condition evaluated on a single method at transaction time. The configuration decides what is on the menu; the rule decides whether one item is shown this time.

How do amount thresholds work across currencies?

You configure transaction limits in a single currency. Stripe says that when it evaluates those limits on a transaction in a different currency, it "automatically calculates the equivalent limits using the current exchange rate", so a threshold set in USD moves with the rate in every other currency you sell in.

Where do Connect platforms set payment method rules?

In the template config for direct charges, where the rules are inherited by all connected accounts and cannot be overridden by them. For destination charges, the platform’s own direct payment methods settings apply instead, and the connected accounts’ rules do not affect them.

Does the payment method appear in QuickBooks?

Only if you turn it on. Acodei documents an Enable Payment Method on Sales toggle that writes the payment method onto each QuickBooks Sales Receipt, and it works only in the sales receipt flow rather than under Invoice Sync. A separate toggle does the same for Refund Receipts.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy