Banque populaire – Disponiblité des fonds

Comment réduire son risque d'impayé ?

Un de nos clients porteur de votre carte de crédit privative effectue une transaction sur un site d’e-commerce avec celle-ci. Le client a donné, au préalable, une délégation à votre établissement.

Via cette API « Disponibilité des fonds » mise à disposition par la Banque Populaire, vous pouvez demander en temps réel la confirmation que le client a suffisamment de fonds sur son compte pour couvrir le montant de cette transaction SANS lui demander ses identifiants de connexion en ligne, réduisant de fait votre exposition au risque d’impayé.

La banque répond positivement ou négativement en fonction du solde minute du client. Cependant, la banque n’effectue aucun blocage de fonds correspondant au montant de la transaction et n’enregistre pas cette transaction.

Les ressources de cette API ne peuvent être consommées que par des prestataires ayant le rôle d’émetteurs d’instruments de paiement liés à une carte (« CBPII » ou « PIISP » suivant la version STET utilisée), ce prérequis étant décrit dans voir la section « Éligibilité ».

Une fois ce prérequis rempli, le processus global est le suivant :

1- Vous avez établi un contrat avec le client, vous lui avez délivré une carte avec prélèvement domicilié dans une Banque Populaire. Il vous l’indique à travers vos interfaces.

2- Lors du premier échange avec les infrastructures du teneur de compte, vous allez faire une demande de jeton d’autorisation (et un jeton de rafraichissement). Le principe de base est, qu’en tant que TPP CBPII, vous devez obtenir ces jetons AVANT de consommer les ressources de l’API. Ce jeton est généré par le teneur de compte (ASPSP) APRES avoir identifié et authentifié le client.

En tant que teneur de compte, nous allons :

• vérifier vos certificats et agréments ;
• et via le jeu de la redirection, nous allons identifier et authentifier fortement le client afin de récupérer son consentement et de générer le jeton d’accès.

3- Si l’autorisation est accordée par le client, vous pourrez ensuite récupérer un jeton d’accès OAUTH2 (et son jeton de rafraichissement) via des échanges sécurisés avec la plateforme BPCE API (voir le cas d’usage « Récupérez votre jeton d’accès !« ).

4- En présentant ce jeton d’autorisation valable 180 jours, vous pourrez alors consommer les ressources de l’API « disponibilité des fonds » et réduire votre risque d’impayé en interrogeant la banque sur l’existence de la provision sur le compte du client correspondant au montant du paiement (voir le cas d’usage « Vérifiez la disponibilité des fonds« ).

Au bout du délai réglementaire de 180 jours, ce processus devra être reconduit (voir le cas d’usage « Rafraichissez votre jeton !« ).

NB : le gestionnaire de compte ASPSP a la possibilité de vous refuser l’accès pour différents motifs justifiés (API non conforme, compte bloqué entre-temps, etc..).

Consommez l'API

Accès à l’API de vérification de la disponibité des fonds

La cinématique ci-après décrit comment consommer l’API disponibilité des fonds, avec la description de chaque étape, depuis la récupération du jeton jusqu’à la requête de couverture de paiement.

Etape 1 – Prérequis

• Vous devez vous enrôler sur le portail BPCE API et lorsque vous souscrirez au live avec le rôle CBPII, vous devrez fournir vos certificats QWAC et QSEALC. Votre rôle CBPII sera alors vérifié sur la base des informations récupérées dans le référentiel de place (REGAFI) => validité des certificats et de votre rôle, non révocation de votre profil, etc…

Etape 2 – Autorisation d’accès en tant que CBPII qui vous est donnée par notre client connecté

• Pour chacun de nos client, vous devrez récupérer récupérer un jeton d’accès initial valable 180 jours :

a) Après avoir demandé à notre client connecté sur votre application dans quelle Banque Populaire se trouvent ses comptes, vous devez soumettre une requête de récupération de votre jeton d’accès pour ce client (cf. cas d’usage « Récupérez votre jeton« ) : il s’agit d’initier la séquence de récupération du jeton d’accès OAUTH2 en redirigeant notre client via son navigateur internet vers l’infrastructure informatique d’autorisation de cette Banque Populaire.

b) Notre client est redirigé via son navigateur internet vers l’infrastructure informatique d’autorisation de cette Banque Populaire : une IHM mobile lui permet de s’identifier.

c) Notre client procède à une authentification forte par l’une des méthodes d’authentification forte que la Banque Populaire propose et présente au client, ce qui génère un jeton d’accès

d) La banque va rediriger le client vers votre site en utilisant les URL de « call-back » (redirection) transmises précédemment ainsi que certains paramètres.

e) Vous récupérez le jeton d’accès initial pour ce client via un appel de type POST et La Banque Populaire va :

Vous identifier et vous authentifier en tant que CBPII via le certificat X509 mis à disposition pour sécuriser l’échange mutuel.

Effectuer des vérifications liées à votre profil de CBPII (validité des certificats et de votre rôle dans le référentiel de place, non révocation de votre profil, etc…).

Une fois ces vérifications effectuées et si elles sont concluantes, la banque va vous renvoyer une réponse HTTP200 (OK) avec un certain nombre de données.

Dès que vous aurez récupéré le jeton d’accès OAUTH2 délivré par la banque (valable 180 jours), vous pourrez le présenter pour pouvoir consommer les ressources de l’API (cf. cas d’usage « Comment récupérer son jeton d’accès OAUTH2 ?« ).

Etape 3 – Requête de couverture de paiement (disponibilité des fonds)

• Lorsque notre client a besoin de régler un achat avec sa carte privative, vous interrogez la solvabilité du compte du client avec la méthode POST /funds-confirmations en fournissant votre jeton d’accès pour ce client (cf. cas d’usage « Vérifiez la disponibilité des fonds« )

Etape 4 – Si le jeton de 180 jours a expiré, vous devez faire une demande de rafraîchissement du jeton pour le client

a) Avec notre client connecté sur votre application, vous soumettez une requête de rafraîchissement du jeton pour ce client (cf. cas d’usage « Rafraîchissez votre jeton« )

b)Notre client est redirigé vers une IHM mobile de sa Banque Populaire et procède à une authentification forte dans cette IHM mobile, ce qui réactive le jeton d’accès

c) Vous récupérez le jeton rafraîchi pour ce client

Récupérer votre jeton

Principe

Votre accès aux API « information sur compte » ou « disponibilité des fonds » vous est autorisé via un jeton d’accès (access_token) qui peut être obtenu en appliquant le standard de place OAUTH2.

Cinématique de récupération du jeton d’autorisation

1. Notre client (PSU) vous indique l’identité de sa Banque Populaire teneur de compte.

2. Vous initiez la séquence de récupération du jeton d’accès OAuth2 en redirigeant le client (PSU), via son navigateur internet, vers l’infrastructure informatique d’autorisation de la Banque Populaire teneur de compte (ASPSP) et en utilisant la commande : GET /authorize.

Voir aussi la spécification de place STET V1.4.0.47 / Part I / section 3.4.3.2 / page 21

3. La Banque Populaire teneur de compte (ASPSP) va :

• Identifier et authentifier son client par l’une des méthodes d’authentification forte qu’elle propose et qu’il présente au client ;

• Effectuer des vérifications liées à votre profil en tant qu’AISP ou CBPII (validité de vos certificats QWAC et QSEALC et de votre rôle, non révocation de votre profil, etc.)

4. Une fois ces vérifications effectuées et si elles sont concluantes, la Banque Populaire va rediriger le client (PSU) vers votre site en utilisant votre URL de « call-back » (redirection) que vous nous aurez transmise lors du processus de « Go Live ».

En effet, l’AISP doit préciser pour son APP consommatrice, une URL qui sera appelée par l’établissement bancaire :

• Si le client a autorisé la récupération de ses données par l’AISP

• Ou en cas de refus du consentement

• Ou si la cinématique d’identification et d’authentification est interrompue à l’une de ses étapes (exemple : timeout sur l’écran d’identification ou sur l’écran d’authentification forte).

Si le PSU vous a autorisé à récupérer ses données chez son teneur de compte, vous trouverez dans la réponse à cet appel un code à utilisation unique qui a une durée de vie courte.

5. Via un appel de type POST /token, vous allez pouvoir alors demander directement au teneur de compte votre jeton d’accès OAUTH2 (access_token) avec les éléments reçus précédemment dont le code à utilisation unique.

NB : les requêtes /token du flow Authorization Code doivent être envoyée SANS le paramètre « scope ».

Voir aussi la spécification de place STET V1.4.0.47 / Part I / section 3.4.3.2 / page 22

6. La Banque Populaire teneur de compte (ASPSP) va :

• Effectuer des vérifications liées à votre profil en tant qu’AISP ou CBPII (validité des certificats et de votre agrément, non révocation de votre profil, etc.)
• Vous identifier et vous authentifier en tant qu’AISP ou CBPII via votre certificat que vous mettrez à disposition pour sécuriser l’échange mutuel.

7. Une fois ces vérifications effectuées et si elles sont concluantes, la Banque Populaire teneur de compte va vous renvoyer une réponse HTTP200 (OK) contenant, entres autres, le jeton d’accès OAUTH2 (access_token).

Voir aussi la spécification de place STET V1.4.0.47 / Part I / section 3.4.3.2 / page 23

8. Dès que le jeton d’accès OAUTH2 (access_token) délivré par la banque a été récupéré par vos soins, vous pourrez le présenter pour pouvoir consommer les ressources de l’API.

Ce jeton est accompagné d’un refresh_token valable 180 jours que vous devez conserver. Lorsque votre access_token arrive à expiration, vous pouvez en redemander un nouveau en suivant la rubrique « Vue d’ensemble » > « Rafraîchir votre jeton« .

Au bout de 180 jours votre refresh_token arrive à expiration. Pour en récupérer un nouveau, vous devrez reprendre cette cinématique « Récupérer votre jeton » et passer, de facto, par une nouvelle étape d’authentification forte du client auprès de son établissement bancaire (cf. point 3. ci-dessus).

Pour plus de détails, voir aussi OAUTH 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749#section-4.1

Exemple

Un exemple de requête est fourni dans la rubrique « Comment tester l’API ? » > « Assemblage Sandbox ».

Pour plus de détail sur les données échangées, voir la rubrique « Comment tester l’API ?« .

Rafraîchir votre jeton

Principe

Le jeton d’autorisation ayant une durée de vie limitée, il vous est nécessaire de demander son rafraîchissement avant son expiration.

Règles de base

La Banque Populaire teneur de compte (ASPSP) dispose au plus d’un jeton d’accès (access_token) et d’un jeton de rafraîchissement (refresh_token) valide par triplet client(PSU)/TPP/rôle AISP ou CBPII

• Le jeton d’accès a une durée de validité courte (de l’ordre d’une heure maximum) sur un périphérique ou une application de notre client
• Le jeton de rafraîchissement a une durée de vie de 180 jours
• Le jeton de rafraîchissement et le jeton d’accès doivent pouvoir être révoqués à tout moment
• Si le jeton d’autorisation est révoqué alors le jeton de rafraîchissement doit l’être aussi et réciproquement

Cinématique du rafraîchissement de votre jeton d’autorisation (access_token)

1. Vous demandez le renouvellement du jeton d’accès auprès de la Banque Populaire

2. La Banque Populaire initie le renouvellement du jeton d’accès

3. Elle récupère le certificat du TPP auprès du référentiel de place

4. Elle contrôle la validité et la non révocation du certificat présenté

5. Elle contrôle la date de la dernière authentification (< 180 jours)

6. Elle vous transmet le nouveau jeton d’accès et l’ancien jeton de rafraîchissement

7. Vous stockez le jeton d’accès et l’ancien jeton de rafraîchissement de façon sûre

8. La Banque Populaire invalide l’ancien jeton d’autorisation

Exemple

Un exemple de requête est fourni dans la rubrique « Comment tester l’API ? » > « Assemblage sandbox ».

Pour plus de détail sur les données échangées, voir la rubrique « Vue d’ensemble » > « Récupérer votre jeton ».

Publications réglementaires

/stet/psd2/v1/accounts/{accountResourceId}/balances

accountsBalances

Résumé

Retrieval of an account balances report (AISP)

Description

Description
This call returns a set of balances for a given PSU account that is specified by the AISP through an account resource Identification

• The ASPSP must provide at least the accounting balance on the account.
• The ASPSP can provide other balance restitutions, e.g. instant balance, as well, if possible.
• Actually, from the PSD2 perspective, any other balances that are provided through the Web-Banking service of the ASPSP must also be provided by this ASPSP through the API.

Prerequisites

• The TPP has been registered by the Registration Authority for the AISP role
• The TPP and the PSU have a contract that has been enrolled by the ASPSP
  • At this step, the ASPSP has delivered an OAUTH2 “Authorization Code” or “Resource Owner Password” access token to the TPP (cf. § 3.4.2).
• The TPP and the ASPSP have successfully processed a mutual check and authentication
• The TPP has presented its OAUTH2 “Authorization Code” or “Resource Owner Password” access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
• The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
• The TPP has previously retrieved the list of available accounts for the PSU

Business flow
The AISP requests the ASPSP on one of the PSU’s accounts. The ASPSP answers by providing a list of balances on this account.

• The ASPSP must provide at least the accounting balance on the account.
• The ASPSP can provide other balance restitutions, e.g. instant balance, as well, if possible.
• Actually, from the PSD2 perspective, any other balances that are provided through the Web-Banking service of the ASPSP must also be provided by this ASPSP through the API.

Scopes

• aisp
• piisp
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1/accounts

accounts

Résumé

Retrieval of the PSU accounts (AISP)

Description

Description
This call returns all payment accounts that are relevant the PSU on behalf of whom the AISP is connected. Thanks to HYPERMEDIA, each account is returned with the links aiming to ease access to the relevant transactions and balances. The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.

Prerequisites

• The TPP has been registered by the Registration Authority for the AISP role.
• The TPP and the PSU have a contract that has been enrolled by the ASPSP
  • At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
• The TPP and the ASPSP have successfully processed a mutual check and authentication
• The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
• The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.

Business Flow
The TPP sends a request to the ASPSP for retrieving the list of the PSU payment accounts. The ASPSP computes the relevant PSU accounts and builds the answer as an accounts list. The result may be subject to pagination in order to avoid an excessive result set. Each payment account will be provided with its characteristics.

Scopes

• aisp
• extended_transaction_history
• piisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1/accounts/{accountResourceId}/transactions

accountsTransactions

Résumé

Retrieval of an account transaction set (AISP)

Description

Description
This call returns transactions for an account for a given PSU account that is specified by the AISP through an account resource identification. The request may use some filter parameter in order to restrict the query

• on a given imputation date range
• past a given incremental technical identification

The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.

Prerequisites

• The TPP has been registered by the Registration Authority for the AISP role
• The TPP and the PSU have a contract that has been enrolled by the ASPSP
  • At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
• The TPP and the ASPSP have successfully processed a mutual check and authentication
• The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
• The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
• The TPP has previously retrieved the list of available accounts for the PSU

Business flow
The AISP requests the ASPSP on one of the PSU’s accounts. It may specify some selection criteria. The ASPSP answers by a set of transactions that matches the query. The result may be subject to pagination in order to avoid an excessive result set.

Scopes

• aisp
• extended_transaction_history
• piisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1/consents

consents

Résumé

Forwarding the PSU consent (AISP)

Description

Description
In the mixed detailed consent on accounts

• the AISP captures the consent of the PSU
• then it forwards this consent to the ASPSP

This consent replaces any prior consent that was previously sent by the AISP.

Prerequisites

• The TPP has been registered by the Registration Authority for the AISP role.
• The TPP and the PSU have a contract that has been enrolled by the ASPSP
  • At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
• The TPP and the ASPSP have successfully processed a mutual check and authentication
• The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
• The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.

Business Flow
The PSU specifies to the AISP which of his/her accounts will be accessible and which functionalities should be available. The AISP forwards these settings to the ASPSP. The ASPSP answers by HTTP201 return code.

Scopes

• aisp
• piisp
• extended_transaction_history

Paramètres

Codes retour

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1/funds-confirmations

fundsConfirmations

Résumé

Payment coverage check request (PIISP)

Description

Description
The PIISP can ask an ASPSP to check if a given amount can be covered by the liquidity that is available on a PSU cash account or payment card.

Prerequisites

• The TPP has been registered by the Registration Authority for the PIISP role
• The TPP and the PSU have a contract that has been registered by the ASPSP
  • At this step, the ASPSP has delivered an « Authorization Code », a « Resource Owner Password » or a « Client Credential » OAUTH2 access token to the TPP (cf. § 3.4.2).
  • Each ASPSP has to implement either the « Authorization Code »/ »Resource Owner Password » or the « Client Credential » OAUTH2 access token model.
  • Doing this, it will edit the [security] section on this path in order to specify which model it has chosen
• The TPP and the ASPSP have successfully processed a mutual check and authentication
• The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU.

Business flow
The PIISP requests the ASPSP for a payment coverage check against either a bank account or a card primary identifier.
The ASPSP answers with a structure embedding the original request and the result as a Boolean.
Scopes

• extended_transaction_history
• piisp
• aisp

Paramètres

Codes retour

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1/trusted-beneficiaries

trustedBeneficiaries

Résumé

Retrieval of the trusted beneficiaries list (AISP)

Description

Description
This call returns all trusted beneficiaries that have been set by the PSU. Those beneficiaries can benefit from an SCA exemption during payment initiation. The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.

Prerequisites

• The TPP has been registered by the Registration Authority for the AISP role.
• The TPP and the PSU have a contract that has been enrolled by the ASPSP
  • At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
• The TPP and the ASPSP have successfully processed a mutual check and authentication
• The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
• The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.

Business Flow
The AISP asks for the trusted beneficiaries list. The ASPSP answers with a list of beneficiary details structure.

Scopes

• piisp
• extended_transaction_history
• aisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/accounts/{accountResourceId}/balances

accountsBalances

Résumé

Retrieval of an account balances report (AISP)

Description

This call returns a set of balances for a given PSU account that is specified by the AISP through an account resource Identification
– The TPP has been registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that has been enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 “Authorization Code” or “Resource Owner Password” access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 “Authorization Code” or “Resource Owner Password” access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU
The AISP requests the ASPSP on one of the PSU’s accounts.
The ASPSP answers by providing a list of balances on this account. – The ASPSP must provide at least the accounting balance on the account. – The ASPSP can provide other balance restitutions, e.g. instant balance, as well, if possible. – Actually, from the PSD2 perspective, any other balances that are provided through the Web-Banking service of the ASPSP must also be provided by this ASPSP through the API.

Scopes

• cbpii
• aisp
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/accounts

accounts

Résumé

Retrieval of the PSU accounts (AISP)

Description

This call returns all payment accounts that are relevant the PSU on behalf of whom the AISP is connected.
Thanks to HYPERMEDIA, each account is returned with the links aiming to ease access to the relevant transactions and balances.
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results. – The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP. The TPP sends a request to the ASPSP for retrieving the list of the PSU payment accounts.
The ASPSP computes the relevant PSU accounts and builds the answer as an accounts list. The result may be subject to pagination in order to avoid an excessive result set. Each payment account will be provided with its characteristics.

Scopes

• extended_transaction_history
• cbpii
• aisp

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/accounts/{accountResourceId}/transactions

accountsTransactions

Résumé

Retrieval of an account transaction set (AISP)

Description

This call returns transactions for an account for a given PSU account that is specified by the AISP through an account resource identification.
The request may use some filter parameter in order to restrict the query – on a given imputation date range – past a given incremental technical identification
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.
– The TPP has been registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that has been enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication – The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) is any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
– The TPP has previously retrieved the list of available accounts for the PSU
The AISP requests the ASPSP on one of the PSU’s accounts. It may specify some selection criteria.
The ASPSP answers by a set of transactions that matches the query. The result may be subject to pagination in order to avoid an excessive result set.
The default transaction set, in the absence of filter query parameter, has to be specified and documented by the implementation.

Scopes

• aisp
• cbpii
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/consents

consents

Résumé

Forwarding the PSU consent (AISP)

Description

In the mixed detailed consent on accounts
– the AISP captures the consent of the PSU
– then it forwards this consent to the ASPSP
This consent replaces any prior consent that was previously sent by the AISP.
– The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
The PSU specifies to the AISP which of his/her accounts will be accessible and which functionalities should be available.
The AISP forwards these settings to the ASPSP.
The ASPSP answers by HTTP201 return code.

Scopes

• aisp
• extended_transaction_history
• cbpii

Paramètres

Codes retour

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/end-user-identity

endUserIdentity

Résumé

Retrieval of the identity of the end-user (AISP)

Description

This call returns the identity of the PSU (end-user).
– The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP. The AISP asks for the identity of the PSU. The ASPSP answers with the identity, i.e. first and last names of the end-user.

Scopes

• aisp
• extended_transaction_history
• cbpii

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/funds-confirmations

fundsConfirmations

Résumé

Payment coverage check request (CBPII)

Description

The CBPII can ask an ASPSP to check if a given amount can be covered by the liquidity that is available on a PSU cash account or payment card.
– The TPP has been registered by the Registration Authority for the CBPII role
– The TPP and the PSU have a contract that has been registered by the ASPSP – At this step, the ASPSP has delivered an « Authorization Code », a « Resource Owner Password » or a « Client Credential » OAUTH2 access token to the TPP (cf. § 3.4.2). – Each ASPSP has to implement either the « Authorization Code »/ »Resource Owner Password » or the « Client Credential » OAUTH2 access token model. – Doing this, it will edit the [security] section on this path in order to specify which model it has chosen
– The TPP and the ASPSP have successfully processed a mutual check and authentication – The TPP has presented its OAUTH2 « Authorization Code », « Resource Owner Password » or « Client Credential » access token which allows the ASPSP to identify the relevant PSU.
The CBPII requests the ASPSP for a payment coverage check against either a bank account or a card primary identifier.
The ASPSP answers with a structure embedding the original request and the result as a Boolean.

Scopes

• aisp
• cbpii
• extended_transaction_history

Paramètres

Codes retour

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/payment-requests/{paymentRequestResourceId}/o-confirmation

paymentRequestOConfirmation

Résumé

Confirmation of a payment request or a modification request using an OAUTH2 Authorization code grant (PISP)

Description

The PISP confirms one of the following requests or modifications:
– payment request on behalf of a merchant
– transfer request on behalf of the account’s owner
– standing-order request on behalf of the account’s owner
The ASPSP answers with a status of the relevant request and the subsequent Credit Transfer. – The TPP has been registered by the Registration Authority for the PISP role
– The TPP was provided with an OAUTH2 « Client Credential » access token by the ASPSP (cf. § 3.4.2).
– The TPP has previously posted a Request which has been saved by the ASPSP (cf. § 4.5.3) – The ASPSP has answered with a location link to the saved Payment Request (cf. § 4.5.4) – The TPP has retrieved the saved request in order to get the relevant resource Ids (cf. § 4.6).
– The PSU has been authenticated by the ASPSP through an OAUTH2 authorization code grant flow (REDIRECT approach) and the PISP got the relevant token
– The TPP and the ASPSP have successfully processed a mutual check and authentication – The TPP has presented its « OAUTH2 Authorization Code » access token Once the PSU has been authenticated through an OAUTH2 authorization code grant flow (REDIRECT approach), it is the due to the PISP to confirm the Request to the ASPSP in order to complete the process flow.
The ASPSP must wait for confirmation before executing the subsequent Credit Tranfer.

Scopes

• pisp
• aisp
• extended_transaction_history
• cbpii

Paramètres

Codes retour

Entrées

application/json

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

/stet/psd2/v1.4.2/trusted-beneficiaries

trustedBeneficiaries

Résumé

Retrieval of the trusted beneficiaries list (AISP)

Description

This call returns all trusted beneficiaries that have been set by the PSU.
Those beneficiaries can benefit from an SCA exemption during payment initiation.
The result may be subject to pagination (i.e. retrieving a partial result in case of having too many results) through a set of pages by the ASPSP. Thereafter, the AISP may ask for the first, next, previous or last page of results.
– The TPP has been registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that has been enrolled by the ASPSP – At this step, the ASPSP has delivered an OAUTH2 « Authorization Code » or « Resource Owner Password » access token to the TPP (cf. § 3.4.2).
– The TPP and the ASPSP have successfully processed a mutual check and authentication
– The TPP has presented its OAUTH2 « Authorization Code » or « Resource Owner Password » access token which allows the ASPSP to identify the relevant PSU and retrieve the linked PSU context (cf. § 3.4.2) if any.
– The ASPSP takes into account the access token that establishes the link between the PSU and the AISP.
The AISP asks for the trusted beneficiaries list.
The ASPSP answers with a list of beneficiary details structure.

Scopes

• cbpii
• aisp
• extended_transaction_history

Paramètres

Codes retour

Sorties

application/hal+json; charset=utf-8

application/json; charset=utf-8

Authentifications disponibles

OAuth 2.0

Vérifiez la disponibilité des fonds

Cas d’usage

Ce service permet de vérifier la disponibilité des fonds pour le compte à vue de notre client pour un montant donné.

Prérequis

Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité, d’avoir récupéré le jeton d’accès OAUTH2 (voir le cas d’usage « Récupérez votre jeton« ) et de fournir les paramètres du body.

Requête

post/funds-confirmations

Paramètres obligatoires ou facultatifs du body requis pour l’appel de ce service

paymentCoverageRequestId – obligatoire : Identifiant de la requête de paiement

payee – facultatif : Le commerçant chez qui la carte est acceptée et donnant des informations sur le PSU

instructedAmount – obligatoire : La structure comprenant le montant renseigné ainsi que la devise

⇒ currency – obligatoire : Devise du montant renseigné

⇒ amount – obligatoire : Montant qui permettra de déterminer si les fonds sont disponibles

accountId – obligatoire : Identifiant unique pour le compte renseigné.

⇒ iban – facultatif : Numéro de compte bancaire international (IBAN)

⇒ other – facultatif : Identifiant unique d’un compte, d’une personne ou organisation

=> identification – obligatoire : Identifiant de l’API

=> schemeName – obligatoire : Type d’identifiant (BANK, COID, SREN, SRET, NIDN, OAUT, CPAN)

=> issuer – facultatif : Entité fournissant l’identification

Résultat retourné

Le résultat retourné reprendra les informations de la requête ainsi que la réponse concernant la disponibilité des fonds sous la forme d’un booléen.

Un lien self sera également présent pour revenir à la page obtenue juste après exécution de la requête.

Exemple

Requête

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

{

« paymentCoverageRequestId » : « MyCoverage123456 »,

« instructedAmount » : {

« currency » : « EUR »,

« amount » : « 123.45 » },

« accountId » : { « iban » : « FR7613807008043001965405158 » }

}

Résultat

Status code : 200

Body
{ « result »: true, « request »: { « accountId »: { « iban »: « FR7613807008043001965405158 » }, « paymentCoverageRequestId »: « MyCoverage123456 », « instructedAmount »: { « amount »: « 123.45 », « currency »: « EUR » } }, « _links »: { « self »: { « href »: « https://www.rs-sandbox.api.89c3.com/stet/psd2/v1/funds-confirmations » } }}

(cas du persona Marc -D0999990I0)

Codes erreurs

Voici la liste de descriptions des codes erreurs de ce service. Il y a une annotation rouge pour ceux étant définis CFONB.

Lien vers la description de la méthode et des codes retour http

Tests d’acceptance

Ces cas de tests ont pour objectif de vous permettre d’effectuer un minimum de tests pour prendre en main cette API et y accéder depuis votre application.

Console Try-it

Principe

En vous connectant sur le portail, vous pouvez

• faire appel à l’API « disponibilité des fonds » via un formulaire dans lequel vous sélectionnez votre application et le jeton d’authentification/d’accès
• puis vous saisissez les paramètres de la méthode POST /funds-confirmations que vous souhaitez tester (soit headers, soit body) dont ceux mentionnés par une étoile sont obligatoires

Une fois les paramètres saisis, vous pouvez lancer l’exécution de la requête : vous obtiendrez soit un résultat, soit une erreur.

Les données utilisées pour faire le test en Try-It sont issues des personnas (voir la rubrique « Comment tester l’API » > « Tester nos personas« ).

L’utilisateur peut choisir un profil spécifique de client pour son test de façon à mieux appréhender les résultat obtenus.

Version 1.4.2

A compter du 8 juillet 2020, le try-it ne sera possible que pour la version V1.4.2.

Si vous avez déjà effectué une demande de GoLive, vous devez alors créer une nouvelle application, puis sélectionner la nouvelle API STET V1.4.2.

Si vous n’avez PAS effectué de demande de GoLive, vous pouvez :

• soit modifier votre application existante pour l’associer à la nouvelle API STET V1.4.2.
• soit créer une nouvelle application, puis sélectionner la nouvelle API STET V1.4.2.

Aperçu de l’écran permettant de récupérer le jeton Oauth2

Cet écran est accessible lorsque l’on édite l’application (dsp2 dans notre cas) et il permet de générer ou éditer un jeton Oauth2 que l’on sélectionnera dans le formulaire d’exécution Try-It.

Aperçu du formulaire d’exécution du Try-It

Paramètres du Try-It pour la méthode « POST/funds-confirmations »

Nb : pour les paramètres de type de données « body », il est possible de copier-coller les exemples (partie gauche de l’écran) dans le formulaire (à droite de l’écran) en changeant juste les valeurs spécifiques au client choisi.

Assemblage sandbox

Schéma Sandbox

La sandbox BPCE API peut être utilisée de 2 manières :

• Via le Try-it du portail BPCE-API (se référer au cas d’usage « Console Try-it« ) ;
• Directement via votre application en appelant l’API « disponibilité des fonds » de la plateforme BPCE-API (assemblage sandbox)

En assemblage sandbox, il y a 2 appels :

• Le premier pour récupérer le jeton d’autorisation.
• Le second pour faire l’appel à l’API d »‘disponibilité des fonds ».

Explications :

Votre application consommatrice de l’API « Disponibilité des fonds » de la sandbox va devoir récupérer un jeton d’accès via sa clé d’authentification auprès de l’AS (Authentification Server).

Ainsi l’application pourra consommer la méthode « POST /funds-confirmations » grâce à son jeton d’accès.

Les données utilisées pour faire les tests seront issues des personnas (voir le cas d’usage « Testez nos persona« ), ce qui permettra de choisir des profils spécifiques selon les tests de façon à mieux appréhender les résultats obtenus.

Testez nos persona

Cette page présente les jeux de données qui permettent de tester l’API :

• Des clients fictifs sont proposés par segment de clientèle (étudiant, cadre, entreprise, etc.)
• Les caractéristiques de leurs comptes et cartes à débit différé y sont déclinées (mono-compte, multi-comptes, multi-bancarisé, solde du compte)
• Les données utiles attendues en entrée par les API y sont énumérées (identifiant banque à distance, code SMS pour les authentifications fortes, IBAN)

Comment récupérer son jeton d'accès OAUTH2 ?

Schéma du principe de récupération du jeton d’accès OAUTH2

En tant que développeur d’une application désirant utiliser cette API, l’obtention d’un jeton d’accès OAUTH2 vous est nécessaire et se fait grâce au processus suivant :

Références

• Section 3.4.3.2 de la spécification STET v1.4.0.47 : https://www.stet.eu/en/psd2/
• OAuth 2.0 Authorization Framework : https://tools.ietf.org/html/rfc6749#section-4.1

Développement pas à pas

1. Le client vous indique l’identité de sa Banque Populaire teneur de compte.

2. Vous initiez la séquence de récupération du jeton d’accès OAUTH2 en redirigeant le client via son navigateur internet vers l’infrastructure informatique d’autorisation de la Banque Populaire teneur de compte, le détail des liens et des paramètres se trouvent ci-après :

Voir aussi [STET Framework page 21]

GET /authorize?response_type=code&client_id={clientId}&redirect_uri={redirectUri}&scope={scope}[&state={state}]

3. La Banque Populaire teneur de compte (ASPSP) va :

• Identifier et authentifier le client par l’une des méthodes d’authentification forte qu’elle propose et présente au client;
• Effectuer des vérifications liées à votre profil en tant qu’AISP ou CBPII (validité des certificats QWAC et QSealc et de votre rôle dans le référentiel de place, non révocation de votre profil, etc.).

4. Une fois ces vérifications effectuées et si elles sont concluantes, la Banque Populaire va vous rediriger notre client vers votre site en utilisant l’URL de « call-back » et les paramètres ci-après. A noter que vous devrez nous communiquer cette URL lorsque vous remplirez le formulaire de souscription pour le live sur le portail BPCE API.

Voir aussi [STET Framework page 22]

5. Vous allez pouvoir alors demander directement à la Banque Populaire le jeton d’accès OAUTH2 via un appel de type POST envoyé avec les paramètres suivants :

Voir aussi [STET Framework page 22]

Exemple

POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &client_id={clientId}

6. La Banque Populaire teneur de compte (ASPSP) va :

• Effectuer des vérifications liées à votre profil en tant qu’AISP ou CBPII (validité des certificats QWAC et QSealc et de votre rôle, non révocation de votre profil etc.
• Vous identifier et vous authentifier en tant qu’AISP ou CBPII via votre certificat que vous mettrez à disposition pour sécuriser l’échange mutuel

7. Une fois ces vérifications effectuées et si elles sont concluantes, la Banque Populaire va vous renvoyer une réponse HTTP200 (OK) qui contiendra les données suivantes:

Voir aussi [STET Framework page 23]

Exemple

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { « access_token »: »2YotnFZFEjr1zCsicMWpAA », « token_type »: »example », « expires_in »:3600, « refresh_token »: »tGzv3JOkF0XG5Qx2TlKWIA » }

8. Dès que le jeton d’accès OAUTH2 délivré par la Banque Populaire (valable 180 jours) a été récupéré par vos soins, vous pourrez le présenter pour pouvoir consommer l’API (voir les cas d’usage pour les méthodes de l’API).

Authentification du client

Méthodes d’identification du client

Il existe trois méthodes différentes pour l’identification du client qui se doit d’être pertinente pour l’ASPSP (établissement de crédit teneur de compte).

Celles-ci sont implémentées de différentes manières :

• soit durant le processus d’authentification (cf. § 3.4), pour la plupart des cas d’utilisation concernant les AISP et les CBPII;
• soit durant le consentement, par exemple dans le cas d’une requête de paiement (cf. § 3.5)

Principe pour la méthode REDIRECT > cette méthode s’applique pour les Banques Populaires

Dans le cas de cette méthode, l’identification du client est faite entièrement par l’ASPSP.

L’AISP va orienter le client vers le service d’authentification de l’ASPSP, ce qui veut dire que le client va délaisser temporairement l’interface de l’AISP pour s’identifier via l’interface de l’ASPSP.

Si l’AISP a déjà récupéré un identifiant du client qui peut être approuvé par l’ASPSP de manière sûre alors dans ce cas l’identifiant peut être inclus dans la redirection à condition que le protocole de redirection le permette.

Une fois l’identification achevée, l’ASPSP va rediriger le client vers l’interface de l’AISP.

Exceptions à l’authentification forte

Les exceptions à une authentification forte sont prévues par les normes techniques de réglementation (éditées par l’Agence Bancaire Européenne) portant sur l’authentification forte et tout particulièrement sur l’initiation des services de paiement.

Dans ce cas, l’API offre la possibilité au TPP de fournir toute information utile à l’ASPSP.

Au final, c’est l’ASPSP qui est garant de la décision d’appliquer ou non cette exception.

Utiliser le fallback

Principe

Conformément à la réglementation, les établissements du groupe BPCE ont mis en place une interface dédiée aux prestataires de services de paiement : il s’agit des API REST DSP2 publiées.

Si les API DSP2 exposées sont défaillantes, le prestataire des services de paiements pourra utiliser la solution couvrant les « mesures d’urgence applicables à une interface dédiée » (ou « fallback ») dont le principe est le suivant :

Cette solution répond aux exigences règlementaires de la DSP2 (article 33 des RTS). Vous pourrez l’utiliser avec les mêmes conditions et pré-requis décrits dans la rubrique « Eligibilité« .

Roadmap

Retrouvez ci-dessous les éléments de notre trajectoire prévisionnelle :

(*) Fonctionnalités Principales :

• Utilisation par le TPP du même endpoint que l’interface dédiée. Il dépend donc du code établissement <cdetab = 13807> qui permet d’adresser le bon référentiel client.

• Un paramètre de requête (header « fallback:1 » présent ou absent) ajouté par le TPP permet de distinguer une requête « Fallback » d’une requête API via l’interface dédiée qui doit être utilisée systématiquement

• Authentification du TPP via authentification mutuelle TLS par un certificat eIDAS (QWAC)

• Sécurisation identique à celle d’un accès à la banque en ligne du PSU (même interface utilisée par le PSU qu’en accès direct, et mêmes moyens d’authentification du client)

• Dans le cadre de la montée en charge de l’usage de l’interface dédiée (API), il n’est pas mis en place de bascule dynamique : la solution fallback est toujours active

• La solution de fallback est une solution de secours ne devant pas être utilisée comme moyen principal d’accès pour proposer les services DSP2. Son usage en est monitoré et tout usage abusif par un/des TPP sera automatiquement reporté auprès de l’autorité nationale compétente.

Exemple

1. Dans le cas où les API DPS2 sont indisponible de façon imprévue ou le système tomberait en panne (voir critères dans le texte RTS Art. 33), le TPP peut alors envoyer la requête :

POST https://www.<codetab>.live.api.89c3.com/stet/psd2/oauth/token

avec par exemple <codetab> =

• 13807 pour BPGO
• 10548 pour Banque de Savoie
• 40978 pour Banque Palatine

avec :

• son certificat eIDAS QWAC de production

• le paramètre header (fallback: »1″)

POST /stet/psd2/oauth/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

X-Request-ID: 1234

fallback: 1

User-Agent: PostmanRuntime/7.16.3

Accept: */*

Cache-Control: no-cache

Host: www.13807.live.api.banquepopulaire.fr

Accept-Encoding: gzip, deflate

Content-Length: 67

Connection: keep-alive

client_id=PSDFR-ACPR-12345&grant_type=client_credentials&scope=aisp

2. Si les vérifications sont positives, nous allons vous renvoyer dans le header une url de type à utiliser dans le cadre de la redirection vers l’environnement de la banque en ligne, et qui contient un jeton JWT (champs « &fallback= ») qui doit être aussi utilisé dans ce cadre :

HTTP/1.1 302 Found

Date: Tue, 25 May 2021 21:46:59 GMT

Location: https://www.ibps.bpgo.banquepopulaire.fr/se-connecter/sso?service=cyber&cdetab=13807&fallback=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImhF…

Content-Length: 870

Connection: close

Content-Type: text/html; charset=iso-8859-1

</head><body>

<h1>Found</h1>

<p>The document has moved <a href= »/www.13807.live.api.banquepopulaire.fr&fallback=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImhF… »>here</a>.</p>

</body></html>

3. Une fois redirigé, le TPP doit utiliser ensuite les identifiants du PSU via sa méthode propriétaire

Pour plus de détails sur la requête POST, voir STET V1.4.2.17 / Part I / section 3.4.3

Limites

Les contraintes de cette solution sont les suivantes :

• Pas de réutilisation du contexte de l’interface dédiée, ni du jeton d’accès valable 180 jours (AISP)

• Suite à la mise en place de la nouvelle solution de banque en ligne, le fallback permet de rester sur les anciens écrans de la banque en ligne

• Seules les fonctionnalités DSP2 présentes sur la banque en ligne (référence: banque à distance sur internet fixe – pas la banque sur mobile) sont accessibles via le fallback. Par exemple, les services de banque en ligne ne proposent pas de paiement e-commerce. Cette fonctionnalité PISP n’est donc pas disponible en mode fallback

• Le client utilisateur des services (PSU) doit être connecté à l’application du TPP (pas de possibilité de traitement batch AISP pour venir récupérer les données consenties du client). La DSP2 imposant également un renforcement des moyens d’authentification forte (AF/SCA) systématique pour les accès à la banque à distance/en ligne, les moyens d’authentification fournis aux clients PSU seront utilisés (liste non exhaustive) :
  • Soft token
  • OTP SMS
  • Clé physique (pour les entreprises)

Historique des versions

Cette API est conforme à la spécification STET (https://www.stet.eu/en/psd2/) afin de répondre aux exigences règlementaires de la DSP2. Elle tient compte des limitations fonctionnelles propres aux Banques Populaires.

Pour rappel

• les textes de la directive de paiement numéro 2 (DSP2, référence UE 2015/2366 du 25/11/2015) sont rentrés en application le 13 janvier 2018 : http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32015L2366
• ils ont été compétés par les normes techniques de réglementation (NTR, règlement délégué UE 2018/389) relatives à l’authentification forte du client et à des normes ouvertes communes et sécurisées de communication dont la date d’application est le 14 septembre 2019. Ces normes sont les RTS (Rules Technical Standards) : https://eur-lex.europa.eu/legal-content/FR/TXT/?toc=OJ%3AL%3A2018%3A069%3ATOC&uri=uriserv%3AOJ.L_.2018.069.01.0023.01.FRA

En France, l’ordonnance n° 2017-1252 du 9 août 2017 transpose la directive DSP2 dans la partie législative du code monétaire et financier. L’ordonnance est complétée au plan réglementaire par les décrets n° 2017-1313 et n° 2017-1314 du 31 août 2017 et les cinq arrêtés du 31 août 2017.

Planning des évolutions à venir de l’API

Conformément à l’article 30 (5) des RTS, une assistance pour les prestataires PSP tiers est mise à disposition. Ce support est accessible via le formulaire sur ce portail BPCE API, ou via https://www.api.89c3.com/fr/nous-contacter. Les réponses se font pendant les heures de travail ouvrées.

Le principe général du support est schématisé ci-dessous en prenant en compte les délais réglementaires prévus à l’article 30 (4) des RTS :

Versionning de l’API

Vous pouvez consulter l’assistant virtuel (en bas à droite de votre écran) au sujet des textes de la norme STET.

Evolutions importantes apportées depuis la première version livrée :

Roadmap

L’API disponibiltié des fonds fait l’objet d’améliorations et d’évolutions continues tout au long de l’année. Retrouvez ci-dessous notre roadmap prévisionnelle :

Limitations

Limitations fonctionnelles

Les limitations de cette API DSP2 sont les suivantes :

• S’applique à toutes les Banques Populaires exceptée la BRED
• Ne s’applique qu’aux comptes de paiements actifs et accessibles en ligne (cf. texte de la Directive DSP2) => l’interrogation du solde ne pourra se faire que pour un compte à vue.
• N’utilise que le mode d’authentification par redirection (Authentification Forte du client demandée et gérée via la banque).
• Ne bloque / ne réserve pas les fonds.
• Ne permet l’accès aux données que via l’IBAN (champ [iban] ) du compte à vue => les Banques Populaires ne connaissent pas les références de vos cartes privatives.

Limitations sur les données

La liste des établissements bancaires actuellement accessibles pour cette API est détaillée ci-dessous. Le code établissement (<cdetab>) vous permet d’adresser le bon référentiel client via un « endpoint » au format www.<codetab>.live.api.89c3.com.

Exemples :

• STET V1.4.0 POST https://www.16807.live.api.89c3.com/stet/psd2/v1/funds-confirmations ( /!\ scope = piisp )

• STET V1.4.2 POST https://www.16807.live.api.89c3.com/stet/psd2/v1.4.2/funds-confirmations ( /!\ scope = cbpii )

Eligibilité

Les ressources de cette API ne peuvent être consommées que par des PSP ayant le rôle « CBPII » ou « PIISP » suivant la version STET utilisée. Ce statut est délivré par les autorités financières du pays dans lequel la demande est effectuée ; en France il s’agit de l’Autorité de Contrôle Prudentiel et de Résolution (ACPR), liée à la Banque de France.

L’obtention et la conservation d’un agrément relèvent de procédures rigoureuses afin d’apporter des garanties fortes aux utilisateurs des services de paiements, les formulaires étant disponibles sur le site de l’ACPR https://acpr.banque-france.fr/autoriser/procedures-secteur-banque/tous-les-formulaires.

De plus, vous devez disposer disposer de certificats délivrés par une autorité de certification reconnue (Qualified Certification Service Providers – QTSP : https://webgate.ec.europa.eu/tl-browser/#/) conformes au règlement eIDAS (electronic IDentification And trust Services : https://www.ssi.gouv.fr/entreprise/reglementation/confiance-numerique/le-reglement-eidas/) et respectant la norme ETSI (https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.02.01_60/ts_119495v010201p.pdf).

Afin de consommer les API DSP2 proposées sur le portail du groupe BPCE, vous aurez à nous transmettre vos certificats QWAC et QSEALC :

• de production pour le fonctionnement de l’assemblage en sandbox

• de production lors des appels sur notre passerelle BPCE API Live

Seules les clés publiques au format .pem sont nécessaires. Des contrôles sur les données des certificats seront effectués à partir des registres Français (REGAFI : https://www.regafi.fr) et Européen (ABE ou EBA : https://euclid.eba.europa.eu/register/pir/disclaimer).

Vous pouvez également consulter l’assistant virtuel au sujet du principe de l’agrément.