Supported Banks:
Starting from December 4th 2021, services for ABI 03126 (Banca Leonardo) will be dismissed.
The access to Account Information Services (AIS) and Payment Initiation Services (PIS) will be allowed until December 3rd 2021 included.
FAQs
The 5 Pillars of PSD2
The Payment Services Directive 2 (PSD 2, Directive (EU) 2015/2366) is an EU Directive, replacing the Payment Services Directive (PSD, Directive 2007/64/EC) administered by the European Commission (Directorate General Internal Market) to regulate payment services and payment service providers throughout the European Union (EU) and European Economic Area (EEA).
PSD2 has the aim to promote the innovation and the development of an efficient, secure and competitive internal payment services market, increasing payment services user protection and electronic payment services safety.
PSD2 creates new type of services, provided by Third Parties, in the payment services framework: Payment Initiation Services, Account information Services and Confirmation on the Availability of Funds Service.
The consumers will have the possibility to access to new payment services offered by Third Parties, allowing them to initiate payments, get information on their bank accounts and use new payment instruments in a smarter way.
Customer safety is the first concern for PSD2 Directive. To protect customer, the Regulator provides that the PSU must choose which Third Party allow to access to his accounts and how long it can access his data, by submitting his consent through a second factor authentication every time it should be required for the safety of his identity and properties.
Cedacri Developer Portal: how it works!
Developer Portal is the web portal dedicated to our PSD2 Gateway. Here you can find all necessary documentation and test the available APIs in order to integrate your external applications with our PSD2 services.
Our PSD2 APIs have been developed following the Berlin Group's NextGenPSD2 XS2 standard. Here you can find more informations about Berlin Group's initiative.
In the “technical documentation” section of the Developer Portal, available here, you can find the Berlin Group’s reference version for each PSD2 APIs set.
To access the test data, you must first sign up to Cedacri's Developer Portal. Once registered, you will get full access to our documentation.
You can find the full catalog of available PSD2 APIs and all the relative informations in the technical documentation, available here
At the moment you can only access the test environment (SANDBOX). You simply have to follow the guide in the document Tpp Onboarding procedure
You can find in our technical documentation, available here, the complete list of Banks you can access through our PSD2 API.
You can find here all the details about the supported Berlin Group’s parameters and Cedacri specific implementation.
In case of scheduled maintenance on our PSD2 APIs, we will publish an informative banner on the Developer Portal’s Home Page well in advance.
Information on our PSD2 APIs versions can be found in the documentation section here.
Any other changes to the service will be communicated to the TTPs via the e-mail address used during the registration process in the Production or SANDBOX environments.
Any other changes to the service will be communicated to the TTPs via the e-mail address used during the registration process in the Production or SANDBOX environments.
According to current regulations available here, upon the release of a new PSD2 APIs version, a communication will be sent to the TPPs by mail and previous versions will be dismissed within the expected period of time
TPP AUTHENTICATION
To obtain the credentials, simply follow the guide in the document Tpp Onboarding procedure
You will be able to log in only after we have enabled the user following the verification of the additional data that will be requested by email, as indicated in step 5 of the guide present in the document Tpp Onboarding procedure
The authorization of the user will be communicated via e-mail to the address used during registration.
The authorization of the user will be communicated via e-mail to the address used during registration.
I made the registration calls for the Production environment but I get the CERTIFICATE_INVALID error
In case you receive the indicated message, to complete the registration process in the production environment, you need to:
- Provide us with the GURN of the certificate, the date and time of the call that went in error
- Alternatively, provide us with the public certificate directly by following the procedure indicated in the FAQ "I can't find an answer to my problem and I want to contact customer support"
In case you receive the indicated message, to complete the registration process in the production environment, you must follow the procedure indicated in the FAQ "I can't find an answer to my problem and I want to contact customer support", providing us the public certificate, the date and time of the call that went in error.
Yes. At the moment you can only access the test environment (SANDBOX). You simply have to follow the guide in the document Tpp Onboarding procedure
If the Global Unique Reference Number (GURN) of the QWAC certificate does not change, the operation has no impact on the Cedacri side and you can make the replacement when you deem it appropriate.
The only check to be made is that the root certificate does not change. If not, please follow the procedure indicated in the FAQ "I can't find an answer to my problem and I want to contact customer support" , to allow us to verify if the root certificate is supported by our infrastructure and, if necessary, to censor it.
If the GURN changes, it is necessary to repeat the registration procedure in the document Tpp Onboarding procedure
Yes, by onboarding with the new certificate it will still be possible to use the consents that are still valid using the old certificate and the clientId and clientSecret obtained with the onboarding carried out previously.
API
This is the version of the PSD2 API published by Cedacri. The Berlin Group version to which it refers is reported in the technical documentation of each specific Cedacri version, available here
.
Yes, our APIs allow you to operate on both corporate and retail accounts, in the AIS and PIS scope.
Yes, there is no limit to the number of valid access tokens for each user. If you were to authorize a second token, the first would still remain valid.
Lifetime of access tokens depends upon the scope they are associated with:
- for the AISP scope access tokens lifetime is 90 days
- for the PISP scope access tokens lifetime is 90 days
- for the CISP scope there is no expiry
- for the AISP scope access tokens lifetime is 90 days
- for the PISP scope access tokens lifetime is 90 days
- for the CISP scope there is no expiry
Calling any API with an expired access token, you will receive in response a 401 Unauthorized and in the response body the link to initiate the procedure for validating the access token.
The protocol we use in our API is OAuth2 (Authorization Code Grant flow). The user must log in on a dedicated Cedacri page, shown during the procedures provided for by OAuth2, as required by the OAuth2 Redirect Authentication.
Here's a comprehensive list of all the transactionStatus codes:
- RCVD - Payment Init Request has been received by the ASPSP
- ACTC - Authentication and syntactical and semantical validation by the ASPSP are successful (this is the payment status right before the SCA completion)
- ACSP - This is the payment status set right after a successful SCA completion
- ACSC - Settlement on the debtor’s account has been completed
- ACCC - Settlement on the creditor's account has been completed.
- RJCT - Payment initiation or individual transaction included in the payment initiation has been rejected.
- CANC - Payment initiation has been cancelled before execution by the PSU (only for future and periodic payments)
TROUBLESHOOTING
With a valid AISP consent, only in case of unattended calls, it's not allowed to retrieve transactions prior to 90 days (starting from the day before the request).
No, the current implementation of the PSD2 standard does not allow to generate an access token linked to different scopes.
Yes, the operation can be performed using the API Updated a TPP registration (PUT / tpp / {uuid}) described in the documentation available here.
Yes, the operation can be performed using the API Updated a TPP registration (PUT / tpp / {uuid}) described in the documentation available here.
The returned paymentId is an identifier associated with the payment but does not match the CRO number.
The Cedacri specifications of the payments API allow you to indicate the desired date on which to make the payment through the requestedExecutionDate field, the requestedExecutionTime field is not supported. For this reason, payments with a future date are made on the requested date but at a fixed time, corresponding to 06:30 of the 'Europe / Rome' timezone (UTC + 1).
Generally, the error in question is due to the incorrect entry of the redirect_uri field in the query string of the SCA authorization link during the call. In fact, the Uri redirect must necessarily correspond to the one configured during registration or subsequently updated through a special call to the API Updated a TPP registration.
For support requests we kindly ask you to:
• Ticket management will follow the following process:
- TPP opens tickets from the Help Center section of the developer portal
- TPP receives confirmation of acceptance via e-mail to the address that TPP indicated when opening the ticket.
- ASPSP analyzes the problem and:
- if the TPP has provided all the details useful for identifying the problem on the dedicated interface, it provides feedback within the 14 days required by law, with indications of remedial actions;
- the ticket is then closed via the ticketing system;
- if essential informations for problem determination are missing, ASPSP requests it via the TPP ticketing system, by sending an e-mail to the address that the TPP indicated when opening the ticket;
- in case of failure by the TPP to respond to the request, ASPSP proceeds with unilateral closure within 2 working days.
- if the TPP has provided all the details useful for identifying the problem on the dedicated interface, it provides feedback within the 14 days required by law, with indications of remedial actions;
- ASPSP communicates the closure of the ticket via e-mail automatically generated by the ticketing system and sent to the address that the TPP indicated when opening the ticket.
- The TPP, having received the closure communication via e-mail, can confirm, using a specific link, acceptance of the resolution of the problem.
- The iteration between TPP and ASPSP on an open ticket occurs by opening a new ticket, in order to:
- keep track of the requests received from the TPP in a structured way;
- guarantee compliance with service levels;
- avoid overlapping different problems; incentivize TPPs to provide clear evidence of the problem.