Klarna Buy Now Pay Later at European Scale

Klarna processes over two million transactions per day across 400,000+ merchant integrations. Inside their engineering stack.

CodeSwiftr Team · 2026-03-23

Klarna Engineering Deep Dive: Buy Now Pay Later at European Scale

Klarna processes over two million transactions per day across more than 400,000 merchant integrations worldwide. Behind the "pay in four" button that European and American shoppers see at checkout sits one of the most sophisticated fintech engineering stacks outside of the traditional banking world. If you are interviewing at Klarna, understanding this infrastructure — not just the product — will separate you from candidates who only know the consumer-facing story.

The Smooth Checkout SDK: Engineering a Universal Payment Layer

Klarna's "Smooth Checkout" SDK is the surface area most engineers will work on or around. The engineering challenge is deceptively hard: a single JavaScript SDK must operate correctly across Shopify, WooCommerce, Magento, Salesforce Commerce Cloud, and thousands of custom e-commerce builds, each with different page architectures, Content Security Policies, and JavaScript environments.

The core isolation model is iframe-based. Each Klarna checkout component renders inside an iframe hosted on Klarna's own domain. This is not just for aesthetics — it enforces PCI DSS compliance by ensuring that card data and personally identifiable financial information never touches the merchant's JavaScript context. The parent page communicates with the iframe through a strictly typed postMessage protocol. Klarna engineers working on the SDK must reason carefully about the security boundaries: what data can flow outbound (session tokens, UI size hints), and what must stay confined (payment method details, credit decisions).

Merchant onboarding is handled via a REST API that provisions a merchant configuration object — which payment methods to offer, which countries to enable, localization rules, risk thresholds. At the SDK initialization call, the client fetches this configuration via an authenticated CDN-cached edge request, keeping cold-start latency under 200ms even at scale. The merchant onboarding API is also the enforcement point for Klarna's regulatory compliance layer: a Swedish merchant cannot offer BNPL products in a jurisdiction where Klarna lacks a consumer credit license.

Real-Time Credit Decisioning: Approving in Under One Second

Klarna approves or declines a BNPL request at checkout in under one second. This is not a marketing claim — it is an engineering constraint imposed by checkout abandonment data. Every additional 200ms of decision latency measurably increases cart abandonment.

The ML model serving infrastructure behind this decision runs on a feature store architecture. At decision time, the system joins real-time signals (device fingerprint, session behavior, basket composition) against pre-computed features (purchase history, repayment track record, bureau signals). The join happens in memory against a low-latency feature store — not via database reads — keeping the critical path under the latency budget.

Klarna's competitive advantage in credit decisioning is its alternative data signals. Traditional lenders rely heavily on bureau scores, which excludes thin-file customers: young adults, recent immigrants, anyone without established credit history. Klarna's purchase history data across 150 million global consumers is a proprietary signal. A customer who has completed 40 BNPL transactions without a late payment over three years is a better credit risk than their bureau score suggests. Basket composition also matters: a customer purchasing high-return-rate categories (electronics, fast fashion) triggers different risk models than one buying furniture.

The regulatory constraints are significant. Under the EU Consumer Credit Directive and its successor frameworks, Klarna must perform creditworthiness assessments that are explainable and non-discriminatory. This creates a tension with black-box ML models. Klarna's approach uses gradient-boosted models with SHAP-based explainability layers, so any decline can generate a regulatory-compliant reason code without exposing the full model logic.

Open Banking Integration: Aggregating 15,000+ European Banks

Klarna pioneered open banking in Europe years before PSD2 made it mandatory for banks to expose APIs. Before the regulatory framework existed, Klarna built screen-scraping adapters against bank web portals to verify account ownership and balance. When PSD2 arrived in 2018, Klarna was already operating at scale and could migrate to API-based access bank by bank.

Today Klarna aggregates data from over 15,000 European financial institutions. The bank adapter layer is a plugin architecture: each bank or bank group gets an adapter that handles authentication flows (OAuth2, proprietary redirect-based auth, legacy Basic Auth), response normalization (translating each bank's idiosyncratic JSON or XML into Klarna's canonical transaction model), and error handling. The long tail of European banks — regional German savings banks, Scandinavian credit unions — still exposes inconsistent APIs, some returning transactions with non-standard date formats, some rate-limiting aggressively, some requiring re-authentication every 90 days under SCA (Strong Customer Authentication) rules.

The engineering challenge of European banking API inconsistency cannot be overstated. A Klarna engineer working on the bank adapter layer spends significant time on defensive parsing, retry logic with jitter, and circuit breakers that degrade gracefully when a bank's PSD2 API is unreliable. The normalization layer also handles currency handling, IBAN validation, and merchant name disambiguation (the same merchant appearing under different reference strings at different banks).

Fraud and Risk at Transaction Time: BNPL-Specific Attack Vectors

BNPL has fraud vectors that traditional card payments do not. The primary difference is that in card fraud, the card issuer bears the loss. In BNPL, Klarna extends credit directly, so fraud losses hit Klarna's balance sheet. This creates strong incentives for aggressive real-time fraud detection.

Synthetic identity fraud is a major vector: fraudsters create credible-looking identities using real name/address combinations (often scraped from data breaches) paired with fabricated SSNs or European ID numbers. Klarna's detection relies on behavioral signals — device fingerprinting, typing cadence, address verification latency — that synthetic identities cannot easily fake at scale. Network graph analysis across millions of transactions identifies shared device fingerprints, IP ranges, or shipping addresses that co-occur with loss events.

Account takeover attacks exploit Klarna's consumer-facing app. Credential stuffing attacks use breached username/password pairs to access legitimate accounts and make fraudulent purchases. Klarna's defenses here include velocity checks, impossible travel detection, and device trust scoring.

Return fraud is a BNPL-specific issue: a customer makes a legitimate purchase, receives the goods, claims a return was sent, and disputes the charge. Klarna's network effects are valuable here — a customer with a history of return disputes across multiple merchants creates a cross-merchant risk signal that no individual merchant could observe.

What Klarna Engineering Interviews Actually Test

Klarna's engineering culture reflects its Swedish origins: relatively flat hierarchies, high autonomy, strong opinions about software craftsmanship. Interview loops are rigorous, with a heavy emphasis on system design and practical coding over theoretical CS trivia.

Expect system design questions that map directly to the infrastructure described above. "Design a real-time credit decision system with sub-second latency" tests your understanding of feature stores, model serving, and latency budgets. "Design a payment SDK that works across thousands of merchant integrations" tests your knowledge of iframe isolation, CSP, and API versioning. "Design a bank data aggregation system for 15,000+ institutions" tests your distributed systems knowledge and your comfort with unreliable external dependencies.

Klarna also values product intuition. They are a product-engineering company, not a pure infrastructure company. Candidates who can articulate the engineering tradeoffs in terms of business outcomes — why sub-second decisioning matters, why alternative data signals expand addressable market — tend to perform well in behavioral rounds.

The technical bar is high and the problems are genuinely hard. Candidates who have studied the infrastructure, thought through the system design questions, and practiced articulating tradeoffs will be in a strong position. That preparation is exactly what Interview Simulator is designed to provide.

Ready to practice for your next interview? Interview Simulator gives you AI-powered feedback on your responses — behavioral, technical, and system design. Start with 3 free practice interviews today.

Try Interview Simulator free →

Senior candidates should also review our system design interview guide — Klarna's technical bar emphasizes architectural thinking.

You might also find our guide on Coding Interview Patterns Deep Dive: Master the 15 Patterns valuable as you prepare.

You might also find our guide on Write a Software Engineering Resume That Gets Past Screening valuable as you prepare.