← All documentation

Sandbox

A publicly reachable testing facility, provided under RTS 2018/389 Art. 30(5). Use it for connection and functional testing before you touch production.

https://xs2a.paysaxas.money:8443

The port is part of the base URL (changelog, 2026-09-14): mutual TLS has its own listener on a load balancer shared with the customer portal. Port 443 on this host is withdrawn — it answers only during the short parallel period while the name moves, and 404 after that. A 404 where you expected the interface means the port is missing.

Open since 2026-08-04, the same date production opened (changelog). It stays open for as long as the production interface runs — RTS Art. 30(5) obliges us to keep a testing facility available, not merely to have had one before launch. The credential, the personas and the flows below are the ones you use against production.

Getting a test certificate

The sandbox accepts certificates issued by the PaySaxas PSD2 Test QTSP, a CA that exists only for this purpose. Download it directly:

https://platform.paysaxas.com/xs2a/test-certs/paysaxas-psd2-test-ca.pem

The index lists it alongside a plain-text README for scripted setups.

Two ways to test:

1. Download the demo credential. Nothing to request, nobody to email:

   https://platform.paysaxas.com/xs2a/test-certs/sandbox-demo-tpp.pem
   https://platform.paysaxas.com/xs2a/test-certs/sandbox-demo-tpp.key
   

   curl https://xs2a.paysaxas.money:8443/v1/accounts \
     --cert sandbox-demo-tpp.pem --key sandbox-demo-tpp.key \
     -H "X-Request-ID: $(uuidgen)"
   

   That is the whole of day one.

   The credential carries all three PSD2 roles, so one credential exercises AIS, PIS and CoF. The private key is published deliberately and shared by everyone — it has no security value, authenticates a fictional provider against fictional customers, and is refused in production. Never reuse it outside the sandbox.

2. Or test with an identity of your own: send a CSR carrying the PSD2 QcStatement extension because it exercises your own certificate handling.

Production QWACs are accepted here too, for identification testing. The sandbox trusts the test QTSP above and the same EU trusted-list authorities production will, so you can present your real eIDAS certificate and confirm it parses, chains, and carries the PSD2 roles you expect — before cutover, not during it. Bring your production QWAC and call any endpoint: a certificate problem surfaces as CERTIFICATE_INVALID or ROLE_INVALID here, where it costs you nothing.

What it does not do is give your production certificate access to production data. It authenticates you against the sandbox’s fictional customers like any other credential; the accounts, balances and payments are the seeded ones.

What is simulated and what is real

A payment stays RCVD until someone authorises it, and that is the whole point. An initiated payment does not advance on its own — no timer moves it, and nothing settles in the background. It progresses when the customer follows your scaRedirect and approves, exactly as in production: RCVD → the pipeline → and onward as the scheme responds. If every payment you initiate sits at RCVD, the ceremony has not been completed, not the sandbox failing to settle.

Which means the statuses beyond RCVD need a person to drive one authorisation per payment, the same person the personas page describes. There is no bulk or automatic path, and we would rather you knew that than watched a queue that never drains.

Once authorised, a persona-to-persona payment settles immediately. Both personas are held here, so the payment is a book transfer: both ledger legs post atomically at execution and there is no clearing round-trip to wait for. You should see RCVD → ACSC within seconds of the ceremony completing, not a slow progression. If you are testing status polling, that is the shape to expect.

An authorisation expires 15 minutes after it is created. If the ceremony is not completed in that window the authorisation reads failed, and the payment then stays at RCVD permanently — correctly, because there is nothing left to authorise. That is worth knowing before you stage a link for someone to open later: the redirect has a short life, so create the payment when the person is ready, not before.

The sandbox is a contract-conformance surface, not a compliance rehearsal. A payment succeeding here says your integration is correct; it says nothing about how a real payment will be screened.

Test personas

The personas, with their IBANs and the static SCA code, are on their own page. Three seeded companies:

• Sandbox Trading Oy — general AIS testing
• Sandbox Low Balance Oy — for a fundsAvailable: false answer
• Sandbox Instant Oy — for the instant product

Use those IBANs rather than inventing one. Payments are persona-to-persona, and Verification of Payee compares creditorName against the registered name, so an invented creditor is refused in a way that looks like a fault in your client.

Restrictions worth knowing before you plan around them

• Payments are persona-to-persona only. A creditor IBAN outside the sandbox personas is rejected. Real scheme rails are not reachable from here, and we will not park your test payment in a queue that never drains.
• Verification of Payee is real here, and it will fail your first payment. Because personas are held with us, we can check the creditor name locally and we do — so creditorName is compared against the persona’s registered name, not accepted as given. Send the persona’s exact registered name to get a match. Send anything else and the customer is shown a mismatch warning and must accept it before they can approve, which is the correct production behaviour and not a sandbox fault. This is the cheapest way to exercise the warning path deliberately: send a deliberately wrong name and watch what the customer sees.
• A payment can sit waiting for the customer, not for us. If the payee check has not answered when they approve, the payment is accepted and pauses as PDNG until they confirm the payee. Poll the status; do not treat PDNG as a failure or retry the initiation.
• The sandbox may reset without notice. Personas are re-seeded regularly. Do not build long-lived state against it.
• Data is fictional. Every name, IBAN and transaction is invented. Nothing here corresponds to a real person or a real account.

Moving to production

Nothing to request. Point your client at the production host with your real QWAC. Your registration is created on the first request, and your authorisation is corroborated against the EBA register.

Sanity-check first:

• Are you sending X-Request-ID on every request, and using it as the idempotency key for payments?
• Do you send PSU-IP-Address only when the customer is genuinely present?
• Do you handle CONSENT_INVALID arriving without warning (the customer may revoke at any time)?
• Do you renew consents before the 180-day ceiling rather than after CONSENT_EXPIRED?