Klarna Merchant Handbook: Integration, Settlement, Disputes, and Traffic Value
The site already has a cross-platform comparison of Klarna, Afterpay and Affirm in the Buy Now Pay Later Platform Comparison, and that article answers which one to pick. This handbook does not repeat the comparison; it covers only the merchant-side operating practice of Klarna: how settlement runs after integration, how refunds are handled, how disputes are answered and how much in-app traffic value actually exists. If your question is still which provider, start with the comparison. If you have decided to integrate, or are evaluating the cost of doing so, this is closer to daily operations.
1. Positioning: Buy Now Pay Later Is Not a Credit Card
1.1 What it is
Klarna is a buy now pay later provider that started in Sweden, expanded across much of Europe and later entered the United States. For the buyer it splits a purchase into a payment now and the remainder later, or offers short interest-free instalments. For the merchant it is an independent payment option on the checkout page, listed next to cards and wallets.
The key distinction is this: the merchant sees a payment method, while the buyer sees an instalment statement. The two sides use different account systems, different interfaces and different responsibility boundaries. Merchant operations concentrate in three back-office modules: orders, settlement and disputes.
1.2 What it is not
First, it is not a credit card. Klarna carries the buyer assessment and the receivable itself, so under the standard model the merchant does not absorb the buyer's credit default. That is very different from extending credit to your own customers.
Second, it is not an acquirer. Card acquiring still runs through your acquirer, and Klarna simply adds one option to the checkout page. Blending the two layers makes you look in the wrong place when a failed order appears.
Third, it is not a traffic guarantee. Integration only earns the eligibility to be shown; whether it brings new customers depends on category, market and operational cooperation, which section six covers.
2. Merchant Eligibility and Regional Requirements
2.1 Entity and documentation
Klarna serves retail and e-commerce merchants with genuine transactions, and onboarding verifies entity registration, the product catalogue and terms on the site, the refund policy and expected volume. The logic matches other payment providers: can a third party understand the business from the site. Exact materials and review standards belong to the official pages.
For teams with a China background, entity location and the markets the site serves are the key variables. Most cases need a local entity in the target market, with site language, currency, delivery and return policy consistent with that market. Mismatches lead to repeated document requests.
2.2 Regional and category differences
Klarna's available markets expanded gradually, and payment details, buyer statement cycles and interest-free product shapes differ by market. The same merchant may be able to enable different products in different markets, so this has to be confirmed during planning rather than inferred from one market's experience.
Category limits exist too. High-ticket, high-return categories are reviewed more strictly because their dispute and return costs are higher. Where a business serves several markets, launch market by market: get settlement and disputes working in one, then copy the pattern; regional payment habits are covered in the Europe Local Payment Guide.
3. Integration Paths and Platform Connectivity
3.1 Integration shapes
There are two shapes. The first is a native integration in a commerce platform, where you enable the method and configure placement and available markets. The second is through a payment provider or a self-built interface, where you handle order creation, redirect, webhooks and state synchronisation yourself.
The first goes live fast with low maintenance, at the cost of limited configuration. The second is flexible, but you carry the full engineering responsibility for callback idempotency, the state machine and reconciliation.
3.2 Platform integration versus self-built stores
With providers such as Mollie or Adyen, Klarna is usually already aggregated as one payment method, so your system handles a unified state model instead of maintaining a separate path for it. That aggregation pays off clearly in multi-market operations.
Self-built stores need more care: instalment methods carry richer states than card payments, because beyond authorisation and capture there is cancellation and adjustment of a plan. The overall architecture is described in the Independent Store Payment Architecture Guide; treat instalments as a payment method with its own lifecycle rather than a variant of card payment.
4. Merchant Back Office: Settlement, Refunds and Disputes
4.1 Settlement and refunds
Settlement is produced periodically from completed orders, and the settled amount is the order value after fees and adjustments. Match settlement records against your order table each period; differences usually come from refunds, cancellations and period cut-offs caused by time zones.
Refunds are raised against an order and terminate or adjust the plan on the Klarna side. Full and partial refunds take different paths, and partial refunds require recalculating the remaining instalment amount. General practice for reverse flows is in the Refund and Settlement Operations Guide.
4.2 Dispute paths
Disputes consume the most merchant labour. Buyers can raise them for non-delivery, item not as described or duplicate charges, and the merchant must submit evidence within the deadline. Evidence quality decides the outcome: tracking numbers and delivery confirmation, product page screenshots, support conversation records and return receipts.
| Scenario | Path | Impact on the merchant |
|---|---|---|
| Cancel before shipping | Cancel in the back office, plan terminates | Low, remember to restore stock |
| Full return after shipping | Refund through returns and terminate the plan | Watch refund timing and buyer contact |
| Partial return | Split the refund, recalculate the rest | Check amounts to avoid over-refunding |
| Buyer claims non-delivery | Submit tracking and delivery evidence | High, weak evidence means loss |
| Buyer claims not as described | Submit description, images and logs | Moderate, depends on accuracy |
| Suspected fraudulent order | Block via risk rules, review order | Early blocking avoids shipping loss |
Evidence has method. Stacking every document is not the answer; each reason maps to its own evidence focus, and the systematic mapping is in the Chargeback Reason Codes and Evidence Playbook, whose evidence map can be adapted to platform specific rules.
5. Fee Structure and the Real Cost
5.1 Fee composition
Merchant cost is made of several parts, not one rate number. The transaction service fee is the base item, the funding of interest-free periods must be read clearly in the contract, refunds and reverse flows produce operating cost, disputes consume support time, and integration plus maintenance carry their own cost. Current rates and conditions belong to official policies and local regulation.
| Cost item | Composition | Controllable |
|---|---|---|
| Transaction fee | Charged on order value, market and category dependent | Partly, via negotiation and mix |
| Interest-free funding | Who funds the subsidy must be confirmed | Yes, via promotion strategy |
| Refund and reverse cost | Handling refunds and plan adjustments | Largely, via returns governance |
| Dispute handling | Evidence, support time and follow-up | Yes, via evidence discipline |
| Integration and upkeep | Plugin updates, API changes, regression tests | Moderate, depends on path |
| Settlement differences | Manual matching from timing gaps | Yes, via reconciliation design |
5.2 A real cost basis
Step outside the headline rate. Use a period of real order data as a baseline, then add service fees, refund losses, dispute losses and operating labour to compute how much of every hundred units of turnover actually stays with you. That number is what can be compared against other payment methods.
Another item often missed is who funds interest-free instalments. In some arrangements the merchant absorbs it, in others the platform does, and in others it is shared by campaign. That item can outweigh the rate difference, so confirm it line by line before signing instead of assuming it sits inside the service fee. For the wider family of instalment and billing products see Instalment Payment Solutions.
6. Traffic and Conversion Value
6.1 Conversion value
The first layer is conversion. Splitting a larger spend into acceptable smaller amounts lowers the decision threshold, and the effect is strongest in higher-ticket categories. It also anchors price: showing a per-instalment amount converts better than showing only the total.
The lift is not unconditional. It needs two preconditions: the ticket is high enough for instalments to matter, and the market and audience have the habit. Adding instalments to low-price fast-moving goods usually leaves only the cost and none of the lift.
6.2 The real limits of in-app placement
The second layer is traffic, and this is where merchants misjudge most. The Klarna app and shopping entry points give partner merchants product placement, a genuine exposure channel, but it is not automatic entry: whether you appear, where you appear and in which markets all depend on category fit, completeness of product data and joint operational effort.
Be careful when valuing this traffic. Orders from the app tend to have healthy ticket and conversion, but volume is capped by category. Treat it as an incremental channel rather than the main acquisition source. Peer platforms differ at this layer too, so compare merchant policies from Afterpay and Sezzle.
7. Categories That Fit and Those That Do Not
7.1 Where it fits
Mid to upper ticket categories with controlled return rates and short decision cycles fit best: fashion, beauty, home goods, consumer electronics accessories and outdoor gear. These categories share one trait: buyers already intend to purchase and only hesitate on payment rhythm, which instalments address directly.
Fit is stronger for merchants targeting younger audiences in Northern and Western Europe, where the payment habit is more established.
7.2 Where it does not fit
Low-price fast-moving goods, subscription services, virtual goods and digital content usually do not fit: instalments add little to the decision, while dispute and refund handling costs do not shrink with the ticket. Large B2B procurement does not fit either, because its payment rhythm is set by contract rather than consumer instalment logic.
High-return categories need caution. High return rates mean frequent disputes and adjustments, operating cost rises sharply and the gain can be cancelled out. If the business delivers digital goods, check payment method fit in the Digital Products Payment Guide first.
8. Operating Points and Common Misreadings
8.1 Daily operating points
Fix four processes: match settlement records each period and attribute every difference; route refunds through one path with an audit trail; answer disputes within the deadline and archive evidence; run placement tests on the checkout page and let data decide the real conversion contribution.
One item is easily missed: manage Klarna orders inside the same order state model as card orders while keeping instalment-specific fields. Mixed modelling supports both paths without sacrificing maintainability.
8.2 Wording and display
Marketing wording has boundaries. Claims about interest-free terms, instalment counts and eligibility must match the actual product and must not extend one market's policy to all markets. The compliance responsibility for that wording sits with the merchant, not the payment provider.
Placement affects experience. Showing instalment information on the product page lowers resistance earlier, while showing it only at checkout gives a smaller effect. Any early display must also carry clear eligibility terms, otherwise it invites misunderstandings and disputes.
8.3 Common misreadings
The first misreading is treating Klarna as a credit card or as an acquirer. It is not a card scheme and not your acquirer; it is one payment option at checkout. Blending the three leads you to the wrong responsible party when a failed order, a refund or a cost question appears.
The second misreading is assuming integration delivers traffic automatically. Placement is a conditional resource that depends on product data, category and joint effort. Building it into a business plan as a given assumption usually gets overturned by data within six months.
The third misreading is assuming buy now pay later and lending products are interchangeable. Their product nature differs and so do compliance duties; that difference is treated separately, and for disclosure requirements around instalment products see the Payment Compliance and Licensing Guide. Migration paths when adding or replacing methods are in the Payment Gateway Migration Guide.
More acquiring and payment options are organised under Payment, grouped by instalments, wallets and local payment methods.
Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow www.klarna.com and related official documentation and contract terms.