Vue d'ensemble
Les bénéfices attendus
Les bénéfices sont multiples, pour les utilisateurs finaux comme pour les développeurs.
L'API Enregistrement DSP2 ouvre aux fournisseurs tiers (TPP) l’accès à notre solution innovante pour optimiser la gestion des transactions financières de leurs clients. Grâce à son automatisation, elle réduit les erreurs, améliore la rapidité des opérations et renforce la sécurité des données. En intégrant cette API, les entreprises bénéficient d'une conformité simplifiée et d'une expérience utilisateur améliorée, favorisant ainsi la fidélisation de leurs clients.
Automatisation des enregistrements
Simplifie le processus d'enregistrement des applications consommatrices, réduisant les erreurs manuelles.
Accélération des services financiers
Améliore la rapidité des transactions pour une expérience utilisateur fluide et immédiate.
Amélioration de la sécurité
Renforce la sécurité des données grâce à des protocoles de protection avancés.
Facilitation d’intégration
Permet une intégration aisée avec des systèmes existants, minimisant les disruptions opérationnelles.
L'offre de service de l'API Enregistrement DSP2 repose sur l'automatisation des processus d'enregistrement des applications consommatrices, garantissant la conformité réglementaire et la sécurité des données tout en facilitant l'accès aux services bancaires.
Les différents cas d’usage possibles
Ce produit API est incontournable pour l’utilisation des solutions DSP2 du Groupe BPCE.
Enregistrement initial d’une application consommatrice
- Cette étape est à mener par tout nouveau TPP qui souhaite accéder et consommer les ressources des APIs DPS2 exposées.
- Tout TPP utilisant déjà nos APIs DPS2 peut aussi utiliser ce produit API pour être indépendant sur la mise à jour des informations de son projet et de son app consommatrice.
- Le TPP peut aussi déclarer plusieurs applications consommatrices, et donc des agents de ces TPP qui pourront aussi être déclarés via cet intermédiaire.
Récupération des données
Ce produit API permet de récupérer les données concernant l’enregistrement technique.
Modification des données
Il permet également de modifier les données fournies concernant l’enregistrement d’une application consommatrice, dont par exemple, des certificats eIDAS qui arrivent à expiration.
Suppression de l’enregistrement
Il est possible de supprimer l’enregistrement global d’une application consommatrice, ce qui est nécessaire par exemple, en cas d’obsolescence de cette dernière.
Comment accéder au produit ?
Pour accéder à l’API Enregistrement DSP2 du Groupe BPCE, les développeurs et les entreprises doivent suivre les étapes ci-dessous.
Vérifiez votre éligibilité
Cette API ne peut être consommée que si vous avez obtenu le statut de Prestataires de Services de Paiement (PSP). Pour en savoir plus, consultez la section "Eligibilité".
Testez avec la sandbox
Avant de vous lancer, testez le produit API dans votre environnement.
Lancez-vous !
Vous êtes prêt ? N'hésitez plus et lancez-vous avec la production Live.
Documentation
Guides
Généralités
Le Groupe BPCE met à disposition des prestataires de services de paiements DSP2 (TPP) une API leur permettant de s’enregistrer (ou de modifier l’enregistrement), basée sur :
- les spécifications STET version V1.4.2 / paragraphe 3.4.2.1
et
- le contrat OAS « DSP2 Oauth2 Technical » setup / swagger TechnicalSetup_1.0.5_OAS2.yaml. Ce dernier est basé sur les RFC 7591, 7592 et 7517, et est complété par cette fiche.
Cette API est réservée pour :
- les TPP DSP2 n’ayant jamais enregistré d’applications consommatrices
ou
- les TPP DSP2 ayant déjà enregistré une/des applications consommatrices via cette API et souhaitant modifier une donnée (par exemple, des certificats eIDAS qui arrivent à expiration).
Méthodes principales
Cette API permet d’effectuer les actions suivantes par le prestataire de paiements externe DSP2 (TPP) :
1er cas d’usage : enregistrement initial d’une application consommatrice
NB 1 : cette étape est à mener par tout nouveau TPP qui souhaite accéder et consommer les ressources des APIs DPS2 exposées.NB 2 : tout TPP utilisant déjà nos APIs DPS2 peuvent aussi utiliser cette API pour être indépendant sur la mise à jour des informations de son projet et de son app consommatrice.
NB 3 : le TPP peut aussi déclarer plusieurs applications consommatrices, et donc des agents de ces TPP qui pourront aussi être déclarés via cet intermédiaire.
- 2ème cas d’usage : récupérer les données concernant l’enregistrement technique du TPP.
- 3ème cas d’usage : modifier les données fournies concernant l’enregistrement d’une application consommatrice, dont par exemple, des certificats eIDAS qui arrivent à expiration.
- 4ème cas d’usage : supprimer l’enregistrement global d’une application consommatrice, ce qui est nécessaire par exemple, en cas d’obsolescence d’une application consommatrice.
Récupération du jeton d'accès
Prérequis
Pour accéder à l’API Enregistrement DSP2, les TPP doivent :
- Etre agréés par leur Autorité Compétente Nationale, et le cas échéant, avoir un passporting en France pour les activités qu’ils souhaitent exercer en France ;
- Posséder un numéro de référence unique (Unique Reference Number ou Organisation Identifier : OID) obtenu par le TPP auprès de son Autorité Compétente Nationale (NCA) et qui permet d’identifier le TPP.
Plus généralement, la norme ETSI intègre ce numéro de référence dans une structure telle que décrite dans la rubrique « Eligibilité ».
Cette codification se retrouve dans les certificats eIDAS (QWAC et QSEALC) que les TPP doivent se procurer auprès d’une autorité de certification agréée pour pouvoir utiliser les APIs DSP2.
Comment utiliser l’API ?
La méthode POST /token est obligatoire et permet en premier lieu de générer un nouvel client_id qui sera nécessaire pour accéder aux autres méthodes de l’API Enregistrement DSP2.
Pour la demande de jeton d’accès via POST /token, les points d’entrée sont les suivants :
- Sandbox : https://www.<codetab>.sandbox.api.89C3.com/stet/psd2/oauth/token
Le client_id générique à utiliser pour récupérer un token d’accès pour utiliser l’API /register est « PSD2_TPPRegister »
- Production Live : https://www.<codetab>.live.api.89C3.com/stet/psd2/oauth/token
Le client_id générique à utiliser pour récupérer un token d’accès pour utiliser l’API /register est « PSD2_TPPRegister »
NB : N’importe quel <codetab> d’un ASPSP exposé sur ce portail peut être utilisé. Même si un seul <codetab> est utilisé, ce processus de déclaration d’un app consommatrice s’appliquera à tous les ASPSP.
Exemple (sandbox)
POST https://www.17515.sandbox.api.89C3.com/stet/psd2/oauth/token
Header : Content-type : application/x-www-form-urlencoded; charset=utf-8
Paramètres :
- client_id : 9d8711ec-f1b4-45e4-8072-2b3aa49793f0
- grant_type : client_credentials
- scope : manageRegistration
NB : L’appel aux ressources de l’API se fait sur une session sécurisée TLS1.2 avec authentification mutuelle par certificat QWAC dans cet appel.
Réponse :
{
« access_token » : « KXyZabcdefghijklmopqrstuvw1234567890 »
}
Une fois le jeton d’accès reçu, les méthodes accessibles sont les suivantes :
| Méthode | Path | Description / Cas d'utilisation |
|---|---|---|
| POST | /register | Method to register an app or an agent |
| PUT | /register/${client_id} | Method to change an app data |
| GET | /register/${client_id} | Method to extract app data |
| DELETE | /register/${client_id} | Method to remove an app |
Auto-enrôlement des données
Prérequis
Pour procéder à cette requête, il est nécessaire de remplir les prérequis d’éligibilité.
Requête POST /register
Exemple (sandbox) : POST https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register
(se référer à l'onglet Documentation)
Paramètres
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
|---|---|---|
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | One of the main information of this registration is the TPP QSEALC certificate which will used by BPCE to verify the signature of all the DSP2 streams. As registration requests must also provide a signature, the TPP must sign this request with the private key corresponding to the QSEALC certificate. As TPP identification is not yet known at the time of this initial request, TPP has to provide the certificate in the body itself, in the first item of the keys table. The certificate information will be retrieved from this form and will be used to verify the signature of the initial request and all future DSP2 requests. Please note that a TPP agent cannot use directly this API set, reserved for the TPP acting on behalf of an agent (only the TPP certificate is authenticated). In case of agents, flows must also be signed with a TPP QSEALC valid certificate. |
| Digest | R | SHA256 body digest base64 encoded. |
| Authorization | R | bearer access_token previously received. |
HTTP Body
| NAME | (O)PTIONNAL / (R)EQUIRED / (F)ORBIDDEN | DESCRIPTION |
|---|---|---|
| redirect_uris | R | String array. It contains all URIs (scheme and authority according to RFC 3986, comma separated) that TPP can use in DSP2 redirect requests. Any URI used afterwards in PSD2 API but not provided in this registration process will be refused. |
| software_statement | O | String. JSON Web Token (JWT). Not used. |
| token_endpoint_auth_method | R | String. Value shall be « tls_client_auth ». |
| grant_types | R | String array. Value shall be « client_credentials ». |
| response_types | R | String array. Value shall be “code”. |
| client_name | R | String. This is the TPP unique legal name. |
| client_uri | O | String. TPP or agent Web page URI. Not used. |
| logo_uri | O | String. TPP or agent logo URI. Not used. |
| scope | R | String. TPP scopes are comma separated, and possible values are : “aisp” and/or “pisp” and/or “cbpii” Example : “aisp” Example : “aisp, pisp” Note : the scope is also mandatory for agents. In that case, the values included in this field shall be the ones from the TPP. |
| contact | R | String. Data for mandatory contact details : « contact »: { « contact_name »: « string », « email »: « string », « phone_number »: « string » } |
| tos_uri | O | String. Data for mandatory contact details : « contact »: { « contact_name »: « string », « email »: « string », « phone_number »: « string » } |
| policy_uri | O | String. URI that points to a human-readable policy document for the client. Not used. |
| jwks_uri | O | String. URL referencing the client JSON Web Key (JWK) document containing the client public keys. Not used. |
| provider_legal_id | R | String. TPP National Authorization number according to ETSI specification on eIDAS certificates for PSD2 (OID = PSDXX-YYYYYYYY-ZZZZZZZZ, see “Eligibility” section). |
| client_legal_id | R/O(*) | String. (*) Optional for a TPP / Mandatory (required) for an agent. This identifier is therefore left to the discretion of the TPP for an agent. However, its format should comply with the ETSI specification on DSP2 eiDAS certificates with “AGT” suffix + a serial number, e.g. “AGTFR-ACPR-12345001”. Note : in order to avoid rejection due to a duplicated alues, we strongly advise to base it on truncated OID TPP number (= no PSD prefix) before the serial number. |
| logo | O | String. Not used. |
| jwks | R | Object. This object contains the following array and shall contain at least one public key (QSEALC) without the chain link to the certification authority. |
| keys | R | JWK objects array. This array shall contain only one item (JWK). |
| kty | R | String. Key type. Value shall be « RSA ». |
| use | R | String. Key usage. Vallue shall be « sig ». |
| alg | R | String. Value shall be « RS256 ». |
| key_ops | R | String array. Value shall be « verify ». |
| kid | R | String. Key id. |
| x5u | F | Not used. |
| x5c | R | String array. Must not contain more than one item representing the QSEALC certificate in DER format based on 64. |
| x5t | F | Not used. |
| x5t#S256 | R | String. SHA256 fingerprint of X509 DER certificate. |
| software_id | R | String. Mandatory name of the TPP app OR brand name OR agent name which will be displayed to PSU (it can be different from the client_name). This parameter is dispayed in priority to PSU during SCA redirect process. |
| software_version | R | String. Mandatory name of the TPP app OR brand name OR agent name which will be displayed to PSU (it can be different from the client_name). This parameter is dispayed in priority to PSU during SCA redirect process. |
Réponse
Une réponse correcte retourne le statut HTTP 201. Le TPP recevra aussi son nouvel client_id qui devra être utilisé dans tous les appels des APIs DSP2.
Erreurs
| HTTP STATUS | DESCRIPTION |
|---|---|
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not allowed. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Modification des données
Prérequis
Pour procéder à cette requête, il est nécessaire de remplir les prérequis d’éligibilité.
Pour modifier les données d’enregistrement d’une application consommatrice des APIs DSP2, le « client_id » permettant d’interroger cette méthode est récupéré via le résultat de la requête POST /register.
Requête PUT /register/{client_id}
Exemple (sandbox) : PUT https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register/AGTFR-ACPR-12345001
avec le client_id récupéré dans la réponse de l’enrôlement (cf. la méthode POST /register).
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
|---|---|---|
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | As registration requests must also provide a signature, the TPP must sign this request with the private key corresponding to the QSEALC certificate. |
| Digest | R | SHA256 body digest base 64 encoded. |
| Authorization | R | bearer access_token previously received. |
HTTP Body
| NAME | (O)PTIONNAL / (R)EQUIRED / (F)ORBIDDEN | DESCRIPTION |
|---|---|---|
| redirect_uris | R | String array. It contains all URIs (scheme and authority according to RFC 3986, comma separated) that TPP can use in DSP2 redirect requests. Any URI used afterwards in PSD2 API but not provided in this registration process will be refused. |
| token_endpoint_auth_method | R | String. Value shall be « tls_client_auth ». |
| grant_types | R | String array. Value shall be « client_credentials ». |
| response_types | R | String array. Value shall be “code”. |
| client_name | R | String. This is the TPP unique legal name. |
| client_uri | O | String. TPP or agent Web page URI. Not used. |
| logo_uri | O | String. TPP or agent logo URI. Not used. |
| scope | R | String. TPP scopes are comma separated, and possible values are : “aisp” and/or “pisp” and/or “cbpii” Example : “aisp” Example : “aisp, pisp” Note : the scope is also mandatory for agents. In that case, the values included in this field shall be the ones from the TPP. |
| contact | R | String. Data for mandatory contact details : « contact »: { « contact_name »: « string », « email »: « string », « phone_number »: « string » } |
| tos_uri | O | String. URI that points to a human-readable terms of service document for the client. Not used. |
| policy_uri | O | String. URI that points to a human-readable policy document for the client. Not used. |
| provider_legal_id | R | String. TPP National Authorization number according to ETSI specification on eIDAS certificates for PSD2 (OID = PSDXX-YYYYYYYY-ZZZZZZZZ, see “Eligibility” section). |
| client_legal_id | R/O(*) | String. (*) Optional for a TPP / Mandatory (required) for an agent. This identifier is therefore left to the discretion of the TPP for an agent. However, its format should comply with the ETSI specification on DSP2 eiDAS certificates with “AGT” suffix + a serial number, e.g. “AGTFR-ACPR-12345001”. Note : in order to avoid rejection due to a duplicated alues, we strongly advise to base it on OID TPP number before the serial number. |
| logo | O | String. Not used. |
| jwks | R | Object. This object contains the following array and shall contain at least one he public key (QSEALC) without the chain link to the cartification authority. |
| keys | R | JWK objects array. This array should only contain one item (JWK). |
| kty | R | String. Key type. Value shall be « RSA ». |
| use | R | String. Key usage. Vallue shall be « sig ». |
| alg | R | String. Value shall be « RS256 ». |
| key_ops | R | String array. Value shall be « verify ». |
| kid | R | String. key id. |
| x5u | F | Not used. |
| x5c | R | String array. Must not contain more than one item representing the QSEALC certificate in DER format based on 64. |
| x5t | F | Not used. |
| x5t#S256 | R | String. SHA256 fingerprint of X509 DER certificate. |
| software_id | R | String. Mandatory name of the TPP app OR brand name OR agent name which will be displayed to PSU (it can be different from the client_name). This parameter is dispayed in priority to PSU during SCA redirect process. |
| software_version | O | String. Not used. |
Réponse
Une réponse correcte retourne le statut HTTP 201.
Erreurs
| HTTP STATUS | DESCRIPTION |
|---|---|
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not found. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Récupération des données
Prérequis
Pour procéder à cette requête, il est nécessaire de remplir les prérequis d’éligibilité.
Pour modifier les données d’enregistrement d’une application consommatrice des APIs DSP2, le « client_id » permettant d’interroger cette méthode est récupéré via le résultat de la requête POST /register.
Requête GET /register/{client_id}
Exemple (sandbox) : GET https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register/AGTFR-ACPR-12345001 (voir le swagger « setting » dans documentation)
avec le client_id récupéré dans la réponse de l’enrôlement (cf. la méthode POST /register).
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
|---|---|---|
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | As registration requests must also provide a signature, the TPP must sign this request with the private key corresponding to the QSEALC certificate. |
| Authorization | R | bearer access_token previously received. |
Réponse
Une réponse correcte retourne le statut HTPP 200.
Erreurs
| HTTP STATUS | DESCRIPTION |
|---|---|
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not found. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Suppression des données
Prérequis
Pour procéder à cette requête, il est nécessaire de remplir les prérequis d’éligibilité.
Pour modifier les données d’enregistrement d’une application consommatrice des APIs DSP2, le « client_id » permettant d’interroger cette méthode est récupéré via le résultat de la requête POST /register.
Requête DELETE /register/{client_id}
Exemple (sandbox) : DELETE https://www.17515.sandbox.api.89C3.com/stet/setting/v1/register/AGTFR-ACPR-12345001 (voir le swagger « setting » dans documentation)
avec le client_id récupéré dans la réponse de l’enrôlement (cf. la méthode POST /register).
HTTP Headers
| NAME | (O)PTIONNAL / (R)EQUIRED | DESCRIPTION |
|---|---|---|
| x-request-id | R | Request correlation id. This id must be a string generated by the TPP. |
| Signature | R | The TPP must sign this request with the private key corresponding to the QSEALC certificate. |
| Authorization | R | bearer access_token previously received. |
Réponse
Une réponse correcte retourne le statut HTTP 204.
Errors
| HTTP STATUS | DESCRIPTION |
|---|---|
| 400 | Bad request. Error is supplied in fields error and error_description. |
| 404 | Resource not found. |
| 405 | Method not allowed. A method other than those described here was used. |
| 500 | Internal server error. |
Politique de décommissionnement des versions de l’API
La politique du décommissionnement est fonction du cycle de vie des APIs, elle-même calée sur les versions des spécifications STET.
Elle est schématisée ci-dessous pour la version N :
Il est prévu une phase de tuilage entre les version majeures d’API (évolutions fonctionnelles majeures en version N+1 ou supérieures non présentes en version N).
La communication du décommissionnement d’une version N se fera à la date de déploiement de la version N+1. Le canal de communication privilégié est ce portail Groupe BPCE API Store dans la partie « roadmap » de l’API impactée.
Roadmap
Cette API est soumise à des revues et des améliorations continues tout au long de l'année.
Limitations fonctionnelles
Cette API ne pourra pas être utilisée pour modifier un profil TPP (avec app consommatrice, URL de redirection, etc…) existant et réalisé au travers du processus de « GoLive » via notre portail BPCE API.
Par exemple, en cas de rajout d’une URL de redirection, ou de remplacement d’un certificat eIDAS QWAC arrivant à expiration, tout nouveau TPP pourra effectuer cette modification de manière autonome en :
- utilisant cette API Enregistrement DSP2,
- recevant un nouvel « client_id » (sur base de l’OID du TPP avec un format étendu) afin de consommer les ressources des APIs DSP2 exposées.
NB 1: un agent qui n’a pas son propre OID ni son jeu de certificats eIDAS ne pourra pas utiliser directement cette API. Ce sera au TPP (auquel est adossé l’agent) de l’utiliser sur base de son OID et ses propres certificats eIDAS pour y déclarer l’app consommatrice de/pour son agent.
NB 2: pour un TPP qui a déjà une app consommatrice enrôlée via le portail, les informations enregistrées via le processus de « GoLive » restent valables et ne seront pas effacées par l’API Enregistrement DSP2.
NB 3: un TPP qui a déjà été enrôlé via l’API Enregistrement DSP2 et qui souhaite créer un second profil (pour obtenir un second client_ID) doit utiliser un second jeu de certificats.
Limitations techniques
L’activation du client_id restitué suite à l’enregistrement sera finalisée à 14h00 à J+1 en jour ouvré après utilisation nominale de l’API (activation à 14h00 à J si l’enregistrement est réalisé avant 09h59), sauf si au moins un critère d’éligibilité ne peut pas s’appliquer (voir section suivante), ce qui pourra générer un délai supplémentaire.
Veuillez aussi noter que :
- les certificats eIDAS signés avec l’algorithme « rsassaPss » ne sont pas acceptés ;
- le jeton d’accès récupéré via
POST /tokena une durée de validité d’une heure.
Eligibilité
Les ressources de cette API ne peuvent être consommées que si vous avez obtenu le statut de Prestataires de Services de Paiement (PSP). 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 APIs 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 APIs DSP2 proposées sur le portail du Groupe BPCE, vous aurez à utiliser des certificats QWAC et QSEALC valides :
- de test pour le fonctionnement de l’assemblage en sandbox ;
- de production lors du processus de demande de GO Live sur le portail BPCE API.
En cas de problème d’accès via l’API Enregistrement DSP2 à cause des certificats, nous vérifierons s’ils ont été signés par une nouvelle autorité de certification, ou avec un nouveau certificat racine (d’une autorité de certification existante). Dans ces deux cas, il faudra compte un délai supplémentaire (de l’ordre de 2 semaines) pour ce chargement.
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éens (ABE ou EBA : https://euclid.eba.europa.eu/register/pir/disclaimer).
Historique
Version de la norme STET
Cette API REST est conforme à la spécification interbancaire française STET (https://www.stet.eu/en/psd2/), version v.1.4.2.17, 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é complé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.
Description du support utilisateur
Conformément à l’article 30 (5) des RTS, une assistance pour les prestataires PSP tiers est mise à disposition. Ce support utilisateur est accessible via le formulaire sur ce portail API Store Groupe BPCE. Les réponses se font pendant les heures de travail ouvrées.
Le principe de la durée de support est schématisée ci-dessous en prenant en compte l’article 30 (4) des RTS :
Evolutions importantes
Evolutions importantes apportées depuis la première version livrée :
| CAS D’USAGE / MÉTHODE(S) | DATE D'EFFET | DESCRIPTION DE L’ÉVOLUTION |
|---|---|---|
| Toutes | 17/03/2021 | Clarifications éditoriales |