Reference · built on requestConnectorPayments, billing & fraud

Klarna

Klarna orders, captures, refunds, and payout reports through the Payments, Order Management, and Settlements APIs.

About

Klarna is a buy now, pay later provider. A purchase starts as a Payments API session and becomes an order once the authorization is placed. From then on the Order Management API owns the order: captures, refunds, cancellation, authorization changes, shipping information, and customer send-outs. The Settlements API lists payouts and the transactions inside each one.

On Fibric, an operator reads orders and payouts and proposes changes: capture the lines that shipped with their tracking details, refund a return within the captured amount, or release an authorization you will not use. Each proposal waits for your approval, is sent once with the request key header Klarna expects, and leaves a record with the capture_id or refund_id Klarna returns.

This is a reference listing. It documents what Fibric would read from Klarna and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Order details from GET /ordermanagement/v1/orders/{order_id}
  • Captures on an order from GET /ordermanagement/v1/orders/{order_id}/captures and each capture from /captures/{capture_id}
  • Refund details from GET /ordermanagement/v1/orders/{order_id}/refunds/{refund_id}
  • Payment session state from GET /payments/v1/sessions/{session_id}
  • Payouts from the Settlements API payouts and payouts/{payment_reference} endpoints, and the transactions inside a payout
  • Payout summaries as CSV or PDF from the payouts/summary and reports/payouts-summary endpoints

Proposed actions

  • Target capability: propose a full or partial capture through POST /ordermanagement/v1/orders/{order_id}/captures, with shipping_info for tracking
  • Target capability: propose a refund through POST /ordermanagement/v1/orders/{order_id}/refunds, not exceeding the captured amount
  • Target capability: propose cancelling an uncaptured order through POST /ordermanagement/v1/orders/{order_id}/cancel
  • Target capability: propose releasing the remaining authorization through POST /ordermanagement/v1/orders/{order_id}/release-remaining-authorization
  • Target capability: propose updating merchant references or the order amount and lines through the PATCH merchant-references and authorization endpoints

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Capture the lines that shipped

    When part of an order ships, the operator proposes a partial capture for those lines with shipping_company, tracking_number, and tracking_uri, and leaves the remainder authorized.

    With Tracking Sync, Split Shipment

  • Refund a return without over-refunding

    The operator reads captured_amount and prior refunds, proposes a refund that fits, and records the refund_id from the 201 response.

    With Returns Triage, Refund Policy

  • Match payouts to orders

    Each payout lists its transactions with order and capture references. The operator ties them to orders in your ledger and flags lines it cannot match.

    With Payout Reconciliation

  • Release what you will not capture

    For cancelled or short-shipped orders, the operator proposes cancel or release-remaining-authorization so the customer's authorization does not linger.

    With Cancellation Window

Requirements

  • A Klarna merchant account and Merchant Portal access to generate API credentials
  • Test credentials for the playground hosts and separate credentials for the production hosts; keys are prefixed klarna_test_ or klarna_live_
  • The regional base URL for your account: api.klarna.com for Europe, api-na.klarna.com for North America, api-oc.klarna.com for Oceania
  • TLS 1.2 with Server Name Indication on every connection
Authentication
HTTP Basic authentication with API credentials generated in the Merchant Portal, sent as Authorization: Basic on every request.

Limits

  • API credentials inactive for two months are disabled, and deleted after ten months, so a dormant integration must be reactivated first.
  • A refund must be less than or equal to the captured_amount; Klarna rejects an over-refund.
  • Extending a capture's payment due date is a paid feature for pay-later methods.
  • Order state is read on request; this listing does not depend on Klarna pushing events to your endpoint.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Klarna ↗

Questions and answers

Which regional host should the connector use?
The one for your Klarna account's region: api.klarna.com for Europe, api-na.klarna.com for North America, api-oc.klarna.com for Oceania. Playground testing uses the api.playground, api-na.playground, and api-oc.playground hosts.
What happens to unused API credentials?
Klarna disables credentials inactive for two months and deletes them after ten months of inactivity. Disabled credentials can be reactivated before deletion, or new ones generated in the Merchant Portal.
Can a capture carry tracking information?
Yes. The capture request accepts shipping_info with shipping_company, tracking_number, and tracking_uri, plus return shipment fields such as return_tracking_number. The same details can be added later through the shipping-info endpoints on the order or on the capture.
Ask about Klarna

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.