Security

API Authentication standards

All server-side REST APIs require API keys for authentication, whereas the Klarna Web SDK uses Client IDs. Ensure all API requests are transmitted over HTTPS using TLS 1.2 protocol at a minimum. Attempts to connect without valid credentials or via plain HTTP will not succeed.

The API key should be included in the Authorization header for every request in the following format:

Authorization: Basic <API key>

The API key can be in it's raw form or base64-encoded.

If the API key is missing or incorrect, Klarna responds with 401 Unauthorized.

API keys are sensitive; handle them with utmost care.

Global authentication for Partner product API

For Klarna Partners working with multiple account_ids, you should consider the following:

• account_id must be included in the path for operations on a specific Partner or its resources (use the account_id returned by the Management API), e.g. /v1/accounts/{account_id}/payment/requests .

DDOS protection

Our integration APIs are fortified with active DDOS protection measures designed to stop traffic identified as illegitimate or exhibiting atypical behaviors. If a DDOS protection rule is triggered, the HTTP-status code 403 will be returned, absent the typical error information object.

Further information about rate limiting is available in the Rate limiting section.

IP Address Management

Effective API security requires careful management of the IP addresses used to access services. It is recommended to use a static IP address because dynamically allocated IPs might have been previously associated with malicious activities. This is particularly important in cloud environments, where IPs can be cycled between accounts if not explicitly architected. Reusing an IP with a history of abuse could lead to its inclusion on threat intelligence lists, potentially resulting in the blocking of legitimate service calls.

Communication security

The global API endpoint is exposed via 2 anycast static IPs, enabling partners to configure egress security measures within their IT infrastructure effectively.

The TLS certificates at API endpoints are issued by AWS Certificate Manager and are subject to automatic renewal as expiration approaches. We advise against reliance on specific certificate details, recommending instead trust in the root CA as outlined in the documentation.

Callbacks from Klarna will originate from specific IP addresses based on the environment, information which should be used to configure firewalls for enhanced security.

Mutual Transport Layer Security

Mutual Transport Layer Security (mTLS) is an enhanced communication security mechanism that adds extra layers of protection to make it more difficult for attackers to misuse leaked credentials. It ensures that both the client and server authenticate each other, making the communication more secure.

Klarna requires acquiring partners to implement mTLS to ensure the security of Partner integrations. For all other account types, it may be enabled manually by Klarna on request.

To enable mTLS for your Klarna account, follow these steps:

1. Reach out to the Klarna partner account team to enable mTLS for your account.
2. Create and Store Your Private Key using elliptic curve cryptography with the prime256v1 specification.
   • Example command:
     Copy

     Copied

     openssl ecparam -genkey -name prime256v1 -out my-key-file.pem

3. Create a Certificate Signing Request (CSR):
   • The Common Name (CN) in the CSR should be the last part of your account ID.
   • For example, if your account ID is krn:partner:global:account:live:LYABCDEI, the CN should be LYABCDEI.
   • Example command:
     Copy

     Copied

     openssl req -new -key my-key-file.pem -out csr.pem -subj "/CN=LYABCDEI"

4. Send the CSR to the Klarna account team. Klarna will return the certificate via Yopass (a secure sharing service).
5. Use the issued certificate and private key to establish connections to the Klarna API.After the certificate has been returned, the APIs will return an response header including the status of the MTLS verification. The header returned is “Klarna-Mtls-Verification-Status” and the value is one of “NOT_PRESENT”, “VALID” and “INVALID” so that the configuration can be verified beforehand.
6. When the integration has been setup and requests returns “VALID” status contact the Klarna account team and communicate from which time mTLS should be enforced
7. At the activation time the mTLS client certificate will be verified on all API-requests and the status header will stop being returned.

Important notes

• CSR Requirements : The CSR should only include the CN and no extra attributes.
• Certificate Validity : The issued certificate is valid for 3 years. You need to monitor its expiration and initiate the renewal process in advance.
• Multiple Certificates : You can have up to 10 active certificates at a time.
• Revoking Certificates : Before revoking an active certificate, ensure a new certificate is issued and installed. Use the partner API to revoke the certificate.

Certificate rotation process

1. Issue a New Certificate following the same steps to create and submit a CSR.
2. Install and Test the New Certificate, ensuring the new certificate works correctly.
3. Revoke the Old Certificate, using the partner API to revoke the old certificate after confirming the new one is functioning.

By following these steps, you can ensure a secure and smooth setup of mTLS for your Klarna account.

Security protocols and recommendations

Security protocols vary by integration and should be assessed individually. However, some universal requirements include:

• Maintaining up-to-date security across all system components, promptly applying the latest patches, and employing a thorough testing process before deployment.
• Carrying out regular fraud assessments to pinpoint and address potential security issues.
• Limiting administrative rights strictly to those who need them, adhering to the principle of least privilege.
• Keeping a formal log of all individuals with access to Klarna systems and ensuring access is granted via corporate email addresses.
• Regularly monitoring and updating access rights , especially after an employee's role changes or departure, and conducting periodic access reviews.
• Avoiding shared accounts to ensure actions can be attributed to individual customers.
• Enforcing the use of strong passwords (14 or more characters) and enabling two-factor authentication (2FA) where feasible.
• Encrypting stored secrets and not keeping them in plaintext.
• Considering suppliers and third-party providers within the organization’s overall security strategy and conducting appropriate evaluations.
• Enabling logging for sensitive actions and monitoring for suspicious activities. Klarna mandates that partners report any suspicious activities through Partner support or the Partner portal chat. This includes unusual Klarna transaction processes. Such collaborative vigilance is crucial in detecting and mitigating potential threats early, ensuring a secure environment for all parties involved. Klarna reserves the right to disable API keys upon detecting any evidence of potential compromise. Adherence to these guidelines is essential for maintaining robust security standards and protecting against potential vulnerabilities.

Authentication type by service

Two authentication methods are used in the platform: API authentication via an API key and a client ID, employed to authenticate the calling account.

• The API key is highly confidential and must never be exposed in clear-text beyond an API request.
• The client-id is used in a browser environment and is not secret in itself, it must be configured with a list of approved websites from which it’s approved to be used which will prevent some fraud scenarios Both API-keys and client-ids are signed tokens which are verified by the platform to ensure the integrity of the information.

The pattern for both API-keys and client-ids are:

• Client ID structure: klarna_<live|test>_<client>_<random>
• Client ID Example: klarna_test_client_elZGI1B5dHBIRWcjZrNldnbEVj[...]uefnc3
• API Key Structure: klarna_<live|test>_<api>_<random>
• API Key Example: klarna_live_api_elZGI1B5dHBIRWltRjF5cjZrNldnbEVjKnIqeC[...]Uybz0

The authentication information used by features of the platform:

Testing

Klarna uses best practices to secure the environments, including but not limited to automated security scanning, penetration tests, white and blackbox testing and resiliency testing.

To ensure the operational characteristcs for all of our customers the following rules apply.

Unauthorized Testing

Do not perform any form of vulnerability scanning, penetration testing, performance testing, stress testing, denial-of-service simulation, or related activities on Klarna systems, networks, APIs, services, or infrastructure in any environment.

Permitted Testing Exception

Limited performance testing is allowed only in Klarna’s designated test environment and must strictly follow Klarna’s specific guidelines and restrictions, as specified here.

Enforcement Measures

Any unauthorized testing activities may lead to immediate remedial actions, such as service suspension, payment withholding, or legal proceedings.