Limits

Operational limitations

These are the operational limitations of this PSD2 API in the version 1.0 :

• Can be used for all Banques Populaires except BRED

• Only apply to active payment accounts that are accessible online (cf. PSD2 Directive texts) => only current accounts will be returned

• Use the REDIRECT authentication  approach only (Strong Customer Authentication required and handled by the bank), which IS NOT an obstacle according to French national competent authority

Note : TPP are not allowed to send to ASPSP the PSU credentials, and only ASPSP SCA redirect screens can be used (no embeding process as clarified by European Banking Authority based on articles PSD2 #95.5 & RTS #31)

• Implement the mixed AISP consent mode, but not the full AISP consent mode :
  • By default, when no consent has been transmitted, all accounts are available
  • But the accounts balances and transactions detail either the cards outstandings and slips are available only for the accounts the consent was given

• The limit is up to 4 batch accesses per calendar day for every method of this API(see use cases of every method for more details), but there is no limit when the customer asks directly his accounts online

• Transmit the PsuIdentity value by retrieving the consented accounts list if the customer has given his consent

• Access to the list of trusted beneficiaries is NOT available (feature not implemented in Banques Populaires online banking service)

• "aisp extended_transaction_history" mode is NOT supported

• Dont allow to get the customer trusted beneficiaries list : it doesnt exist for Banques Populaires (<=> a recorded beneficiary and validated by strong authentication and no strong authentication is needed after for a payment validation and for this beneficiary)

• As a first step, only the GET /accounts, PUT /consents, GET /balances and GET /transactions methods will be available. The GET /trustedBenficiaries et GET /endUserIdentity will be available later (see "Roadmap" use case)

• Return data only for active delayed cards which have been used at least once in the past two months

 The table below shows the limitations by method for this API (fields names are in italic) :

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 : 

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) Sunday morning from 02:00 to 06:00 am, and could generate some perturbations during this period. 

For live operations, the parameter "bankcode" will allow you to setup the right customer database thru a dedicated « endpoint » for each bank using the following format www.<bankcode>.live.api.89c3.com or

• www.<bankcode>.live.banquepopulaire.fr aligned on direct access domain name www.banquepopulaire.fr 

• www.10548.live.api.banque-de-savoie.fr aligned on direct access domain name www.banque-de-savoie.fr

• www.40978.live.api.palatine.fr aligned on direct access domain name www.palatine.fr

Once chosen, this entry point shall also be used for all subsequent requests.