How to send Klarna Network Data

Partners integrating Klarna through an Acquiring Partner do not call Klarna's APIs directly. The Acquiring Partner acts as the transmission layer between Partners and Klarna. This page explains how purchase data reaches Klarna through that layer, what data to share, and when.

There are two ways through which purchase data flows between Partners, the Acquiring Partner, and Klarna.

klarna_network_data is a serialized JSON string that Partners include directly in the Payment Request to the Acquiring Partner. The Acquiring Partner forwards it to Klarna exactly as received, without interpreting or modifying it.

This is the recommended channel for sharing purchase data. Because Partners control the format directly using Klarna's own schema, there is no risk of data loss from intermediate mapping. Partners starting a new integration should use this approach from the start.

klarna_network_data supports the full range of purchase data:

• Line items with name, quantity, amounts, tax, images, URLs, and product identifiers
• Purchase reference
• Customer details — name, email, phone, address
• Shipping information — delivery address, carrier, method, recipient
• Industry-specific data such as travel reservations, lodging details, and car rental
• Customer account purchase history

For the full schema definition, refer to the Klarna Network Data Schema documentation.

Klarna also returns data to Partners through a reverse passthrough field called klarna_network_response_data. The Acquiring Partner forwards this field back to Partners without alteration. Common use cases include:

• Receiving a payment_request_url to launch the Klarna Purchase Journey
• Receiving Payment Request or Payment Transaction identifiers

Partners should validate that their klarna_network_data JSON includes "operation": "payment_request" and nests the data inside "request". Omitting these fields causes Klarna to silently reject the data without returning an error.

Some Acquiring Partners expose fields for line items, customer details, shipping information, and purchase reference directly in their payment API.

If the Acquiring Partner does not support certain fields that Klarna requires, Partners must share those fields using klarna_network_data instead. Both channels can be used together — structured fields for the data the Acquiring Partner supports, and klarna_network_data for everything else.

The following diagram summarizes what Partners provide, what the Acquiring Partner does, and what Klarna receives:

The Acquiring Partner is responsible for:

• Forwarding klarna_network_data — Passing the data Partners provide to Klarna without modification
• Returning klarna_network_response_data — Delivering Klarna's response data to Partners without alteration
• Mapping structured fields (when applicable) — Translating Partner API fields to Klarna's schema at Payment Authorization
• Maintaining data across the lifecycle — Ensuring data is transmitted at Payment Authorization, capture, refund, and other post-purchase operations

This is the most critical point. Partners should send all available data when initiating a payment through the Acquiring Partner:

• Complete line items with name, quantity, amounts, tax, images, URLs, and product identifiers
• Purchase reference — the customer-facing order identifier
• Customer — name, email, phone, address
• Shipping — delivery address, recipient

This data powers Klarna's real-time fraud assessment and underwriting. Missing data at this stage directly impacts approval rates.

When capturing a Payment Transaction, Partners should send the same line item data again. This ensures:

• Klarna can verify the captured items match the authorized items
• Customer-facing displays remain consistent
• Partial captures are correctly attributed to specific items

If line items change between Payment Authorization and capture (for example, out-of-stock items removed), Partners should update them accurately — but keep name and product_identifier consistent for items that remain.

When processing refunds, Partners should include the line items being refunded with the same name and product_identifier used at Payment Authorization and capture. This enables:

• Accurate refund mapping to original items
• Clear customer communication about what was refunded
• Proper dispute evidence if the refund is later contested

klarna_network_data is supported in capture and refund calls. When available, Partners should forward it in all API interactions related to post-purchase operations to help Klarna maintain a complete picture of the transaction throughout its lifecycle.

Each line item should include the following fields.

Required:

Highly recommended:

Optional for enhanced experience:

The purchase reference is the customer-facing order identifier. It should be unique per order, stable across all operations, and meaningful to the customer.

Partners should provide as much customer information as available. Klarna uses these data points for fraud assessment, underwriting, and to simplify the sign-up experience for returning customers.

Required:

Highly recommended:

Optional:

Each shipping object provides delivery details for the purchase. If the purchase contains multiple shipments with different recipients, provide one shipping object per shipment.

Required:

Highly recommended:

Optional:

The klarna_network_data field is a serialized JSON string.

Sample request

{
  "content_type": "vnd.klarna.network-data.v2+json",
  "content": {
    "operation": "payment_request",
    "request": {
      "payment_request": {
        "purchase_reference": "TRAIN-BKG-3321098",
        "line_items": [
          {
            "name": "ICE Amsterdam-Frankfurt 1st Class",
            "quantity": 1,
            "total_amount": 12900,

The JSON must include "operation": "payment_request" and nest the data inside "request". Omitting these fields causes Klarna to silently reject the data without returning an error.

For the full schema reference, including all supported fields and operations, see the Klarna Network Data Schema documentation.