← 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

Not open yet. The facility and this documentation are published ahead of go-live; the host above does not answer today. The opening date is announced in the changelog, and nothing below changes when it does — the credential, the personas and the flows are the ones you will use.

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://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 — the files are live today even though the host is not:

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

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

   That is the request you will make on day one; today it reaches nothing, and the changelog carries the date it starts answering.

   It 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

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

Seeded customers with published credentials and IBANs — see the developer portal for the current list, which is regenerated whenever the sandbox resets. Each persona has a static SMS code, documented alongside it, so you can complete the redirect flow unattended.

Personas cover:

• a company with two accounts and transaction history — general AIS testing
• a low-balance persona — for a fundsAvailable: false answer
• an instant-payments persona — for the instant product

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?