Authorize the payment

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:

  1. The Partner sends a request to the Acquiring Partner to create a Klarna payment session.
  2. The Acquiring Partner forwards the required payment context data to Klarna’s Payment Authorization API.
  3. Klarna returns one of the following responses:

    APPROVED – transaction is completed.

    STEP_UP_REQUIRED – customer needs to go through Klarna's Purchase Journey

    DECLINED – payment was denied.

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.

ParameterPurpose
interoperability_tokenEncodes Klarna-specific session context (e.g., preselected payment option, pre-qualification results).
interoperability_dataSubmit supplementary purchase data directly to Klarna

These ensure consistent customer and transaction context throughout the payment flow and must be forwarded unaltered to Klarna.

Implementation requirements

  • Accept the interoperability parameters in the Partner-facing payment request API.
  • Forward the interoperability parameters unmodified to Klarna’s Payment Authorization API.
Sample request

Below an example of how Acquiring Partners can accept the interoperability parameters in their Create Payment request API endpoint.

JSON
{
  "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.

Parameter validation guidelines

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:

ParameterTypeMax length<span>Validation</span>
interoperability_tokenstring (JWT)8192 charsOptional: verify format only
interoperability_datastring (stringified JSON object)10240 charsOptional: 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:

  1. Embedded in interoperability_data

    • No parsing needed. Just forward it as-is.
  2. As individual fields in the Acquiring Partner’s API

    • The Acquiring Partner is responsible for mapping those fields into Klarna’s 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:

Path

Parameter nameDescription
partner_account_idThe unique identifier of the Partner account. This is used to scope the request.

Header

Parameter nameDescription
Klarna-Interoperability-TokenMust contain the interoperability token if provided by the Partner.

Body

Parameter nameDescription
currencyCurrency in ISO 4217 format.
request_payment_transactionRepresents a request to authorize a payment transaction, this object contains the following parameters:
  • amount to authorize (in minor units, e.g., cents)
step_up_config
  • This object is required to support a step-up scenario, where the customer must approve the payment. Acquiring Partners must configure customer_interaction_config to determine how the purchase journey is launched. Applicable customer interaction config method for this integration pattern is HANDOVER.
  • Acquiring Partners must also indicate a return_url and/or an app_return_url, to ensure proper redirection after authorization. This will be covered in detail in the section Handle step-up scenario.<br />
  • This object also allows Acquiring Partners to provide a payment_request_reference for the purpose of correlating the payment session or equivalent resource with the Klarna Payment Request. This will also be exposed in payment request webhooks.
This will be covered in detail in section Handle step-up scenario.
supplementary_purchase_dataAdditional 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_dataThis 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)

JSON
{
  "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:

ResultDescription
APPROVEDThe Payment Authorization is approved without additional customer interaction. A Payment Transaction is created and contained in the response.
STEP_UP_REQUIREDAdditional 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.
DECLINEDThe 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.

Response body

The response will contain a payment_transaction_response object with the following parameters:

Parameter nameDescription
resultThe result parameter which specifies the outcome of the authorization.
In case of a successful Authorization the result will be set to APPROVED
payment_transactionThe payment_transaction object represents a single payment transaction
This object is only returned if the payment_transaction_response.result is set to APPROVEDThe payment_transaction_id  returned is necessary to manage the Payment Transaction through the Payment Transaction API.

Sample response - APPROVED

JSON
{
  "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.

Response body

The response will contain a payment_transaction_response object with the following parameters:

Parameter nameDescription
resultThe result parameter which specifies the outcome of the authorization.
In case of a decline, the result will be set to DECLINED

Sample response - DECLINED

JSON
{
  "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.

Response body

Parameter nameDescription
payment_transaction_responseThe 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_requestThe 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:
  • The payment_request_id necessary for the Partner to launch the Klarna Purchase Journey using the Klarna SDK.
  • The payment_request_urlnecessary for the Partner to redirect the customer to the Klarna Purchase Journey

Sample response - STEP_UP_REQUIRED

JSON
{
  "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",
  • Accept and forward interoperability_token and interoperability_data from the Partner, unmodified.
  • Map relevant fields from your API to Klarna’s Payment Authorize API, including:

    supplementary_purchase_data

    step_up_config

    request_payment_transaction
  • Call Klarna’s Payment Authorization API with all parameters provided by Partners.
  • Handle API responses:

    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 Partner

    DECLINED: inform the Partner that the payment could not be completed, the Partner should invite the customer to select another payment method.