The Klarna Settlements API reads merchant settlement reports and transactions. It is one of 21 APIs that Klarna publishes on the network, tagged Settlements and Reporting, served from api.klarna.com.
Its published artifact set is one item: documentation.
Settlements is the unglamorous half of payments
Every payments integration has two halves. The first is authorisation — take the payment, get a yes or no, show the customer a confirmation. That half gets the SDKs, the sandbox, the quickstart and the conference talk.
The second half is reconciliation: money arrives in the merchant’s bank account days later, netted, batched, with fees deducted and refunds and chargebacks folded in, and somebody has to match that deposit back to the individual orders that produced it.
That is what Settlements is for, and it is where finance teams actually live. A payments integration that authorises perfectly and cannot reconcile produces a monthly spreadsheet exercise that never ends.
Klarna splitting settlements into its own API — separate from Orders, Payments, Captures, Refunds and Payouts — is the right decomposition. The people who need settlement data are not the people who need the checkout flow, and they need it on a completely different cadence.
What is missing
No OpenAPI specification. No AsyncAPI. Documentation only.
For a reporting API, that omission bites harder than it would elsewhere. Reporting endpoints return deeply-nested financial objects — transaction rows, fee breakdowns, currency conversions, adjustment types — and the shape of that object is the entire integration. Without a schema, every field is discovered by calling the endpoint and reading what comes back.
Reconciliation code written that way is brittle in a specific and expensive way: it works against the payloads you happened to observe, and breaks when an adjustment type you have never seen appears in a settlement six months later.
Settlement data is also inherently eventful — a settlement is created, then paid out — which makes the absent AsyncAPI a second gap. Compare Segment’s Regulations API, covered yesterday, which publishes both an OpenAPI and an AsyncAPI for an equally asynchronous process.
The provider context
Klarna scores 37.7 on the Kin Score — a thin band — across 21 APIs.
That is a low number for one of Europe’s most recognisable fintech brands, and it is a publishing finding rather than a product one. Klarna’s checkout works, at enormous scale, in dozens of markets. What the catalog measures is the machine-readable description of that surface, and on this API the description is a documentation link.
The pattern across Klarna’s 21 entries is consistent: well-decomposed APIs — Captures, Checkout, Customer Token, HPP, Order Management, Payouts, Refunds, Settlements, plus four separate Merchant URLs callbacks — with thin artifact coverage behind the decomposition.
Good API design. Sparse API description.
Takeaway
The right API, carved out at the right boundary, for the half of payments that finance teams depend on and vendors usually neglect — published with documentation and nothing else. For a reporting surface where the payload shape is the integration, a schema is not a nicety.
Read the docs at docs.klarna.com/settlements/, and the provider entry at apis.io/providers/klarna/.