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.
All Klarna Services and their corresponding endpoints are categorized within the following 3 types:
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 |
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
States the actual time when the Service Features are not responding request less any downtime with exception of:
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 |
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.