← All documentation

Changelog

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.

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-10-30 — notice: Berlin Group IG v1.3.16 from 2027-02-01

A notice under the change policy above. Nothing changes until 2027-02-01, and nothing you send or receive changes then.

• From 2027-02-01 we implement Berlin Group NextGenPSD2 XS2A Implementation Guidelines v1.3.16 (2025-12-02), in place of v1.3.15. The OpenAPI document and these pages will name v1.3.16 from that date.
• v1.3.16’s only change is the optional access.statements extended service. We do not offer account statements: a consent request carrying access.statements is refused with SERVICE_INVALID (path: access.statements), today and after the change.
• Everything else reads the same in both versions, including §11.1 footnote 11, on which optional debtorAccount rests. An integration that works against v1.3.15 today needs no change.

2026-10-30 — bank-offered consents

An addition. Nothing you already send behaves differently.

• You can now ask the customer to choose the accounts. Send POST /v1/consents with every access list you want left empty ("accounts": [], "balances": [], "transactions": []). The customer ticks the accounts to share when they authorise. See Consents → Bank-offered.
• Until then, the lists read back empty. Once the customer has authorised, GET /v1/consents/{consentId} names the accounts they chose. Read it back before GET /v1/accounts.
• Account details are always included in a bank-offered consent, even if you sent only balances or transactions, so you can always list what you were given.
• A request that names an IBAN in any list is unchanged: a dedicated-account consent, with any empty list ignored, exactly as before.
• Previously a request with every list empty was refused with FORMAT_ERROR (“At least one account must be specified.”). It is now accepted. availableAccounts, availableAccountsWithBalance and allPsd2 are still refused with SERVICE_INVALID; only the wording of that message changed.

2026-10-30 — correction: consents could not be authorised by a recently signed-in customer

A correction (same release). If the customer had signed in to PaySaxas with full strong customer authentication recently, authorising your account-information or confirmation-of-funds consent failed on our screen, so the consent stayed received and then lapsed after 15 minutes. You would have seen consents that were never authorised and could not tell why. Fixed: such a customer now authorises without being asked again, as RTS Art. 10(b) allows. Nothing changes in what you send or receive. Payment authorisations were not affected in the cases we observed.

2026-10-30 — payments without debtorAccount

An addition. Nothing you already send behaves differently.

• debtorAccount is now optional on POST /v1/payments/{product} (Berlin Group IG v1.3.15 §11.1, footnote 11). Omit it and the customer chooses the account to pay from when they authorise, on our screen. See Payments → Field notes.
• You get the usual paymentId, authorisationId and scaRedirect. Until the customer has chosen, GET /v1/payments/{product}/{paymentId} reads RCVD with no debtorAccount (RJCT if they decline or it lapses); afterwards it carries the account they chose. DELETE before they choose cancels it (CANC).
• The same checks run at initiation (product, amount, creditor format). What depends on the paying account is decided once the customer has chosen it.
• Previously a request without debtorAccount was refused with PAYMENT_FAILED. It is now accepted.

2026-10-30 — account statements refused by name

• access.statements (added in Berlin Group IG v1.3.16) is now refused with SERVICE_INVALID (path: access.statements). Account statements are not offered. Before, it was dropped without a word and the consent created without it, so it could look granted.

2026-10-30 — clarification: confirmation-of-funds consents are standing

• Docs only; nothing behaves differently. Confirmation of funds now says that a CoF consent is not retired by use. One-off retirement applies to account-information consents only, so a CoF consent lasts until validUntil (CONSENT_EXPIRED after) or until the customer revokes it (CONSENT_INVALID).

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 SERVICE_BLOCKED. 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.