Comment agréger les données ?
Un client multi bancarisé souhaite accéder à l’ensemble de ses données afin d’en avoir une vision consolidée.
Via cette API « information sur compte » mise à disposition par les teneurs de comptes, vous pouvez demander en temps réel l’accès à l’une et/ou l’autre des données que le client a autorisé SANS lui demander ses identifiants de connexion en ligne.
Les ressources de cette API ne peuvent être consommées que si vous avez obtenu le rôle de prestataire de Services d’Information sur les Comptes (« TPP AISP »), ce prérequis étant décrit dans voir la rubrique « Éligibilité« .
Le processus global est le suivant :
Le client souhaite utiliser vos services afin de consolider des informations d’un ou plusieurs comptes de paiement détenus auprès de banques, dont l’une d’entre-elles est le Crédit Coopératif. Il vous l’indique donc laquelle à travers vos interfaces.
Lors de ce premier échange, vous allez faire une demande de jeton d’autorisation (et un jeton de rafraichissement). Le principe de base est, qu’en tant que TPP AISP, vous devez obtenir ces jetons AVANT de consommer des ressources de l’API. Ce jeton est généré par le teneur de compte (ASPSP) APRES avoir identifié et authentifié le client.
En tant que teneur de compte :
- nous allons vérifier vos certificats et agréments
- et via le jeu de la redirection, nous allons identifier et authentifier fortement le client afin de pourvoir générer le jeton d’accès
Si l’autorisation est accordée par le client, vous pourrez alors récupérer les jetons OAUTH2 via des échanges sécurisés avec la plateforme BPCE API (voir la rubrique « Vue d’ensemble » > « Récupérer votre jeton« ).
En présentant ce jeton d’autorisation, vous pourrez alors consommer les ressources de l’API « information sur compte » afin de :
- demander la liste des comptes éligibles
- nous transmettre le consentement client
- accéder de manière sécurisée aux données dont l’accès a été autorisé (voir la rubrique « Vue d’ensemble » > « Comment consommer l’API ?« ).
Au bout du délai réglementaire de 180 jours, ce processus devra être reconduit (voir la rubrique « Vue d’ensemble » > « Rafraîchir votre jeton« ).
NB : le gestionnaire de compte ASPSP a la possibilité de vous refuser l’accès pour différents motifs justifiés (API non conforme, compte bloqué entre-temps, etc.).
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 « passerelle BPCE API Live » 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
BPCE API Dev Portal & Sandbox |
Live
Date de déploiement BPCE 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 href= »/www.17515.live.api.caisse-epargne.fr&fallback=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImhF… »>here</a>.</p>
</body></html>
3. Une fois redirigé, le TPP doit utiliser ensuite les identifiants du PSU via sa méthode propriétaire
Pour plus de détails sur la requête POST, voir 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)
Activer l'App2App
Introduction
Cette fonctionnalité permet d’activer automatiquement l’app bancaire du client à toutes fins d’identification et d’authentification.
Prérequis
Le client doit avoir chargé et utilisé au moins une fois la dernière version de l’application bancaire sur les magasins d’applications Android et Apple (version V6.4.0 et plus).
Note : les segment clients PRO & ENT ne sont pas activés
Le lien de retour (Universal link) doit être définie en avance par le TPP sur le même principe qu’une url de callback :
- si ce lien / cette url a déjà été déclarée sur notre passerelle BPCE API, il n’y a rien d’autre à faire
- sinon le TPP doit le déclarer en utilisant notre API Register
Nos liens « Universal links » ont été déclarés sur les plateformes iOS et Android. Ce n’est pas la peine d’y accéder via par exemple https://www.<codetab>.live.api.caisse-epargne.fr/89C3api/accreditation/v2/.well-known/apple-app-site-association qui renverra une erreur.
Requête
L’activation de la fonctionnalité App2App s’effectuera en production via l’envoi d’une requête par l’app du TPP au format STET suivant :
| Brand | App2App endpoint |
 |
http://www.40978.live.api.palatine.fr/stet/psd2/oauth/authorize |
 |
http://www.<codetab>.live.api.banquepopulaire.fr/stet/psd2/oauth/authorize
(voir la liste des <codetab> sur la fiche produit API Banque Populaire) |
 |
http://www.10548.live.api.banque-de-savoie.fr/stet/psd2/oauth/authorize |
 |
http://www.<codetab>.live.api.caisse-epargne.fr/stet/psd2/oauth/authorize
(voir la liste des <codetab> sur la fiche produit API Caisse d’Epargne) |
 |
http://www.12579.live.api.banquebcp.fr/stet/psd2/oauth/authorize |
 |
http://www.42559.live.api.credit-cooperatif.coop/stet/psd2/oauth/authorize |
 |
http://www.30258.live.api.btp-banque.fr/stet/psd2/oauth/authorize |
 |
http://www.18919.live.api.natixis.com/stet/psd2/oauth/authorize |
Sinon, une webview sera affichée via le navigateur du smartphone du client dans les cas suivants :
- si l’app bancaire n’est pas chargée sur le smartphone du client
ou
- si l’app bancaire chargée n’est pas compatible avec l’App2App (voir les prérequis)
ou
- si l’autre format d’appel des point d’accès a été utilisé http://www.<codetab>.live.api.89c3.com/stet/psd2/oauth/authorize (ce qui peut être utile comme backup en cas de problème avec l’App2App)
Obtenir l'identité du client
Cas d’usage
Ce service permet de récupérer l’identité d’un client qui a donné son consentement au TPP pour pouvoir y accéder.
Prérequis
Pour procéder à cette requête il est nécessaire de remplir les prérequis d’éligibilité et d’avoir récupéré le jeton d’accès OAUTH2 (voir la rubrique « Vue d’ensemble » > « Récupérer votre jeton« ).
Pour récupérer l’identité d’un PSU :
- L’autorisation de transmettre au TPP ces informations d’identité doit nous avoir été transmis via la valorisation à true de l’attribut « psuIdentity » de la méthode PUT /consents et ne doit pas avoir été révoqué depuis (c’est à dire pas d’annule et remplace via PUT /consents avec un attribut « psuIdentity » valorisé à false)
- L’URI pour l’accès à cette méthode est donnée via la rubrique « _links« : {« endUserIdentity »: {« href »: …}} en résultat de la requête GET /accounts.
Requête
GET /end-user-identity
Voir aussi la spécification de place STET
Paramètres obligatoires ou facultatifs du body requis pour l’appel de ce service
Paramètres obligatoires : PSU-IP-ADDRESS => à alimenter si le PSU est connecté.
Résultat retourné
Cet appel permet de récupérer l’identité du client final.
Un lien self sera également pour revenir à la page obtenue après exécution de la requête.
Vos accès à cette méthode sont limités à 4 accès batch maximum par jour calendaire, pour un client. En revanche, lorsque c’est le client connecté qui interroge directement ses comptes à vue, le nombre d’accès n’est pas limité.
Exemple
Requête
GET /stet/psd2/v1.4.2/end-user-identity
Un exemple plus complet de requête est fourni dans la rubrique « Comment tester l’API ? » > « Assemblage sandbox ».
Voir aussi la spécification de place STET
Assemblage sandbox
Introduction
La sandbox BPCE API peut être accédée directement via votre application : c’est le mode assemblage décrit ci-après.
Les données utilisées sont fictives (voir la rubrique « Comment tester l’API ? » > « Tester nos personas« ). Elles permettront de choisir des profils spécifiques de façon à mieux cibler vos tests.
Prérequis
Vous devez déclarer votre APP via l’API Register (en choisissant le point d’entrée « sandbox ») et nous transmettre :
- votre identifiant fourni par votre autorité compétente (Organization Identifier = OID)
- la clé publique de votre certificat QSEALC (de production dédié aux tests)
- votre URI de redirection (redirect_uri) qui sera appelée par l’ASPSP :
- si le PSU a autorisé la récupération de ses données par l’AISP
- ou en cas de refus du consentement
- ou si la cinématique ci-dessous est interrompue (par exemple : timeout sur les écrans)
Rappel : vous devez être accrédité pour le rôle « AISP ».
Enchaînement des étapes pour tester l’accès à l’API AISP depuis votre APP
1ère étape : demande de jeton d’accès
Ceci est nécessaire afin d’obtenir un jeton d’accès à toutes fins de consommer les ressources de l’API, et permet de déclencher la redirection du PSU chez l’ASPSP.
La description de la fonctionnalité est décrite dans la rubrique « Vue d’ensemble » > « Récupérer votre jeton« .
NB : Le PSU peut domicilier ses comptes dans plusieurs banques du Groupe BPCE. Il vous faudra un jeton différent pour accéder à chacune de ces banques –> cet appel est donc à répéter pour chacun des établissements concernés.
Notre point d’entrée dépend du code établissement : www.<cdetab>.sandbox.api.89C3.com, et pour l’assemblage sandbox, le seul <cdetab> est fixé à 17515 (Caisse d’Epargne Ile de France).
Exemple de requête en assemblage sandbox :
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/oauth/authorize
Headers :
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Params:
response_type:code
client_id:PSDFR-ACPR-13807
redirect_uri:https://myAPP.fr/Home/OAuth2Callback
scope:aisp
Remarque sur l’alimentation des champs :
- client_id: identifiant fourni par votre autorité nationale compétente (PSDXX-YYYY-ZZZZZ)
- redirect_uri: URL de redirection prédéclarée dans votre application consommatrice ET à communiquer à l’ASPSP pour toute une demande d’assemblage ou de Go Live
2ème étape : redirection vers les écrans d’authentification forte (AF/SCA)
Une fois redirigé vers l’ASPSP, celui-ci va afficher des écrans d’identification et d’authentification au PSU.
La cinématique nominale des enchaînements de ces écrans est résumée par le schéma ci-dessous :
1. Le PSU est redirigé vers un écran d’identification proposé par ASPSP.
L’identifiant banque à distance du PSU est à saisir :
NB : si le PSU est un professionnel ou une entreprise, il y aura un numéro d’usager à saisir en sus de l’identifiant banque à distance.
2. Le PSU se voit afficher alors un écran d’authentification forte proposé par l’ASPSP pour valider son identité.
La cinématique dépend aussi de la méthode d’authentification forte (AF/SCA) mise à disposition par l’ASPSP (exemple d’un OTP par SMS, voir exemple ci-dessous) :
ou pour la sandbox
NB : Dans certains cas, une notification peut être envoyée vers le PSU afin qu’il active son moyen d’AF/SCA sur son smartphone pour terminer cette étape :
3ème étape : récupération du jeton d’accès / access_token
Cet appel permet à l’AISP de récupérer le jeton d’accès pour pouvoir accéder aux données.
La description de la fonctionnalité est décrite dans la rubrique « Vue d’ensemble » > « Récupérez votre jeton ».
Le certificat QWAC est à fournir dans cette requête POST /stet/psd2/oauth/token pour établir l’authentification mutuelle avec l’ASPSP. Le certificat doit correspondre à celui-ci que le PSP a fourni:
- lors de l’étape goAssemblage (resp. goLive en production) si le TPP a été enregistré par la procédure via le portail BPCE API
- ou via l’API REGISTER si le TPP (auto-enrôlement automatisé, voir la fiche produit : https://www.api.89c3.com/fr/nos-produits/item/522-api-register-fr)
POST https://www.17515.sandbox.api.89C3.com/stet/psd2/oauth/token
Header:
Content-Type:application/x-www-form-urlencoded; charset=utf-8
Params:
client_id:PSDFR-ACPR-13807
grant_type:authorization_code
code:NnZx1hqHY2CLkCFjiTwhJeflgFedCBa
redirect_uri:https://myAPP.fr/Home/OAuth2Callback
Remarques sur l’alimentation des champs :
- client_id : numéro donné par votre autorité compétente lors de votre demande d’agrément (PSDXX-YYYY-ZZZZZ)
- code : récupéré dans l’url de callback
- redirect_uri : il faut que cette « redirect_uri » soit identique à celle envoyée dans la requête GET /authorize !!!
- le certificat eiDAS QWAC doit être envoyé avec cette requête
Réponse :
{
« token_type »:« Bearer »,
« expires_in »:3600,
« scope »:« aisp »,
« refresh_token »:« KUZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoD0Kr2rSi1mSCFNewRfrsH »
}
4ème étape : consommation des méthodes de l’API
1) Obtenir la liste des comptes à vue d’un PSU
Une fois le jeton d’accès récupéré après l’authentification forte du PSU, cet appel vous permet de lister les comptes du PSU connecté lors de la première connexion.
La description de la fonctionnalité est décrite dans le cas d’usage « Obtenir la liste des comptes« , notamment sur la pemière utilisation de cette méthode avant un PUT /consents.
La séquence est :
- GET /accounts pour récupérer les comptes sans les soldes et sans les links vers les soldes et transactions
- affichage des comptes au client par le TPP pour récupérer son consentement
- PUT /consents pour transmettre le consentement sur les comptes
- GET /accounts pour récupérer les comptes consentis et les links vers le solde (si donnée consentie) et/ou vers les transactions (si données consenties)
Exemple de requête en assemblage sandbox SANS PUT /Consent au préalable:
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts
Header :
Authorization: Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAbCdEf
X-Request-ID: id-1234567890111121 1
Signature: keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_<empreinte sha256>\ », algorithm=\ »rsa-sha256\ », headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ », signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QiMViAmthebEst=\ »
Psu-IP-Address:192.168.0.1
Pas de corps de requête
Remarques sur l’alimentation des champs :
- Authorization : Bearer < access_token précédemment récupéré>
- X-Request-ID : <en-tête de corrélation de la requête émise>
- Signature : <signature de la requête émise>
- Psu-Ip-Address => permet de différencier les appels batch et les appels avec le PSU connecté : ce champ est à alimenter pour un PSU connecté
Réponse : 200 (=> OK)
Header :
X-request-id: id-1234567890111121 1
Content-Type: application/hal+json;charset=UTF-8
Body :
{
« accounts »:[
{
« accountId »:{
« iban »:« FR7617515000920400430518020 »,
},
« usage »:« PRIV »,
« psuStatus »:« Account Holder »,
« name »:« CPT DEPOT PART. »,
},
« accountId »:{
« iban »:« FR7617515000920400851811524« ,
},
« usage »:« PRIV »,
« psuStatus »:« Account Holder »,
« name »:« CPT DEPOT PART. »,
}
],
« self »:{
« href »:« /stet/psd2/v1.6.2/accounts »
},
« consents »:{
« href »:« /stet/psd2/v1.6.2/consents »
« EndUserIdentity »:{
« href »:« /stet/psd2/v1.6.2/end-user-identity »
}
}
}
Exemple de requête en assemblage sandbox AVEC la méthode PUT /Consent au préalable:
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.4.2/accounts
Header :
Authorization: Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAbCdEf
X-Request-ID: iid-1234567890111121 2
Signature: keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_<empreinte sha256>\ », algorithm=\ »rsa-sha256\ », headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ », signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxinDocH1ne=\ »
Psu-IP-Address:192.168.0.1
Pas de corps de requête
Remarques sur l’alimentation des champs :
- Authorization : Bearer < access_token précédemment récupéré>
- X-Request-ID : <en-tête de corrélation de la requête émise>
- Signature : <signature de la requête émise>
- Psu-Ip-Address => permet de différencier les appels batch et les appels avec le PSU connecté : ce champ est à alimenter pour un PSU connecté
Réponse : 200 (=> OK)
Header :
X-request-id: id-1234567890111121 2
Content-Type: application/hal+json;charset=UTF-8
Body :
{
« accounts »:[
{
« accountId »:{
},
« name »:« CPT DEPOT PART. »,
« cashAccountType »:« CACC »,
« _links »:{
« balances »:{
« href »:« /stet/psd2/v1.4.2/accounts/175159000004003580740/balances »
},
« transactions »:{
« href »:« /stet/psd2/v1.4.2/accounts/175159000004003580740/transactions »
},
« href »:« /stet/psd2/v1.4.2/accounts/175159000004003580740/overdrafts »
}
}
{
« resourceId »:« 175159000008003580740 »,
« accountId »:{
},
« name »:« CPT DEPOT PART. »,
« cashAccountType »:« CACC »,
« _links »:{
« balances »:{
« href »:« /stet/psd2/v1.4.2/accounts/175159000008003580740/balances »
},
« transactions »:{
« href »:« /stet/psd2/v1.4.2/accounts/175159000008003580740/transactions »
},
« href »:« /stet/psd2/v1.4.2/accounts/175159000008003580740/overdrafts »
}
}
}
],
« self »:{
« href »:« /stet/psd2/v1.6.2/accounts »
},
« consents »:{
« href »:« /stet/psd2/v1.6.2/consents »
},
« href »:« /stet/psd2/v1.6.2/end-user-identity »
}
}
}
2) Transmettre la liste des comptes consentis par le PSU
Cet appel vous permet de transmettre à l’ASPSP la liste des comptes consentis par le PSU.
La description de la fonctionnalité est décrite dans le cas d’usage « Transmettre la liste des comptes« .
Exemple de requête en assemblage sandbox :
PUT https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.4.2/consents
Headers :
Authorization: Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAbCdEf
X-request-id: id-1234567890111121 3
Signature: keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_<empreinte sha256>\ »,algorithm=\ »rsa-sha256\ »,headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ »,signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4
Psu-IP-Address:192.168.0.1
Body :
{
« balances »:[
{
},
{
}
],
« transactions »:[
{
},
{
}
],
« overdrafts »:[
{
« owners »:[
{
},
],
« trustedBeneficiaries »: false,
« psuIdentity »: false
}
Réponse : 201 (=> created)
Headers :
X-request-id: id-1234567890111121 3
Pas de body
3) Obtenir le solde
Cet appel vous permet d’obtenir le solde d’un compte consenti.
La description de la fonctionnalité est décrite dans le cas d’usage « Obtenir les soldes d’un compte« , et cette information n’est remontée que si un consentement PSU a été reçu au préalable par l’ASPSP via la méthode PUT /consents.
Exemple de requête en assemblage sandbox avec un {accountResourceId} = numéro de compte ciblé :
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.6.2/accounts/175159000004003580740/balances
Headers :
Authorization: Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAbCdEf
X-request-id: id-1234567890111121 4
Signature: keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_<empreinte sha256>\« ,algorithm=\ »rsa-sha256\ »,headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ »,signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4x
Réponse :
200 OK
Headers :
X-request-id: id-1234567890111121 4
Content-Type: application/hal+json;charset=UTF-8
Body :
{
« balances »: [
{
« balanceType »: « CLBD »,
« name »: « Solde comptable au 01/07/2022 »,
« balanceAmount »: {
« amount »: « -150.00 »,
« currency »: « EUR »
}
}
],
« _links »: {
« self »: {
« templated »: false,
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/balances »
},
« transactions »: {
« templated »: false,
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions »
},
« overdrafts »: {
« templated »: false,
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/overdrafts »
},
},
« parent-list »: {
« templated »: false,
« href »: « /stet/psd2/v1.6.2/accounts »
}
}
}
4) Obtenir les transactions
Cet appel vous permet d’obtenir les transactions d’un compte consenti.
La description de la fonctionnalité est décrite dans le cas d’usage « Obtenez les transactions« , et ces informations ne sont remontéee que si un consentement PSU a été reçu au préalable par l’ASPSP via la méthode PUT /consents.
Exemple de requête en assemblage sandbox avec un {accountResourceId} = numéro de compte ciblé :
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.6.2/accounts/175159000004003580740/transactions
Headers :
Authorization: Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAbCdEf
X-request-id: id-1234567890111121 5
Signature: keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_<empreinte sha256>\« ,algorithm=\ »rsa-sha256\ »,headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ »,signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1T0tOtuTuT1ti=\ »
Psu-IP-Address:192.168.0.1
Pas de body
Réponse : 200 (=> OK)
Headers :
X-request-id: id-1234567890111121 5
Content-Type: application/hal+json;charset=UTF-8
Body :
{
« transactions »: [
{
« entryReference »: « 382040554102518000713473520220722 »,
« transactionAmount »: {
« amount »: 8.12,
« currency »: « EUR »
},
« creditDebitIndicator »: « DBIT »,
« status »: « BOOK »,
« bookingDate »: « 2022-07-23T00:00:00+0200 »,
« bankTransactionCode »: {
« domain »: « PMNT »,
« family »: « RDDT »,
« subFamily »: « OTHR »,
« code »: « 06 »,
« issuer »: « SI MYSYS – Caisse d’Epargne »
},
« remittanceInformation »: {
« unstructured »: [
« VIR SEPA BP RIVES PARIS »
]
},
« _links »: {
« details »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions/RUNIU0VQQTgwMDA3MTM0NzM1IERVMjIwNzIwMjJUXzIzMDcyMDIyXzIwMjItMDctMjMtMDEuMTguNTIuODE4ODMxXzQ2MTAw/details »,
« templated »: false
}
}
},
{
« entryReference »: « 382040554102512022-07-12-02.42.40.510668 »,
« transactionAmount »: {
« amount »: 11.4,
« currency »: « EUR »
},
« creditDebitIndicator »: « DBIT »,
« status »: « BOOK »,
« bookingDate »: « 2022-07-12T00:00:00+0200 »,
« bankTransactionCode »: {
« domain »: « ACMT »,
« family »: « MDOP »,
« subFamily »: « COMM »,
« code »: « 62 »,
« issuer »: « SI MYSYS – Caisse d’Epargne »
},
« remittanceInformation »: {
« unstructured »: [
« * COT FORFAIT FSE + »
]
},
« _links »: {
« details »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions/bnVsbF8xMjA3MjAyMl8yMDIyLTA3LTEyLTAyLjQyLjQwLjUxMDY2OF8zMDYwMA/details »,
« templated »: false
}
}
},
{
« entryReference »: « 382040554102512022-07-06-11.22.06.175250 »,
« transactionAmount »: {
« amount »: 8.25,
« currency »: « EUR »
},
« creditDebitIndicator »: « DBIT »,
« status »: « BOOK »,
« bookingDate »: « 2022-07-06T00:00:00+0200 »,
« bankTransactionCode »: {
« domain »: « PMNT »,
« family »: « ICDT »,
« subFamily »: « DMCT »,
« code »: « 06 »,
« issuer »: « SI MYSYS – Caisse d’Epargne »
},
« remittanceInformation »: {
« unstructured »: [
« VIREMENT VERS BP RIVES PARIS »
]
},
« _links »: {
« details »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions/U0VQQSAyMjE4Nzg1QlAwMDAwMDAyOTk5OThfMDYwNzIwMjJfMjAyMi0wNy0wNi0xMS4yMi4wNi4xNzUyNTBfbnVsbA/details »,
« templated »: false
}
}
},
{
« entryReference »: « 382040554102512216685I10000004 »,
« transactionAmount »: {
« amount »: 11.33,
« currency »: « EUR »
},
« creditDebitIndicator »: « DBIT »,
« status »: « BOOK »,
« bookingDate »: « 2022-06-15T00:00:00+0200 »,
« bankTransactionCode »: {
« domain »: « PMNT »,
« family »: « IRCT »,
« subFamily »: « ESCT »,
« code »: « C1 »,
« issuer »: « SI MYSYS – Caisse d’Epargne »
},
« remittanceInformation »: {
« unstructured »: [
« VIR INST DES C17 »
]
},
« _links »: {
« details »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions/MjIxNjY4NUkxMDAwMDAwNDIwMjIwNjE1ICAgSVAwXzE1MDYyMDIyXzIwMjItMDYtMTUtMTEuMzMuNTcuNTI5ODQzX251bGw/details »,
« templated »: false
}
}
}
],
« _links »: {
« self »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions »,
« templated »: true
},
« balances »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/balances »,
« templated »: false
},
« overdrafts »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/overdrafts »,
« templated »: false
},
« parent-list »: {
« href »: « /stet/psd2/v1.6.2/accounts »,
« templated »: false
}
}
}
5) Obtenir l’identité du client
Cet appel vous permet d’obtenir l’identité du PSU connecté (qui n’est pas forcément le client possédant le compte).
La description de la fonctionnalité est décrite dans le cas d’usage « Obtenir l’identité du client« , et cette information n’est remontée que si un consentement PSU a été reçu au préalable par l’ASPSP via la méthode PUT /consents.
Exemple de requête en assemblage sandbox :
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.6.2/end-user-identity
6) Rafraîchir le jeton d’accès
Cet appel vous permet d’obtenir le découvert autorisé du PSU.
La description de la fonctionnalité est décrite dans le cas d’usage « Obtenir le découvert« , et cette information n’est remontée que si un consentement PSU a été reçu au préalable par l’ASPSP via la méthode PUT /consents.
Exemple de requête en assemblage sandbox :
GET https://www.17515.sandbox.api.89C3.com/stet/psd2/v1.6.2/accounts/175159000004003580740/overdrafts
Headers :
Authorization: Bearer KXZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoI0Kr2rSi1mSCFNehAbCdEf
X-request-id: id-1234567890111121 7
Signature: keyId=\ »https://<www.myUrlPath.to>/myQsealCertificate_<empreinte sha256>\« ,algorithm=\ »rsa-sha256\ »,headers=\ »(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\ »,signature=\ »LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1T0tOtuTuT1ti=\ »
Psu-IP-Address:192.168.0.1
Pas de body
Réponse : 200 (=> OK)
Headers :
X-request-id: id-1234567890111121 7
Content-Type: application/hal+json;charset=UTF-8
Body :
{
« overdrafts »: {
« allowedAmount »: {
« amount »: 0,
« currency »: « EUR »
}
},
« _links »: {
« self »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/overdrafts »,
« templated »: false
},
« balances »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/balances »,
« templated »: false
},
« transactions »: {
« href »: « /stet/psd2/v1.6.2/accounts/175159000004003580740/transactions »,
« templated »: true
},
« parent-list »: {
« href »: « /stet/psd2/v1.6.2/accounts »,
« templated »: false
}
}
}
7) Rafraîchir le jeton d’accès
Cet appel vous permet de rafraichir le jeton d’accès avec le refresh-token.
La description de la fonctionnalité est décrite dans la rubrique « Vue d’ensemble » > « Rafraîchir votre jeton ».
Exemple de requête en assemblage sandbox :
POST https://www.17515.sandbox.api.89C3.com/stet/psd2/oauth/token
Header :
Content-Type : application/x-www-form-urlencoded; charset=utf-8
Params:
client_id: PSDFR-ACPR-13807
grant_type: refresh_token
refresh_token: KUZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoD0Kr2rSi1mSCFNehAbCdEf
Réponse :
{
« token_type »: « Bearer »,
« expires_in »: 3600,
« scope »: « aisp offline_access »,
« refresh_token »: « KUZyspFBZ1R6NqWQdmsZhfdo1nbjK7MoD0Kr2rSi1mSCFNehAbCdEf »
}
Tester nos personna
Conformément à la réglementation DSP2 (cf. RTS Art. 30 (5)), nous devons, en tant qu’ASPSP, mettre à disposition un dispositif d’essai comprenant une assistance et permettant des tests de connexion et de fonctionnement afin que les TPP qui ont demandé l’agrément nécessaire puissent tester les logiciels et applications qu’ils utilisent pour proposer un service de paiement aux utilisateurs.
Il est aussi demandé l’utilisation de données fictives. C’est l’objectif de ces données de tests sous forme de « persona » qui rassemblent divers clients sur base de :
- segment de clientèle (étudiant, actif, retraité, entrepreneur individuel, etc..) ;
- caractéristiques de leurs comptes (mono-compte, multi-comptes, solde qui est statique) ;
- le consentement PSU a déjà été donné ;
- données utiles attendues en entrée par les API (identifiant banque à distance, IBAN).
Ce jeu de données évoluera au cours du temps avec rajout de données additionnelles (autres clients, nombre de transactions, profondeur d’historique). Revenez régulièrement sur cette section pour être à jour !
Les identifiants et données ci-dessous sont des données fictives et ne peuvent pas être utilisées en production.
Personas
 |
 |
|
LEA SANDBOXA Etudiante |
CLAIRE RECETTEB Actif et entrepreneur individuel |
 |
 |
| GEORGES PERSONAC
Actif |
GILLES TESTUNID
Retraité |
NB : pour tous ces personas, il vous faudra saisir le code SMS = « 12345678 » dans l’écran d’authentification proposé en mode assemblage.
ATTENTION : NOUVEAUX IDENTIFIANTS
| PERSONA | SEGMENT | NOUVEL IDENTIFIANT | CODETAB | IBAN | DÉTENTEUR | CONSENTEMENT : SOLDE / TRANSACTIONS / IDENTITÉ |
SOLDE | DEVISE |
| LEA SANDBOXA | Particulier | 9999999901 | 17515 | FR7617515000920400430518020 | Mme LEA SANDBOXA | TRUE TRUE FALSE |
-150.00 | EUR |
| CLAIRE RECETTEB | Particulier | 9999999902 | 17515 | FR7617515900000400358074026 | Mme CLAIRE RECETTEB | TRUE TRUE FALSE |
0.00 | EUR |
| CLAIRE RECETTEB | Entrepreneur individuel | 9999999902 | 17515 | FR7617515900000800358074006 | Mme CLAIRE RECETTEB | TRUE TRUE FALSE |
+23766.98 | EUR |
| GEORGES PERSONAC | Particulier | 9999999903 | 17515 | FR7617515000920400085945890 | Mr et Mme GEORGES PERSONAC | TRUE TRUE FALSE |
+10.00 | EUR |
| GILLES TESTUNID | Particulier | 9999999904 | 17515 | FR7617515000920440878790811 | Mr GILLES TESTUNID | TRUE TRUE FALSE |
+11880.30 | EUR |
| GILLES TESTUNID | Particulier | 9999999904 | 17515 | FR7617515000920402428687756 | Mr OU Mme GILLES TESTUNID | TRUE TRUE FALSE |
0.00 | EUR |
| GILLES TESTUNID | Particulier | 9999999905 | 17515 | FR7617515000920402428748381 | Mr ET Mme GILLES TESTUNID | TRUE TRUE FALSE |
+5879.22 | EUR |
Historique des versions
Version de la norme STET utilisée pour l’API
Cette API REST est conforme à la spécification interbancaire française STET (https://www.stet.eu/en/psd2/), version v.1.6.2.0, 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.
Les utilisateurs peuvent également consulter l’assistant virtuel en cliquant sur le pictogramme sur la page d’accueil du portail.
Description du support
Conformément à l’article 30 (5) des RTS, une assistance pour les prestataires PSP tiers est mise à disposition. Ce support est accessible via le formulaire sur ce portail BPCE API, ou via https://www.api.89c3.com/fr/nous-contacter. Les réponses se font pendant les heures de travail ouvrées (du lundi au vendredi inclus, de 09h00 à 17h00).
Le principe général du support est schématisé ci-dessous en prenant en compte les délais réglementaires prévus à l’article 30 (4) des RTS :
Principaux changements effectués depuis la première version publiée
| Toutes | 01 janvier 2023 | Reprise de toutes les évolutions éditoriales précédentes de la fiche V1.4.2 (API version V1.4.2) |
| Toutes | 01 janvier 2023 | Rajout des spécificités de la version STET V1.6.2 (API version V1.6.2) |
| Toutes | 22 mai 2023 | Documentation portail :
Augmentation du délai à 180 jours au lieu de 90 jours avant expiration du jeton Refresh Token AISP : bascule progressive entre le 24 mai et le 2 juin 2023 pour l’ensemble des TPP enrôlés. |
Roadmap
Politique de décommissionnement des versions de l’API
La politique du décommissionnement (= arrêt d’une version d’une API sur les environnements de production et sandbox) est fonction du cycle de vie des API, et il est prévu une phase de tuilage entre deux versions majeures d’API comme indiqué dans le schéma ci-dessous :
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 le portail BPCE API dans la partie « Roadmap » de l’API impactée. Une communication via courriel vers les correspondants des prestataires enrôlés sur le portail BPCE API pourra venir compléter ce dispositif.
Planning des évolutions fonctionnelles à venir de l’API
L’API d’Information sur compte fait l’objet d’améliorations et d’évolutions continues tout au long de l’année*.
(*) NB : l’article 30 (4) des RTS précise que des changements significatifs de l’API peuvent intervenir sans délai. Nous appliquons cette clause dans les cas suivants :
- problème bloquant impactant de façon généralisée au moins l’un des segments de clients majeur (particuliers, professionnels, entreprises),
- problème de sécurité,
- évolutions demandées par les autorités nationales compétentes pour répondre à la trajectoire réglementaire.
Retrouvez ci-dessous notre roadmap prévisionnelle.
| VERSION DE L’API |
VERSION DE LA NORME STET | FONCTIONNALITÉS | DATE DE DÉPLOIEMENT BPCE API DEV PORTAL & SANDBOX |
DATE DE DÉPLOIEMENT BPCE LIVE API GATEWAY |
DATE DE DÉCOMMISSIONNEMENT |
| v1.6.2 | v1.6.2.0 | API version V1 :
API version V1.4.2 = API version 1 plus :
API version V1.6.2 = API version V1.4.2 plus :
|
20 octobre 2022 | 08 février 2023 | non encore annoncée |
Limitations
Limitations fonctionnelles
Limitations de cette API DSP2
- Ne s’applique qu’aux comptes de paiements (le critère déterminant réside dans la faculté d’exécuter des opérations de paiement quotidiennes à partir d’un tel compte géré par le système d’information central « backend », source des informations remontées par les API), en euros et éligibles (compte de paiements actif – non bloqué ni sous séquestre-, et accessible en ligne, cf. texte de la Directive DSP2)
- 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)
NB : le TPP n’a pas la possibilité de fournir à l’ASPSP les données de sécurité personnalisées du client à des fins d’authentification, et donc, seuls les écrans de redirection et d’authentification forte (SCA) de l’ASPSP doivent être utilisés (l’encapsulage de ces écrans par le TPP est interdit au regard des articles PSD2 #97.5 et RTS #31)
- N’implémente que le mode de consentement « mixte AISP » via la méthode PUT /consents qui devient obligatoire :
- tous les comptes à vue sont remontés (y compris les nouveaux)
- le détail des soldes et des transactions exécutées n’est accessible que pour les comptes de paiements dont le consentement a été transmis par le TPP
- Ne fixe pas de limite d’accès (rate limit) lorsque c’est le PSU connecté qui interroge ses comptes de paiements (PSU-IP-ADDRESS fourni), sinon limité à 4 accès à l’initiative du TPP (cf. texte de la Directive DSP2) :
- par jour calendaire (00h00:00:000 – 23h59:59:999)
- par TPP OID
- par ASPSP / point d’accès
- par PSU ID
- par IBAN
- par méthode API AIS (/!\ méthode /transactions avec ou sans dateFrom / dateTo = considérée une seule et même méthode)
- Ne permet l’accès au compte que via l’IBAN du compte de paiement
- Seules les méthodes GET /accounts, PUT /consents, GET /balances, GET /transactions, GET /details, GET /overdrafts, GET /end-user-identity sont disponibles :
- le mode « aisp extended_transaction_history » n’est pas supporté : la profondeur d’historique des transactions est à l’identique de celle de la banque en ligne internet fixe, soit un maximum de 62 jours pour les PRO (pas de pagination gérée par l’API), et 90 jours pour les ENT (limitation à 500 comptes, pas de pagination gérée par l’API)
- ne permet pas de récupérer la liste des bénéficiaires de confiance d’un client (cette notion n’existe pas pour les établissements listés ci-dessous)
- ne permet pas de récupérer la liste des propriétaires d’un compte via GET /owners (fonctionnalité non supportée)
- Pas de gestion des données optionnelles « dateType » et « entryReference » (via les paramètres « entryReferenceFrom » / « entryReferenceTo »)
Limitations liées aux segments de clientèle
Sont couverts par l’API les segments clients suivants :
- Client « particulier » (y compris compte joint et mineur rattaché) ayant un abonnement à la banque en ligne « DEI PART » ou « DEI PRO » et un compte commençant par 04
NB 1 : le particulier (PART) est une personne physique catégorisée comme « majeur capable ». Le PART peut aussi avoir des activités dans le cadre d’une entreprise individuelle (EI) = une entreprise dirigée par une seule personne, et qui n’a pas le statut de « persone morale », bien qu’elle soit inscrite au répertoire des métiers ou au Registre du Commerce et des Sociétés (RCS, exemples : artisan ou profession libérale). Dans ce cas, l’EI est considéré comme un PART
NB 2 : est non compris à ce jour le tuteur de personne protégée/sous tutelle ou curatelle utilisant la solution Web Protexion
- Client « entrepreneur individuel » (EI) et « petit professionnel » ayant un abonnement à la banque en ligne « DEI PRO » et un compte commençant par 04 ou 08
NB 3 : les catégories « entreprise » (ENT) et « association » (ASSOC) couvrent les personnes morales.
- Client « gros professionnel », « entreprise » et « association » ayant un accès direct à la banque en ligne « CE Net » (ayant un abonnement « CE Net Compte » et un compte commençant par 08 autorisant les virement et prélèvements électroniques)
NB 3 : les catégories « professionnel » (PRO), « entreprise » (ENT) et « association » (ASSOC) couvrent les personnes morales.
Limitations liées aux moyens d’authentification forte
- Il est de la responsabilité de l’ASPSP d’équiper ses clients avec un ou des moyens d’authentification forte :
- PART : Accès aux comptes PART et Opération sensible / Dynamic linking (DL) : (Sécur’Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)
- PRO/ENT : Accès aux comptes PART et Opération sensible / Dynamic linking (DL) : (certificat matériel) ou (Sécur’Pass) ou (lecteur CAP) ou (Mot de Passe + OTP SMS)
NB 4 : le certificat matériel n’est pas proposé aux client sur mobile/smartphone
Accès aux données de production
Conformément à la réglementation, les modes de test Try-it et Assemblage n’utilisent que des données fictives. Ces données de tests sont décrites dans la rubrique « Comment tester l’API ?« .
Pour accéder aux données de production, l’utilisation de l’API REGISTER est un prérequis (voir la fiche www.api.89c3.com/fr/component/bpceportal/products/522/usecases/523).
NB : La plage hebdomadaire du lundi matin de minuit à 06h00 est utilisée pour la maintenance des infrastructures des systèmes d’information (tous composants, y compris le système central/backend, les passerelles, etc…) et peut engendrer des requêtes API en erreur ou des indisponibilités le temps des interventions (de même pour des traitements bancaires programmés en début et fin de journée/mois/trimestre/année).
Le code établissement (voir ci-dessous) permettra d’adresser le bon backend via le « endpoint » www.<cdetab>.live.api.89c3.com (ou www.<cdetab>.live.api.caisse-epargne.fr aligné sur le nom de domaine de l’accès direct www.caisse-epargne.fr). Une fois choisi, ce point d’accès doit être conservé pour toutes les requêtes sous-jacentes.
Une fois choisi, ce point d’accès doit être conservé pour toutes les requêtes sous-jacentes.
| CDETAB | NOM DE L’ÉTABLISSEMENT | NOM ABRÉGÉ | DISPONIBLE EN TRY-IT ET ASSEMBLAGE | DISPONIBLE EN PRODUCTION |
| 11315 | Caisse d’Epargne Provence Alpes Corse | CEPAC | – | Oui |
| 11425 | Caisse d’Epargne Normandie | CEN | – | Oui |
| 12135 | Caisse d’Epargne Bourgogne Franche-Comté | CEBFC | – | Oui |
| 14445 | Caisse d’Epargne Bretagne-Pays de Loire | CEBPL | – | Oui |
| 13135 | Caisse d’Epargne Midi-Pyrénées | CEMP | – | Oui |
| 13335 | Caisse d’Epargne Aquitaine Poitou-Charentes | CEAPC | – | Oui |
| 13485 | Caisse d’Epargne Languedoc-Roussillon | CELR | – | Oui |
| 13825 | Caisse d’Epargne Rhône Alpes | CERA | – | Oui |
| 14265 | Caisse d’Epargne Loire Drôme Ardèche | CELDA | – | Oui |
| 14505 | Caisse d’Epargne Loire-Centre | CELC | – | Oui |
| 17515 | Caisse d’Epargne Ile De France | CEIDF | Oui | Oui |
| 18315 | Caisse d’Epargne Côte d’Azur | CECAZ | – | Oui |
| 18715 | Caisse d’Epargne Auvergne et Limousin | CEPAL | – | Oui |
| 15135 | Caisse d’Epargne Grand Est Europe | CEGEE | – | Oui |
| 16275 | Caisse d’Epargne Hauts de France | CEHDF | – | Oui |
