Sharing supplementary purchase data

Improve approval rates, fraud assessment, and customer experience by sharing supplementary purchase data with Klarna in payment requests and authorizations.

Supplementary purchase data is additional information sent to Klarna alongside the transaction itself (line items, shipping, customer details, and industry-specific data). While these fields are technically optional in the API, including them is highly recommended: they significantly improve underwriting, fraud assessment, and the customer's post-purchase experience.

This information supports many use cases, from generic line items to industry-specific data such as travel reservations, lodging, or marketplace seller details.

Why it matters

Sharing supplementary purchase data with Klarna unlocks value across multiple areas:

Better post-purchase experience: detailed transaction breakdowns streamline disputes and returns, reduce support requests, and surface upselling and repurchasing opportunities inside the Klarna app.
Higher acceptance rates: historical data informs Klarna's underwriting, supporting higher credit limits and improved acceptance.
Stronger fraud assessment: detailed transaction insights enable more accurate fraud decisions, especially in high-risk segments.
Risk monitoring: granular data points help Klarna monitor and control risk exposure over time.
Personalized customer experience: customer and shipping details support a smoother Klarna Purchase Journey.

Where to send it

Partners call Klarna's APIs directly and send supplementary purchase data on the same calls that drive the payment flow:

On createPaymentRequest when starting the Payment Request. This is the primary entry point.
On authorizePayment when finalizing the authorization, if any details have been adjusted since the Payment Request was created.

flowchart LR Partner[Partner]:::tertiaryEntity LineItems[Line items, shipping,<br/>customer, etc.]:::secondaryEntity SPD[supplementary_purchase_data]:::secondaryEntity Klarna[Klarna]:::primaryEntity Partner --> LineItems --> SPD --> Klarna

supplementary_purchase_data vs. klarna_network_data

Partners send transaction details to Klarna as structured fields under supplementary_purchase_data (line items, shipping, customer, etc.). This is the recommended mechanism, as it powers underwriting, fraud detection, and customer communication.

Klarna also exposes a separate klarna_network_data field, a serialized JSON passthrough that follows the Klarna Network Data Schema API

. Use it to share additional information with Klarna without implementing the corresponding structured fields under supplementary_purchase_data. Treat the value as opaque; Klarna does not validate or infer its structure.

Pick one mechanism. The same information should not be sent through both.

Sample request

Sample createPaymentRequest request with supplementary_purchase_data

SHELL

1 2 3 4 5 6 7 8 9 10

curl https://api-global.test.klarna.com/v2/payment/requests \
  -H 'Authorization: Basic <API key>' \
  -H 'Content-Type: application/json' \
  -d '{
        "currency": "EUR",
        "amount": 2079,
        "customer_interaction_config": {
          "method": "HANDOVER",
          "return_url": "https://partner.example/klarna-redirect?id={klarna.payment_request.id}"
        },

For the full request and response specifications, refer to the createPaymentRequest API

and authorizePayment API

API references.

Supplementary purchase data use cases

Line items

Line items sit at the crossroads of Klarna's operations and are crucial for fraud detection, underwriting, and customer experience. By breaking down a transaction into individual units, they provide the detail needed for streamlined dispute resolution and a richer Klarna app experience, while reducing customer support contacts.

Purchase reference

The purchase_reference field is a required identifier used throughout the payment process to support customer-facing activities. It should correspond to the customer-facing payment reference the customer sees in the Partner's store. Keeping this value consistent and recognizable helps minimize customer service requests:

Customer service: a clear, recognizable identifier customers can use during disputes, inquiries, or support interactions.
- Klarna uses purchase_reference in all customer touchpoints (the Klarna app, email communications, and push notifications about payment status).
Dispute resolution: a shared identifier across all parties reduces confusion and human error during dispute handling.
Fallback identifier: when other session identifiers are unavailable, purchase_reference provides continuity and traceability.

All supported use cases

The following table lists the supplementary_purchase_data fields Partners can share with Klarna and the value each adds:

Field	Details
`purchase_reference`	The customer-facing order number. Displayed to customers in the Klarna app and other Klarna communications, and included in settlement reports for reconciliation.
`customer`	Who the customer is according to the Partner's store. Klarna uses these data points to streamline authentication and sign-up on the Klarna Purchase Journey and during fraud assessment.
`shipping`	Shipping information for the purchase. Used for fraud detection and customer communication. Supports pick-up in store and split-shipment delivery to multiple addresses.
`line_items`	Detailed information about each item in the purchase, including name, quantity, and unit price.
`customer.customer_accounts`, `customer.customer_device`	Applicable when the Partner supports registered checkout to complete a purchase.
`travel_reservations`	Applicable for travel services including flights, bus, train, ferry, and car rental.
`lodging_reservations`	Lodging details such as hotel booking information.
`insurances`	Applicable when the Partner offers standalone insurance policies.
`vouchers`	Applicable when the Partner offers coupons or vouchers exchangeable for a service.
`event_reservations`	Applicable when the Partner sells tickets for events, such as concerts or sporting events.
`ondemand_service`	Applicable when the Partner enables registration of the payment method for faster on-demand purchases.
`subscriptions`	Applicable when the Partner offers subscriptions to customers.
`marketplace_seller_details`	Applicable when the Partner operates marketplace services and processes transactions on behalf of sub-sellers.

SPD package support: server side vs client side

Where each package can be shared depends on how the payment form is built. Server-side integrations — the Klarna Payment Presentation API, server-side authorization, and tokenization — support every package. Client-side integrations built with the Klarna Web SDK support only a subset; the industry and regulated packages must always be shared server-side to preserve data integrity and security.

SPD package	Server side	Client side
`purchase_reference`	Yes	Yes
`line_items`	Yes	Yes
`shipping`	Yes	Yes
`customer`	Yes	Yes
`subscriptions`	Yes	Yes
`ondemand_service`	Yes	Yes
`travel_reservations`	Yes	No
`lodging_reservations`	Yes	No
`event_reservations`	Yes	No
`vouchers`	Yes	No
`insurances`	Yes	No
`marketplace_seller_details`	Yes	No

When sharing packages client-side through the Klarna Web SDK, use the camelCase field names (for example, line_items becomes lineItems and purchase_reference becomes purchaseReference). Server-side APIs use the snake_case names shown above.

API & SDK references

Authorize a payment transaction.

Create a server-to-server payment request

Authorize a payment transaction.