What you can pull from a Klarna account, and how we build the integration

A US Klarna login opens onto more than a buy-now-pay-later ledger: purchases and their installment schedules, a Visa-rail card issued by WebBank, a deposit balance held at WebBank, and a points balance from cashback. Every row sits server-side, keyed to one account. For an integrator the value is not a single statement but the spread of small, fast-moving records — a Pay in 4 plan that ticks down every two weeks, a balance that moves when a refund or cashback credit lands. The natural way to hold a copy is incremental, pulling only what changed since the last read.

The short version: a Klarna integration is mostly an exercise in modelling installment state and keeping a balance current, not in reading one tidy bank statement. We would mirror the account from a consenting session, seed it from a native export, then keep it current with a cursor-based poll. Where an EU balance account is in scope, the regulated open-banking route reaches the same deposit and transaction data with a stronger durability guarantee. Both can live behind one client.

Account data behind a Klarna login

The surfaces below are what the app shows a signed-in user. Each maps to a server-side record an integrator can reconcile against.

Authorized routes to the data

Four routes apply here. Which one leads depends on the market and on whether real-time freshness or regulatory durability matters more.

Authorized interface integration of the app's session

We instrument the authenticated mobile session — the bearer token, its refresh, and the device binding — and map the endpoints that back the purchases, plans, card, and balance views. Replayed under a consenting account, this reaches everything the user can see. Effort is moderate; durability tracks Klarna's app releases, so we re-validate the mapped endpoints when a version bumps. Access is arranged with you during onboarding against a consenting account, not requested as a hurdle.

PSD2 account information services (EU and UK)

Klarna Bank AB is a bank, not a wrapper: its banking licence was granted in 2017 and it carries FI identification number 41538 and corporate ID 556737-0431, per the Finansinspektionen company register. That makes the EU or UK balance account reachable as a regulated account through a PSD2 AIS connection under the holder's consent. This route is the most durable — it does not move when the app ships an update — but it covers the deposit and transaction layer, not the BNPL installment plans. We handle the AISP-side consent flow with you.

Consumer-consented session access (US)

In the US the dependable basis is the account holder's own authorization. The user consents, we hold the session, and the poller reads on their behalf. This is the working spine for a US build because it reaches the WebBank-backed balance and the BNPL plans in one place.

Native export as a backfill

Klarna lets a signed-in user export their orders and statements, commonly as CSV, and exercise GDPR access rights on personal data. That export is a clean way to seed history on day one; it is not a live feed, so we use it to backfill and then switch to incremental reads.

For a US-led project we would build on consented session access, seed from the export, and keep current with delta polling — adding the PSD2 connection where an EU balance account needs the regulated guarantee. That mix gives the broadest coverage without leaning on any one fragile point.

A delta sync against the purchases feed

The polling loop is small. Refresh the session, ask for everything updated since the last cursor, persist the new cursor, repeat. Re-reading a page that was already applied is harmless because rows upsert on the purchase id, so a retried or overlapping page is a no-op rather than a duplicate.

# Illustrative request shapes — confirmed against a consenting account during
# the build, not copied from a published contract.

# 1) Refresh the short-lived session token
POST /auth/v1/token/refresh
  { "refresh_token": "<stored>", "device_id": "<bound>" }
  -> { "access_token": "...", "expires_in": 1800 }

# 2) Pull only what changed since the last watermark
GET /consumer/v2/purchases?updated_after=<cursor>&page_size=50
  Authorization: Bearer <access_token>
  -> {
       "purchases": [
         { "id": "p_8fa3...", "merchant": "...", "amount_minor": 4999,
           "currency": "USD", "plan": "pay_in_4",
           "installments": [
             { "due": "2026-06-20", "amount_minor": 1250, "state": "scheduled" }
           ],
           "updated_at": "2026-06-08T12:04:11Z" }
       ],
       "next_cursor": "Y3Vyc29yOjE2..."
     }

# Store next_cursor. An empty "purchases" array means the mirror is caught up.
# Upsert each row on "id"; balance and cashback use their own endpoints.
      

What ships at the end

The headline deliverable is code that runs, not a folder of diagrams. Concretely:

• Runnable client source, Python and Node.js — typed wrappers for the purchases, installment, card, balance, and cashback endpoints, with the token-refresh and cursor-poll loop already wired in.
• A sync engine — the delta-polling worker with cursor persistence, backfill-from-export seeding, and the installment state machine that tracks scheduled, due, paid, late, and paused-by-return rows.
• Webhook handlers — if you prefer push over poll, handlers for events the hosted layer emits on a new purchase or an installment state change, ready to drop onto your queue.
• An automated test suite — recorded response fixtures plus a thin live check against a consenting account, covering the field shapes the client depends on.
• A normalized schema — one account model that keeps balance, card ledger, plans, and points as separate streams.
• An OpenAPI description of that normalized interface, a protocol and auth-flow write-up of the OAuth, token, and device-binding chain, plus interface documentation and data-retention guidance — the reference layer that sits under the code.

Keeping the mirror fresh

Freshness needs differ by stream, and the sync design reflects that. Installment due dates are the part a user actually feels, so we poll them on a tighter cadence than, say, profile fields that rarely move. The balance is read on its own endpoint and reconciled against incoming cashback credits and refunds, which is where a naive merge would double-count. History comes from the one-time export, after which the cursor takes over and the request volume drops to whatever changed. Where you need lower latency than a poll gives, the webhook path lets Klarna-side changes arrive as they happen, and the two can run together — poll as the backstop, push for speed.

Authorization, Klarna's banking licence, and data rights

The basis we build on is the account holder's authorization — the consumer consents to the read, and we keep the consent record alongside the data. In the US that consumer authorization is the dependable footing today. The CFPB's Personal Financial Data Rights rule (Section 1033) is the forward-looking piece, not current law: the agency reopened it for reconsideration through an advance notice of proposed rulemaking in August 2025, and a federal court enjoined enforcement that autumn, so we treat it as where US open banking may go rather than a framework the integration rides now.

Klarna's US money products run through WebBank — the balance deposits are held there, Member FDIC, and the card is issued by WebBank under a Visa licence; the monthly financing is issued by WebBank under NMLS #1353190, per the app's own footnotes. In Europe the picture is different: Klarna Bank AB holds a Swedish banking licence and is supervised by Finansinspektionen, with GDPR governing personal data and a statutory duty, as a bank, to retain certain records even after a deletion request. Finansinspektionen also fined Klarna SEK 500 million in December 2024 over anti-money-laundering deficiencies, per the regulator's own notice — a useful reminder that this is a supervised institution, and that our access stays authorized, logged, and minimized to the domains in scope, under NDA where a client needs it.

Engineering notes specific to Klarna

Two things shape a Klarna build more than anything else, and we account for both up front.

First, the installment layer is not bank-statement data. A Pay in 4 plan is a small state machine that moves on its own schedule, and a return is a first-class event: reporting one pauses the affected payments inside the app. We model that explicitly, so a paused installment is recomputed rather than left as a stale due date that was never collected. Second, a single Klarna identity can straddle markets, and the markets are not symmetric — a US account exposes the WebBank balance and dollar plans through consented session access, while an EU account is a Klarna Bank AB account reachable over PSD2. We map both into one normalized model so the client handles a user wherever they signed up. We also keep the cashback points ledger distinct from the deposit balance, because points redeem into the balance and a merged view would count the same money twice. None of this needs the client to clear a checklist first; the consenting environment and any sandbox are arranged with you as part of onboarding.

Screens we mapped against

Store listing screenshots, used to confirm which surfaces the signed-in app exposes.

Where Klarna sits among everyday-money apps

The same integration approach maps onto Klarna's neighbours, which is useful if you are aggregating several BNPL and wallet providers into one view.

• Affirm — holds pay-in-four and longer monthly loans, with repayment schedules and balances per borrower.
• Afterpay — keeps pay-in-four order and installment records tied to a consumer wallet.
• Sezzle — stores installment plans, reschedule events, and a rewards and subscription layer per user.
• Zip — holds pay-in-four plans alongside a virtual card ledger.
• PayPal Pay in 4 — carries installment plans next to a broader wallet balance and transaction history.
• Cash App — holds a balance, card transactions, and, through Afterpay, installment data per account.
• Chime — keeps spending and savings balances with debit-card transaction history behind an account.
• Revolut — holds multi-currency balances, card transactions, and statements per user.

Questions integrators ask about Klarna

Do you poll the Klarna purchases feed, or can you push changes?

The default is delta polling on a stored cursor: each cycle asks only for purchases and installments updated since the last watermark. If you would rather receive pushes, the hosted layer can emit webhooks that fire on a new purchase or an installment changing state, so you trade a little request volume for lower latency. We size the cadence to how fresh your view of due dates needs to be.

Can you keep the WebBank balance separate from the Pay in 4 plans in one feed?

Yes. The normalized schema keeps four distinct streams under one account: the deposit balance held at WebBank, the Klarna Card transaction ledger, the installment plans, and the cashback points ledger. They are joined on the account id but never collapsed, so reconciliation does not double-count a cashback credit against a deposit.

Can you cover the EU Klarna accounts as well as the US app, or just one market?

Both, modeled into one client. The US account is reached through consumer-consented session access against the WebBank-backed products. An EU or UK account belongs to Klarna Bank AB, a Finansinspektionen-licensed bank, so its balance and transactions are reachable through a PSD2 AIS connection under the holder's consent. The two markets carry different fields and currencies, and we map them so a single integration handles a user wherever they signed up.

What happens to an installment schedule when a shopper files a return?

Reporting a return pauses the affected payments inside Klarna. Our installment state machine moves those rows from scheduled to paused and recomputes the due dates, so the mirror you hold matches what the shopper sees in the app rather than carrying a stale amount that was never collected.

What I checked, and where it came from

This assessment was compiled by OpenFinance Lab on 2026-06-08, working from Klarna's own US product pages, the public register entry for Klarna Bank AB, and the current US data-rights position. Primary sources opened for it: the Klarna balance product page, the Finansinspektionen company register entry for Klarna Bank AB, the CFPB's Personal Financial Data Rights reconsideration notice, and Klarna's banking-licence announcement.

A runnable Klarna client plus its interface documentation starts at $300, billed only after delivery once you have checked it against your own account — or skip the build fee and call our hosted endpoints, paying per call with nothing upfront. Either way the cycle runs one to two weeks. Tell us which account data you need at /contact.html and we scope the route.