Sandbox test data
The published test PSUs, accounts, and transaction data available in Klarna's XS2A v2 Sandbox, and how to use them for AIS and PIS testing.
3 min read
The Sandbox is backed by a fixed set of test customers (PSUs) with realistic, static account and transaction data — there are no real Klarna accounts behind it. This page documents that data so you can build automated tests against it.
These identities are a published, stable contract: the emails, IBANs, BICs and transaction counts below do not change between releases, so you can assert against them directly in automated tests. They exist only in the Sandbox and have no equivalent in Production.
Test PSUs
| John Doe | Sven Svensson | |
|---|---|---|
john. | sven. | |
| Country / Currency | DE / EUR | SE / SEK |
| IBAN | DE23100000001234567890 | SE6297800000097802578096 |
| BIC | KLRNDEBEXXX | KLRNSESS |
| Usable for | AIS and PIS (debtor account for sepa-credit-transfers and instant-sepa-credit-transfers) | AIS and PIS (debtor account for se-domestic-credit-transfers) |
Each PSU owns exactly one fully active, IBAN-bearing payment account, addressable through Consent and account information (AIS). Both accounts can also be used as the debtor account when testing Payment Initiation (PIS): John Doe's (EUR) for the SEPA products, Sven Svensson's (SEK) for
se-domestic-credit-transfers.Email family / tagging
Both PSU emails support a
+tag suffix, for example john. — the whole family resolves to the same PSU and account. This is how you simulate SCA outcomes (+confirm, +deny, +confirm<N>s, +deny<N>s), by sending the tagged email as PSU-ID when you start the authorization; any other tag is treated as an unrecognized tag and defaults to confirm.Any email outside these two families — with or without a tag — resolves as an unknown PSU: creating the consent or payment still works, but starting the authorization with that
PSU-ID returns 401 PSU_ ("PSU-ID is unknown") and the authorization moves to failed.Transaction history
Each PSU's account returns a fixed history of 130 transactions, paginated across 3 pages of 50 / 50 / 30, so you can exercise transaction pagination end to end. Only John Doe's history contains pending transactions (seven of them are flagged pending); all of Sven Svensson's transactions are booked. Use John Doe to test the booked/pending split when filtering the
bookingStatus of your transactions request.Transaction detail differs by PSU, reflecting different real-world transaction types:
- John Doe (DE / EUR) — transactions include SEPA transfers and card transactions, with counterparties Jane Doe and Max Mustermann. SEPA and internal transfers carry the counterparty's IBAN and BIC; card transactions do not. John Doe's transactions are enriched with additional Klarna transaction-reference detail, so you can also test the richer, enriched transaction shape.
- Sven Svensson (SE / SEK) — transactions run on domestic Swedish rails (internal transfers and card/Swish-style external transfers), with counterparties Anna Andersson (incoming,
SE3550000000054910000003/ESSESESS) and Erik Svensson (outgoing,SE5280000816959386930266/SWEDSESS). Sven Svensson's transactions are not enriched — use this account to test the plain (non-enriched) transaction shape. Amounts and balances are in SEK (minor unit: öre).
Notes
- All data is static — repeated requests against the same PSU return the same accounts and transactions. Nothing you do in the Sandbox (for example, initiating a payment) changes another PSU's data or persists new transactions.
- Data is anonymized test data only — the PSUs and counterparties above are fictional and not real individuals.
- For how to drive SCA outcomes on these accounts, see Simulating Strong Customer Authentication.
- Base URLs and general Sandbox access are covered in URLs and environments.
If you need additional test scenarios not covered by these two PSUs, contact
support..Jump to section...