Age Verification with Sign in with Klarna

Quick account creation with social login and consented verified profile data (verified email, phone, name, and date of birth) to speed up checkout and enable age-gating. Approved by the KJM, the German Commission for the Protection of Minors in the Media, this product meets the standards required for compliant age verification.

Early access product – Integration is limited to selected, pre-approved Partners only.

Sign in with Klarna (powered by the Identity API) lets customers use their Klarna account to sign up and sign in without passwords, and when they consent, share verified profile data with you. This reduces registration friction and enables faster, prefilled checkout experiences.

Partner checkout	Pre-filled checkout	Verified profile data

Prerequisites

Klarna Partner Portal access and API key (authorization: klarna_api_key).
Partner Account identifier {partner_account_id}.
Redirect/app return URLs for the chosen interaction method (e.g., HANDOVER).
Ability to store tokens and personal data securely; request only needed scopes.
For how to present, style, and brand the Sign in with Klarna button, see Styling the Klarna button.
Consent screen configuration: provide the following for the consent screen:
- Privacy URL and Terms URL — required for Sign in with Klarna. Must point to the Partner's privacy policy and terms of service (or equivalent).
- Logo and name — same as for standard Klarna integration; used to identify the Partner on the consent screen.

Integration overview

Create an identity request (state starts as SUBMITTED).
Handover/redirect the customer to Klarna to authenticate and consent.
Read the identity request state until COMPLETED.
Use the returned customer_token to finalize login/account linking and (when requested and consented) access verified attributes to prefill checkout.

Identity request states

State	Description
`SUBMITTED`	The identity request has been created. The customer has not yet been handed over to Klarna or has not started the sign-in flow.
`IN_PROGRESS`	The customer has been redirected to Klarna and is in the sign-in or consent flow.
`COMPLETED`	The customer completed sign-in and consent. Identity is verified; use the returned `customer_token` and profile data to complete login and prefill.
`DECLINED`	The customer failed the verification or abandoned the flow. Do not use the request for login; you may create a new identity request if the customer tries again.

Integration details

1. Initiate the identity flow (create request)

Use createIdentityRequest API

to start the flow. The new request starts in the SUBMITTED state. The same path is served on both base URLs (see Endpoints).

Path: POST /v2/accounts/{partner_account_id}/identity/requests
Production: https://api-global.klarna.com/v2/accounts/\{partner_account_id\}/identity/requests
Test: https://api-global.test.klarna.com/v2/accounts/\{partner_account_id\}/identity/requests
Headers:
- Klarna-Idempotency-Key (required)
- Partner-Correlation-Id
Body (summary):
- request_customer_token (include scopes)
- customer_interaction_config (e.g., method: HANDOVER, return_url, app_return_url)

customer_interaction_config fields

Field	Description
`method`	Interaction method. Use `HANDOVER` to redirect the customer to Klarna for authentication.
`return_url`	Web URL where Klarna redirects the customer after authentication. Supports template variables (see Template variables below).
`app_return_url`	Mobile application return URL using an app scheme deeplink (not http/https). Used to return customers to the partner's mobile app after being redirected to another app (e.g., Klarna app or banking app) for authentication steps. The URL should restore the app to its last state without triggering navigation or state changes.

In customer_interaction_config, set method: HANDOVER to redirect the customer to Klarna. return_url supports template variables (see Template variables), and app_return_url takes an app-scheme deeplink (not http/https) to return the customer to your mobile app. Include known customer details under supplementary_enrollment_data to prefill and validate identity (see Pre-fill customer data).

JSON

1 2 3 4 5 6 7 8 9 10

{
  "request_customer_token": {
    "scopes": [
      "customer:login",
      "profile:verified:name",
      "profile:verified:date_of_birth",
      "profile:email",
      "profile:phone",
      "profile:billing_address"
    ]

2. Pre-fill customer data (optional but recommended)

You can optionally include known customer information in supplementary_enrollment_data.customer to:

Prefill forms during the enrollment flow to speed up the sign-up process.
Enable identity validation — Klarna compares the prefill data you provide with the authenticated customer's verified identity to detect potential account mismatches.

How identity validation works

Klarna compares the prefill data you provide with the authenticated customer's verified information. If there's a mismatch (for example, the customer's verified email, phone number, or name differs from your records), Klarna can help prevent account takeover by identifying that the verified Klarna customer identity doesn't align with your stored account details.

When you use the profile:verified:name or profile:verified:date_of_birth scopes, Klarna guarantees that these fields are verified before they're returned. This process is essential for identity validation, as it ensures your prefill data is checked against the customer's verified identity.

If verification cannot be completed, such as when customer details are unverifiable, the request may require the customer to take additional actions before completion.

3. Handover the customer

Redirect the customer to Klarna based on your customer_interaction_config to authenticate and grant consent.

4. Handle the web redirect

On a successful login, Klarna redirects the customer back to the URL you defined in customer_interaction_config.return_url.

Use redirect callbacks, not polling. Always rely on the redirect callback to be notified when the identity request is completed. Do not poll the GET endpoint repeatedly to check for state changes.

Template variables

You can include template variables in your return_url to receive identity request data in the redirect. Klarna replaces these variables with actual values when redirecting the customer.

Variable	Description
`{klarna.identity_request.id}`	The unique identifier of the identity request.
`{klarna.identity_request.state}`	The current state of the identity request (e.g., `COMPLETED`, `DECLINED`).

Example return_url with template variables:

TEXT

https://www.example.com/klarna/callback?klarna_identity_request_id={klarna.identity_request.id}&request_state={klarna.identity_request.state}

Use the identity_request_id from the query parameter to read the full request state and retrieve customer data.

5. Read request state

Use readIdentityRequest API

to read the current state of the request. When the state is COMPLETED, store the returned customer_token and create an account for the customer using the data returned in the request.

Path: GET /v2/accounts/{partner_account_id}/identity/requests/{identity_request_id}
Store customer_token
Create an account for the customer using the data returned in the request

Session expiration. Identity request sessions expire after 1 hour. Attempting to query an expired session results in a 404 Not Found response.

Sample response

JSON

1 2 3 4 5 6 7 8 9 10

{
  "identity_request_id": "krn:partner:eu1:test:identity:request:0daf4df6-00b2-48cc-9165-c425cfcb36fe",
  "state": "COMPLETED",
  "previous_state": "IN_PROGRESS",
  "request_customer_token": {
    "scopes": [
      "customer:login",
      "profile:verified:name",
      "profile:verified:date_of_birth",
      "profile:email",

When the request state is COMPLETED, use customer_token to establish the session and — when requested and consented — access verified attributes to prefill checkout.

7. Forward the Klarna Network session token to your Acquiring Partner

When the identity request reaches COMPLETED, the response includes a klarna_network_session_token (KNST) in state_context alongside klarna_customer. The KNST securely transfers the Klarna session context from the Sign in with Klarna flow to your Acquiring Partner, who then carries it into payment authorization with Klarna.

flowchart LR A[Klarna<br/>Sign in with Klarna] --> B[You] B -->|forward the KNST| C[Acquiring Partner] C --> D[Klarna<br/>payment]

This linkage is what allows Klarna to recognize that the customer who just verified through Sign in with Klarna is the same customer now paying, and to reduce friction during payment authorization.

How to forward it

Pass the KNST to your Acquiring Partner when you initiate the payment, alongside the rest of the payment details. The exact field or header name depends on the Acquiring Partner — consult your Acquiring Partner's integration docs. The Acquiring Partner forwards the token to Klarna's payment APIs on your behalf; you don't call Klarna directly.

If you have a direct Klarna SDK or API integration in addition to (or instead of) an Acquiring Partner, pass the KNST as the Klarna-Network-Session-Token header on Klarna API calls, or during Klarna Web SDK / Klarna Mobile SDK initialization.

How it relates to customer_token

The two tokens have different scopes and lifecycles:

customer_token identifies the customer long-term. Store it associated with the customer's account.
klarna_network_session_token identifies this specific verified session. Forward it once for the next step in the flow; don't persist it long-term.

Properties

Opaque. Pass it through as-is. Don't parse, decode, or validate it.
Short-lived. Valid for 1 hour after issuance.
Session-scoped, not customer-scoped.

Expiration handling

If the token has expired or is invalid, Klarna's APIs ignore it gracefully — no error is returned and the call proceeds without the session context. You don't need to validate the token before forwarding it.

Pass-through only. Treat the klarna_network_session_token as an opaque value. Don't decode it, don't persist it long-term, and don't compare its contents.

Re-verification

Some verticals and Partners require re-verification of customers after a period (for example, one year). When you need to re-verify a customer, use the same flow as the initial verification: create an identity request, redirect or hand over the customer to Klarna to authenticate, then read the identity request state and use the returned customer_token and profile data as you do for the first verification.

What can and cannot change:

Date of birth — cannot change. It remains as originally verified.
Name — can change. Re-run the flow to obtain re-verified name data.
Email and phone — can change, like address. They are always verified when returned (see Customer-token scopes), but new values may be returned after re-verification.
Address — can change. Address is not one of the verified data points. The address returned may be externally verified or may belong to a strongly authenticated customer; Klarna does not guarantee that address is verified.

Stable identifier: store customer_id. The customer_id (returned in customer_profile) stays the same for the customer for their whole lifecycle. Email, phone, name, and address can change over time. Store customer_id so you can recognize the same customer across all interactions and re-verifications.