Authentication

How to authenticate against Klarna's XS2A v2 (Berlin Group openFinance) PSD2 API using mutual TLS with an eIDAS QWAC, the QWAC validity changes under the new TLS rules, the accepted QTSPs, and how to access the sandbox.

9 min read

Every request to the XS2A v2 API is made over mutual TLS (mTLS). You authenticate by presenting a valid eIDAS certificate during the TLS handshake; Klarna validates it, extracts your PSD2 identity and roles, and authorizes the request.

How authentication works

1.
You open a TLS connection to the API and present your certificate as the TLS client certificate.
2.
Klarna validates the certificate chain against the trust anchors of the accepted QTSPs, and checks the certificate's validity period (notBefore / notAfter). Revocation checking is planned and is not performed yet.
3.
Klarna reads your PSD2 identity from the certificate — the organizationIdentifier (OID 2.5.4.97, for example PSDDE-BAFIN-123456) and the PSD2 roles from the QcStatements extension (OID 1.3.6.1.5.5.7.1.3).
4.
The requested operation is authorized against your role(s) — PSP_AI for account information, PSP_PI for payment initiation, PSP_IC for confirmation of funds (planned — the role is accepted in the certificate, but no funds-confirmation endpoint is available yet; see PSD2 roles for the full list).

You must present the certificate on every request. Without a valid client certificate from a trusted CA the connection is refused during the TLS handshake and you get no HTTP response. If a certificate passes the handshake but is invalid, expired, or does not carry the role required for the operation, the API responds with a 401 and a structured error (a certificate that cannot be parsed is a 400) — see Certificate validation and errors.

Certificate requirements

You authenticate with a QWAC (Qualified Website Authentication Certificate, eIDAS Art. 3(39)). In the 1‑QWAC model the QWAC is the TLS client certificate you present on the mTLS connection.

The QWAC must follow the PSD2 profile (ETSI TS 119 495): a valid organizationIdentifier, the PSD2 QcStatements listing your authorized role(s), and a chain that validates against the production eIDAS trust stores.

Klarna does not currently require a QSEAL (Qualified Certificate for Electronic Seal). This may change in a future milestone — any such requirement will be announced here and in the change log before it takes effect.

QWAC validity is shrinking — enforcement is planned

QWACs used for TLS are subject to the CA/Browser Forum maximum-validity schedule, which is being reduced in steps. This applies to QWACs through the EU regulatory chain — Commission Implementing Regulation (EU) 2025/2527 (applies 6 January 2027) adopts ETSI EN 319 411-2, whose QEVCP-w policy defers the maximum validity period to the CA/Browser Forum rules — and is enforced in practice today by root-program inclusion.

QWAC issued	Maximum validity
Before 15 March 2026	398 days
15 March 2026 – 14 March 2027	200 days
15 March 2027 – 14 March 2029	100 days
From 15 March 2029	47 days

(QTSPs typically issue one day below the cap — so ~199 / ~99 / ~46 days in practice.)

Klarna plans to apply this schedule and reject non-compliant certificates, but does not enforce it yet. Today the only validity check is the certificate's own notBefore / notAfter period. Once enforcement starts, a QWAC whose validity period exceeds the maximum permitted for its issuance date will be rejected at authentication. Because the windows shorten over time, plan for automated certificate rotation so a freshly issued, compliant QWAC is always in place well before the current one expires.

Accepted QTSPs

Production is not yet live — see Regulated timelines for switching to the new API for the launch schedule. Once live, Klarna validates your certificate against the trust anchors of the Qualified Trust Service Providers (QTSPs) configured for Production. The complete list will be added here; at launch the following QTSPs are accepted:

QTSP	Country	Description
DigiCert (QuoVadis Trustlink B.V.)	NL / EU	Pan-European QTSP issuing PSD2 QWACs through its CertCentral Europe platform.
D-Trust	DE	Qualified trust-service provider and Bundesdruckerei company; widely used by German banks for PSD2 certificates.
Bundesdruckerei	DE	German federal security-technology group and parent of D-Trust, offering PSD2 eIDAS certificates.

Using a different QTSP? If your certificate is issued by a QTSP that is not in this list, contact us at support.xs2a.banking@klarna.com with your QTSP and its trust anchors (root / intermediate CA certificates), and we will add it to our environments. Any QTSP holding a valid "granted" status for the relevant service on the EU Trusted List can be added.

Certificate validation and errors

Every request is authenticated by mutual TLS at the edge: a connection without a valid client certificate from a trusted CA is refused during the TLS handshake, before any HTTP request is made. For a certificate that passes the handshake, the API then parses and validates it, and failures return a structured error with one of the following codes:

Code	Meaning
`CERTIFICATE_MISSING`	No client certificate reached the API. You typically won't see this code, because a connection without a client certificate is refused at the TLS handshake.
`CERTIFICATE_INVALID`	The certificate could not be parsed (HTTP `400`), has no TPP identifier, or carries no usable TPP role.
`CERTIFICATE_EXPIRED`	The certificate is past its validity period.
`CERTIFICATE_REVOKED`	Planned — not returned yet. The certificate has been revoked by the issuing QTSP.
`CERTIFICATE_BLOCKED`	Planned — not returned yet. The certificate is blocked.
`ROLE_INVALID`	The certificate is valid but does not include the role required for the requested operation.

These errors are returned with HTTP 401; the one exception is a certificate that cannot be parsed, which is a 400 CERTIFICATE_INVALID. The body is {"apiClientMessages":[{"category":"ERROR","code":"CERTIFICATE_MISSING","text":"Client certificate required"}]}.

A certificate that is not issued by a trusted CA likewise fails the TLS handshake before reaching the API.

Sandbox access

The sandbox uses the same mTLS mechanism as production. A certificate that can access production can also access the sandbox, and Klarna's own Sandbox Root CA is an additional trust anchor for the sandbox. Request a dedicated sandbox test certificate — see Getting a sandbox test certificate.

Legacy test certificate

The test certificate shown on Legacy XS2A API Integration works only with the legacy XS2A API, and the v2 sandbox does not accept it. Use the self-service flow in Getting a sandbox test certificate.

Base URLs for each environment are listed in URLs and environments. Sandbox test accounts and how to drive SCA outcomes are listed in Sandbox test data.

Getting a sandbox test certificate

Request a dedicated sandbox test certificate through our self-service flow — no support ticket needed:

1.

Generate a CSR. You generate the certificate signing request (CSR) and keep the private key yourself — only the public key is sent to Klarna. For example, with OpenSSL:

SH
1 2 3
openssl req -new -newkey rsa:2048 -nodes \ -keyout sandbox.key -out sandbox.csr \ -subj "/CN=your-company-sandbox"

RSA (2048–4096 bit, exponent 65537) and EC (P-256 / P-384) keys are both accepted. The CSR's subject and any requested extensions are ignored — Klarna assigns the certificate's identity — so the -subj value above is just a placeholder.
2.

Submit a request — POST https://xs2a-newsletter.banking.klarna.com/v1/sandbox/tpp-certificates with a JSON body containing your email address, the PEM-encoded CSR, and optionally a company name (used as the certificate's common name):

JSON
1 2 3 4 5
{ "email": "you@company.com", "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIBoTCCAQoCAQAwHDEaMBgGA1UEAwwReW91ci1jb21wYW55LXNhbmRib3gw...\n-----END CERTIFICATE REQUEST-----\n", "companyName": "Your Company AB" }

Paste the full contents of sandbox.csr as the csr value, keeping the \n line breaks. email must be the plain mailbox address — subaddressing (a + tag) is rejected. companyName is optional.
3.

Confirm by email — you will receive a one-time link at the address you submitted. Opening it and confirming triggers issuance; the link can only be used once and expires after 30 minutes.
4.

Download your certificate — a signed client certificate (PEM) for the Sandbox only. We assign the certificate's PSD2 roles (PSP_AI, PSP_PI, PSP_IC) for you. The certificate is valid for 180 days, after which you repeat the process for a new one.

This certificate is Sandbox-only and cannot be used against Production — Production always requires a QWAC issued by an accepted QTSP.

To prevent abuse, a request for the same email address can be repeated at most once every 15 minutes, and each IP address may make at most 3 requests per 10 minutes.

If you run into trouble with certificate issuance, contact support.xs2a.banking@klarna.com.

Simulating Strong Customer Authentication (SCA)

There is no real Klarna app in the Sandbox to approve or reject an authorization, so the Sandbox resolves each SCA automatically based on the PSU email address you send as PSU-ID when you start the authorization of the consent or payment. Append a tag to the local part of one of the test PSU emails using a + suffix:

Tag	Behavior
`+confirm`	Authorization is confirmed (default if no tag, or an unrecognized tag, is present).
`+deny`	Authorization is rejected.
`+confirm<N>s`	Authorization is confirmed after an `N`-second delay, for example `+confirm30s`.
`+deny<N>s`	Authorization is rejected after an `N`-second delay, for example `+deny30s`.

For example, john.doe+deny10s@example.com rejects the authorization after 10 seconds. Every authorization resolves no sooner than 3 seconds after it is started, so +confirm1s also resolves after 3 seconds; without a delay tag the Sandbox resolves after those 3 seconds, to mimic a real customer interacting with their banking app. If the requested delay exceeds the authorization's SCA validity window (10 minutes), the authorization expires instead of resolving.

This behavior is specific to the Sandbox — in Production, SCA is always completed by the PSU in their Klarna app.

Jump to section...