Authorize payments with Klarna seamlessly by integrating the Payment Authorize API. This guide outlines how to receive and forward required data, call the API, and handle all possible response flows.
Once the customer selects Klarna at checkout and click on the Pay button:
Before calling Klarna’s Payment Authorization API, the Acquiring Partner must ensure their backend accept and forward Klarna specific parameters. These include interoperability parameters that preserve session context as well as supplementary purchase data which improves Klarna’s ability to assess risk, optimize approval rates, and deliver a more personalized checkout experience.
When Partners optimize their integration with Klarna, they are likely to have interoperability parameters to share with the Acquiring Partner.
Parameter | Purpose |
---|---|
interoperability_token | Encodes Klarna-specific session context (e.g., preselected payment option, pre-qualification results). |
interoperability_data | Submit supplementary purchase data directly to Klarna |
These ensure consistent customer and transaction context throughout the payment flow and must be forwarded unaltered to Klarna.
Below an example of how Acquiring Partners can accept the interoperability parameters in their Create Payment request API endpoint.
{
"currency": "USD",
"amount": 17800,
"payment_method_options": {
"klarna": {
"interoperability_token": "eyJhbGciOiJ...",
"interoperability_data": "{\"content_type\":\"application/vnd.klarna.interoperability-data.v2+json\",\"content\":{\"payment_request\":{...}}}"
}
}
}
The Partner-facing field should be named either klarna_interoperability_token
/klarna_interoperability_data
or interoperability_token
/interoperability_data
in a Klarna-specific context, ensuring that it’s easy for any Partner to identify and use.
As those parameters can change over time and are versioned so that the third party integration continues to work, Acquiring Partners need to respect these guidelines if they wish to validate parameters:
Parameter | Type | Max length | <span>Validation</span> |
---|---|---|---|
interoperability_token | string (JWT) | 8192 chars | Optional: verify format only |
interoperability_data | string (stringified JSON object) | 10240 chars | Optional: check for valid JSON |
The Acquiring Partner can validate the input based on the provided guidelines but must not modify it. The input must always be forwarded as received, without any interference.
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:
interoperability_data
supplementary_purchase_data
object format when calling the Klarna Payment Authorization API.Read more about Supplementary Purchase Data here.
Acquiring Partner must not add specific fields of the supplementary purchase data to their APIs for supporting Klarna, but rather make sure interoperability_data
and its requirements are properly implemented.
In both cases, the Acquiring Partner must ensure that data provided by the Partner is forwarded to Klarna. Do not require Partners to resubmit the same information through multiple mechanisms.
In the request to the Payment Authorize API, Acquiring Partners must specify the following parameters:
Parameter name | Description |
---|---|
partner_account_id | The unique identifier of the Partner account. This is used to scope the request. |
Parameter name | Description |
---|---|
Klarna-Interoperability-Token | Must contain the interoperability token if provided by the Partner. |
Parameter name | Description |
---|---|
currency | Currency in ISO 4217 format. |
request_payment_transaction | Represents a request to authorize a payment transaction, this object contains the following parameters:
|
step_up_config |
|
supplementary_purchase_data | Additional information that provides more detailed information about the transaction, which helps reduce the risk of fraud and enhances transparency. Shopping basket, customer billing / shipping details or specific transaction data can be provided through this object. |
interoperability_data | This field should be used for any additional interoperability data sent by the Partner. |
Below an example request body for the Payment Authorize API. (interoperability token sent as an HTTP header parameter)
{
"currency": "USD",
"supplementary_purchase_data": { .. },
"interoperability_data": "<serialized-json>",
"request_payment_transaction": {
"amount": 11800,
"payment_transaction_reference": "acquiring-partner-transaction-reference-1234"
},
"step_up_config": {
"payment_request_reference": "acquiring-partner-request-reference-1234",
The Payment Authorize API can yield 3 different outcomes depending on the transaction and the consumer:
Result | Description |
---|---|
APPROVED | The Payment Authorization is approved without additional customer interaction. A Payment Transaction is created and contained in the response. |
STEP_UP_REQUIRED | Additional customer interaction is required to authorize the payment. Those interactions need to happen in Klarna’s Purchase Journey and the customer has to be redirected to it. Read more about how to handle the Step-up Scenario. |
DECLINED | The payment cannot proceed due to reasons such as fraud, final decline or risk concerns. |
When the request is successful, a Payment Transaction is created on Klarna Network and will be available for post-purchase operations through the Payment Transactions API. No further customer interactions are needed and the Acquiring Partner can directly inform their partners that the payment session is completed and that the customer can be redirected to the order confirmation page.
Acquiring Partners must store the Klarna payment_transaction_id
for future operations on the transaction through the Payment Transactions API, such as capture and refund. The Acquiring Partner will receive the following parameters in the response.
The response will contain a payment_transaction_response
object with the following parameters:
Parameter name | Description |
---|---|
result | The result parameter which specifies the outcome of the authorization.In case of a successful Authorization the result will be set to APPROVED |
payment_transaction | The payment_transaction object represents a single payment transaction This object is only returned if the payment_transaction_response.result is set to APPROVED The payment_transaction_id returned is necessary to manage the Payment Transaction through the Payment Transaction API. |
Sample response - APPROVED
{
"payment_transaction_response": {
"result": "APPROVED",
"payment_transaction": {
"payment_transaction_id": "krn:payment:eu1:transaction:6debe89e-98c0-[...]",
"payment_transaction_reference": "acquiring-partner-transaction-reference-1234",
"amount": 11800,
"currency": "USD",
"payment_funding": {...},
"payment_pricing": {...}
If a transaction could not be approved by Klarna and step-up scenario cannot be triggered (due to missing configuration or for permanent decline), the Acquiring Partner will receive a decline. Declines should not be replayed without change of context.
The Acquiring Partner should inform the Partner that the payment could not be completed and the Partner should invite the customer to select another payment method.
The response will contain a payment_transaction_response
object with the following parameters:
Parameter name | Description |
---|---|
result | The result parameter which specifies the outcome of the authorization.In case of a decline, the result will be set to DECLINED |
Sample response - DECLINED
{
"payment_transaction_response": {
"result": "DECLINED"
}
}
When a Payment Transaction could not be immediately created by Klarna and a step-up configuration was provided in the call to the Payment Authorization API, the Step-up scenario will be triggered and the Acquiring Partner will receive a STEP_UP_REQUIRED
result.
In case your systems cannot support a pattern where there is no consumer interaction at the initialization of the session, it is possible to force the Step-up flow. This can be achieved by adding the mode = REQUIRED
to the step_up_config
object.
The mode = REQUIRED
will be available in a future release.
In such scenario, the Payment Authorization API returns a Payment Request in the response. The expectation is that the customer will go through Klarna’s Purchase Journey to complete the payment, usually triggering authentication and payment option selection. The required work to properly make the step-up scenario work is outlined in the next section.
The following parameters are present in the response to the request.
Parameter name | Description |
---|---|
payment_transaction_response | The payment_transaction_response object will contain the result parameter which specifies the outcome of the the authorization.In case of the Step up flow the result will be set to STEP_UP_REQUIRED |
payment_request | The base properties of a Payment Request. This field is only returned if the payment_transaction_response.result is set to STEP_UP_REQUIRED .The state_context.customer_interaction object contains:
|
Sample response - STEP_UP_REQUIRED
{
"payment_transaction_response": {
"result": "STEP_UP_REQUIRED"
},
"payment_request": {
"payment_request_id": "krn:payment:eu1:request:552603c0-fe8b-4ab1-aacb-41d55fafbdb4",
"payment_request_reference": "acquiring-partner-request-reference-1234",
"amount": 11800,
"currency": "USD",
"state": "SUBMITTED",
interoperability_token
and interoperability_data
from the Partner, unmodified.supplementary_purchase_data
step_up_config
request_payment_transaction
APPROVED
: proceed to confirmation and store payment_transaction_id
STEP_UP_REQUIRED
: either return the klarna payment_request_id
or payment_request_url
to the PartnerDECLINED
: inform the Partner that the payment could not be completed, the Partner should invite the customer to select another payment method.