Payment method order at checkout: what to show first, and how many

Most checkouts list payment methods in the order someone added them. Cards came first because they were integrated first, the local method arrived later and went at the bottom, and nobody looked at the list again. A Dutch customer then scrolls past a card form to reach the method that most Dutch online purchases go through, on a page that feels built for someone else.

This article covers which methods to show first by country, how many to show, what to preselect, where wallets belong and what the research on choice actually says. It assumes you already know which methods to offer, the subject of which local methods to add first. For the fields and forms that follow the choice, see checkout form design.

Which method should come first in each country?

The one most people there use online. Baymard’s payment UX guidance says to show the most commonly used methods for the market prominently and to group methods logically, with cards, wallets and buy now, pay later each kept together. The table gives starting points from the most recent figures we could confirm.

Market	Lead with	Evidence	Keep close behind
Netherlands	iDEAL	72% of online purchases and 58% of spending, Q1 2026, Thuiswinkel Markt Monitor	Cards, Klarna
Poland	BLIK	67% of online shoppers used it in the past year, Gemius via IAB Polska	Cards, bank transfers
Germany	PayPal	28.7% of 2025 online revenue, ahead of invoice at 26.1%, direct debit at 14.4% and cards at 13.7%, EHI via IT Finanzmagazin	Invoice, direct debit, cards
Brazil	Pix and cards	42% and 40% of 2025 e-commerce value, Worldpay via Poder360	Boleto
Saudi Arabia	mada	SR101.4 billion of online spending in Q2 2026, SAMA via Zawya	Visa, Mastercard, wallets
United States	Cards	Baymard names credit cards as the usual most popular method for US users	Wallets, PayPal

These figures measure different things: purchases, spending, revenue, users. They are not comparable with each other, so use them to set an order inside one market, not to rank markets. Our article on checkout localisation has more markets, including Mexico, Turkey and Kazakhstan, and covers currency and language.

Count and value can point in different directions. iDEAL takes 72% of Dutch purchases and 58% of spending, while credit cards take 8% of purchases and 16% of spending. Cards are carrying larger baskets. Germany offers a different warning: Apple Pay appears at 1.3% of online revenue in the EHI study. It may be well worth offering, but that figure gives no case for placing it ahead of PayPal and invoice for most German customers.

Local data then beats national data. If your own checkout shows that 60% of your Polish customers pay by card because you sell to expatriates or businesses, your numbers win.

How many methods should you show?

No study we found gives a number, and any article that states one should show its evidence. What exists points in a clear direction.

Offering too little costs sales. In Baymard’s 2023 study of 2,219 US shoppers, 11% had abandoned a checkout in the past three months because their preferred option was not offered. Baymard also says 21% of sites have problems with the payment options they offer. Stripe’s holdback experiment on more than 50 methods found that adding at least one relevant method beyond cards was associated with a 7.4% conversion increase and a 12% revenue increase across businesses. By method, it reported 91% for Alipay in China, 46% for BLIK in Poland and 39% for iDEAL in the Netherlands. Stripe also reports a neutral result for ACH Direct Debit in the US and for pre-authorised debits in Canada. These are one vendor’s averages, and it stresses that the right method, under specific conditions, produced the effect.

Offering too much clutters the page. Baymard says that as accepted methods grow, choosing one can become difficult for some users, and it advises putting less common options behind a “more payment options” link. Stripe’s accordion layout displays up to five methods by default and hides the rest behind a More button, which you can change. That is a product default, not a research finding, but it matches Baymard’s approach.

So the practical answer is: a short visible list that fits on one phone screen, built from relevant methods, with the rest one tap away.

Relevance comes before count. Remove anything that cannot complete this payment before you decide what to show. Stripe’s Payment Element hides methods that do not support the current currency or payment type, so a JPY recurring payment never shows a method that cannot take it. Apply the same logic to minimum and maximum amounts: a method capped below this basket should not appear at all.

Does too much choice really hurt conversion?

Less than its reputation suggests. The idea became famous through lab and field studies on choice overload, but the evidence is mixed. Scheibehenne, Greifeneder and Todd’s meta-analysis in the Journal of Consumer Research pooled 63 conditions from 50 experiments with 5,036 participants and found a mean effect of virtually zero, with considerable variance between studies. In other words, more options do not reduce choosing on average, but in some settings they do. The authors found several possible preconditions for overload and no sufficient ones, so nobody can yet say in advance when a long list will backfire.

Those experiments were not about payment pages, and we would expect paying to be a different kind of choice, because a customer usually arrives with a method in mind and scans for a familiar logo. Baymard’s testing fits this: it found that the payment interfaces it tested on mobile and desktop all performed well, including radio buttons and tabs, and advised only against drop-downs.

Stripe goes further and says that the more relevant methods displayed, the higher the likelihood of purchase. It did not test a point at which the effect reverses, so that is not proof that longer lists are always better. The word doing the work is “relevant”. Twelve logos a customer does not recognise do not count.

Should a method be preselected?

Usually, yes. Baymard recommends preselecting the most common method and showing its fields, typically credit card for US users, and it calls this recommended rather than required. For a returning customer, the method they last used is the obvious default, as long as it is still valid.

Three rules limit this.

Rule	Where	What it means
Debit before credit	Sweden, from July 2020	Debit must appear before credit, and credit may not be preselected, according to Stripe support
Non-credit first	Finland, from October 2023	Methods that do not involve credit or deferred payment come first, according to Stripe support
Co-badged cards	EEA	A merchant may set a priority brand, but the customer must be able to override it

For co-badged cards, Article 8(6) of Regulation 2015/751 allows a merchant’s automatic priority selection and bars preventing the payer from overriding it. Adyen’s guidance adds that you must make clear which brand will be used and show each one with the same visual quality. Stripe notes the Sweden and Finland rules in its own documentation on sorting methods. Get legal advice before you rely on these summaries, particularly if you sell instalments or invoice.

Preselection also needs care with wallets. Preselecting a method that this device cannot use is worse than having no default.

Where should wallets go?

Above the card form, on devices that support them, and at the same visual weight as other options. Baymard’s guidance says Apple Pay, Google Pay and PayPal should appear as distinct, clearly labelled buttons above the card form.

The wallets’ own rules push in the same direction, and both go further.

• Apple says to offer Apple Pay only on devices that support it, and to consider showing it as the first option. If you use its APIs to check whether someone has an active card in Wallet, Apple says you must make Apple Pay the primary option wherever you use them, for example by preselecting it. It also says to avoid making people scroll to see the button.
• Google says to display the Google Pay button prominently, says it can be the default option, and asks for equal prominence and size with other buttons.

Both ask to be primary, so let the device settle it where you can: lead with the wallet this customer’s device is set up to use, then the local leader, then cards.

Placement seems to matter as well as presence. Stripe reports that separate studies found an average 2x conversion increase when Apple Pay was offered earlier in the flow through its Express Checkout Element, compared with showing it at the end. Stripe also reports 22.3% more conversion from offering Apple Pay at all. Those two figures come from different studies, and they are vendor averages, so treat them as a direction rather than a forecast. Our article on Apple Pay and Google Pay covers country availability, which differs from the card list.

A wallet does not have to outrank the market’s leader everywhere. In Germany or the Netherlands, a customer on an iPhone may still prefer PayPal or iDEAL. If you do not use Apple’s card check, you have more freedom, so test it. Stripe’s ordering documents this kind of control: its dynamic ordering sorts methods for each customer, and it describes the inputs as device, location and transaction amount, while its paymentMethodOrder setting lets a merchant override the order.

How do you set the order for a market?

Use this list for each market above a set share of revenue.

1. Start with market data from the table above or a national source.
2. Replace it with your own once you have enough checkouts: share of attempts and completions by method.
3. Remove what cannot work for this currency, amount or customer.
4. Apply local rules on credit, co-badging and disclosures.
5. Split by device. Put a supported wallet at the top, then the leading local method.
6. Group the rest by type, and keep the visible list short.
7. Set a default: the last used method for returning customers, the market leader for new ones.
8. Watch cost and approval. Order can steer volume. If two methods convert equally, the cheaper or better-approved one can go first.
9. Test one change at a time and review it twice a year. Markets move: see our article on iDEAL, Bancontact and Wero for one example.

Worked example: reordering a Polish checkout

Example figures, for illustration only.

A fashion shop’s Polish checkout lists cards first, then PayPal, then BLIK under a “more options” link. It gets 10,000 payment sessions a month. It moves BLIK to the top, preselected, leaves cards second and runs a 50/50 test for four weeks.

Metric	Cards first	BLIK first
Sessions	5,000	5,000
Share choosing BLIK	22%	51%
Share choosing cards	62%	38%
Completed payments	3,700 (74.0%)	3,900 (78.0%)

The test shows 200 more completed payments in a month, and the 74% and 78% results are far enough apart at this volume to be unlikely to be noise. It also shows two side effects. Average basket falls a little, because large baskets stay on cards, and more orders now follow BLIK’s refund process. The team keeps the new order, and it reviews revenue, not just completed payments, before rolling the change out to other markets.

What are the common mistakes?

• One global order. A single list suits one market at best.
• Listing by integration date. The oldest method is rarely the most used.
• Long lists of logos. Show what this customer can use.
• Hiding the leading method. A local favourite behind “more options” may as well be missing.
• Measuring clicks. Choosing a method is not paying with it. Compare completed payments per session.
• Treating a vendor’s average as your forecast. Published uplifts are averages across other merchants.

How does Omno help order payment methods?

Omno’s hosted checkout has a no-code builder for layout, branding, categories, minimum and maximum amounts, routing and fields, so a team can change the order without a release. The checkout can be personalised by country, currency, amount and payment history, and saved cards and accounts are supported. It takes cards, Apple Pay, Google Pay, local methods and crypto, where a connected provider offers them. Reports and widget analytics show the results. The hosted checkout page has the details.