Functional limitations :

The limitations of this PSD2 API in the version 1.0 are as follows:

  • Apply only to authorized and eligible payment accounts (the determining criterion for the purposes of that categorisation lies in the ability to perform daily payment transactions from such accounts) that are accessible online (cf. PSD2 Directive text) for retail banking customers (PART), small professionnals (PRO), but not large professionals, corporates and associations using CE Net direct acess interface neither attorneys for tutorships using WebProtexion ;
  • Use the authentication with redirect mode only (Strong Customer Authentication required and handled by the bank), which IS NOT an obstacle according to french national competent authority ;
  • Manage only single payment initiation requests in euro currency either in SCT CORE (immediate or difffered) or Instant Payment (not available for professionnals neither corporates and associations segments) ;
  • The methods POST/paymentRequest (except POST/paymentRequest/{paymentRequestResourceId}/confirmation), GET/paymentRequest and PUT/paymentRequest (only for differed PIPS) are the only ones available.
  • Field "chargeBearer" is mandatory as of POST /payment-requests method and must be valued to "SLEV" ;
  • Field "categoryPurpose" is mandatory as of POST /payment-requests method ;
  • Field "creditorAccount" is mandatory as of POST /payment-requests method ;
  • Field "successfulReportUrl" is mandatory as of POST /payment-requests method ;
  • Cancellation of PISP operations can be made thru the API or by the PSU through his/her direct access.

 Limitations linked to SCA :

  • retail PSU : password + OTP SMS and/or CAP reader and/or soft token Sécur'Pass ;
  • small professionals : password + OTP SMS and/or CAP reader.

NB : CASH PISP operations will be rejected if the PSU is not using Sécur'Pass and if the creditor IBAN is not registred by the PSU in his direct access.


From test to live data :

According to PDS2 regulation, the data set available thru this dev portal, Try-it mode and sandbox are based on fictive data (or non-real ones).These data are described in the use case "Test our API".

In order to access to live data, you will need to request for a GO Live thru the 89C3 API portal after testing your app using Try-it and Sandbox environments as described below : 

étapes test sandbox6 UK

Refer to Art. 30 (5). Account servicing payment service providers shall make available a testing facility, including support, for connection and functional testing to enable authorised payment initiation service providers, payment service providers issuing card-based payment instruments and account information service providers, or payment service providers that have applied for the relevant authorisation, to test their software and applications used for offering a payment service to users.

Please note that a weekly slot is reserved for a programmed maintenance (all IT infrastructure incl'd backends and API gateways) Monday morning from 02:00am to 06:00 am), and could generate some perturbations during this period . 

For live operations, the parameter "bankcode" allows TPP to send API requests to the right ASPSP backend thru a dedicated « endpoint » www.<bankcode> (or www.<bankcode> aligned on direct access domain name Once chosen, this entry point shall also be used for all subsequent requests.

Bank Code

Bank name

Bank short name


Caisse d'Epargne Provence Alpes Corse


11425 Caisse d'Epargne Normandie


12135 Caisse d'Epargne Bourgogne Franche-Comté


14445 Caisse d'Epargne Bretagne-Pays De Loire


13135 Caisse d'Epargne Midi-Pyrénées


13335 Caisse d'Epargne Aquitaine Poitou-Charentes


13485 Caisse d'Epargne Languedoc-Roussillon


13825 Caisse d'Epargne Rhône Alpes


14265 Caisse d'Epargne Loire Drôme Ardèche


14505 Caisse d'Epargne Loire-Centre


17515 Caisse d'Epargne Ile De France


18315 Caisse d'Epargne Côte d'Azur


18715 Caisse d'Epargne Auvergne et Limousin


15135 Caisse d'Epargne Grand Est Europe


16275 Caisse d'Epargne Hauts de France



carte FR CE