Ecosystem

Environments

Klarna provides both test and live environments, each designed to support seamless global integration of the Partner management API, Partner product API, and other Klarna products, irrespective of your location, the customer’s origin or other particular considerations.

Klarna Partners are required to make both test and live environments available to all Partners integrated via their services to allow for the validation of their Klarna integration. All payment services available in production are required to be included in this availability. Klarna requires that accounts in any environment not be shared across multiple Partners.

These environments function entirely independently of each other, and may behave differently as a result of the below considerations:

• Access and authentication: different base URLs and credentials are used to access the live and test environments.
• Functionality: the test environment simulates the live environment but lacks active fraud assessments, including any identity or address detail validation. Any atypical flow needs manual initiation through test triggers.
• Data security: the test environment does not use One-time passwords (OTP), making it inappropriate for sharing Personal Identifiable Information (PII). PII entered into the test environment is replaced with synthetic data, which means response values might vary unless Klarna's sample data is used. This approach minimizes data leak risks.
• Settings: Adjustments made in one environment do not affect the other. For instance, changes to branding or product offering made in the test environment won't impact the live environment.
• Transactions and accounts: transactions or accounts created in one environment do not transfer to the other. For example, transactions placed in the test environment will not appear in the live environment.

Endpoints

Global base URLs are provided to optimize latency and enhance fault tolerance.

Callbacks

Callbacks from Klarna will originate from specific IP addresses for each environment.

Versioning and deprecation

Klarna is committed to ensure that updates to our APIs are backward compatible whenever possible, allowing your systems to continue running smoothly as new features are introduced. Should there be any breaking changes, these will be implemented under a new API version. Examples of breaking changes:

• Removal of ENUM values
• Removal of actions (HTTP Methods)
• Removal of resources/Endpoints
• Change in state machine transitions, or introduction of new states

Backward-compatible changes

We classify certain updates as backward-compatible, meaning they should not require modifications on your side to continue using the API effectively. Your integration should be capable of handling the following changes:

• Adding new API resources: introduction of new endpoints or resources will not affect existing functionality.
• Adding new optional request parameters: new parameters added to existing API methods will not alter the behavior of existing calls; they will provide additional functionality if you choose to use them.
• Adding new properties to API responses: additional fields in API responses are designed to be ignored by partners who do not expect them, ensuring compatibility with older versions.
• Changing the order of properties: the sequence of properties in API responses may vary, but this will not impact integrations that rely on proper key-based parsing instead of the order of data.
• Adjustments to opaque strings: changes to the format of strings such as IDs.
• Introducing new event types: new events might be added to our webhooks, if they are optional, and do not affect the behavior of the existing integration. Ensure your webhook listeners are prepared to handle atypical event types gracefully, either by logging them for review (recommended) or safely ignoring them.

Ensure a high-quality integration

To optimize your integration and prepare for future updates, ensure you are following Klarna’s recommendations:

• Flexible data handling: implement flexible data parsing that can accommodate additional fields without causing errors or disruptions.
• Regular updates: stay updated with our latest API documentation and changes. Regular updates to your integration can help leverage new features and enhancements while maintaining compatibility. Klarna will keep you informed about deprecations.
• Error handling: develop robust error handling mechanisms to manage unexpected API responses or failures gracefully. This minimizes the impact on the customer experience and makes your application more resilient. By adhering to these guidelines and preparing your integration for both backward-compatible changes and keeping your integration up-to-date with the latest API version from Klarna will ensure a seamless interaction with Klarna's evolving API landscape.

Availability and latency

Find here details of service level commitments related to Klarna’s solutions. This includes the execution of API calls related to the creation of new transactions from an accounts website through Klarna’s API as well as other features and functionalities that may be provided as part of our product suite.

Latency

The latency of a service indicates the time to get a response to a request done to Klarna service. This latency is measured and calculated on all requests at the 99 percentile and at the edge of the region in which the service is deployed. This latency however, does not include Internet network latency impact.

Availability

The availability of a service indicates that it is error-free and fully usable and functional. It is directly associated with the number of requests processed correctly and that results in responses received with status code being 2xx, 3xx and 4xx in a given month. Availability data does not include cases if, for some functional reason, there is no traffic. It is calculated as follows: A %= [ SR/ R ] * 100 where:

• A means the availability in % during a given month.
• SR means the total number of successful requests responded with 2xx , 3xx and 4xx during a given month.
• R means total number of requests performed during a given month.

Downtime

Downtimes in Klarna’s payment services reflect the actual time when a Klarna solution is not responding to requests with status code being 2xx, 3xx or 4xx. It is important to note that the following scenarios are not considered downtime:

• Unavailability due to circumstances that are outside of Klarna’s control such as force majeure which affects all of Klarna’s redundant and geographically dispersed production sites.
• Any unavailability or downtime attributable to acts or omissions of Klarna Partners, Third Party Payment Option Providers, banks or other external data providers.
• Unavailability caused by or attributable to the Klarna partner and/or any of the Partners contractors, suppliers or any other third party that the Partner cooperates with.
• Unavailability due to maintenance downtime. Transactional services are designed to be zero downtime, however in the exceptional case that maintenance downtime is required, Klarna will inform this via our Status monitor system with at least 7 days in advance.

Technical support

Customer support for Partners is available by email, chat or telephone from 9:00 to 17:00 local time on business days (Monday to Friday). Weekend availability is based on the market and may vary, check specific market availability here.

Web SDK

Klarna.js is a Web SDK that bundles all our products, including payments and Boost products. This SDK will allow you to handle your most frequent use cases easily, with a few lines of code, and allowing customization for additional edge cases.

Our API is primarily redirect driven, but will run on-page through modal when supported by the device. The same integration pattern can be used for both redirect and on-page mode. This means that the SDK survives a loss of JavaScript context and can restart itself.

To learn more on how to integrate Klarna leveraging Klarna's SDK, see Recommended integration: Klarna.js section. Consult the SDK reference for a complete description of the specifications.

Mobile SDK

Klarna Mobile SDK enables Klarna services to work seamlessly within a native mobile app. The Mobile SDK supports Klarna Payment Services, Klarna Express checkout, Sign in with Klarna, On-Site messaging, and more, using technologies like Kotlin, Swift, JavaScript, and Typescript.

This SDK is the recommended default way to use Klarna products in mobile applications. This is mainly due to the limitations of the WebViews in both iOS and Android. The SDK adds iOS/Android native components and lets Klarna services overcome those issues with a communication between web and native environments.

Not using the Mobile SDK can degrade your Klarna integration and may prevent customers from completing their payments because:

• Third-party banks and card processors may block or restrict interactions through WebViews.
• Cookies in WebViews are handled differently, causing additional friction during checkout.
• WebViews don't handle navigation to third-party applications for authorization and authentication, while the Mobile SDK does.
• The App Handover feature enabled by Mobile SDK allows seamless redirection for authentication and consent within the Klarna app, enhancing security and streamlining processes.
• The Mobile SDK supports SSO/"Remember me" across apps, enabling shared login and pre-filled customer details, making it easier for returning customers.