3.7. Rendicontazione e Accredito¶
Per ogni pagamento avvenuto, il PSP si impegna a riversare le somme incassate verso gli IBAN contenuti nelle richieste di pagamento tramite disposizione di SCT cumulativi di tutti i pagamenti verso il medesimo conto corrente della PA. Inoltre, a fronte di un pagamento avvenuto in data D, il PSP in data D+2 deve inviare un Flusso di Rendicontazione (FdR).
Il Flusso di Rendicontazione rappresenta il dettaglio dei pagamenti contenuti all’interno del medesimo SCT identificato (per mezzo del campo AT-05) con l’identificativo del flusso di rendicontazione.
3.7.1. Pagamento tramite PSP¶
Nel caso di un pagamento effettuato direttamente tramite i servizi del
PSP (si veda Sez-III “Pagamento di un Avviso”), a fronte di un addebito
eseguito dal PSP, descritto dalla primitiva sendPaymentOutcome
, nel
corrispondente Flusso di Rendicontazione il campo
datiSingoloPagamento
viene così composto:
identificativoUnivocoVersamento
: IUV della richiesta di pagamento, il medesimo restituito all’interno della primitiva getPayment da parte dell’EC e contenuto all’interno della ricevuta acquisita dall’Ente Beneficiario.identificativoUnivocoRiscossione
: pari al paymentToken generato dalla piattaforma e riportato all’interno della ricevuta acquisita dall’Ente Beneficiario.indiceDatiSingoloPagamento
: identificativo della porzione dell’importo indicato all’interno della ricevutasingoloImportoPagato
: importo parzialecodiceEsitoSingoloPagamento
: 0dataEsitoSingoloPagamento
: data del pagamento riportata all’interno della ricevuta
Pertanto, qualsiasi Ente Beneficiario è in grado di riconciliare il pagamento ricercando per ogni datoSingoloPagamento la corrispondente ricevuta identificata da paymentToken e IUV, selezionando l’importo parziale corrispondente al campo indiceDatiSingoloPagamento.
3.7.1.1. Pagamento Bollettino Postale¶
Nel caso di un pagamento multi-beneficiario effettuato tramite la sezione “Bollettino Postale” presente all’interno di un avviso di pagamento, a fronte di un addebito eseguito dal PSP Poste Italiane è possibile che i corrispettivi FdR per gli Enti Beneficiari vengano eseguiti da due PSP distinti.
In particolare :
- i versamenti destinati a conti correnti postali verranno eseguiti dal PSP Poste Italiane
- i versamenti destinati a conti correnti bancari verranno eseguiti dal PSP Postepay.
In conclusione, a fronte di un un’inca receipt dove il PSP attestante è identificato come Poste Italiane potrebbero corrispondere ( in base alla composizione dei versamenti ) due FdR forniti da due PSP distinti.
La fase di riconciliazione non viene modificata in quanto i due enti beneficiari saranno sempre in grado di riconciliare ricercando per ogni datoSingoloPagamento la corrispondente ricevuta identificata da paymentToken e IUV, selezionando l’importo parziale corrispondente al campo indiceDatiSingoloPagamento.
3.7.2. Pagamento in Wallet¶
Nel caso di un pagamento effettuato tramite i servizi di pagamento resi
disponibili all’interno del wallet (WISP), a fronte di un addebito
eseguito dal PSP, il corrispondente Flusso di Rendicontazione conterrà
il campo datiSingoloPagamento
così composto:
identificativoUnivocoVersamento
: IUV della richiesta di pagamento, il medesimo contenuto all’interno della RPT ricevutaidentificativoUnivocoRiscossione
: il medesimo contenuto all’interno della RT emessa dal PSPsingoloImportoPagato
: importo parzialecodiceEsitoSingoloPagamento
: 0dataEsitoSingoloPagamento
: data del pagamento riportata all’interno della ricevuta.
3.7.3. Nota codiceEsitoSingoloPagamento¶
E’ importante evidenziare le possibili casistiche in funzione dell’esito
della sendPaymentOutcome()
, insieme al suo valore semantico, in
virtù della retrocompatibilità nella generazione del FdR:
OK
=> codiceEsitoSingoloPagamento = 0- EC configurato con il precedente modello: è possibile consegnare l’RT all’EC
- EC configurato con il nuovo modello: è possibile consegnare la Receipt all’EC
PPT_TOKEN_SCADUTO
=> codiceEsitoSingoloPagamento = 9- EC configurato con il precedente modello: è possibile consegnare l’RT all’EC (solo nel caso in cui le Retry vadano a buon fine)
- EC configurato con il nuovo modello: è possibile consegnare la Receipt all’EC (a meno che il pagamento non si effettuato sul modello on-line)
PPT_PAGAMENTO_DUPLICATO
=> codiceEsitoSingoloPagamento = 9- non è possibile consegnare l’RT/Receipt all’EC
Infine se non è possibile ottenere l’esito prima della generazione dei FdR allora non sarà possibile consegnare l’RT/Receipt all’EC. A tal proposito è importate sottolineare due considerazioni:
- si ritiene questa ultima casistica molto ridotta in quanto la durata dal token (al netto del limite superiore) è impostata dal PSP stesso in base alle proprie necessità e circostanze;
- a livello di servizio PagoPA SpA attua un monitoraggio su tali eventi con l’obiettivo di minimizzarli con opportune azioni.