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.
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.
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 contacting us at psd2@cedacri.it

In case you receive the indicated message, to complete the registration process in the production environment, you must provide us by contacting us at psd2@cedacri.it , 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 contact us at psd2@cedacri.it , 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.
LIVE: Lifetime of access tokens depends upon the scope they are associated with:

- for the AISP scope access tokens lifetime is 180 days
- for the PISP scope access tokens lifetime is 180 days
- for the CISP scope there is no expiry

SANDBOX: Lifetime of access tokens depends upon the scope they are associated with:

- for the AISP scope access tokens lifetime is 180 days
- for the PISP scope access tokens lifetime is 180 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.