Payment method analysis: where buyers drop out at checkout

Why the payment method deserves its own analysis

For many customers, the payment method is not a detail at the end of a purchase. In a representative Bitkom survey of 1,120 internet users in Germany aged 16 and over (Bitkom 2025), 1,072 of them online shoppers, 54 percent of those online shoppers rated payment options as very important when choosing an online shop (Bitkom 2025). Shipping and delivery reached 53 percent, security and trust 51 percent (Bitkom 2025). Price and discounts only came after that.

The figure describes how people choose a shop, not why they abandon at checkout. It says nothing about how many purchases fail because of the payment method. It does show the expectation customers bring to the checkout: the method they are used to should be there, and it should work.

Many customers, when in doubt, choose the provider that offers them a suitable payment option or the right delivery partner.

— Dr. Rohleder, managing director of Bitkom, press release of 24 November 2025 (translated from German)

How much is lost between cart and purchase overall is shown by a compilation from the Baymard Institute: across the studies it collected, the average documented shopping cart abandonment rate is 70.22 percent (Baymard Institute). A large part of that is browsing without intent to buy. Leaving that segment out, US online shoppers who abandoned a purchase name several reasons directly tied to payment: 19 percent did not trust the site with their credit card information, 10 percent left because the credit card was declined, and 9 percent found too few payment methods (Baymard Institute). Another 17 percent cited errors or crashes on the website (Baymard Institute).

The abandonment reasons come from a survey in the US, where cards dominate checkout. German shops see a different mix, and that is exactly the point: no industry study tells you which method fails how often in your own checkout. Industry figures show what customers expect. Whether your shop meets that expectation is something only your own measurement shows.

How customers in Germany pay online

For its study "Payment behaviour in Germany 2025", the Deutsche Bundesbank has participants keep a payment diary that is representative of the German-speaking population aged 18 and over. For purchases on the internet, 50 percent of payment transactions go to online payment services such as wallets (Bundesbank). Direct debit and credit transfer follow with 30 percent and credit cards with 15 percent (Bundesbank). By value, the picture flips: direct debit and credit transfer account for 45 percent of online revenue (Bundesbank), online payment services for 32 percent (Bundesbank).

Customer age matters too. People aged 18 to 25 pay for almost 70 percent of their internet purchases with online payment services (Bundesbank), while older groups use direct debit, credit transfer and credit cards more often. A sneaker shop and a garden tools shop can therefore see very different distributions with the same checkout, and a method that is marginal in one shop can carry a large share of revenue in another.

Merchants provide a second angle. For its study "Payment systems in retail 2026", the EHI Retail Institute analyses a panel of 172 companies with a combined 50.7 billion euros in net online revenue (EHI). In that panel, 26.1 percent of revenue goes to pay-by-invoice (EHI), 14.4 percent to direct debit (EHI) and 13.7 percent to credit and international debit cards (EHI).

The Bundesbank and the EHI measure different things: one counts transactions and amounts from the payer's side, the other revenue shares from the merchant's side. Both series help answer which methods a shop should offer. Whether those methods actually carry sales in your own checkout is a question they cannot answer.

What an analysis per payment method shows

In XICTRAQ, the report sits in the e-commerce area of cookieless analytics under "Payment and shipping methods". A toggle switches between payment method and shipping method. For each payment method, the table shows how many sessions it carried, how many of them reached checkout and how many bought, along with completion rate, revenue, average order value and revenue share. Once the shop reports failed payments, a "Payment failed" column is added. The e-commerce area is included from the Business plan upwards.

Counting happens per session, not per event. A session's payment method is the one used for the purchase; without a purchase, the one chosen at checkout. There is a practical reason for this: someone who picks card at checkout, then switches to invoice and buys counts once, under invoice. The filter bar in the analytics area also applies per session. If you filter by device, country or channel, you see payment methods for the matching sessions only. How checkout steps, revenue and refunds are captured overall is described in conversion tracking without third-party scripts.

How the payment method gets into your data

For shop systems that the tracker detects automatically, checkout and purchase are recorded without a single line of your own code. The tracker reads the payment method in one central place, in a fixed order: first whatever the shop passes itself, then an order object on the window, a meta tag or a data attribute, then entries in the dataLayer and the checkout data of one widely used hosted shop system. If none of these apply, the checked option in the checkout form counts, and finally the label "Payment method:" with its value on the confirmation page.

The tracker filters out amounts along the way. Some systems show the shipping fee under similar labels, and "4.90 EUR" or "free" is neither a payment method nor a shipping method. If you want to be on the safe side or run your own front end, pass the payment method explicitly. There are three ways to do this:

<!-- Option 1: meta tag on checkout and confirmation page -->
<meta name="xictraq:payment-method" content="Invoice">

<!-- Option 2: data attribute on any element -->
<section data-payment-method="Invoice">…</section>

<!-- Option 3: order object, set at the latest at purchase -->
<script>
  window.xictraqOrder = { payment_method: 'Invoice', shipping_method: 'Standard shipping' };
</script>

With manual tracking, the information goes into the extras of xictraq.checkout() and xictraq.revenue(). The full signatures are in the JS tracker API documentation. For an overview of the other shop events from cart to refund, see e-commerce tracking without cookies.

Failed payments: what only the shop knows

Many payments leave the shop for a moment. The customer is redirected to the payment provider, confirms in the banking app or fills in an embedded form. If the payment is declined or cancelled there, a tracker on the checkout page sees nothing of it. The shop finds out when the customer returns with an error status or when the provider reports the status. That is why there is no automatic detection for failed payments but a dedicated call instead.

// Return from the payment provider with status "declined" or "cancelled"
xictraq.paymentFailed('B-2026-10418', 89.00, 'EUR', { payment_method: 'Credit card' });

All four arguments are optional. If the payment method is missing from the extras, the tracker reads it from the page, just as it does for a purchase. If it is missing there as well, the failure counts under "No method". The order number helps later when matching against the payment provider's logs, and the amount shows whether mainly large baskets fail.

Here, too, counting happens per session: if a customer tries the same card three times, that is one failed attempt, not three. The denominator of the rate is the sessions that wanted to pay with that method, meaning they failed or bought with it, with a session that did both counted once. In addition, the report shows how many sessions still bought after the failure. These recovered sessions are revealing: if many still buy after a declined card, for example with another payment method, that points to a problem with the card rather than a lack of willingness to buy.

Decide in advance what counts as failed. A report makes sense when the payment provider declines, when the customer cancels at the provider or when the confirmation in the app times out. Errors while entering an address or phone number do not belong here; those are form problems. How to measure such drop-offs separately is covered in form analytics and form abandonment.

Typical breaking points per payment method

Every payment method has its own weak spots. The report does not name the cause, but it shows where to look. The overview below maps typical breaking points to signals in the data.

EU law generally requires strong customer authentication for electronic payments (EBA/ECB), and for cards the confirmation often happens in the bank's app. It works: according to the joint report of the European Banking Authority and the European Central Bank, card payment fraud was 17 times higher when the payee was outside the European Economic Area, where this authentication is not legally required and often not used (EBA/ECB). For the shop, though, this step also means that a switch to another app sits between click and payment, and every switch is a point where the process can break off.

Then there is the device. Of the online shoppers surveyed in Germany, 73 percent use a smartphone for online shopping (Bitkom 2025). That is exactly where switching between shop, wallet and banking app is fragile. The filter bar lets you view payment methods by device. If a method's completion drops on mobile devices only, that points to a problem in the flow on the small screen rather than an outage at the provider.

Wallets and embedded payment forms load code and windows from third-party origins. A content security policy that is too strict, or a content blocker, can stop them without the rest of the page looking broken. How to set up a policy that protects without blocking checkout is explained in configuring a content security policy.

Spotting the outage of a single method

When a payment method with a small share fails, the overall rate barely moves. A worked example with made-up values, not measured data: a shop has 1,000 sessions with checkout, 200 of them with card. If card completion drops from 59 to 41 percent, a fall of 18 points, 36 purchases are missing. The shop's overall rate falls by 3.6 points, a value that can get lost in the noise on a sale day. In the table per payment method, the same outage shows up as an 18-point jump in a single row.

The report shows an outage after customers have experienced it. An active test raises the alarm earlier. With browser monitoring, a real browser clicks through your checkout: add an item to the cart, fill in the address, select the payment method and check whether the payment provider's page or form appears. One scenario per payment method, with assert_url or wait_for steps at the handover, pinpoints the method that breaks. Every failed step produces a screenshot, and alerting reports the break on the channel you choose. Browser monitoring is included from the Business plan.

The test sensibly ends at the handover to the payment provider. Real payments every few minutes are neither necessary nor desirable, and provider test accounts do not check live operation. How such a flow is set up for login and checkout is shown in monitoring login flows.

When a method stands out, a fixed sequence helps:

1. Narrow it down: device, country and channel in the filter bar show whether the drop affects everyone or only some.
2. Reproduce: run the browser monitor for that method right away and look at the screenshot of the failed step.
3. Check changes: was there a deploy, a plugin update or a change to the content security policy shortly before?
4. Ask the provider: check the status with the payment provider and send along the order numbers of the failed payments.
5. Guide customers: if in doubt, hide the method temporarily and update the information on accepted payment methods.
6. Record it: note start and end of the outage so that later comparisons can explain it.

Changing payment methods: the legal side

Switching a method off or adding one touches obligations under German consumer law. Under § 312j(1) of the German Civil Code (BGB), a shop must state clearly and legibly, at the latest when the ordering process begins, which means of payment it accepts (BGB). If a method is hidden temporarily because of a disruption, this information should match, including notes in the footer and on the shipping and payment page.

Surcharges are limited as well. Under § 270a BGB, an agreement to pay a fee for using a SEPA direct debit, a SEPA credit transfer or a payment card is invalid (BGB); for payment cards this applies to transactions with consumers where the EU regulation on interchange fees applies. For other means of payment, § 312a(4) BGB makes a fee invalid if there is no common and reasonable free payment option or if the fee exceeds the merchant's costs (BGB). Anyone who wants to steer customers towards a particular method therefore usually does so through order and presentation, not through fees.

Before the sale days: checking payment methods in Q4

In Q4, every hour counts. 52 percent of internet users surveyed planned to use the reduced prices around Black Friday and Cyber Week in 2025, most of them online (Bitkom 2025). On such days, it is not only your own shop that sees more load; payment providers are busier too. A method that runs reliably on an ordinary Tuesday can confirm more slowly or decline more often on the Friday of the sale.

A few weeks before Black Friday on 27 November 2026, a fixed check date pays off: review the coverage of the payment method, run a declined test payment in the provider's test mode and check whether paymentFailed arrives in the report, and set up one browser scenario per method. How to prepare the website as a whole for peak load is described in Q4 traffic peaks. And because customers also run into fake shops during the sale period, a look at fake shops using your brand belongs in the same preparation. In the Bitkom survey, 51 percent of the online shoppers surveyed rated security and trust as very important when choosing a shop (Bitkom 2025).

Checklist: payment method analysis in eight steps

• Capture the payment method at checkout and purchase, automatically or via meta tag, data attribute or order object.
• Define consistent names for each method in checkout, confirmation page and error message.
• Check coverage and investigate the cause of sessions listed under "No method".
• Call xictraq.paymentFailed() at the point where the shop receives the payment provider's error status.
• Define what counts as failed: decline, cancellation at the provider, expired confirmation.
• Compare completion and failure rate per method with the prior period every week, split by device.
• Set up one browser scenario per payment method up to the handover to the provider, with alerting.
• Keep the information on accepted payment methods up to date, including methods that are temporarily switched off.

Run each payment method as a channel of its own

An overall checkout rate is an average across methods that work differently and fail differently. If you run each payment method like a sales channel of its own, with its own completion rate, its own failure rate and its own test, you see an outage in the row where it happens. The data is collected without cookies in the shop itself. With automatically detected shop systems, the shop mainly contributes the report of the failed payment; with a custom front end, it also passes the payment method. For the other reports in the e-commerce area, see the overview of cookieless analytics; the calls for your own shop are listed in the JS tracker API.