Natixis Wealth Management – Information sur compte – (Norme STET V1.6.2)
Accédez aux données autorisées par les clients
Description des services proposés [NORME STET V1.6.2]
Récupérer son jeton d’autorisation
Le client (PSU) doit indiquer l’identité de sa banque teneuse de compte à l’AISP.
L’AISP initie ensuite 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 teneuse de compte.
La banque teneuse de compte (ASPSP) va :
- Identifier et authentifier le client PSU par l’une des méthodes d’authentification forte proposée préalablement au client
- Demander le consentement au client par l’intermédiaire d’écrans de saisie d’informations
Une fois ces vérifications effectuées et si elles sont concluantes, la banque va rediriger le client vers le site de l’AISP en utilisant les URL de « call-back » (redirection) transmises précédemment ainsi que certains paramètres.
L’AISP va pouvoir alors demander directement à la banque le jeton d’accès OAUTH2 via un appel de type POST.
La banque teneuse de compte (ASPSP) va alors :
- Identifier l’AISP et l’authentifier en tant que TPP via le certificat X509 mis à disposition pour sécuriser l’échange mutuel
- Effectuer des vérifications liées au profil du TPP (validité des certificats eIDAS et du rôle AISP dans le référentiel de place, non révocation de l’agrément DSP2, etc…)
Une fois ces vérifications effectuées et si elles sont concluantes, la banque va renvoyer une réponse HTTP 200 (OK) à l’AISP avec un certain nombre de données.
Dès que le jeton d’accès OAUTH2 délivré par la banque a été récupéré par l’AISP, celui-ci pourra le présenter pour pouvoir consommer les ressources de l’API.
NB : vous pouvez vous référer au cas d’usage « Comment récupérer son jeton d’accès OAUTH2 ? » pour plus de détails.
Obtenir la liste des comptes à vue d’un client
Description
Cet appel permet de récupérer la liste des comptes à vue du PSU pour lequel l’AISP est connecté.
Chaque compte est retourné avec les liens permettant de consulter les soldes ou les encours ainsi que les transactions associées à celui-ci.
L’identifiant de ressource fourni pour chaque compte servira de paramètre pour les requête de récupération de soldes et de transactions.
Une pagination de la liste renvoyée peut être faite si le nombre de comptes est élevé, dans ce cas des liens donnant accès à la première page,
la précédente, la suivante et la dernière page faciliteront la consultation des résultats.
Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client ou pour un TPP, hors pagination.
Prérequis
Le TPP est présent dans le référentiel des autorisations avec un rôle d’AISP.
Le TPP et le PSU sont liés à l’ASPSP par un contrat.
Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.
Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.
Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.
L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.
Echange de données
Le TPP envoie une requête à l’ASPSP pour récupérer la liste des comptes du PSU. L’ASPSP obtient la liste des comptes du PSU et en constitue une liste.
Le résultat obtenu peut être paginé de façon à répartir les données sur plusieurs pages et rendre l’ensemble plus lisible.
Chaque compte sera détaillé avec ses caractéristiques.
Consultez le cas d’usage « Obtenir la liste des comptes à vue d’un client » sous la rubrique « Cas d’usage AISP ».
Obtenir la liste des soldes d’un client
Description
Cet appel permet de récupérer la liste des soldes d’un compte à vue du PSU pour lequel l’AISP est connecté.
Ce service fait suite à la restitution de la liste des comptes et cartes d’un client : un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des soldes.
D’après les spécifications STET, quatre types de soldes peuvent être retournés dans le cas d’un compte passé en paramètre :
- En valeur (« VALU » dans la norme STET) => non applicable
- Comptable (« CLBD » dans la norme STET) => solde comptable en fin de période (semaine / mois / trimestre / semestre / année)
- Instantané (« XPCD » dans la norme STET) => non applicable
- Autre (« OTHR » dans la norme STET) => non applicable
Une pagination de la liste renvoyée peut être faite s’il y a beaucoup de données à afficher, dans ce cas des liens donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats.
Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP.
Prérequis
Le TPP est présent dans le référentiel des autorisations avec un rôle d’AISP.
Le TPP et le PSU sont liés à l’ASPSP par un contrat.
Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.
Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.
Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.
L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.
Le TPP a récupéré auparavant la liste des comptes disponibles pour le PSU.
Echange de données
L’AISP sollicite l’ASPSP pour un des comptes à vue ou une des cartes à débit différé du PSU.
L’ASPSP répond en envoyant la liste des soldes du compte.
L’ASPSP doit fournir au minimum le solde comptable du compte.
L’ASPSP peut fournir d’autres soldes si cela est possible.
D’un point de vue DSP2, tous les soldes qui seront proposés par l’ASPSP via son web Banking service devront provenir de l’API Information sur compte.
Consultez le cas d’usage « Obtenir la liste des soldes d’un compte d’un client » sous la rubrique « Cas d’usage AISP ».
Obtenir la liste des transactions d’un client
Description
Cet appel permet de récupérer la liste des opérations d’un compte à vue du PSU pour lequel l’AISP est connecté.
Les transactions obtenues sont inférieures ou égales à 90 jours par rapport à la date du jour.
Une pagination de la liste renvoyée peut être faite s’il y a beaucoup de données à afficher, dans ce cas des liens donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats.
Ce service fait suite à la restitution de la liste des comptes à vue d’un client : un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des transactions.
Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP, hors pagination.
Prérequis
Le TPP est présent dans le référentiel des autorisations avec un rôle d’AISP.
Le TPP et le PSU sont liés à l’ASPSP par un contrat.
Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.
Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.
Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.
L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.
Le TPP a récupéré auparavant la liste des comptes à vue disponibles pour le PSU.
Echange de données
L’AISP sollicite l’ASPSP pour un des comptes à vue ou cartes à débit différé du PSU. Il peut fournir certains critères de sélection.
L’ASPSP répond avec une liste de transactions correspondant à la requête.
Le résultat obtenu peut être paginé de façon à répartir les données sur plusieurs pages et rendre l’ensemble plus lisible.
Consultez le cas d’usage « Obtenir la liste des transactions d’un compte d’un client » sous la rubrique « Cas d’usage AISP ».
Gestion du consentement d’un client
Description
Cet appel permet d’enregistrer le consentement d’un PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.
Ce consentement contient le détail des accès consentis par le PSU. Quatre types d’accès peuvent être définis :
- Balances : accès aux soldes d’un ou plusieurs comptes du PSU
- Transactions : accès aux transaction d’un ou plusieurs comptes du PSU
- TrustedBeneficiaries : accès à la liste des bénéficiaires de confiance du PSU
Un enregistrement de consentement est donc réalisé pour un PSU donné, un AISP donné, une opération donnée et un compte donné (sauf pour les accès trustedBeneficiairies).
Chaque nouvel appel de l’AISP au service d’enregistrement du consentement pour un PSU donné, anullera et remplacera le consentement précédent le cas échéant.
Par ailleurs, à la demande du PSU, le consentement pourra être modifié ultérieurement par type d’opération : par exemple, le consentement pour l’accès à l’historique des transactions peut être révoqué alors que le consentement pour les soldes reste actif.
Le consentement est vérifié à chaque requête passée.
Prérequis
Le prestataire est présent dans le référentiel des TPP avec un rôle d’AISP.
Le TPP et le PSU sont liés à l’ASPSP par un contrat.
Lors de cette étape, un code d’autorisation OAUTH2 (ou jeton/token d’accès) a été délivré au TPP par l’ASPSP.
Le TPP et l’ASPSP se sont mutuellement contrôlés et authentifiés.
Le TPP a fourni son jeton d’accès de façon à ce que l’ASPSP puisse identifier le PSU et récupérer le contexte associé.
L’ASPSP a pris en compte le jeton d’accès qui établit le lien entre le PSU et l’AISP.
Echange de données
Le PSU communique à l’AISP la liste des comptes et des fonctionnalités pour lesquels un consentement est donné.
L’AISP transmet ces informations à l’ASPSP.
L’ASPSP répond par un code retour http 201.
Publications réglementaires
| Période | Document |
| Disponibilité des API DSP2 à date | Télécharger le document |
| Statistiques T4 2023 | Télécharger le document |
| Statistiques T3 2023 | Télécharger le document |
| Statistiques T2 2023 | Télécharger le document |
| Statistiques T1 2023 | Télécharger le document |
| Statistiques T4 2022 | Télécharger le document |
| Statistiques T3 2022 | Télécharger le document |
| Statistiques T2 2022 | Télécharger le document |
| Statistiques T1 2022 | Télécharger le document |
| Statistiques T4 2021 | Télécharger le document |
| Statistiques T3 2021 | Télécharger le document |
| Statistiques T2 2021 | Télécharger le document |
| Statistiques T1 2021 | Télécharger le document |
| Statistiques T4 2020 | Télécharger le document |
| Statistiques T3 2020 | Télécharger le document |
| Statistiques T2 2020 | Télécharger le document |
| Statistiques T1 2020 | Télécharger le document |
Catégories
/stet/psd2/v1.6.2/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
Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was 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 should provide at least one balance on the account. – For cash account, this balance should be the accounting balance (CACC) – For card transactions account, the accounting balance is meaningless and must be replaced by an other type of balance (OTHR).
– Case of no registered transaction on the account, this balance will have an amount equal to zero.
– 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
- pisp
- aisp
- cbpii
- extended_transaction_history
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| accountResourceId (required) | string path Identification of account resource to fetch |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | The ASPSP answers with a list of account balances |
| 204 | No content. |
| 400 | Invalid status value |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 503 | Service unavailable. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/accounts
accounts
Résumé
Retrieval of the PSU accounts (AISP)
Description
Description
This call returns all payment accounts that are relevant for 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 was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was 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
- pisp
- cbpii
- aisp
- extended_transaction_history
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | The ASPSP return a PSU context – listing the accounts that were made available to the AISP by the PSU and, – for each of these accounts, the further transactions that were enabled by the PSU through HYPERMEDIA links. |
| 204 | No content. |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 503 | Service unavailable. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/accounts/{accountResourceId}/overdrafts
accountsOverdrafts
Résumé
Retrieval of an account overdraft (AISP)
Description
Description
This call returns the overdrafts that can be used 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
Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was 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.
The ASPSP answers by the overdraft that can be applied.
Scopes
- pisp
- extended_transaction_history
- cbpii
- aisp
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| accountResourceId (required) | string path Identification of account resource to fetch |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | Overdraft response |
| 204 | No content. |
| 400 | Invalid status value |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 503 | Service unavailable. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/accounts/{accountResourceId}/owners
accountsOwners
Résumé
Retrieval of an account owners (AISP)
Description
Description
This call returns the owners identities for a given PSU account that is specified by the AISP through an account resource identification.
This call cannot be used when the account is owned by a legal entity where the identity of this entity is directly available in the account structure (field [company]).
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was 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.
The ASPSP answers by the identities of the account owners.
Scopes
- extended_transaction_history
- cbpii
- pisp
- aisp
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| accountResourceId (required) | string path Identification of account resource to fetch |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | Account owners identities response |
| 204 | No content. |
| 400 | Invalid status value |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 503 | Service unavailable. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/accounts/{accountResourceId}/transactions/{transactionResourceId}/details
accountsTransactionsDetails
Résumé
Retrieval of transaction details (AISP)
Description
Description
This call returns the details of a transaction from a given PSU account.
The AISP has to specified
– the account through an account resource identification
– the transaction through a transaction resource identifcation
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was 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 and the transactions from one given account
– A transaction includes a « details » hyperlink which indicates that detailed information is available for this transaction.
Business flow
The AISP requests the ASPSP on one of the transactions.
The ASPSP answers by the details on this transaction.
Scopes
- pisp
- cbpii
- aisp
- extended_transaction_history
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| accountResourceId (required) | string path Identification of account resource to fetch |
| transactionResourceId (required) | string path Identification of transaction resource to fetch |
| dateFrom | string query Inclusive minimal imputation date of the transactions. Transactions having an imputation date equal to this parameter are included within the result. |
| dateTo | string query Exclusive maximal imputation date of the transactions. Transactions having an imputation date equal to this parameter are not included within the result. |
| dateType | string query This parameter specifies the type of date on which [dateFrom] and [dateTo] apply. If not provided, the ASPSP will use its own default date type as specified in its implementation documentation. The implementation documentation must also specify which date types are supported. |
| entryReferenceFrom | string query Specifies the value on which the result has to be computed. Only the transaction having a technical identification greater than this value must be included within the result |
| entryReferenceto | string query Specifies the value on which the result has to be computed. Only the transaction having a technical identification less than or equal to this value must be included within the result |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | Complete transactions response |
| 204 | No content. |
| 400 | Invalid status value |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 503 | Service unavailable. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/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 was registered by the Registration Authority for the AISP role
– The TPP and the PSU have a contract that was 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.
– Case of no registered transaction on the account, this result will be an empty list.
The default transaction set, in the absence of filter query parameter, has to be specified and documented by the implementation.
The sort order of transaction might be specific to each ASPSP, due to each Information System constraints.
Scopes
- extended_transaction_history
- cbpii
- aisp
- pisp
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| accountResourceId (required) | string path Identification of account resource to fetch |
| dateFrom | string query Inclusive minimal imputation date of the transactions. Transactions having an imputation date equal to this parameter are included within the result. |
| dateTo | string query Exclusive maximal imputation date of the transactions. Transactions having an imputation date equal to this parameter are not included within the result. |
| dateType | string query This parameter specifies the type of date on which [dateFrom] and [dateTo] apply. If not provided, the ASPSP will use its own default date type as specified in its implementation documentation. The implementation documentation must also specify which date types are supported. |
| entryReferenceFrom | string query Specifies the value on which the result has to be computed. Only the transaction having a technical identification greater than this value must be included within the result |
| entryReferenceto | string query Specifies the value on which the result has to be computed. Only the transaction having a technical identification less than or equal to this value must be included within the result |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | Complete transactions response |
| 204 | No content. |
| 400 | Invalid status value |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 503 | Service unavailable. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/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 was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was 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
- cbpii
- extended_transaction_history
- aisp
- pisp
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| access (required) | Access body List of consents granted to the AISP by the PSU. |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
Codes retour
| 201 | Created |
| 400 | Invalid status value |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 408 | Request Timeout. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 501 | Not Implemented. This code should be used when the entry point is implemented but cannot provide a result, given the context. When the entry point is not implemented at all, HTTP400 will be returned. |
| 503 | Service unavailable. |
Entrées
application/json
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/end-user-identity
endUserIdentity
Résumé
Retrieval of the identity of the end-user (AISP)
Description
Description
This call returns the identity of the PSU (end-user).
### Prerequisites
– The TPP was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was 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 identity of the PSU. The ASPSP answers with the identity, i.e. first and last names of the end-user.
Scopes
- aisp
- pisp
- cbpii
- extended_transaction_history
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
Codes retour
| 200 | The ASPSP returns the identity of the PSU |
| 204 | No content. |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 429 | Too many requests. |
| 500 | Internal server error. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
/stet/psd2/v1.6.2/trusted-beneficiaries
trustedBeneficiaries
Résumé
Retrieval of the trusted beneficiaries list (AISP)
Description
Description
This call returns all trusted beneficiaries that were 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 was registered by the Registration Authority for the AISP role.
– The TPP and the PSU have a contract that was 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
- cbpii
- aisp
- extended_transaction_history
- pisp
Paramètres
| Authorization (required) | string header Access token to be passed as a header |
| PSU-IP-Address | string header IP address used by the PSU’s terminal when connecting to the TPP |
| PSU-IP-Port | string header IP port used by the PSU’s terminal when connecting to the TPP |
| PSU-HTTP-Method | string header Http method for the most relevant PSU’s terminal request to the TTP |
| PSU-Date | string header Timestamp of the most relevant PSU’s terminal request to the TTP |
| PSU-GEO-Location | string header Geographical location of the PSU as provided by the PSU mobile terminal if any to the TPP |
| PSU-User-Agent | string header « User-Agent » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Referer | string header « Referer » header field sent by the PSU terminal when connecting to the TPP. Notice that an initial typo in RFC 1945 specifies that « referer » (incorrect spelling) is to be used. The correct spelling « referrer » can be used but might not be understood. |
| PSU-Accept | string header « Accept » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Charset | string header « Accept-Charset » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Encoding | string header « Accept-Encoding » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Accept-Language | string header « Accept-Language » header field sent by the PSU terminal when connecting to the TPP |
| PSU-Device-ID | string header UUID (Universally Unique Identifier) for a device, which is used by the PSU, if available. UUID identifies either a device or a device dependant application installation. In case of installation identification this ID need to be unaltered until removal from device. |
| Digest | string header Digest of the body |
| Signature (required) | string header [http-signature of the request](https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId must specify the way to get the relevant qualified certificate. It is requested that this identifier is an URL aiming to provide the relevant Qualified Certificate. |
| X-Request-ID (required) | string header Correlation header to be set in a request and retrieved in the relevant response |
| workspace | string query Workspace to be used for processing an AISP request. If not provided, the default workspace is computed from the authentication that was used for getting the OAuth2 Access Token. |
Codes retour
| 200 | The ASPSP returns the list of whitelisted beneficiaries |
| 204 | No content. |
| 401 | Unauthorized, authentication failure. |
| 403 | Forbidden, authentication successful but access to resource is not allowed. |
| 404 | Not found, no request available. |
| 405 | Method Not Allowed. |
| 406 | Not Acceptable. |
| 429 | Too many requests. |
| 500 | Internal server error. |
| 501 | Not Implemented. This code should be used when the entry point is implemented but cannot provide a result, given the context. When the entry point is not implemented at all, HTTP400 will be returned. |
Sorties
application/hal+json; charset=utf-8
application/json; charset=utf-8
Authentifications disponibles
OAuth 2.0
Catégories
Obtenir un jeton d'accès
1- Vous envoyez directement une requête vers l’infrastructure informatique d’autorisation de la banque teneuse de compte, le détail des liens et des paramètres se trouvent ci-après :
2 -La banque teneuse de compte (ASPSP) va effectuer des vérifications liées à votre profil en tant que TPP (validité des certificats et de votre rôle dans le référentiel de place, non révocation de votre profil, etc…).
3 -Une fois ces vérifications effectuées et si elles sont concluantes, la banque va vous répondre via un code HTTP200 (OK) et les données suivantes :
Le jeton d’accès doit être utilisé dans toutes les requêtes au niveau du header « Authorization » préfixé par le type de jeton « Bearer ». Si le jeton a expiré, la requête sera rejetée avec un code HTTP400 et des données indiquant « Token invalide ». Cette requête pourra être renvoyée une fois un nouveau jeton d’accès de type Client Credential demandé et obtenu.
A noter que la durée de vie maximale d’un jeton d’accès est à ce jour de 180 jours calendaires.
Obtenir la liste des comptes
Ce service permet de lister tous les comptes éligibles* à la DSP2.
NB (*) : comptes de paiements actifs et accessibles en ligne, soit des comptes à vue pour les professionnels et entreprises gérés par ce teneur de compte.
Prérequis
Cet appel permet de récupérer la liste des comptes paiement du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.
Chaque compte est retourné avec les liens permettant de consulter les soldes ou les encours ainsi que les transactions associées à celui-ci.
Une pagination de la liste renvoyée peut être faite si le nombre de comptes est élevé, dans ce cas des liens de navigation donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats.
Un lien self sera également présent pour revenir à la page obtenue juste après exécution de la requête.
Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un TPP sans connexion du client, hors pagination.
Requête
« GET /accounts »
Paramètre
Aucun paramètre spécifique n’est requis lors de l’appel à ce service (en dehors du jeton oauth2).
Exemple
Requête
GET www.18919.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts
Obtenir les soldes
Prérequis
Cet appel permet de récupérer le solde d’un compte de paiement du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.
Ce service fait suite au retour de la liste des comptes de paiement d’un client: un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des soldes.
Un type de solde est retourné dans le cas d’un compte passé en paramètre: le solde comptable (« CLBD » dans la norme STET) à J-1.
Un lien self sera présent pour revenir à la page obtenue juste après l’exécution de la demande.
L’accès à cette méthode est limité à un maximum de 4 accès par lots par jour calendaire, pour un client, pour un compte ou pour un TPP.
Requête
« GET /accounts/{accountRessourceId}/balances »
Paramètres
Paramètre « accountRessourceId » : compte de paiement dont nous voulons consulter les soldes, ces données correspondent à la section « resourceId » obtenue dans la page de résultat de la requête get /accounts.
Exemple
Requête
GET www.18919.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510B
Obtenir la liste des transactions
Prérequis
Cet appel permet de récupérer la liste des opérations d’un compte de paiement du PSU (usager d’un service de paiement) pour lequel l’AISP (prestataire de service de paiement) est connecté.
Les transactions obtenues sont inférieures ou égales à 90 jours par rapport à la date du jour.
Une pagination de la liste renvoyée peut être faite s’il y a beaucoup de données à afficher, dans ce cas des liens de navigation donnant accès à la première page, la précédente, la suivante et la dernière page faciliteront la consultation des résultats (voir la section « Limitations » pour le nomber de résultats max retourné par page).
Un lien self sera également présent pour revenir à la page obtenue juste après exécution de la requête.
Ce service fait suite à la restitution de la liste des comptes de paiement d’un client : un identifiant de ressource correspondant à un compte doit être fourni pour obtenir la liste des transactions.
Les accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client, pour un compte ou pour un TPP, hors pagination.
Requête
« GET /accounts/{accountRessourceId}/transactions »
Paramètres
Paramètre accountRessourceId : compte paiement pour lequel on veut consulter les opérations, cette donnée correspond à la rubrique « ressourceId » obtenue dans la page de résultat de la requête get/accounts.
Paramètres facultatifs :
- dateFrom (date limite de début pour les transactions recherchées)
- dateTo (date limite de fin pour les transactions recherchées)
- afterEntryReference (référence d’incrément minimum pour l’identifiant technique)
Exemple
Requête
GET www.18919.sandbox.api.89c3.com/stet/psd2/v1.6.2/accounts/EURFR353000799999A40166510BB25/transactions
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 l’infrastructure de production « portail developer » exposant les API DSP2 est défaillante, 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 :
| Version | Fonctionnalités | Sandbox
Date de déploiement API Dev Portal & Sandbox |
Live
Date de déploiement Live API Gateway |
| toute version API DSP2 | Fallback (*) | Non applicable | Fin Septembre 2019 |
(*) Fonctionnalités Principales :
- Utilisation par le TPP du même endpoint que l’interface dédiée.
- 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.17515.live.api.89c3.com/stet/psd2/oauth/token
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.17515.live.api.caisse-epargne.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
Content-Length: 870
Connection: close
Content-Type: text/html; charset=iso-8859-1
</head><body>
<h1>Found</h1>
<p>The document has moved <a >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 spécifications STET
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 actuellement)
- Seules les fonctionnalités DSP2 présentes sur la banque en ligne (référence: banque à distance sur internet fixe) 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 Sécur’Pass
- OTP SMS
- Clé physique (pour les entreprises)
Assemblage sandbox
Sandbox
La sandbox Portail developer API peut être utilisée directement via l’application de l’AISP en appelant les API de la plateforme developer-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
Explications
L’application consommatrice des APIs 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 les APIs grâce à son jeton d’accès.
Les appels d’API pourront être enchaînés : en récupérant une liste de comptes à vue dans un premier temps puis en exécutant une seconde requête pour obtenir le solde d’un des comptes de la liste en passant en paramètre le « ressourceId » récupéré du résultat de la première requête.
Les données utilisées pour faire les tests seront issues des personnas ce qui permettra de choisir des profils spécifiques selon les tests de façon à mieux appréhender les résultats obtenus.
En cas de nécessité, une pagination des résultats sera faite pour faciliter la lisibilité et des liens de navigation entre les différentes pages de résultats seront présents (voir les exemples présents dans les cas d’utilisation pour les obtentions de comptes, soldes et transactions), ce qui implique que l’application consommatrice puisse gérer correctement cette pagination.
Gérez les erreurs
Voici la liste de descriptions des codes erreurs pour chaque méthode (il y a une annotation en rouge pour ceux étant recensés dans la norme définie par le CFONB (Codification CFONB) :
- Obtenir la liste des comptes : get/accounts
- Obtenir la liste des soldes : get/accounts/{accountRessourceId}/balances
- Obtenir la liste des transactions : get/accounts/{accountRessourceId}/transactions
| Erreur | Description de l’erreur |
| AC01 (CFONB) | IncorrectAccountNumber : le numéro de compte est incorrect ou inconnu |
| AC04 (CFONB) | ClosedAccountNumber : le compte est clos |
| AC06 (CFONB) | BlockedAccount : le compte est bloqué / fait l’objet d’une opposition |
| BE05 (CFONB) | UnrecognisedInitiatingParty : l’AISP est inconnu |
| BADS | BadScope : l’appel au service a été fait avec un jeton PIISP (AISP attendu) |
| INTE | InternalError : il y a une erreur interne de traitement |
| INTS | InternalServerError : il y a une erreur interne de communication avec le SI |
| IPGN | InvalidPageNumber : le numéro de page est invalide |
| NGAC | NotGrantedAccount : le compte n’est pas consenti |
| NIMP | NotImplemented : le mauvais verbe est appelé (GET attendu) |
| TMRQ | TooManyRequest : le nombre de requêtes possibles a été dépassé |
| IPSU | InvalidPSU : Numéro d’abonné non référencé ou abonnement Cyber résilié |
Historique des versions
Cette API REST est conforme à la spécification interbancaire française STET (https://www.stet.eu/en/psd2/) afin de répondre aux exigences règlementaires de la DSP2. Elle tient compte des limitations fonctionnelles décrites dans la section « Limitations ».
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 se situe au 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.
Changements effectués depuis la première version
| Méthode(s) | Date | Description |
| POST/paymentRequest GET/paymentRequest |
17 mai 2019 | Documentation : clarification sur des paramètres obligatoires et optionnels |
| Fallback | 26 juillet 2019 | Documentation : rajout des mesures d’urgence (Fallback) |
| Toutes | 18 septembre 2019 | Documentation
|
| Toutes | 21 décembre 2020 | Documentation : rajout d’un point d’accès /section « limitations » |
| Fallback | 29 septembre 2021 | Précision apportée sur le fait que l’identifiant du terminal accédant (TermId) doit être obligatoirement fourni dans les requêtes du fallback |
| App2App | 03 Février 2023 | Ouverture du service de redirection via l’app mobile |
Roadmap
L’API d’information sur compte fait l’objet d’améliorations et d’évolutions continues tout au long de l’année. Retrouvez ci-dessous notre roadmap prévisionnelle.
| Version API | Version des
spécifications STET |
Fonctionnalités | Sandbox
Date de déploiement API Dev Portal & Sandbox |
Live
Date de déploiement Live API Gateway |
| v1 | V1.4.0.47 |
|
14 mars 2019 | 15 Octobre 2019 |
| v1.6.2 | V1.6.2.0 | idem v1 | 01 mars 2023 | 1 juin 2023 |
Limitations
Limitations fonctionnelles
Les limitations de cette API sont les suivantes :
- Ne s’applique qu’aux comptes en espèces en euros, éligibles (non bloqué ou sous séquestre) et accessibles en ligne (cf. texte de la Directive DSP2)
- Ne permet pas de récupérer la liste des bénéficiaires de confiance d’un client (cette notion n’existe pas), ni l’identité du client utilisateur du service de paiement (nom et prénom)
- N’utilise que le mode d’authentification par redirection (Authentification Forte du client demandée et gérée via la banque teneur de compte du client utilisateur du service de paiement)
- La profondeur d’historique des transactions est à l’identique de celle de la banque en ligne internet fixe, soit un maximum de 50 jours
- Le mode « aisp extended_transaction_history » n’est pas supporté
- Ne permet l’accès au compte que via l’IBAN du compte de paiement, par contre, L’IBAN n’est pas retourné dans la réponse
- Limite à 4 accès batch par jour pour chacune des méthodes de cette API (cf. texte de la Directive DSP2)
- La bascule en V1.6.2 ne permettra pas une période de tuilage avce la version STET V1.4.0 (v1 de l’API)
Accès aux données de production
Conformément à la réglementation, les données fournies via le portail et la sandbox d’assemblage ne sont que des données fictives.
Ces données de tests sont décrites dans les cas d’usage « Comment tester l’API ? » et « Tester nos persona« .
Pour accéder aux données de production, l’utilisation de l’API REGISTER est un prérequis (voir la fiche https://developer.bpce.fr/caisse-depargne-api-register/).
Le code établissement (voir ci-dessous) vous permettra d’adresser le bon référentiel client via le « endpoint » www.<codetab>.live.api.89c3.com (ou www.<codetab>.live.api.natixis.com). Une fois choisi, ce point d’accès doit être conservé pour toutes les requêtes sous-jacentes.
| Code | Nom de la banque abrégé | Nom de la banque |
| 18919 | NWM | Natixis Wealth Management France |
Eligibilité
Les ressources de l’API “Agrégation de comptes” ne peuvent être consommées que par des PSP ayant le rôle d’agrégateur (AISP). 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.
Une fois l’agrément donné, le format de cet identifiant (Organisation Identifier = OID) fourni par l’autorité compétente est :
PSDXX-YYYYYYYY-ZZZZZZZZ:
XX =>code ISO 3166 du pays de l’autorité compétente hyphen-minus « – » (0x2D (ASCII), U+002D (UTF-8))YYYYYYYY => 2-8 caractères du l’identifiant de l’autorité compétente (A-Z, pas de séparateur)hyphen-minus « – » (0x2D (ASCII), U+002D (UTF-8))ZZZZZZZZ => identifiant du PSP spécifié par l’autorité nationale compétente (sans restriction sur le nombre – ou sur le type – de caractère utilisé)
Cet identifiant OID est important à 2 titres :
- il servira à vous identifier lors des appels dans les requêtes des API STET (via le paramètre « client_id »)
- il devra être présent dans les certificats eIDAS que vous fournirez au teneur de compte (voir ci-dessous)
De plus, vous devez 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 ce portail, le TPP doit enrôler son app et nous transmettre via notre API Register des certificats de production signés par une autorité de certification agréée :
- un premier jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Register) pour la sandbox
- un autre jeu de certificats QWAC (pour l’authentification mutuelle TLS) et QSEALC (à charger sur notre passerelle via l’API Register) pour la production
NB IMPORTANT : en cas de renouvellement de certificat, et si l’autorité de certification (QTSP) est différente (ou c’est la même entreprise QTSP mais qui utilise des clés racines différentes), le TPP doit avertir le support API disponible via ce site de 2 mois avant à toutes fins de vérifier que les élements de la nouvelle autorité de certification sont bien chargés sur nos infrastuctures.
Un identifiant keyID devra aussi être fourni dans un format conforme à la spécification STET intégrant une empreinte SHA256 après le caractère « _ » char, voir exemple dans la documentation STET Part 3 / Interaction Examples : keyId=https://path.to/myQsealCertificate_612b4c7d103074b29e4c1ece1ef40bc575c0a87e.
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).