Buy now pay later: Klarna, Clearpay and what it means for your conversion

Last updated: June 2026.

Here is the decision a PrestaShop merchant actually has to make about Buy Now Pay Later, stripped of the marketing: you are paying a premium fee, roughly double a card transaction, to remove the price barrier at the exact moment a customer hesitates. Sometimes that fee buys you a sale you would never have made. Sometimes it buys you a sale you would have made anyway, at a worse margin. BNPL is genuinely capable for some catalogues and a quiet margin leak for others, and the difference comes down to your average order value, your category, and where you place the messaging. This guide is about getting that calculation right on a PrestaShop store specifically, which providers to wire in, where they hook into checkout, and how to read the data before you commit.

If you are still deciding which payment methods to offer at all, start one level up with why offering more payment options means more sales and what European customers expect at checkout. This post assumes you have the basics covered and are deciding whether to add the instalment layer on top.

What BNPL actually changes for a PrestaShop store

The mechanics are simpler than the branding suggests. The customer chooses Klarna or Clearpay at the payment step; the provider pays you upfront minus their fee; the customer repays the provider over time, typically three or four instalments across six to eight weeks, or the full amount deferred 14 to 30 days. From your back office, a BNPL order looks almost identical to a card order: the provider assumes the credit risk, so if the customer defaults that is the provider's loss, not yours, and your fulfilment, stock and shipping flow are untouched.

Two things do change, and both matter operationally. First, the order state. BNPL modules add their own PrestaShop order statuses (you will see them under Shop Parameters → Order Settings → Statuses after install, with names like "Awaiting Klarna payment" or "Payment accepted by Clearpay") and they update via webhook, the provider calls back to a module controller on your store to confirm capture. If your store sits behind aggressive caching or a firewall that blocks unknown POST endpoints, those callbacks can fail silently and leave orders stuck in a pending state. Second, refunds. A BNPL refund has to be issued through the provider so the customer's remaining instalments are cancelled. Refunding only inside PrestaShop's order page leaves the customer still owing Klarna. Good modules surface a refund button inside the order detail that talks to the provider's API; cheap ones force you into two separate dashboards.

The conversion case, and when it does not hold

BNPL works by shrinking the psychological commitment without changing the price. A customer who stalls at €120 may not stall at "three payments of €40." The total is identical; the felt cost is not. That is real, and it is strongest in a predictable band:

• Order values roughly €50, €500. Below about €30, splitting a payment feels faintly absurd and adds a step for no benefit. Above €500, shoppers more often reach for a credit card or financing. The sweet spot is the mid-basket where the number is large enough to give pause but small enough that instalments feel trivial.
• Aspirational categories. Fashion, furniture, electronics, hobby gear, purchases driven by want rather than need, see the highest BNPL take-up. A customer buying printer ink does not need to spread the cost; a customer eyeing a €280 jacket might.
• Younger shoppers and mobile. The 18–35 band leans heavily on BNPL, and a meaningful share use it precisely because they do not hold a credit card. On mobile, a BNPL flow is often fewer taps than typing card details, which trims checkout friction where abandonment is worst.

Providers will quote you 20–30% conversion uplift and 30–50% higher average order value. Those figures are real for the right catalogue but they are vendor numbers from vendor-friendly samples, treat them as the ceiling, not the expectation. The honest framing is the question at the end of this post: did BNPL bring you orders you would otherwise have lost, or did it just move customers who would have paid by card onto a more expensive rail? Only your own data answers that, and the "How to read the data" section below tells you which numbers to record.

The providers worth wiring into PrestaShop

You do not need all of them. Pick by where your customers are.

The lowest-friction starting point for most stores is PayPal Pay Later (Pay in 3 where available), because it may be available through the official PayPal/PrestaShop Checkout integration you already run, potentially no new contract, no extra integration fee, and you can test demand before signing anything, subject to your merchant and market eligibility. Check your country-specific PayPal eligibility first, since the exact Pay Later product and its availability vary by market. If your traffic is German, Nordic or UK, Klarna is the name customers look for and its absence is felt. Many merchants ultimately route several of these through a single aggregator instead of stacking individual modules, Mollie for PrestaShop exposes Klarna and other instalment methods through one gateway and one set of credentials, which is far less to maintain than four separate provider modules. For the broader processor decision behind that, see Stripe vs PayPal; for where BNPL sits among the full module field, the complete payment modules comparison maps it out.

The fee maths, done honestly

BNPL costs more than cards. That is the whole trade. Card processing typically runs 1.5–2.5%; BNPL runs roughly 2.5–6% depending on provider and market. Call the premium 1–3% per order. On a €100 sale that is €1. €3 Of extra cost.

The question is never "is the fee higher", it always is, but "does the incremental revenue cover it." A worked example makes the threshold concrete. Say a category does €10,000/month in card sales and you add BNPL at a 3% premium on the orders that use it:

• If BNPL is pure substitution, the same customers, now paying via Klarna instead of card, you have simply paid an extra 3% on those orders for nothing. That is the failure case, and it is invisible unless you measure it.
• If BNPL lifts conversion by even 10% and raises the average basket on BNPL orders by 20%, the new revenue dwarfs the fee. A handful of genuinely incremental mid-basket orders pays for the premium on all of them.

So the entire economic case hinges on one unknown: how much of your BNPL volume is new versus shifted. You cannot reason your way to that answer. You measure it, which is why this post ends on data rather than a recommendation.

Where the conversion is actually won: product-page messaging

This is the part most merchants get wrong. Offering BNPL only at the payment step is leaving most of its value on the table, because by then the customer has already decided whether the price is acceptable. The lift comes from showing the instalment option on the product page, next to the price, "or 3 payments of €33.33" under a €99.99 price tag, so the smaller number is what frames the buying decision in the first place.

On PrestaShop, that messaging is rendered by the provider's module hooking into the product template, usually displayProductPriceBlock or displayProductAdditionalInfo (Klarna's on-site messaging widget and PayPal's Pay Later messaging both attach here). After installing a BNPL module, confirm the messaging hook is actually transplanted in your theme under Design → Positions; on custom or heavily modified themes the hook sometimes needs manual transplanting or a small template edit before the widget appears. If you do not see the "pay in instalments" line on a product page after setup, an unregistered or wrongly-positioned hook is the usual cause, not a billing problem.

One more placement note: the messaging widget also reads the cart total for dynamic amounts, so on a true single-page checkout where the total updates live it stays accurate as the basket changes. If your checkout still leaks orders before BNPL can even help, fix that first. Our Checkout Revolution module turns PrestaShop's stepped native checkout into a genuine one-page flow from the back office, with no theme surgery, so the BNPL option sits in front of the customer on the same screen as everything else instead of behind another gate. (Disclosure: we make PrestaShop modules, including Checkout Revolution, so this is our own product, judge it on the same evidence you'd ask of any vendor.)

Where BNPL does not belong

Adding it to the wrong catalogue is worse than not adding it. You pay the premium and confuse the checkout. Skip or limit BNPL for:

• Sub-€30 baskets. Splitting a small amount into instalments is friction without benefit. Most provider modules let you set a minimum order amount in their PrestaShop configuration, use it so the method only appears where it makes sense.
• Subscriptions and recurring billing. BNPL is built for one-off purchases; it does not model a renewing charge cleanly.
• B2B orders. Businesses settle on invoice terms, not consumer instalments. If your store mixes B2C and B2B, restrict BNPL to the relevant customer groups in the module config rather than offering it shop-wide.
• Instant-delivery digital goods. When "buy now" is already instant, "pay later" loses its persuasive pull. The buying motivation that makes BNPL work is mostly absent.

The compliance and reputation footnote

You are not liable for how customers manage their own instalments, the provider underwrites the credit. But two things are worth knowing. EU regulators are tightening BNPL oversight, and creditworthiness checks before approval are rolling out across Europe; in practice this is the provider's obligation, handled inside their checkout flow, not new work for you. And BNPL carries some public-perception baggage around encouraging overspending. Neither is a reason to avoid it. It is a reason to position it as one payment option among several rather than the headline of your checkout.

How to read the data before you commit

Because the whole economic case turns on incremental-versus-shifted volume, you decide with numbers, not instinct, and not three days of them. Before switching BNPL on, record a baseline from your analytics: cart-to-order conversion rate, average order value, and your current card-vs-other payment-method mix. Then run BNPL live for at least 60 days and watch four things:

• BNPL take-up rate, what share of orders actually choose it. Very low take-up means it is not worth the maintenance.
• Average order value on BNPL orders vs the rest. A clear gap upward is the signal that it is opening up bigger baskets, not just shifting them.
• Overall conversion rate vs baseline, especially in the €50. €500 Band and on mobile, where the lift should show first.
• Card-payment cannibalisation. If card orders fall by roughly the number of BNPL orders gained, you are paying the premium for substitution, the failure case.

The recommendation, then, is procedural rather than a verdict: start with PayPal Pay Later (Pay in 3 where available) if you already run PayPal and it is eligible in your market, because it costs nothing extra to test; add product-page messaging from day one so you are measuring BNPL's real effect and not a hidden version of it; give it 60 days and 200-plus orders before you read the result. If the AOV gap and conversion lift are there, layer in Klarna or Clearpay for the markets that expect them. If the numbers say substitution, you have lost nothing but a test, and saved yourself a standing fee on sales you already owned. For markets with their own preferred rails, pair this with local payment methods that reach local markets, where the right method beats any instalment plan.

Frequently asked questions

Does BNPL put me on the hook if a customer doesn't pay?

No. The provider pays you upfront minus their fee and assumes the credit risk, so a customer default is the provider's loss, not yours. Your fulfilment, stock and shipping flow are untouched, and a BNPL order looks almost like a card order in your back office. The two things that change operationally are the order statuses (BNPL modules add their own, updated by webhook) and refunds, see below.

How do I refund a BNPL order?

Issue the refund through the provider, not only inside PrestaShop's order page, otherwise the customer's remaining instalments aren't cancelled and they keep owing Klarna or Clearpay. Good provider modules surface a refund button inside the order detail that talks to the provider's API; weaker ones force you into two separate dashboards. Confirm which you have before you need it.

What does BNPL cost compared to a card?

More, that's the whole trade. Card processing typically runs around 1.5–2.5%; BNPL runs roughly 2.5–6% depending on provider and market, so call the premium 1–3% per order. These are general market ranges, not a quote: actual fees vary by provider, country and your contract, so confirm the current figures with each provider before planning margins around them. The fee is only worth it if BNPL brings genuinely incremental orders rather than shifting card customers onto a more expensive rail.

Where should the instalment message appear?

On the product page, next to the price ("or 3 payments of EUR 33.33" under a EUR 99.99 tag), not only at the payment step. By checkout the customer has already decided whether the price is acceptable. On PrestaShop the provider's module renders this through a product hook, usually displayProductPriceBlock or displayProductAdditionalInfo. If the line doesn't appear after setup, an unregistered or wrongly-positioned hook (check Design → Positions) is the usual cause, not a billing problem.

Is there a legal or compliance angle I should worry about?

You are not liable for how customers manage their own instalments, the provider underwrites the credit and handles creditworthiness checks inside their own checkout flow. But EU regulators are tightening BNPL oversight, and consumer-credit rules and required affordability checks are evolving across Europe, so treat the provider's compliance as something to verify rather than assume, and review your obligations with your own advisor if you're unsure. BNPL also carries public-perception baggage around encouraging overspending, reason enough to position it as one payment option among several rather than the headline of your checkout, not to avoid it.

Which catalogues should skip BNPL?

Sub-EUR 30 baskets (splitting a small amount is friction without benefit. Set a minimum order amount in the module config), subscriptions and recurring billing (BNPL models one-off purchases, not renewing charges), B2B orders (businesses settle on invoice terms, restrict BNPL to the relevant customer groups), and instant-delivery digital goods (where "pay later" loses its pull because "buy now" is already instant).