Table of contents
Quality indicators for registered entities
Response time
The following chart shows the lead times of the pagoPA platform
- the Processing time represents what is indicated in Livelli di servizio dei metodi degli ec;
- Node Timeout represents what is indicated in Gestione dei timeout verso gli ec or Gestione dei timeout verso i psp, depending on the nature of the Called Node;
- the Node Caller Timeout represents what is indicated in Gestione dei timeout del nodo for the synchronous methods.
The following chart shows the times in which the pagoPA platform acts as a server in the case of non-synchronous methods
.png)
- the Node Caller Timeout represents what is indicated in Gestione dei timeout del nodo for the non-synchronous methods.
The following chart shows the times in which the pagoPA platform acts as a client
- the Processing time represents what is indicated in Livelli di servizio dei metodi degli ec or Livelli di servizio dei metodi dei psp, depending on the nature of the Called Node;
- Node Timeout represents what is indicated in Gestione dei timeout verso gli ec or Gestione dei timeout verso i psp, depending on the nature of the Called Node.
Retry processes
In cases of timeout, the retry processes must be activated for the following primitives:
The retry processes must be adopted for calculating the exponential backoff logic wait time starting from the detection of the timeout
$$wait time = slot time * (2^k - 1)$$
with K that is the number of the attempt (first attempt = 1) and slottime is equal to the maximum wait time of the original caller.
The retry processes must have a maximum number of 5 attempts, functions must be provided for consulting and resetting the attempt counter so that the process can be restarted if necessary.
In the case of timeout for the following primitives:
an automatic retry process is not necessary, but if a new invocation is necessary the minimum wait time before performing a new attempt must respect the exponential backoff logic indicated above.
Managing the node timeouts
The timeout represents a predetermined period of time after which a given operation can considered concluded by the EC and PSP.
The following table shows, for each primitive:
- the minimum wait times for synchronous methods
- the suggested wait times for non-synchronous methods
for the node response
by the ECs
| Primitive | Timeout in seconds | Synchronous |
|---|---|---|
| nodoChiediElencoFlussiRendicontazione | 15 | |
| nodoChiediFlussoRendicontazione | 60 |
by the PSPs
| Primitive | Timeout in seconds | Synchronous |
|---|---|---|
| activatePaymentNotice | 12 | |
| demandPaymentNotice | 12 | |
| nodoChiediCatalogoServizi | 15 | |
| nodoChiediInformativaPA | 15 | |
| nodoChiediTemplateInformativaPSP | 15 | |
| nodoInviaFlussoRendicontazione | 60 | |
| sendPaymentOutcome | 15 | |
| verificaBollettino | 12 | |
| verifyPaymentNotice | 12 |
Resolution time for a critical event
If a critical event occurs, the Creditor or PSP must acknowledge the problem within 5 minutes and then send an email to the operational workgroup of the NodoSPC containing information regarding the overall planning they will adopt to resolve the problem in question, structured based on the complexity of the problem itself (e.g. immediate bug fix, possible temporary solution, closure of the event).
Tell us what you think
For clarifications on implementation specifications, such as SACI and SANP, you can open an issue on GitHub