Sharing supplementary purchase data

Enhance transactions with Klarna’s Supplementary Purchase Data to improve customer experience, optimize risk management, and unlock upselling opportunities.

Supplementary Purchase Data refers to additional data points that provide additional context related to a transaction to improve outcomes and customer experience. While these data points are technically optional, they are often required to enhance underwriting and fraud assessment, as well as to improve the customer's post-purchase experience.

This information supports different use cases and may include data associated to specific industries or business models such as airline, marketplaces, as well as data related to the transaction (line items, subscriptions and on demand transactions) or even custom data.

The supplementary data shared with Klarna will support multiple use cases and add value in different fronts such as:

Enhance post purchase experience: Enhance customer’s post-purchase experience with detailed transaction breakdowns, streamlining disputes and returns, reducing support requests, and boosting affiliate revenue through upselling and repurchasing opportunities—all within the Klarna app.
Acceptance rate improvement: Historical data informs underwriting processes, allowing for increased credit limits and improved acceptance rates.
Enhancement of solution offering: Based on historical behavior of the customer with a brand, Klarna is able to develop enhanced solutions for incentives and to drive particular actions.
Effective fraud case investigation: Detailed transaction insights support thorough investigations, tailoring responses to unique characteristics in high-risk segments.
Klarna’s risk exposure monitoring: Data points facilitate ongoing monitoring of risk exposure in high-risk segments, ensuring timely identification and control of potential risks.
Enhance underwriting and fraud assessment processes: Enhance the underwriting and fraud assessment for Partners and Klarna can make better-informed decisions in assessing the risk of the transaction. Historical data informs underwriting processes, allowing for increased credit limits and improved acceptance rates.

Supplementary purchase data improves Klarna’s ability to assess risk, optimize approval rates, and deliver a more personalized checkout experience. It includes structured information such as line items, L2/L3 data for Card Network optimization and other transaction context. Acquiring Partners may receive this data from the Partner in two ways:

1.
Embedded in klarna_network_data
- 1.1.
  No parsing needed. Just forward it as-is.
2.
As individual fields in the Acquiring Partner’s API
- 2.1.
  The Acquiring Partner is responsible for mapping existing fields in their payment API with the fields defined in the supplementary_purchase_data object when calling authorizePayment.

flowchart LR Partner[Partner]:::tertiaryEntity LineItems[Line items,\nL2/L3 data,\netc]:::secondaryEntity KlarnaNetLeft[Klarna Network Data]:::secondaryEntity AP[Acquiring Partner's API]:::primaryEntity Supplementary[Supplementary\nPurchase Data]:::secondaryEntity KlarnaNetRight[Klarna Network Data]:::secondaryEntity Auth[Payment Authorization]:::primaryEntity %% Main flows Partner --> LineItems --> AP --> Supplementary --> Auth Partner --> KlarnaNetLeft --> AP --> KlarnaNetRight --> Auth

Acquiring Partner must collect and forward data that aligns with Klarna’s Supplementary Purchase Data package by utilizing their existing schema. Acquiring Partner should not add additional fields of the supplementary purchase data in their APIs to support Klarna. Instead, they must ensure that the klarna_network_data

and its required structure are properly implemented.

In both cases, the Acquiring Partner is responsible for ensuring that the data provided by the Partner is accurately forwarded to Klarna. Partners should not be asked to resubmit the same information through multiple mechanisms.

Read more about Supplementary Purchase Data here. Sample authorize payment request with supplementary_purchase_data

SHELL

1 2 3 4 5 6 7 8 9 10

curl https://api-global.test.klarna.com/v2/accounts/{partner_account_id}/payment/authorize \
  -H 'Authorization: Basic <API key>' \
  -H 'Content-Type: application/json' \
  -d '{
        "currency": "EUR",
        "request_payment_transaction": {
          "amount": 2079,
          "payment_transaction_reference": "payment-transaction-reference-36ac766a-[...]"
        },
        "supplementary_purchase_data": {

Supplementary Purchase Data use cases

Line Items

Line items stand at the crossroads of Klarna's operations and are crucial in enhancing Klarna's fraud detection, underwriting capabilities, and customer experience. By breaking down transactions into individual units, they provide detailed insights that streamline dispute resolution and efficient interaction within the Klarna app, while reducing customer support errands.

Purchase reference

The purchase_reference field is a required identifier used throughout the payment process to support various Partner and customer-facing activities. This parameter should correspond to the Partner's customer-facing payment reference. Ensuring this parameter is both consistently applied and understandable to end customers is helpful in minimizing errands and ensuring customer satisfaction. Below are some key use cases:

Customer Service: It provides a clear, recognizable identifier that customers can use during disputes, inquiries, or interactions with customer support, improving the overall user experience.
- In addition, Klarna leverages the purchase_reference in all touchpoints with the customer, ensuring clear communication and understanding within the Klarna App, email communications, and push notifications regarding payment status.
Dispute Resolution: purchase_reference provides all involved parties with an aligned understanding of the order being discussed, reducing the chances for confusion or human error for both customers and customer service agents.
Fallback Identifier: When other session identifiers are unavailable, the purchase_reference may act as a fallback to ensure continuity and traceability within the transaction.

Purchase reference plays a key role in supporting visibility and alignment between all parties, and drives increased customer satisfaction.

All use cases supported

The following table list the supplementary_purchase_data shared with Klarna will support multiple use cases and add value in different fronts such as:

Supplementary Purchase Data	Details
`purchase_reference`	Used for storing the customer-facing order number. It will be displayed to customers on the Klarna app and other communications channels between the customer and Klarna. It will also be included in settlement reports for the purpose of reconciliation. For Acquiring Partners, this is the reference your Partners share for their customer orders.
`customer`	This represents who the customer is according to the merchant. These data points may be used by Klarna to simplify the authenticate /sign-up on the Klarna Purchase Journey and during fraud assessment.
`shipping`	Shipping information for the purchase. This data is used for fraud detection and customer communication: This shipping array also support: pick up in store for online purchases. Split shipment: if a Partner supports delivery to multiple addresses for an order
`line_items`	Applicable for any Partners, represents essential detailed information such as the name, quantity, and unit price of a purchase.
`customer.customer_accounts` `customer.customer_device`	Applicable for any segment, if a Partner supports registered checkout to complete a purchase.
`travel_reservations`	Applicable for any Partner that offers travel services including flights,bus, train, ferry, car rental. See specific Merchant Category Codes required to provide this information on Restricted businesses.
`lodging_reservations`	Supplementary lodging details, such as hotel booking details. See specific Merchant Category Codes required to provide this information on Restricted businesses.
`insurances`	Applicable for any Partner that offers any type of standalone insurance policy.
`vouchers`	Applicable for any Partner that offers to buy coupons or vouchers that are later exchanged for a service.
`event_reservations`	Applicable for any Partner that offers tickets to access for events, such as a concert or a sporting event. See specific Merchant Category Codes required to provide this information on Restricted businesses.
`ondemand_service`	Applicable to any Partner that enables registration of the payment method to complete purchases faster on-demand. See details on Tokenized Payments.
`subscriptions`	Applicable to any Partner that offers subscriptions to their customers. See details on Tokenized Payments.
`marketplace_seller_details`	Applicable when enabling marketplace services and processing transactions for sub-seller.

Payments on restricted businesses

API & SDK references

Generate SDK token

Authorize a payment transaction.