When Klarna requires additional verification from the customer (e.g., login, authentication, or payment method selection), it returns a Payment Request in the response to the Payment Authorize API call.

The Acquiring Partner backend must detect this and return the necessary data points to Partners so they can start the Klarna’s purchase journey with the customers.

As shown in the below diagram, the high level flow is the following:

1. Partner submits a Klarna payment request to the Acquiring Partner.
2. Acquiring Partner calls the Klarna Payment Authorize API.
3. Klarna returns a step-up required response containing:
   1. payment_request_id
   2. payment_request_url
4. Customer enters Klarna’s purchase journey.
5. Customer completes authentication/payment method selection.
6. Klarna redirects the customer back to the Partner.

To support the step-up scenario, Acquiring Partners must define return URLs when calling the Payment Authorize API.

• return_url: if the Klarna purchase flow is launched in a web environment, Klarna will redirect the customer to this URL after the customer finishes their interaction with Klarna, either by approving or aborting the purchase flow. This could either be a URL from the Acquiring Partner who will handle the redirection logic or a URL collected from the Partner.

• app_return_url: The customer may be redirected to a third party app (bank app) or the Klarna app during the Klarna purchase journey on mobile environments. This URL enables Klarna to return the customer back to the Partner’s mobile app.

Implementation notes for Partners

• Ensure the app_return_url is set up to register a URL scheme (e.g., yourapp://klarna) or universal link that resumes the payment flow.
• Klarna uses this URI after the customer completes a native app-based flow (e.g., biometric auth in a bank app or Klarna app login).
• Partners are expected to open the integrating mobile application in its last state (no state changes or deeplink navigations).

Acquiring Partners must include a step_up_config object when calling Klarna’s Payment Authorize API, and specify the following parameters:

Sample request

curl https://api-global.test.klarna.com/v2/accounts/{partner_account_id}/payment/authorize \
  -H 'Authorization: Basic <API key>' \
  -H 'Content-Type: application/json' \
  -H 'Klarna-Interoperability-Token: eyJhbGciOiJIU...' \
  -d '{
        ...
        "step_up_config": {
          "payment_request_reference": "acquiring-partner-request-reference-1234",
          "customer_interaction_config": {
            "method": "HANDOVER",

​Whenever the step-up scenario is triggered, the Payment Authorize API response will contain

• payment_request_id: The unique Klarna identifier for the payment request
• payment_request_url: A URL to launch the Klarna purchase journey

Sample response

{
  "payment_transaction_response": {
    "result": "STEP_UP_REQUIRED"
  },
  "payment_request": {
    ...
    "state_context": {
      "customer_interaction": {
        "method": "HANDOVER",
        "payment_request_id": "krn:payment:eu1:request:552603c0-fe8b-4ab1-aacb-41d55fafbdb4",

Forwarding Klarna parameters to the Partner

​Acquiring Partners should extract and expose these parameters in their API response to the Partner system. This enables the Partner to:

• Redirect the customer to Klarna’s purchase journey directly, ensuring automatic app handover
• Use Klarna’s Web SDK or Mobile SDK to start the purchase flow

{
  "status": "pending",
  "klarna": {
    "payment_request_id": "krn:payment:eu1:request:552603c0-fe8b-4ab1-aacb-41d55fafbdb4",
    "payment_request_url": "https://pay.test.klarna.com/eu/requests/6bbf6775-[...]/start"
  }
}

Avoid the use of intermediate redirects

In some implementations, the Acquiring Partner might be returning a general-purpose redirect_url under their domain for all payment methods. Partners then use this URL to trigger a client-side redirect to Klarna’s payment_request_url.

{
  "status": "pending",
  "redirect_url": "https://acquiringpartner.com/payment/xxxxx"
}

However, this pattern is generally discouraged due to the following limitations:

• Reduced app handover success: Cross-domain redirects decrease the likelihood of a successful automatic handover to the Klarna app, which can negatively impact Klarna’s purchase conversion rate.
• Incompatibility with Klarna SDK integration: This approach is not compatible with partners who use the Klarna Web SDK to optimize the purchase experience, such as enabling popup flows on websites or facilitating app-to-app handoff within native mobile applications.
• Network issues: frontend redirects expose customers to network issues which can

Instead, expose Klarna’s payment_request_url directly to the Partners:

{
  "status": "pending",
  "redirect_url": "https://pay.klarna.com/xxxxx"
}

Partners may have two options to start the Klarna purchase journey based on the parameters returned by Acquiring Partners:

• Launch the purchase journey directly using Klarna payment_request_url
• Use Klarna Web SDK or Mobile SDK to trigger the flow, based on the provided payment_request_id.

The Klarna purchase journey enables the customer to:

• Authenticate with Klarna (via login, OTP, etc.)
• Choose the payment method (Pay in N, Pay Later, etc)
• Accept the payment.

After the customer finishes or aborts the Klarna purchase flow—whether on web or in the app—Klarna does the following:

1. Redirect the customer to return_url and/or app_return_url: Klarna redirects the customer to the return_url and/or app_return_url specified in the customer_interaction_config object. As discussed above, either or both URLs may be triggered, and app_return_url can even be invoked in the middle of the purchase flow. Therefore, avoid adding any special logic or dependencies to these URLs.
2. Issuance of payment_token (upon completion): Klarna issues a payment_token to the Acquiring Partner, which is required to finalize the payment. This part will be covered in the following section – Monitor the payment request state.