Penso di aver letto ormai almeno una decina di volte la nuova monografia e ormai mi sono reso conto che rispetto al passato è cambiato tutto, non solo rispetto al vecchio modello ma anche rispetto alla prima versione della monografia.
La prima monografia è stata in consultazione per un mese, io personalmente non ho segnalato nulla a PagoPA perché le modifiche introdotte erano condivisibili e non costituivano cambiamenti particolarmente impattanti, introdotti invece dalla versione 2, su cui però non è stata aperta nessuna consultazione. Peraltro, a mio avviso, le consultazioni dovrebbe essere realmente pubbliche, nel senso che la discussione dovrebbe essere accessibile pubblicamente (al limite previa registrazione degli interessati) con la possibilità di discutere le varie proposte.
Di seguito evidenzio alcuni dei principali aspetti che meritano attenzione.
Terminologia: tutto in inglese, ma non è sempre una traduzione dei vecchi nomi in italiano, che comunque non vengono mantenuti neanche quando sarebbe stato possibile.
Colloquio fra i diversi attori: prima la gestione della comunicazione era separata dalla semantica del contenuto, venivano scambiati dati contenuti in messaggi tecnici (RPT, RT ecc) che venivano trasportati via SOAP ma risolti dai vari attori, adesso la semantica è inclusa nel messaggio SOAP stesso.
Quindi RPT ed RT non ci sono più nel modello 3, ma rimangono nel modello 1 per il momento e anche questo ha un impatto: ora i diversi attori si scambiano messaggi diversi in modo diverso a seconda di come un utente sceglie di pagare una posizione debitoria, è ancora possibile pagare la stessa posizione debitoria usando indifferentemente un modello o l’altro? Ad esempio per una posizione rateizzata, posso pagare una rata dal portale dell’ente creditore ed un’altra presso un PSP? Il pagamento multi-beneficiario funziona con il modello 1? A mio avviso no, servono nuove API per il modello 1, ma la possibilità per un soggetto di scegliere come pagare non era uno degli aspetti distintivi di pagoPA?
Pattern di comunicazione: prima era tendenzialmente asincrono, ora è sincrono, con diverso impatto sugli SLA da rispettare.
Gestione delle rate: prima pagoPA non sapeva della presenza di piani rateali, una rata era un pagamento pagoPA come gli altri e non era correlato alle altre rate o ad una posizione debitoria pagabile in un’unica soluzione o a rate a seconda delle scelte dell’utente. Era l’ente che a livello di singolo gestionale o di intermediario tecnologico si occupava della gestione delle rate.
Ora però sembra che ad un avviso (e quindi ad uno IUV) possano essere collegate tutte le rate, quindi ad uno IUV verrebbero associati più pagamenti. Per me questo è decisamente un breaking change con impatto sostanziale e con aspetti che servirà analizzare in modo accurato per capire se e come il tutto può funzionare.
Ruolo dello IUV: prima era l’elemento unificante che identificava un pagamento in tutto il suo ciclo di vita, ora forse rimane più qualcosa che identifica l’intera posizione debitoria nei confronti dell’utente. Se analizziamo in dettaglio il contenuto dei messaggi SOAP possiamo notare che lo IUV non viene usato per correlare la response della paGetPayment e la request della paSentRT o meglio, i due messaggi sono ora correlati internamente dal nodo: può farlo perchè ora tutti i messaggi sono sincroni, quindi non è più necessario sincronizzare la comunicazioni con un correlation-token specifico. Il token di correlazione vien invece spostato sulle singole voci di pagamento (idTransfer) perchè serve per gestire la riconciliazione delle singole voci di pagamento (disponibili presso attori diversi nel caso dei pagamenti multi-iban). Anche nel colloquio con i PSP pagoPA usa un payment-token e non lo IUV per correlare richiesta ed esito del pagamento oltre che per gestire richieste concorrenti.
Tutti questi cambiamenti modificano sostanzialmente la gestione del pagamento con un impatto che andrà attentamente analizzato sotto diversi aspetti.
Purtroppo la monografia non è abbastanza dettagliata per chiarire tutti i dubbi e gli asset informatici disponibili che descrivono la nuova API (wsdl e xsd) forniscono dettagli ulteriori, ma lasciano spazio ad interpretazioni non essendo documentati in modo puntuale.
Visti i tempi previsti per portare in produzione il nuovo modello l’esigenza di disporre di informazioni tecniche precise è abbastanza pressante. L’auspicio è che le nuove SANP 2.4 chiariscano tutti i dubbi, soprattutto che siano molto chiari gli scenari d’uso da supportare visto che in passato AGID ha spesso introdotto nelle specifiche funzionalità che non sono mai state realizzate (gestione delle revoche e degli avvisi telematici, ma anche pagamenti modello 3 con più voci non hanno mai visto la luce).
Mi riprometto di approfondire su questo post i vari aspetti man mano che riesco ad ottenere una visione più chiara sui singoli punti, e ringrazio fin d’ora chiunque possa fornire il suo contributo in tal senso.