Best practice
PreviousIntegrazione touch point dell’EC con CheckoutNextGenerazione dell’Identificativo Univoco di Versamento
Last updated
SANP 3.4.0
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.
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.
Nella fase di verifica l'EC è sempre tenuto ad attualizzare l'importo del pagamento.
La richiesta di verifica avviene sempre per mezzo della primitiva , sia nel caso di che nel caso di , 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.
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.
nel caso di Pagamento di un avviso presso PSP al transfer con idTransfer = 1 deve essere per forza associato l'IBAN di un conto corrente postale
Per identificare la casistica specifica è possibile utilizzare il parametro paymentNote come indicato in Fase di attivazione.
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..
Il parametro paymentNote nel caso di Pagamento presso frontend dell'EC viene popolato con il valore inserito dall'EC in idCart contenuto nella di redirect.
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 se nella request della il parametro transferType fosse valorizzato a POSTAL
nel caso di Pagamento presso frontend dell'EC a tutti i transfer dell'avviso l'EC deve associare un metadata con key per la gestione del e, se possibile, deve inserire un IBAN di un conto corrente postale per ogni transfer o nel tag IBAN o nel value del metadata con key IBANAPPOGGIO.
In caso di una risposta alla 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 il nodo cerca di sottomettere nuovamente le receipt in questione: