[RFC] faultCode PAA_PAGAMENTO_IN_CORSO

[lucagargiulo]

Fra i possibili faultCode previsti per la paVerifyPaymentNotice documentati nella tabella FaultCode EC è elencato anche PAA_PAGAMENTO_IN_CORSO: in quale occasione dovrebbe verificarsi?

Mi aspetto che sia direttamente il nodo a notificare al PSP se c'è un pagamento in corso per il numero avviso specificato (esiste un paymentToken attivo per quel numero avviso), mentre per l'EC l'operazione di pagamento o è possibile (pagamento in attesa) o è stato già terminata (è arrivata la ricevuta).
Anche se è stato attivato un pagamento modello 1 è sempre il nodo che genera il paymentToken, quindi sarà sempre il nodo a gestire lo stato pagamento in corso.

Stesso ragionamento farei per la paGetPayment.

[ghost]

Ciao Luca.

E' assolutamente corretta la tua assunzione. Il nodo con il nuovo modello è in grado di gestire il pagamento in corso e il pagamento duplicato, senza arrivare a fare la richiesta all'Ente Creditore.

Il nodo per fare questo controllo si basa però esclusivamente sullo IUV.

L'unico motivo per cui è stato mantenuto questo faultCode è per permettere a chi gestisce con IUV diversi anche il modello attivato presso all'EC di comunicare alla piattaforma esiste un pagamento in corso.
Se l'EC gestisce con un unico IUV entrambi i modelli il problema non si pone e l'Ente può non gestire quel faultCode.

Lascio aperta la issue per eventuali controdomande.

[lucagargiulo]

Ciao Fabio, grazie per la risposta, ma purtroppo mi ha fatto sorgere altri dubbi.
In effetti a modello 3 nuovo le primitive si basano sul numero avviso, mentre per il modello 1 una RPT trasporta uno IUV, che potrebbe essere indipendente dal numero avviso, ma supponiamo pure che per convenzione un avviso contenga uno iuv e che per una posizione si rilascino più avvisi, uno per ogni possibile pagamento.
Prendiamo come esempio un pagamento pagabile in 2 rate con iuv1 e iuv2 o in unica soluzione con iuv0. Supponiamo che ad ognuno dei 3 pagamenti sia associato un numero avviso distinto avv0, avv1 e avv2.
Quando cerco di pagare la rata 1 a modello 3 specifico avv1 e iuv1 e pagoPA mi genera un paymentToken1 per avv1. Posso immaginare che se a modello 1 cerco di pagare iuv1 pagoPA si accorge che è legato ad avv1 per cui esiste in vita paymentToken1 e impedisce il tentativo.
Il legame fra iuv1 e avv1 però a modello 3 è esplicito mentre a modello 1 è implicito, basato sulla convenzione che avv1 contiene iuv1, nella RPT non c'è un riferimento all'avviso, c'è solo lo iuv.
Ma anche facendo affidamento sulla convenzione, se cerco di pagare a modello 1 in unica soluzione parte una RPT con iuv0. Come fa il nodo a capire che iuv0 e iuv1 sono collegati alla stessa posizione debitoria? In realtà in questo caso anche se cerco di pagare avv0/iuv0 da un altro PSP ho 2 pagamenti simultanei con 2 paymentToken diversi ed entrambi potrebbero venir accettati se l'ente non blocca la posizione per conto suo (ma non dovrebbe farlo perchè non gestisce il paymentToken e finchè non arriva la ricevuta non sa e non deve sapere cosa sta succedendo). L'ente dovrebbe infatti rispondere ad ogni paGetPayment relativa ad un avviso senza modificare il suo stato finchè non arriva una ricevuta positiva che lo avvisa che quello iuv è stato pagato.
Se associo tutti i pagamenti allo stesso numero avviso risolvo il problema per i pagamenti modello 3 contemporanei, ma mi rimane per il pagamento modello 1 contemporaneo al pagamento modello 3 sempre perchè a modello 1 uno iuv non mi identifica un numero avviso.
Inoltre avrei un problema gestendo una sola opzione di pagamento perchè se devo offrire una sola opzione non posso far scegliere all'utente se preferisce un pagamento in unica soluzione o un pagamento a rate con un solo avviso.

[lucagargiulo]

Provo ad ipotizzare una soluzione.
A modello 1 per un pagamento multi-ente vengono inviate 2 RPT e al carrello viene assegnato un identificativo che contiene il numero avviso. Il codiceContestoPagamento (CCP) delle RPT deve contenere l'id carrello e quindi il numero avviso. Per una richiesta di pagamento multi-ente quindi il nodo può recuperare dalle RPT il numero avviso e verificare se per quell'avviso esiste un paymentToken in vita.
Si potrebbe standardizzare il CCP anche per le RPT di pagamenti modello 1 mono-ente in modo che contengano sempre il numero avviso nel caso che il pagamento sia esposto anche ai PSP.
Ovviamente nulla vieta ad un EC di farlo già adesso, ma non mi risulta che ci sia un'indicazione precisa di come generare il CCP, a parte il requisito che il CCP sia univoco per cui il nodo non può attualmente fare ipotesi sulla semantica del contenuto del CCP.
Va quindi documentato in modo preciso nelle specifiche come generare il CCP di una RPT in modo che il nodo possa estrarre da esso il numero avviso.
Inoltre dovrei a questo punto usare un unico numero avviso per posizione debitoria a cui sono associati tutti gli iuv: in questo modo quale che sia lo iuv che sto cercando di pagare l'intera posizione (e quindi anche tutti gli altri iuv) viene bloccata: questo significa anche che devo poter restituire più opzioni e non solo una per consentire all'utente di scegliere quale iuv pagare.

[ghost]

Ciao Luca,
faccio una doverosa premessa: i ragionamenti che stai facendo mi sembrano assolutamente corretti, ma li astrarrei da modello 3 e modello 1.

Questo perché le problematiche mi sembrano le medesime su entrambi i modelli e sono più legate alla gestione della posizione debitoria che al modello di pagamento utilizzato. Dal punto di vista tecnico, in questo momento, la piattaforma non ha evidenze di correlazione fra IUV distinti in relazione a rate (o altro "fattore di correlazione").

Quindi nell’esempio che hai fatto:

• IUV0 = rata unica
• IUV1 = rata1
• IUV2 = rata2

se un cittadino prova a paga la rata1 (IUV1) la piattaforma non ha modo di bloccare lo IUV0 su un tentativo di pagamento "immediatamente prossimo": questa gestione rimane tuttora in carico all’Ente Creditore (come nel "precedente" modello 3). Consideriamo tale casistica comunque marginale, e che merita un approfondimento nelle future evoluzione della piattaforma (già in roadmap interna). I fault code PAA_PAGAMENTO_IN_CORSO e PAA_PAGAMENTO_DUPLICATO aiutano l'Ente Creditore a gestire anche casistiche di questo tipo.

E' quindi corretta la tua affermazione:

In realtà in questo caso anche se cerco di pagare avv0/iuv0 da un altro PSP ho 2 pagamenti simultanei con 2 paymentToken diversi ed entrambi potrebbero venir accettati se l'ente non blocca la posizione per conto suo.

Per quanto riguarda invece il comportamento del nodo sull' “estensione del modello 1” ( https://docs.italia.it/italia/pagopa/pagopa-specifichepagamenti-docs/it/v2.5.0/_docs/sezione3-specifiche-tecniche/3_01_04_multi_beneficiario.html) l’obiettivo di alcune delle assumptions che trovi in SANP sono orientate proprio al permettere di introdurre controlli sullo IUV in termini di “pagamento in corso” e “pagamento duplicato”. Per quanto riguarda la documentazione stiamo lavorando sull’esplicitare meglio alcuni comportamenti.

Un ultimo appunto: è stato eliminato il concetto di “opzioni multiple di pagamento” per la difficoltà di gestione lato Ente Creditore. Per permettere infatti una gestione corretta delle opzioni multiple (che alla fine è quello che stai scrivendo tu) ci sarebbero due alternative:

• restituire sempre tutte le opzioni con i relativi "fattori di correlazione" e demandando la gestione al Nodo (ma complicherebbe la gestione/aggiornamento delle opzioni stesse)
• introdurre un nuovo identificativo “in testa” agli IUV (come "fattore di correlazione").

Ti chiedo cortesemente di darmi un feedback su quanto ti ho scritto.

Lascio inoltre aperta questo discussione perchè:

• potrei non aver inteso perfettamente quello che hai scritto (ti chiedo quindi di indicarmi se sono andato “out-of-scope” con le risposte)
• mi sembra una discussione molto costruttiva

[lucagargiulo]

Ciao Fabio,
la soluzione che io ho proposto si basa su un requisito (che al momento non è soddisfatto):

• per una posizione debitoria esiste un unico numero avviso: tutti gli iuv generati per consentire il pagamento della posizione sono correlati all'unico numero di avviso

Il requisito va soddisfatto sia a modello 3 che a modello 1: a modello 3 i messaggi scambiati consentono già di supportare agevolmente il requisito, a modello 1, è necessario introdurre una correlazione fra gli iuv: per le posizioni multi-ente il CCP, per come è costruito, contiene già il numero avviso, l'idea potrebbe essere estesa anche alle posizioni mono-ente.
In questo modo il nodo potrebbe bloccare la posizione (e quindi tutti gli iuv correlati) e l'EC non dovrebbe gestire lo stato in pagamento.
Conseguenze: a modello 3 la paVerifyPayment deve restituire tutte le opzioni di pagamento valide in quel momento (non tutte le opzioni, solo quelle valide).

Commento puntualmente alcune tue frasi per chiarire meglio alcuni aspetti

Per quanto riguarda invece il comportamento del nodo sull' “estensione del modello 1” l’obiettivo di alcune delle assumptions che trovi in SANP sono orientate proprio al permettere di introdurre controlli sullo IUV in termini di “pagamento in corso” e “pagamento duplicato”. Per quanto riguarda la documentazione stiamo lavorando sull’esplicitare meglio alcuni comportamenti.

Certo, ma è richiesto solo per i pagamenti multi-ente , ma basterebbe estendere le assumptions sul CCP a tutti i pagamenti modello1 (ovviamente richiede anche che esista un numero avviso, che per un pagamento modello1 spontaneo non sarebbe tecnicamente necessario)

è stato eliminato il concetto di “opzioni multiple di pagamento” per la difficoltà di gestione lato Ente Creditore

Per restituire un'unica opzione di pagamento lato EC è necessario eseguire logiche che dipendono dal tipo di servizio di pagamento, sono le stesse logiche che dovrei eseguire per restituire opzioni multiple, solo che alla fine devo sceglierne una, fornendo alla fine meno supporto all'utente: in sintesi restituire una sola opzione semplifica la vita solo nel caso in cui ne esiste di fatto una sola, restituire tutte le opzioni valide non crea difficoltà ulteriori, anzi.

restituire sempre tutte le opzioni con i relativi "fattori di correlazione" e demandando la gestione al Nodo (ma complicherebbe la gestione/aggiornamento delle opzioni stesse)

A modello 1, la modalità con cui si consente all'utente di eseguire il pagamento è un problema dell'EC, l'uso delle opzioni potrebbe essere peraltro un modo intelligente per guidare l'utente; a modello 3 lo opzioni sono importanti per veicolare, tramite il PSP, le informazioni disponibili all'utente.
Creare preventivamente e mantenere aggiornate le opzioni è un'implementazione possibile, ma non l'unica.
Una considerazione importante, secondo me, è che la generazione delle opzioni richiede la conoscenza di un contesto di pagamento dinamico. Un caso emblematico è quello delle sanzioni, in cui la data di scadenza del pagamento dipende dalla data di notifica dell'avviso di pagamento all'utente: in questo caso la data di notifica è un dato che va acquisito dal sistema di pagamento dell'EC da una fonte esterna al sistema stesso. Alla ricezione della paVerifyPaymentNotice il sistema di pagamento dovrebbe interrogare la fonte esterna per acquisire la data di notifica e, se disponibile, usarla per generare l'unica opzione di pagamento valida e certa in quel momento; se la data di notifica non è disponibile dovrà invece restituire un'unica opzione con "importo ANY" e data di scadenza non nota o più opzioni con i diversi importi (di cui l'ultimo GT per via degli interessi) per lasciare all'utente la scelta più corretta in base al contesto a lui noto (l'utente sa quando ha ricevuto la notifica).
L'alternativa alla gestione dinamica delle opzioni è la gestione dell'aggiornamento delle informazioni che servono al sistema di pagamento per determinare le opzioni disponibili: nel caso delle sanzioni un attore esterno deve notificare al sistema di pagamento la disponibilità di una data di notifica con cui il sistema di pagamento aggiorna le varie date di scadenza, quando arriva la paVerifyPaymentNotice il sistema di pagamento sarà in grado di determinare l'opzione corretta.
Se quando arriva la paVerifyPaymentNotice la scadenza è ancora indeterminata si ricade nel caso precedente.
Si tratta di architetture diverse, ma in entrambi i casi è necessaria la collaborazione di un sistema esterno. A tipi di pagamento diversi dalle sanzioni si possono applicare considerazioni analoghe, ma in tutti i casi o viene gestito un evento che causa una modifica dei dati che il sistema di pagamento usa per la generazione delle opzioni o si usa un'architettura che consente la cooperazione a run-time fra sistema di pagamento e sistemi esterni.
Però anche gestendo una sola opzione ho le stesse necessità.

introdurre un nuovo identificativo “in testa” agli IUV (come "fattore di correlazione").

Se il numero di avviso è unico per una posizione debitoria questo diventa il "fattore di correlazione": nel modello 3 c'è già, nel modello 1 bisogna imporre la costruzione del CCP in modo che contenga il numero avviso.

Se si abbandona l'ipotesi di gestire un unico numero avviso per la posizione debitoria, il nodo con il paymentToken può bloccare il singolo pagamento ma non l'intera posizione. Probabilmente è improbabile che qualcuno cerchi di pagare due avvisi distinti per la stessa posizione debitoria (quasi) contemporaneamente, però tecnicamente diventa possibile.
La gestione del pagamento in corso lato EC peraltro ha delle controindicazioni, perchè se a fronte di una paGetPayment il pagamento non viene finalizzato (per vari motivi) il nodo riceve un esito negativo, ma l'EC non viene notificato quindi deve mantenere il pagamento bloccato fino a che riceve la ricevuta positiva o scade l'expirationTime massimo (il default di 30' del nodo o il PSP può chiedere un tempo maggiore? e se il default dovesse cambiare?) Quindi l'utente prima di ritentare il pagamento dovrebbe aspettare la scadenza del token.

[andreapasuch]

Ciao Luca,
ho reso la issue enhancement per la richiesta di un unico numero avviso per una posizione debitoria.
Analizziamo la questione e ti teniamo aggiornato.

[ghost]

Aggiornamento:

La gestione dei FaultBean è ora riportata qui:

https://docs.pagopa.it/gestionedeglierrori/struttura-degli-errori/fault-bean