Pagamento avvisi bianchi ad iniziativa PSP

[nardil]

Facendo seguito a quando segnalato in link-it/govpay#264 da utenti di GovPay, proponiamo la seguente evolutiva

Necessità

Lo scenario è quello in cui la posizione da pagare non è presente nei sistemi dell'EC, ad esempio come nel caso dei preavvisi delle sanzioni del codice della strada.

In gran parte delle amministrazioni, queste vengono elevate tramite bollettario cartaceo che alimenta l'archivio dei pagamenti in attesa in tempi successivi. Nel periodo che va dall'emissione della sanzione al suo inserimento a sistema l'avviso risulta sconosciuto al sistema pagoPA e pertanto non pagabile, determinando un peggioramento del servizio al cittadino rispetto alla situazione tradizionale.

pagoPA suggerisce nelle linee guida l'uso da parte degli operatori dell'Ente di dispositivi portatili (palmari, smarphone o altro) per l'allineamento immediato dei sistemi informativi ed il bollettario come soluzione di backup.

Di fatto molte delle amministrazioni intervistate ritengono le soluzioni proposte non sostenibili:

• Costi aggiuntivi non sostenibili (hardware, sviluppi, manutenzione, supporto, formazione)
• Maggior tempo necessario all'emissione della sanzione
• Impossibilità di garantire sempre al cittadino (non solo nell'happy path) tutto il tempo utile per eseguire il pagamento entro termini previsti, in particolar modo quando sono previste riduzioni di importo entro pochi giorni dalla contestazione.

Risulta quindi necessario dar modo all'EC di poter replicare lo scenario attuale, ovvero quello di lasciare un avviso cartaceo compilato manualmente ed immediatamente pagabile a prescindere dal suo caricamento sui sistemi informativi dell'EC.

Proposta

L'evolutiva che viene richiesta a pagoPA è dunque quella di fornire la possibilità di supportare il pagamento ad iniziativa PSP di avvisi ad importo libero.

Nel proseguo utilizzeremo questa teminologia:

• Avviso bianco: avviso di pagamento pagoPA privo di importo, scadenza e dati del soggetto debitore.
• Posizione debitoria indeterminata: posizione priva di importo, scadenza e dati del soggetto debitore.
• Posizione debitoria attualizzata: posizione completa di tutti i dati necessari al pagamento.
• APA: archivio dei pagamenti in attesa, ovvero il repository delle posizioni debitorie dell'Ente.

Vediamo in dettaglio le varie casistiche che potrebbero presentarsi ed una possibile implementazione:

UC-0 (Happy path): Emissione e pagamento avviso bianco

Questo caso d'uso dettaglia i passi necessari a predisporre gli avvisi di pagamento cartacei per i quali non sono noti importo, scadenza e debitore.

1. L'EC predispone dei numeri avviso dedicati al pagamento di uno specifico sevizio (eg. le sanzioni del CDS) con associate nell'APA delle Posizioni Debitorie indeterminate, aventi cioè importo, scadenza e debitore sconosciuti. Tutti gli altri parametri, come ibanAccredito, ibanAppoggio e datiSpecificiRiscossione, sono noti ed individuati dal servizio a cui sono dedicati.
2. L'EC stampa gli avvisi di pagamento bianchi associati ai numeri avviso individuati al passo precedente, ed aventi lo spazio dedicato all'importo in bianco ed un QrCode che codifica un importo pari a 0. Il formato dell'avviso può essere quello standard pagoPA oppure di altro formato concordato con pagoPA per consentire l'inserimento di altre informazioni specifiche del servizio gestito (eg targa, luogo, importi ridotti, etc..).
3. L'incaricato dell'EC compila manualmente l'avviso nelle sue parti mancanti, in particolare dell'importo, e consegna l'avviso al cittadino.
4. L'incaricato dell'EC effettua l'inserimento dei dati dell'avviso emesso nei sistemi dell'Ente, aggiornando la Posizione Debitoria indeterminata ad esso associata se non ancora pagata che diventa cosi una posizione debitoria attualizzata.
5. Il cittadino può effettuare il pagamento dell'avviso come previsto dalle SANP.

UC-1: Pagamento di avviso bianco associato ad una Posizione debitoria indeterminata

Questo caso d'uso gestisce lo scenario di pagamento di un avviso bianco prima che la posizione debitoria ad esso associata sia stata aggiornata con l'importo dovuto, ovvero durante il periodo che intercorre tra i punti 3 e 4 dell'UC-0

1. Vedi UC-0
2. Vedi UC-0
3. Vedi UC-0
4. Il Soggetto versante si presenta presso il PSP per il pagamento dell'avviso bianco debitamente compilato dall'incaricato del comune.
5. Il PSP individua i dati idDominio e numeroAvviso tramite inserimento manuale o scansione del QRcode.
6. Il PSP effettua l'operazione VerificaRPT a cui l'EC, trovando nell'APA la posizione indeterminata, risponde con esito KO, indicando il codice di errore PAA_VERIFICA_RPT_IMPORTO_LIBERO
7. Il PSP, ricevendo l'errore PAA_VERIFICA_RPT_IMPORTO_LIBERO richiede l'inserimento manuale dell'importo da corrispondere.
8. Il PSP esegue l'operazione AttivaRPT con l'importo fornito dall'utente, .
9. L'EC attiva l'RPT, utilizzando importo e eventualmente i dati del versante e debitore comunicati dal PSP nella richiesta di attivazione e rispondendo con esito OK.
10. Il PSP esegue la riscossione dell'importo rilasciando la ricevuta al versante.
11. PSP ed EC scambiano RPT ed RT come previsto dalle specifiche pagoPA.
12. Alla ricezione dell'RT positiva, l'EC attualizza la Posizione Debitoria con l'importo pagato.

UC-1.1: Variante UC-1, pagamento senza verifica

Il PSP può richiedere l'importo all'utente ed effettuare direttamente l'operazione di AttivaRPT senza la verifica riconoscendo l'avviso come libero e richiedendo l'importo da pagare senza attendere l'esito della verifica.

UC-1.2: Variante UC-1, pagamento senza riscossione

Lo scenario in questione copre il caso in cui a valle dell'attivazione non si perfezioni la riscossione. Questo può accadere ad esempio se l'utente si accorge di aver attivato un importo errato e rinuncia al pagamento. La transazione si completa con l'emissione di una RT negativa, ovvero con codiceEsitoPagamento=1. Alla ricezione dell'RT di pagamento non eseguito, l'EC non attualizza la Posizione Debitoria associata, consentendo successivamente di ritentare il pagamento ad importo libero.

UC-2: Pagamento avviso ad importo libero associato ad una RPT annullata, scaduta, pagata

Lo scenario non presenta differenze dal pagamento di una avviso ordinario.

UC-3: Pagamento avviso ad importo libero associato ad una RPT indeterminata con validazione dell'importo

Questo scenario copre il caso in cui l'EC applichi delle logiche di validazione all'importo comunicato dal PSP in sede di AttivaRPT determinando se sia compatibile con il servizio oggetto del pagamento.

Nel caso in cui l'importo non risulti coerente, l'EC può rifiutare l'attivazione indicando il codice di errore PAA_ATTIVA_RPT_IMPORTO_NON_VALIDO già previsto dalle SANP.

Modifiche richieste alle API pagoPA

• Aggiungere nell'operazione VerificaRPT la possibilità di restituire l'errore PAA_VERIFICA_RPT_IMPORTO_LIBERO

Note

Pagamento importi ridotti

Alcune sanzioni del CDS prevedono una riduzione di importo se pagate entro 5 giorni dalla data di contestazione o notifica. Nel caso delle sanzioni non contestate immediatamente, ma notificate, la posizione debitoria è a sistema al momento della consegna della notifica, ma la data con cui determinare l'importo corretto può essere sconosciuta al momento del pagamento.

Una soluzione è quella di emettere tanti avvisi quanti sono i possibili importi e lasciare al pagatore la scelta dell'avviso corretto da pagare. L'EC, quando è nota la data di notifica, verifica che l'avviso pagato dall'utente fosse quello corretto.

La soluzione proposta può essere utilizzata anche per semplificare questo scenario: l'ente può infatti emettere un avviso con associata una pendenza indeterminata, lasciando all'utente la scelta dell'importo da pagare che l'EC. Se poi l'Ente acquisisce la data di notifica prima del pagamento, attualizza la Posizione Debitoria riconducendo lo scenario al caso d'uso tradizionale.

In aggiunta, si potrebbe consentire all'EC di indicare gli importi possibili, di modo che il PSP possa facilitarne l'inserimento all'utente:

<esitoVerificaRPT>
  <esito>KO</esito>
  <fault>
    <faultCode>PAA_VERIFICA_RPT_IMPORTO_LIBERO</faultCode>
    <fauitString>Pagamento di importo definito dall'utente.</faultString>
    <id>01234567890</id>
  </fault>
  <importi>
    <importo descrizione="Pagamento entro 5 giorni dalla notifica">70</importo>
    <importo descrizione="Pagamento entro 60 giorni dalla notifica">100</importo>
  <importi>
</esitoVerificaRPT>

Poste Italiane

La soluzione dovrebbe essere attuabile anche in caso di pagamento presso Poste Italiane, predisponendo sull'avviso un datamatrix che codifica un importo pari a 0.

[gammam]

@nardil direi che il nuovo processo di pagamento per i PSP all'interno della monografia possa gestire la casistica da te riportata.

In tale scenario il medesimo avviso di pagamento fà riferimento ad una posizione debitoria il cui ammontare può variare a seconda delle condizioni al contorno. L'avviso prevederà quindi tre opzioni di pagamento :

• pagamento scontato del 30%, se pagato entro 5gg dalla notifica
• pagamento dell'importo totale riportato nell'avviso se pagato entro 60gg dalla notifica
• pagamento con more se pagamento oltre i 60gg dalla notifica

Solitamente non essendo nota a priori la data di notifica, la data di scadenza delle opzioni di pagamento è puramente indicativa.

Attraverso la paaVerifyPaymentNotice verranno quindi proposte tutte le opzioni disponibili fino a quando non si verifichi uno dei seguenti eventi :

• viene notificata una ricevuta di pagamento, pertanto la posizione debitoria risulta chiusa e nessuna opzione di pagamento disponibile.
• l'EC diviene in possesso della data di notifica, pertanto può aggiornare le opzioni di pagamento inserendo la data di scadenza corretta per ognuna delle opzioni.

[nardil]

Analizzando piu' dettagliatamente le nuove specifiche, avrei bisogno di un chiarimento sul come viene gestito lo scenario degli avvisi bianchi elevati tramite bollettario cartaceo, ovvero di cui non sono noti a priori importo e scadenza.

Il bollettario presenta prestampati un numero avviso ed il QrCode, quest'ultimo con codificato un importo fittizio. Sui sistemi, all'avviso e' associata una posizione debitoria senza importo o scadenza. L'idea e' che, nel pagamento ad iniziativa psp dell'avviso, sia il cittadino a comunicare l'importo da corrispondere individuandolo sull'avviso, realizzando di fatto quello che gia' accade negli scenari tradizionali.

Come si realizza questo scenario con le nuove API?

[andreapasuch]

Ciao @nardil quanto descritto in https://docs.pagopa.it/sanp/casi-duso/pagamento-spontaneo-presso-psp potrebbe rispondere all'esigenza di avviso ad importo libero?

[nardil]

Ciao @andreapasuch

Sembra di si: riepilogando si vuol coprire il caso di sanzione elevata in strada con strumenti non digitali, ovvero con compilazione manuale del verbale. Nella prima ipotesi, il bollettario presentava prestampati Numero Avviso e QRCode, ma possono passare diversi giorni prima che la posizione associata sia presente nell'APA, rendendone impossibile il pagamento da PSP con il classico modello 3.

La soluzione potrebbe essere quindi di lasciare il bollettario privo di Numero Avviso e QRcode prestampati, evidenziando il fatto che non si tratta di un Avviso pagabile con un modello 3, ma come spontaneo. Se questa fosse la giusta direzione, si dovrebbe chiarire quali sono i criteri che un servizio deve soddisfare per poter essere incluso nel catalogo e qual'e' l'iter da seguire per farlo.

[andreapasuch]

Nel caso di pagamento spontaneo i parametri da passare per il calcolo e creazione della posizione debitoria potranno essere definiti dall'EC che vuole attivare il servizio, naturalmente in compartecipazione con PagoPA, in modo da evitare una proliferazione sconsiderata di servizi molto simili tra di loro. Quindi per definire un servizio la procedura è quella di far richiesta a PagoPA tramite i canali classici per il momento (Tech o Operations), il futuro prevede il passaggio tramite l'Area Riservata, che a breve sarà disponibile.