← All documentation

Changelog

The policy is in force

From 2026-08-04 this specification is stable and every breaking change gets three months’ notice. Before that date it was a moving target and said so: nothing had served a provider, so no correct integration existed that a change could break, and corrections shipped without notice. That period is over. You may pin against this version.

Our change policy

Breaking changes to this interface are published at least three months before they take effect (RTS 2018/389 Art. 30(4)). A breaking change means anything that could make a correct integration stop working: a removed endpoint, a removed or renamed field, a narrower accepted input, a new required header, or a change to the Berlin Group specification version we implement.

Non-breaking additions — a new optional field, a new endpoint, clarified prose — ship without notice and are recorded here.

The exception is a security fix, which may ship immediately. When that happens we document it here afterwards and explain why the notice period was not observed.

Corrections — the case the policy above does not obviously cover

Sometimes the interface does not do what these documents say, and we fix the interface. That is a correction, and it is worth being explicit about how we treat it, because you may have integrated against the behaviour rather than the document.

A correction ships without notice. We are not going to leave a documented contract unmet for three months. If your integration follows the published documents, a correction can only move us toward you — the case it breaks is a client that adapted to a bug.

But every correction is recorded here, on the day it ships, and named plainly enough that you can tell whether you had worked around it. That is the half that matters to you, and it is not optional: the value of this page is that you can learn from it that behaviour you built against has moved.

Why this is stated at all: a provider building against our sandbox hit PRODUCT_INVALID where the catalogue promised PAYMENT_FAILED, and a less careful integrator would have changed their client to expect the wrong code and then broken silently when we fixed ours. They asked us which way the policy cut. This is the answer, published rather than left to be inferred.

So: build against the documents. Where the interface and these pages disagree, the pages are what we are obliged to deliver, and the difference is a bug you should tell us about rather than accommodate.

Subscribe to changes via support.

Releases

2026-09-18 — production moved to port 8443 today, ahead of the announced date

This supersedes the 2026-09-16 entry below, which said port 443 would serve until 2026-12-16. It stopped today instead. Production is:

https://xs2a.paysaxas.com:8443

https://xs2a.paysaxas.com (port 443) no longer serves the interface and returns 404. Everything else is unchanged: same paths, headers, status codes, certificate requirements, and your registration carries over untouched.

We shortened our own notice period, and that is worth stating plainly rather than leaving you to notice the date moved. The policy above promises three months. The ground for departing from it is the same one the pre-2026-08-04 period and the 2026-09-14 sandbox entry rest on: no provider has ever completed a mutual-TLS handshake against this interface. As of today, across 68,314 recorded requests, not one presented a client certificate, no provider has ever registered, and no access has ever been granted — every request on record is our own availability probe or an unauthenticated scanner. So there is no correct integration in existence that this change could break.

If you are reading this because something of yours broke, we were wrong about that and we want to hear from you immediately — support. We will restore port 443 while you migrate.

The three-month commitment stands for every future breaking change. This entry is the record that it was not honoured here, and why.

2026-09-16 — production base URL moves to port 8443 on 2026-12-16

Superseded by the 2026-09-18 entry above: port 443 stopped on 2026-09-18, not on the date named below. The entry is kept unedited because a changelog that quietly rewrites its own history is worth nothing.

Three months’ notice, as the policy above requires. Production is moving to:

https://xs2a.paysaxas.com:8443

It answers today. Both ports serve the interface, identically — same certificate, same mutual-TLS handshake, same paths, same behaviour. Move when it suits you; there is nothing to coordinate with us and no need to tell us you have. If your egress firewall allows only 443, add 8443 for this host.

On 2026-12-16, https://xs2a.paysaxas.com (port 443) stops serving the interface and returns 404. That listener will serve our customer portal, which has no route for this host.

Why. Mutual TLS is a per-listener property on the load balancer, and the listener a browser reaches must never ask for a client certificate — so an interface sharing that load balancer takes its own port. Nothing in PSD2, RTS 2018/389 or the EBA guidance prescribes a port; Berlin Group paths are relative to a base URL, and production hubs serve major banks the same way (Redsys on :20443). The sandbox moved first, on 2026-09-14.

Nothing else changes. No path, header, status code, field or certificate requirement is affected, and your registration carries over untouched — the interface on :8443 is the one you are already integrated with.

2026-09-14 — sandbox base URL moves to port 8443

The sandbox now answers at:

https://xs2a.paysaxas.money:8443

Paths, headers, certificates and behaviour are unchanged — only the port is new. If your test environment restricts outbound traffic to port 443, allow 8443 for this host.

https://xs2a.paysaxas.money (port 443) is withdrawn as of this entry. It answers for a short parallel period while the name moves onto the shared load balancer, and once that move completes it returns 404 — that listener serves our customer portal and has no route for this host. Treat it as gone from today rather than as a fallback: the parallel period is measured in days and it is not announced separately.

Why. The sandbox moved onto the load balancer that also serves our customer portal. Mutual TLS is a per-listener property there, and the portal’s port 443 must never ask a browser for a client certificate, so the XS2A interface takes its own port. Nothing in PSD2 or RTS 2018/389 prescribes a port, and Berlin Group paths are relative to the base URL; production hubs serve major banks the same way (for example Redsys on :20443).

On the notice period. A base-URL change is a breaking change, and the policy above promises three months’ notice. This one ships without it, for the same reason the pre-2026-08-04 period carried no notices: no provider has ever completed a handshake against this interface, so there is no correct integration this change can break. We record the departure here rather than leave it to be inferred; if you had integrated, this entry would instead have been the start of a three-month parallel-running window.

Production is unchanged: https://xs2a.paysaxas.com stays as published. When production moves the same way, it will be announced here in accordance with the policy above.

2026-08-04 — production open

https://xs2a.paysaxas.com answers. AIS, PIS and CBPII are all live, at the version of this specification published on this date; the sandbox at https://xs2a.paysaxas.money stays open unchanged and remains the place to test.

Registration is self-service and there is nothing to apply for: present an eIDAS QWAC carrying your PSD2 QcStatement and your first call registers you, with your roles read from the certificate and checked against the EBA register.

One known limitation. Certificates issued by the Cypriot QTSP are not yet trusted and are refused with CERTIFICATE_INVALID. This is our trust store, not your certificate. If it affects you, contact support — the fix is a rebuild of the store on our side and needs no change from you. It will be recorded here when it lands.

From today the change policy above binds: breaking changes are announced here at least three months before they take effect.