➤ Functional limits  

General limits 

• Apply only to eligible accessible online payment accounts (the determining criterion for the purposes of that categorisation lies in the ability to perform daily payment transactions from such accounts), and to PIS requests between two different accounts which are don't belong to the same PSU ID / same ASPSP 

• Use the authentication with redirect reinforced mode only (Strong Customer Authentication required and handled by the bank, which IS NOT an obstacle according to french national competent authority) & call for o-confirmation method

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)

• Manage only single payment initiation requests in euro currency either in
  • SCT CORE (immediate or difffered or recurrent) for all customer segments 
  • or Instant Payment for all customer segments 

• The following methods are available
  • POST/paymentRequest
  • POST/paymentRequest/{paymentRequestResourceId}/o-confirmation
  • GET/paymentRequest 

• BIC is mandatory only for PIS request in non eurozone (still in euro currency)

• Cancellation of PIS operations by the PSU is possible through his/her direct access (as well as via API before the same dead line applied for online banking environment)

• Different PIS requests having the identical parameters as an already executed one (same date, same debtor & creditor IBAN, same amount, ...) will be rejected (same feature as direct access)   

• If the PSU doesn't perform any action during 04 mns on redirect screens (or 30 mns overall), the PSU will be considered as disconnected and no redirection will be provided back to the TPP

Customer segments limitations

• PART segment is retail segment (adult & autonomous customers, also includes "individual entrepreneur")
  

• PRO segment gathers small companies

• ENT segment gathers medium to large corporations having online banking subscriptions (as CE Net Comptes or equivalent) allowing unitary funds transfers

Note : it doesn't apply to legal guardians managing tutorships 

Payment account limitations

• Payment accounts are those available through the online banking 

• Some business rules can apply and may limit fund tranfer operations (anti-fraud rules, ...)

SCA limitations

• PART : [soft token Sécur'Pass] and/or [password + CAP reader] and/or [password + OTP SMS] 

• PRO  : [soft token Sécur'Pass] and/or [password + CAP reader] and/or [password + OTP SMS]

• ENT  : [certificate on physical token] and/or [soft token Sécur'Pass] and/or [password + CAP reader] and/or [password + OTP SMS] 

Note 1 : no SCA exemptions apply

Note 2 : PIS requests with "CASH" categoryPurpose will be rejected IF PSU SCA is not performed using Sécur'Pass (or the physical token for PRO & ENT) AND if the creditor IBAN is not registered before (> 72 hours) by PSU using direct access / online banking

➤ Access 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, please use first our API Register (see the product data sheet www.api.89c3.com/en/component/bpceportal/products/543/usecases/533).

Please note that a weekly slot is reserved for a programmed maintenance (all IT infrastructure incl'd backends and API gateways) Monday morning from midnight 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>.live.api.89c3.com (or www.<bankcode>.live.api.credit-cooperatif.coop aligned on direct access domain name www.credit-cooperatif.coop). Once chosen, this entry point shall also be used for all subsequent requests.