Klarna service level
Klarna Services status can be monitored 24/7 via our Operational Status site. This Portal will also enable Information on past incidents as well as a subscription option to receive updates via email, SMS or RSS.
Klarna Service Level Objectives described on this page are only applicable to regional integration APIs and should be considered public and general guidelines for reference only. A Service Level Agreement attachment could be added to your partnership agreement with Klarna upon request.
Service Features Types
All Klarna Services and their corresponding endpoints are categorized within the following 3 types:
- Transaction Critical Services: refers to any functionality of the Services that constitutes a purchase critical dependency, i.e. a functionality of the Service that directly affects the Customers’ possibility to finalize purchases via Klarna Payment Services in the Merchant’s Store or any other purchase channel supported.
- Transaction Non-critical Services: refers to any functionality of the Services that constitutes a purchase non-critical dependency, i.e. ability to programmatically manage disputes via Klarna’s Payment Services API’s.
- Additional Services: Refers to any functionality or feature provided via Klarna’s Services that does not fall within the scope of the Transaction Critical or Transaction Non-critical Services. Includes but is not limited to:
Service Level Objectives
Latency
Latency states the time to respond to a request from a Transaction service in milliseconds and is measured on all requests at the 99 percentile and at the edge of the region the service is deployed in and does not include Internet network latency.
Latency objectives vary per endpoint based on the level of complexity in the corresponding processing as follows:
Product | Operation / Technical name | Latency p99 |
---|---|---|
Payments API | Create payment Session payments-acquiring-service_/payments/v1/sessions_post | 150ms |
Authorize and place order payments-acquiring-service_/payments/v1/authorizations (POST) | 500ms | |
Tokens API | Place order on token tokens-acquiring-service_/customer-token/v1/tokens (POST) | 5000ms |
Hosted API | Create payment Session klarna-payments-hosted-payment-page_/hpp/v1/sessions (POST) | 200ms |
Order Management API | Read operations order-management-api_/ordermanagement (GET) | 800ms |
Other operations order-management-api_/ordermanagement | 1000ms | |
Settlements API | Read operations settlements-api-node_/settlements/v1 (GET) | 6000ms |
Disputes API | All operations disputes-api_/disputes/v2 | 4000ms |
VCN API | Create promise /merchantcard/v3/promises (POST) | 150ms |
Create a card settlement /merchantcard/v3/settlements (POST) | 1000ms | |
Other operations /merchantcard/* | 1000ms |
Availability
This objective states the accessibility of a Service and its capability to be fully usable and functional on a monthly basis.
Availability objectives may vary per Service Feature type and by default are as follows:
Service feature type | Availability |
---|---|
Transaction Critical Services | 99% |
Transaction Non-critical Services | 99% |
Additional Services | 99% |
This is calculated by dividing the number of requests processed correctly (responses having status code being 2xx, 3xx and 4xx) by the total number of requests during the time window.
Availability data does not include cases if, for some functional reason, there is no traffic and is calculated as follows:
A %= \[ SR/ R \] \* 100
- A means the Availability in % during a Measurement Period.
- SR means total number of requests responded with 2xx, 3xx and 4xx during a Measurement Period.
- R means total number of requests performed during a Measurement Period.
Unavailability and maintenance downtime
States the actual time when the Service Features are not responding request less any downtime with exception of:
- 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 Acquirers, Third Party Payment Option Providers, banks or other external data providers.
- Unavailability caused by or attributable to the Merchant and/or any of the Merchant’s sub-contractors, suppliers or any other third party that the Merchant cooperates with.
- Unavailability due to Maintenance Downtime.
You should check any schedule maintenance downtime here. |
---|
Definitions | Threshold |
---|---|
Maximum number of maintenance downtime occasions | 5 times per year |
Maximum maintenance downtime in hours | 15 hours per year |
Communication of maintenance downtime | 7 days in advance |
Technical support
Regular customer support for Merchants is available by email, chat or telephone from 9:00 to 17:00 on local business days (Monday to Friday). Weekend availability is based on the market.
Check market availability here.