Best practice
Gestione della posizione debitoria
L’EC crea una posizione debitoria in attesa nell'archivio dei pagamenti, e vi associa un numero avviso. Nella versione attuale del software è previsto il pagamento in un’unica soluzione.
L'EC nelle fasi intermedie del pagamento non deve modificare lo stato della posizione, che rimane sempre nello stato "aperta", è cura della piattaforma pagoPA gestire gli stati intermedi, l'EC modifica la posizione debitoria in stato “pagato” solo se il pagamento va a buon fine.
In questo caso la posizione risulta interamente saldata, esiste quindi un solo pagamento “pagato” associato alla posizione debitoria.
Causale di versamento
A partire dalla versione 2.0.0 delle SACI è stato rimosso il capitolo "Formato della causale di versamento", per la composizione di tale dato si deve fare riferimento direttamente al paragrafo 7.1 delle Linee Guida.
Si raccomanda di non inserire all'interno della causale di versamento dati personali e/o dati particolari.
Data di scadenza
La piattaforma pagoPA non opera alcun blocco preventivo rispetto alla data di scadenza riportata dall'Ente Creditore nel campo dueDate previsto nelle varie Primitive.
È sempre responsabilità dell'Ente Creditore tenere aggiornato lo stato di una posizione debitoria, così come l'inserimento corretto della data di scadenza.
Il campo dueDate va popolato con l'effettiva data di scadenza riportata sugli avvisi di pagamento. Questo consente di mostrare l'informazione all'utente che intende pagare l'avviso tramite canali digitali (es.: l'app IO, pagoPA Checkout).
Rappresenta la data di scadenza riportata sull'avviso di pagamento e va comunicata secondo il formato: ISO 8601 [AAAA]-[MM]-[GG].
PagoPA S.p.A. non è responsabile della correttezza delle informazioni comunicate dall'Ente Creditore, e non effettua alcuna verifica sulle stesse.
PagoPa S.p.A. si riserva la facoltà di non mostrare sui canali digitali la data di scadenza nei casi descritti di seguito:
formati errati che non rispettano lo standard ISO 8601;
date troppo lontane o riferite al passato (es.: 2099-12-31, 1800-12-31).
Tale facoltà è necessaria per migliorare l'esperienza degli utenti e ridurre le richieste di assistenza sui propri canali e su quelli degli Enti Creditori.
Fase di verifica
Nella fase di verifica l'EC è sempre tenuto ad attualizzare l'importo del pagamento.
La richiesta di verifica avviene sempre per mezzo della primitiva paVerifyPaymentNotice, sia nel caso di verificaBollettino che nel caso di verifyPaymentNotice, anche perché l'EC non è a conoscenza da quale primitiva sia nata la verifica.
L’EC deve rispondere sempre con un'unica opzione di pagamento e per mezzo del parametro allCCP deve sempre indicare se la posizione debitoria è associabile a tutti conti correnti postali o meno:
allCCP = true : l’opzione è associabile a tutti Conti Correnti Postali;
allCCP = false: l’opzione non è associabile a tutti Conti Correnti Postali.
Fase di attivazione
Nella fase di attivazione l'EC è sempre tenuto ad attualizzare l'importo del pagamento.
Per mezzo del parametro transferType la piattaforma richiede all’EC per ogni singolo transfer:
i conti correnti postali (quando disponibili) con il parametro transferType=POSTAL;
qualsiasi conto corrente, a discrezione dell’EC stesso, se il parametro transferType non è indicato.
Il parametro retentionDate al momento viene ignorato dalla piattaforma pagoPA.
Il parametro lastPayment al momento viene ignorato dalla piattaforma pagoPA.
Il parametro paymentNote nel caso di Pagamento presso frontend dell'EC viene popolato con il valore inserito dall'EC in idCart contenuto nella POST di redirect.
Bollettino Postale PA
Se l'EC dispone di almeno un conto corrente postale per gli incassi è necessario includere nell'avviso di pagamento anche il Bollettino Postale PA, in tal caso si possono verificare le seguenti casistiche:
nel processo di Pagamento di un avviso presso PSP nel caso il parametro transferType della request della paGetPayment fosse valorizzato a POSTAL al transfer con idTransfer = 1 deve essere per forza associato l'IBAN di un conto corrente postale;
Coda delle receipt da risottomettere
In caso di una risposta alla paSendRT che porta la receipt in stato NOTICE_PENDING (timeout, errore response, non raggiungibile), la receipt viene inserita in una coda per essere sottomessa nuovamente all’EC.
Con la primitiva paSendRT il nodo cerca di sottomettere nuovamente le receipt in questione:
se una receipt viene sottomessa nuovamente e va in uno stato finale si toglie dalla coda;
se una receipt viene sottomessa nuovamente ma rimane in uno stato non finale (NOTICE_PENDING) si lascia in coda e si aumenta il contatore relativo al numero di retry.
Raggiunto il numero finale di retry (è un parametro di configurazione della piattaforma) il processo si ferma e l'elemento rimane in coda, è possibile riavviare il processo di retry con una richiesta all'assistenza di PagoPA S.p.A..