Regulatory publications

Get your token

Access to PSD2 API is granted by the bank with an authorization token (or access token) issued using OAuth2 standardized process.
 

How it works ?

See also STET V1.4.2.17 / Part I / section 3.4

Image

1. The customer (PSU) provides the identity of the bank which holds his accounts (ASPSP) to the TPP.
    
2. The TPP initiates an OAuth2 access token request sequence by redirecting the customer to the ASPSP’s authorization infrastructure using GET /authorize
   See also STET V1.4.2.17 / Part I / section 3.4 
    
3. ASPSP will :
   - Identify and authenticate the PSU
   - Check your role and validity of your eIDAS certificates and agreement
    
4. Once checks are done and correct, ASPS will redirect the PSU to your site using “call-back” URL given in the GET /authorize and to ASPSP for the Go Live process.
   You will find in the response of this request a one-time-token with a short life period.
    
5. You can then call the ASPSP to request the OAuth2 token (and refresh token) using POST /token with the previously received data (including the one-time token).
   Note: these /token requests for getting the Authorization Code flow shall be sent WITHOUT the « scope » parameter.
   See also STET V1.4.2.17 / Part I / section 3.4 
    
6. ASPSP will :
   - Check your role and validity of your eIDAS certificates and agreement
   - Checks the direct or indirect matching between the Authorization Number within the eIDAS certificate and the [client_id] value
    
7. Once checks are done and correct, ASPSP returns a response HTTP 200 (OK) with data including the access token.
   See also see STET V1.4.2.17 / Part I / section 3.4 
    

As soon as you get the OAuth2 access token (and a 180-day valid refresh token) issued by the bank, you can use it for each API request within the “Authorization” header, prefixed by the token type “Bearer”.
The [client_id] that is linked to the access token must directly or indirectly match with the Authorisation Number that is located within the TPP’s eIDAS certificate (QWAC).

If the access token is expired, the request will be rejected with HTTP 401 with an error equal to invalid_token.

The request can be replayed once the access token has been refreshed suing the use case “Refresh your token“.

If your refresh token is about to expire, you will have to perform again all this process, meaning also redirect to ASPSP for customer’s strong authentication (PSU SCA).

For more details, see also OAuth 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749#section-4.1
 

Check funds availability

This service allows you to check if customer has enough funds available on his payment bank account (linked to your payment card based instrument) to cover the current transaction.
 

Prerequisites

In order to proceed, TPP needs to fulfill all eligibility criteria and to present a valid OAuth2 Authorization token (see the use case “Get your token“).
 

Request

POST /funds-confirmations

see STET V1.4.0 / Part II / section 4.6.4 page 23

Mandatory parameters 

paymentCoverageRequestId : Id for the request 

payee : merchant 

instructedAmount : amount and currency of the transaction 

accountId : Unique Id for the customer’s account 

Result

The result given by the ASPSP is a boolean (YES or NO).

 

Example

Request

POST http://localhost:8080/v1/funds-confirmations

Body 

{

“paymentCoverageRequestId” : “MyCoverage123456”,

“instructedAmount” : {

“currency” : “EUR”,

“amount” : “12345” },

“accountId” : { “iban” : “YY13RDHN98392489481620896668799742” }

}

 

Result

Status code : 200

Body

{

“request” : {

“paymentCoverageRequestId” : “MyCoverage123456”,

“instructedAmount” : {

“currency” : “EUR”,

“amount” : “12345” },

“accountId” : { “iban” : “YY13RDHN98392489481620896668799742” }

},

“result” : true,

“_links” : {

“self” : {

“href” : “v1/funds-confirmations”

}

}

}

see also STET V1.4.0 / Part III / section 6  page 12

Acceptance tests

The purpose of these tests is to ensure that the API complies with the STET standard. They should be validated before any application deployment.

Refresh your token

Principle

The refresh token issued by the bank ASPSP is valid up to 180 days and needs to be renewed before it expires. Please also note that :

•  Authorization and refresh tokens can be revoked at any moment ;
• If the Authorization token is revoked, then the refresh one is automatically revoked (and the other way round) ;
• The access token has a shorter life cycle (10 to 15min) on standalone device.

How it works ?

1. You request for a refresh token using POST /token
   See also STET V1.4.0.47 / Part I / section 3.4.3.4 / page 25 
   
    
2. ASPSP :
   - Identifies and authenticates the TPP through the presented eIDAS certificate (QWAC)
   - Checks the direct or indirect matching between the Authorization Number within the eIDAS certificate and the [client_id] value.
   - Controls last PSU SCA date (< 180 jours).
    
3. If correct, ASPSP then answers through a HTTP200 (OK) that embeds a new authorization token and refresh token that can replace the previous one. You need to store safely these tokens.
    
4. ASPSP de facto revokes the previous refresh token :
   - After timeout of the by-law specified delay between two SCAs ;
   - After timeout of the ASPSP specified delay based on internal rules if any ;
   - After reject of a request for insufficient scope in order to allow the AISP to request another token with the desired scope ;
   - On request of a PSU wanting to revoke the TPP access on his/her account data.

Please also note that, as a TPP, you are able to ask for the revocation of the refresh token through a POST /revoke request.

See also STET V1.4.0 / Part I / section 3.4.3.5 / page 26 

RFC 7009, cf. https://tools.ietf.org/html/rfc7009

Roadmap

• urgent functional issue to solve impacting all PSU of at least one major customers segment
• security issue
• evolutions requested by the national competent authority
   

Please do find below our forecast roadmap :

Deprecation process

According to API product life cycle, an API version can be deprecated (means this API is not any more accessible on gateways and sandbox). An overlap period between two major API releases is provided as described below :

Image

The communication on the deprecation of a version N will be done at the release date of version N+1 through this portal / “roadmap” section.

Functional limitation

The limitations of this PSD2 API are :

• Apply only to Caisse d’Epargne customers who subscribed online banking services
• Apply only to active and eligible online accessible payment accounts in euro currency
• Payment accounts from corporate segments are not yet available using this API
• Use the authentication with redirect only (Strong Customer Authentication required and handled by the bank APSPS)
• Access to the customer’s information will only be possible if he gave his consent previously
• Access to payment account is done only using IBAN as main parameter (and not your payment instrument)
• There will be no reservations of funds

Limitations on data

Live data will be accessible by using first our enrolment API “PSD2 Registration”.

The list of current available bank institutions for this API is detailed below.

Examples :

• STET V1.4.0   POST https://www.17515.oba-bad-me-live.api.89c3.com/stet/psd2/v1/funds-confirmations   ( /!\ scope = piisp )
• STET V1.4.2   POST https://www.17515.oba-bad-me-live.api.89c3.com/stet/psd2/v1.4.2/funds-confirmations   ( /!\ scope = cbpii )
• STET V1.6.2   POST https://www.17515.oba-bad-me-live.api.89c3.com/stet/psd2/v1.6.2/funds-confirmations   ( /!\ scope = cbpii )

(new URL to be taken into account from now on)
(As a reminder, the existing URL www.<codetab>.live.api.89C3.com will no longer be available as of September 28, 2025)

The list of current available bank institutions for this API is detailed below. The parameter “codetab” will allow you to setup the right customer database thru a dedicated « endpoint » for each bank having the following format : www.codetab.live.api.89c3.com

Eligibility

The “Funds availability” API resources can only be used by Payment Service Providers (PSP) with a “Card Based Payment Instrument Issuer” role (CBPII or PIISP depending on used STET version).

In order to provide a service to users of payment services under PSD2 directive, you must be a licenced PSP such as credit institution, electronic money institution, and payment institution. This status is delivered by financial authorities of the country where the request is made; in France it is the “Autorité de Contrôle Prudentiel et de Résolution” (ACPR), under the supervision of the Banque de France regulatory body.

Obtaining and maintaining an authorization requires rigorous procedures in order to give strong guarantees to the payment services users.

The forms are provided on the ACPR website : https://acpr.banque-france.fr/autoriser/procedures-secteur-banque/tous-les-formulaires.

Once the agreement is granted, the Organisation Identifier (OID) given by the national authority has the following format :

PSDXX-YYYYYYYY-ZZZZZZZZ

“PSD” as 3 character legal person identity type reference

2 character ISO 3166 country code representing the NCA country

2-8 character NCA identifier (A-Z uppercase only, no separator)

PSP identifier (authorization number as specified by NCA)

This OID is very important for :

• Identify yourself as a TPP in the STET API requests using the parameter “client_ID”
• To be included into the eIDAS certificates to be delivered to the bank (see below)

You also need eIDAS (electronic IDentification And trust Services) compliant certificates delivered by a Qualified Certification Service Provider (QTSP, see list available on https://webgate.ec.europa.eu/tl-browser/#/).

In order to be able to consume PSD2 API published on our BPCE Portal, you have to forward us using .pem format :

• QWAC and QSEALC live certificates for the sandbox (if available for this ASPSP)
• QWAC and QSEALC live certificates for our BPCE API Live gateway

Please embed only public keys. Controls on other data will be based on the European Banking Association TPP register (https://euclid.eba.europa.eu/register/pir/disclaimer).

You can also refer to the FAQ section about the principle of eligibility.

Planning of upcoming developments for the API.

In accordance with Article 30 (5) of the RTS, assistance for third-party PSP providers is available. This support can be accessed via the form on the Groupe BPCE API Store. Responses are provided during business hours.

The general principle of support is outlined below, taking into account the regulatory deadlines set forth in Article 30 (4) of the RTS:

Image

Important developments made since the last delivered version.