Grant access via Alternative methods

Explore alternative methods for granting Partners access to Klarna Partner Portal when the recommended Deep Link + AP Button approach cannot be implemented due to technical or business constraints.

Overview

When the recommended Deep Link + AP Button approach cannot be implemented, Klarna supports two alternative methods:

Method	Description	When to use
User Access Management API	API-based access for creating and managing semi-permanent user accounts in Klarna Partner Portal. Users receive invitation emails and set up their own passwords.	For Acquiring Partners without an admin portal or when Partners need to request access through a manual process.
Identity Provider (IdP) via SAML	Delegates authentication to your system using SAML v2.0 protocol. You become the Identity Provider, and Klarna acts as the Service Provider.	For Acquiring Partners with advanced technical capabilities to implement SAML IdP, providing seamless single sign-on experience.

These methods are alternatives to the recommended approach. They may require additional technical implementation or result in less seamless user experience. Discuss with your Klarna representative before choosing an alternative method.

User Access Management API

Klarna Partner Portal accounts can be created via createUserAccess API

endpoint.

When to use this method

Use the User Access Management API when:

You don't have a Partner-facing admin portal
Partners need to manually request access (e.g., via support ticket)
You want to manage Partner users programmatically
Long-term access without frequent re-authentication is preferred

How it works

1.
User requests Access: Partners request access through your defined process (e.g., support ticket, self-service form)
2.
Integration: Your system calls the User Access Management API to create access
3.
Email invitation: Klarna sends an invitation email to the Partner
4.
Partner activation: Partner follows the activation flow (accept T&Cs, set up password and 2FA)

Implementation steps

Important: This method requires JWT signing with a client certificate. If you haven't completed the JWT setup yet, follow the JWT signing setup.

Build and sign your JWT

After completing the JWT signing setup, create your JWT with the following structure:

Sample header

JSON

1 2 3 4 5 6

{
  "alg": "ES256",
  "typ": "JWT",
  "x5c": ["<your_cert_base64>"]
}

Sample payload

JSON

1 2 3 4 5 6 7 8 9 10

{
  "iss": "krn:partner:global:account:live:LYABCDEI",
  "jti": "a4728c02-9885-41bf-b539-251ffa7f7eaa",
  "sub": "portal.user@merchant.com",
  "iat": 1716768000,
  "exp": 1716768060,
  "account_id": "krn:partner:global:account:test:MB6KIE1P",
  "on_behalf_of": "krn:partner:global:account:test:MB6KIE1P",
  "roles": ["merchant:admin"],
  "expires_at": "2024-12-31",

Note: Unlike deep linking, the User Access Management API JWT does not require the amr field.

Payload structure

The JWT grants a user access to a single Partner Account per request.

Claim	Description
`iss`	Required. Partner Account ID of the requesting partner.
`jti`	Required. A unique token ID (a UUID is recommended).
`sub`	Required. Email of the user to give access to.
`iat`	Required. Time the token was issued, in seconds since the Unix epoch (UTC).
`exp`	Required. Expiration time (UTC). Must be no more than 60 seconds after `iat`.
`account_id`	Required. The Partner Account the user gets access to.
`on_behalf_of`	Optional. The Partner Account the user represents in Klarna Partner Portal. If omitted, defaults to `account_id`. When you act as an Acquiring Partner on behalf of a Partner Account you manage, use your own Partner Account ID.
`roles`	Required. The roles to assign to the user.

Optional JWT claims

The JWT can include the following optional claims to control access duration:

Claim	Description	Format	Example
`expires_at`	The date when the user's access expires. Must be a future date.	YYYY-MM-DD	`2024-12-31`
`inactivity_grace_period`	How long the access remains valid after user inactivity. Must be between 1 day and 6 months.	ISO 8601 duration	`P30D` (30 days) or `P3M` (3 months)

See the full JWT parameter documentation here API

Create user access

User access for Partners is created using a POST request to createUserAccess API

endpoint.

Request payload:

JSON

1 2 3 4

{
  "jwt": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.<....>SMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

On success, the endpoint responds with 204 No Content and dispatches an invitation email to the specified address. If that address is already registered, no new email will be sent.

You can define the level of access granted to the user by setting the roles array in the JWT payload.

What happens next:

1.
Klarna creates a Portal user for the supplied email (sub in JWT)
2.
Klarna gives the user access to the Partner Account specified in account_id
3.
Klarna sends an invitation email containing an activation link
4.
User follows the activation flow:
- 4.1.
  Accept Terms & Conditions
- 4.2.
  Update their given name and family name
- 4.3.
  Set up password
- 4.4.
  Configure two-factor authentication (2FA)

Deleting user access

User access can be deleted at any time. Make a DELETE request to deleteUserAccess API

endpoint, with optional query parameters:

Parameter	Description
`account_id`	The Partner Account ID of the access to delete
`on_behalf_of`	When specified, only the specific access with this `on_behalf_of` value will be deleted
`principal`	The ID or email of the user to delete the access from

Warning: If no parameters are supplied, all user access created by you will be deleted.

If both account_id and principal parameters are provided, they are combined to precisely target and delete the user's access to the specified Partner account.

Deleting a user's access always removes all of the user's access along with all associated access policies. Deletion cannot be scoped to individual access policies.

When user access is revoked, the user's access to the Partner account will be removed within 5 minutes.

Multi-account user access (future release)

The multi-account version: 2 payload isn't available yet. You can't use it in the test environment or in production today — it's planned for a future release. When released, a single createUserAccess request will grant a user access to one or more Partner Accounts (1–100) through an accesses array, with an optional access policy per entry.

This upcoming flow uses JWT payload version: 2 with a single top-level on_behalf_of and an accesses array, instead of the flat account_id and top-level roles claims used by the live flow above.

Sample version: 2 payload:

JSON

1 2 3 4 5 6 7 8 9 10

{
  "iss": "krn:partner:global:account:live:LYABCDEI",
  "jti": "a4728c02-9885-41bf-b539-251ffa7f7eaa",
  "sub": "portal.user@merchant.com",
  "iat": 1716768000,
  "exp": 1716768060,
  "version": 2,
  "on_behalf_of": "krn:partner:global:account:live:LYABCDEI",
  "accesses": [
    {

Future JWT payload claims:

Claim	Description
`version`	Required. Payload version. Set to `2`.
`on_behalf_of`	Required. The Partner Account the user represents in Klarna Partner Portal.
`accesses`	Required. List of access entries (1–100) to grant in a single request.
`accesses[].partner_account_id`	Required. The Partner Account the user gets access to.
`accesses[].roles`	Required. The roles to assign for that Partner Account.
`accesses[].access_policy_id`	Optional. An access policy that narrows which Payment Accounts the user can see within that Partner Account. It must belong to the entry's `partner_account_id`. All entries must consistently include or omit this field.
`accesses[].expires_at`	Optional. Expiration date for the entry, in YYYY-MM-DD format. Must be a future date.
`accesses[].inactivity_grace_period`	Optional. ISO 8601 duration for how long the access remains valid after user inactivity. Must be between 1 day and 6 months.

Acquiring Partner as Identity Provider (IdP)

An Identity Provider (IdP) is a system that authenticates users and authorizes their access to applications and services. In this setup, you act as the IdP and Klarna acts as the Service Provider (SP).

Benefits of IdP integration

By leveraging SAML v2.0, this setup ensures:

Secure Authentication: User credentials remain securely managed by your IdP
Policy Enforcement: Enables your security policies such as MFA
Enhanced Efficiency and Compliance: Centralized user management
Seamless SSO: Partners authenticate once and access multiple services

Prerequisites

Before implementing IdP integration, ensure you have:

SAML 2.0 IdP infrastructure in place
Ability to generate and sign SAML assertions
Certificate management capabilities
User attribute mapping configuration

Implementation steps

Provide Klarna with the required SAML configuration details:

IdP metadata XML or equivalent configuration
X.509 certificate for signing SAML assertions
IdP entity ID
Single Sign-On (SSO) endpoint URL
Single Logout (SLO) endpoint URL (if supported)

Klarna will complete the necessary configuration to accept SAML assertions from your IdP.

Step 2: Set up Klarna Partner Portal as the Service Provider

Configure Klarna Partner Portal to accept SAML assertions from your IdP
Enforce MFA during SAML authentication for enhanced security
Configure assertion consumer service (ACS) URL provided by Klarna
Set appropriate SAML binding (HTTP-POST recommended)

Step 3: Map user attributes

Define and map user attributes from your IdP to the corresponding Klarna Partner Portal users. Required attributes include:

Attribute	Description	Required
`email`	User's email address (used as unique identifier)	Yes
`account_id`	Partner Account ID in Klarna (e.g., `krn:partner:global:account:test:MB6KIE1P`)	Yes
`roles`	Array of role identifiers (e.g., `merchant:admin`)	Yes
`given_name`	User's first name	Optional
`family_name`	User's last name	Optional

Step 4: Handle SAML authentication requests

When Partners attempt to access Klarna Partner Portal:

1.
Klarna sends a SAML authentication request to your IdP
2.
Your IdP authenticates the user according to your policies
3.
Your IdP generates a SAML assertion with user attributes
4.
Your IdP signs the assertion and sends the SAML response to Klarna
5.
Klarna validates the assertion and grants access

Step 5: Testing

Before going live, test the complete SAML flow:

1.
Initiate authentication from Klarna Partner Portal
2.
Verify authentication redirects to your IdP
3.
Complete authentication at your IdP
4.
Verify successful redirect back to Klarna Partner Portal
5.
Confirm appropriate access based on roles

The SAML IdP solution requires coordination with Klarna for configuration. If you are interested in proceeding with this option for Klarna Partner Portal access, please reach out to your Klarna representative to discuss further.

Grant access via Deep Link

Klarna Partner Portal Overview

API & SDK references