← 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: mutual TLS has its own listener on a load balancer shared with the customer portal. Port 443 on this host is withdrawn and answers 404. A 404 where you expected the interface means the port is missing.

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 flows below are the ones you use against production; the demo credential and the personas exist only here.

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)"
   

   With no Consent-ID this answers 403 CONSENT_UNKNOWN — which is the success signal on day one: your certificate was accepted, registered and role-checked, and the refusal is about the missing consent. A certificate problem would have answered with a CERTIFICATE_* code or SERVICE_BLOCKED instead.

   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 ETSI TS 119 495 PSD2 QcStatement to support and we will issue a test certificate from the test QTSP. Worth doing if you want to exercise your own certificate handling rather than ours.

Production QWACs are accepted here too, for identification testing. The sandbox trusts the test QTSP above and the same EU trusted-list authorities production does, 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 here, where it costs you nothing. Expect CERTIFICATE_INVALID for a certificate that cannot be parsed, SERVICE_BLOCKED for one that does not chain to an authority we trust, and ROLE_INVALID for one that lacks the role an endpoint needs.

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. Persona balances are topped back up every night, and other state can be reset. 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?