Enable Partners to access Klarna's Partner Portal securely to manage Conversion features, retrieve credentials, and complete integration setup within Klarna's ecosystem.
Why grant access to Klarna Partner Portal
As an Acquiring Partner, you need to make sure your Partners have access to the Klarna Partner Portal so they can manage their Klarna setup effectively. The Portal is where they enable Conversion features, create and manage credentials to support their Klarna integration, and handle operational tasks such as Disputes. Providing the right access helps ensure they can optimize performance and maximize sales.
Depending on your Acquiring Partner agreement with Klarna, Partners may not have access to Dispute management functionality or other Portal features.
Access methods
Klarna supports multiple methods for granting Partners access to the Portal.
| Classification | Description | Applicability |
|---|---|---|
| Recommended Methods | Deep Link: A complete solution with two entry points:
Both use signed JWT tokens for secure, passwordless access with MFA enforced on your portal. | Suitable for all Acquiring Partners with a Partner-facing admin portal. |
| Alternative Methods | Two alternative approaches when the recommended method cannot be implemented:
| For Acquiring Partners with technical constraints or without admin portal capabilities. |
The recommended approach combines two entry points that work together as a complete package, providing the best user experience by:
- Eliminating password setup - Users authenticate through your existing system
- Supporting audit-ability - All access is managed through your portal
- Ensuring non-repudiation - Signed JWT tokens provide security guarantees
- Offering flexibility - Partners can access from either your portal or Klarna's login page
Common concepts
The following concepts apply across all access methods and are essential to understand before implementing any solution.
Roles
Roles define the level of access granted to the user. When provisioning access, you must specify one or more roles.
| Role | Description |
|---|---|
| Provides full access to all apps defined within the Acquiring Partner agreement with Klarna. Enables Partners to manage all aspects of their Klarna integration. |
| Provides access to developer-focused apps for implementing Klarna. Allows creation of client-side tokens and implementation of Klarna Conversion features. |
| Provides access to apps that assist support agents in helping Partners with their Klarna integration. |
On behalf of
The on_behalf_of parameter represents what account the user is acting on behalf of when accessing the portal. This parameter is used to determine the appropriate permissions.
How it works
- If
on_behalf_ofis set to the Acquiring Partner's Account ID: The user represents the Acquiring Partner while accessing a sub-account. They receive different permissions (e.g., read-only access to certain apps). - If
on_behalf_ofis set to the same value aspartner_account_id: The user represents that same account and receives full write access to manage their own account.
Default behavior
This parameter is optional. When not set, it defaults to the same value as the partner_account_id parameter.
The on_behalf_of parameter is supported by Deep Link and User Management API methods. It is not used when implementing IdP (SAML) authentication.
Prerequisites
Before implementing any access method, ensure you have:
- Acquiring Partner Account ID: Your Klarna account ID (e.g.,
krn:partner:global:account:live:LYABCDEI) - API Credentials: Access to Klarna Management API with appropriate permissions
- Partner Account IDs: The account IDs of Partners you want to grant access to
- User Information: Email addresses of users who need access
- Agreement with Klarna: Any links or buttons presented between your Partner-facing admin portal and Klarna Portal must be agreed upon and signed off in accordance with Klarna's user experience guidelines
JWT signing setup (for Deep Link and User Management API)
The Deep Link method and the User Access Management API require JWT signing with a client certificate. This is a "one-time setup" that enables both methods.
Note: If you're implementing IdP (SAML) authentication, you can skip this section as it doesn't use JWT signing.
Step 1: Generate your private key
Use OpenSSL with the prime256v1 curve:
openssl ecparam -genkey -name prime256v1 -out private-key.pem
Store private-key.pem securely in your secrets manager. Never commit this file to version control or expose it publicly.
Step 2: Create a Certificate Signing Request (CSR)
The Common Name (CN) in the CSR must be the last segment of your account ID:
| Account ID | CN |
|---|---|
|
|
openssl req -new \
-key private-key.pem \
-out csr.pem \
-subj "/CN=LYABCDEI"
Step 3: Submit CSR and retrieve public certificate
Submit your csr.pem via the createCredentialsClientCertificate
JWT_SIGNING for the usage parameter.
Before sending the csr.pem file in the API request, you must format its content as a JSON-compatible string using:
In the response, you'll get your public certificate in PEM format:
-----BEGIN CERTIFICATE-----\n
MIICFT...Z9hBA==\n
-----END CERTIFICATE-----
Step 4: Prepare the x5c header value
- Remove the
-----BEGIN CERTIFICATE-----and-----END CERTIFICATE-----lines - Delete all
\ncharacters so the Base64 data is one line - Place in the JWT header as:
"x5c": ["MIICFT...Z9hBA=="]
Setup complete! You can now use this certificate to sign JWTs for both Deep Link and User Access Management API methods. The same private key and certificate work for both.
Next steps
Choose the implementation method that best fits your technical capabilities:
- Recommended: Implement Deep Link for the best user experience
- Alternative: Explore alternative methods if the recommended approach cannot be implemented