In più occasioni ho sottolineato come la standardizzazione delle interazioni fra software e sistemi che partecipano all’intero percoso di vita di un pagamento elettronico tramite la piattaforma abilitante PagoPA sia interamente concentrata sul dialogo col nodo dei pagamenti SPC, mentre per le inevitabili ulteriori interazioni fra le altre compnenti del sistema complessivo vige piena autonomia (che diventa spesso anarchia).
Eccomi con un’esperienza reale.
Stiamo dematerializzando l’intero processo di gestione della TARI, dalle istanze alla rendicontazione degli incassi, ovviamente appoggiandosi a PagoPA per i pagamenti.
Mi concentro su un aspetto di dettaglio relativo all’avvio del pagamento.
Il progetto prevede di esporre al contribuente TARI il dettaglio della sua posizione. Questo si ottiene, in modo quasi obbligato, “aprendo” parte del DB del software di gestione dei tributi all’utente tramite una vista via web accessibile con autenticazione SPID/CIE. L’abc dell’orientamento all’utente impone di consentirgli di avviare da questa vista web anche il pagamento di quanto dovuto (questo in aggiunta alla pagina dei pagamenti pagoPA generici, esposta sul sito web del Comune, che comunque non è in grado di fornire informazioni di dettaglio specifiche sul debito se non la stringata causale).
Tecnicamente si tratta di un “processo di pagamento attivato presso l’ente creditore” (paragrafo 2.1 delle SANP, con la piccola differenza che lo IUV esiste già quando l’utilizzatore finale decide di avviare il pagamento). Qualcuno insiste a chiamare questo processo “modello 1”.
Bene, software dei pagamenti pagoPA (cioe’ il generatore e custode di IUV e posizioni) e software dei tributi sono diversi e di software house differenti.
Occorre stabilire un collegamento fra i due. Di fondo e’ necessario che la pagina dei tributi contatti il software dei pagamenti e gli fornisca qualche dato (IUV e CF) per invoare correttamente lo WISP. Questo e’ l’aspetto base. Ma già qui non esiste uno standard. Nel caso specifico, a dirla tutta, il PT non prevede proprio questa funzione: o avvii il pagamento dalla mia pagina o lo avvii presso un PSP (con l’avviso). Prima integrazione: le due software house devono concordare un linguaggio e un protocollo per comunicare e consentire all’utilizzatore finale di affacciarsi al WISP con i dati del pagamento da fare.
Ma non finisce qui: vanno gestiti i “ritorni”. Se tutto va bene, cioe’ se arrivo sul WISP e il pagamento va a buon fine, dovrei tornare sulla pagina dei tributi che, ricevuta la notizia del buon esito del pagamento, mostra quel pagamento come fatto (in attesa poi della RT, del riversamento e della riconciliazione per dare il pagamento come definitivametne acquisito). Oppure qualcosa può andare storto e il pagamento viene rifiutato dallo WISP o annullato dall’utente. Allora occorre tornare nuovamente sulla pagina dei tributi che deve essere consapevole del pagamento fallito e consentire di avviarlo nuovamente. C’e’ quindi una seconda integrazione: il software dei pagamenti è impostato per gestire i ritorni dal WISP sulle sue pagine esposte all’utilizzatore finale, non a quelle altrui. Anche qui allora occorre che le due software house stabiliscano un linguaggio e un protocollo di trasmissione: il software dei tributi insieme a IUV e CF invia due URL dinamici per il reindirizzamento dell’utilizzatore finale dopo l’interazione con il WISP, il software dei pagamenti usa l’uno e l’altro URL per reindirizzare l’utilizzatore fianle mentre contestualmente trasmette al software dei tributi qualche altro messaggio circa l’esito del pagamento.
Questo in linea di massima. Ci sono poi vari altri dettagli.
Fra i dettagli anche la RT che non riesce a transitare da un sistema all’altro (nel caso specifico c’e’ un ulteriore software che si frappone fra gestionali che generano esigenze di pagamento e PT, ma questa e’ un’altra storia…). Oppure la spinosissima questione del carrello PagoPA che ciascuno intende a modo suo (ma mai come descritto sulla documentazione ufficiale). Oppure ancora, più di base, il fatto che il softawre dei tributi vorrebbe crearsi lo IUV per conto proprio e poi comunicarli con agio al software dei pagamenti, mentre il sistema dei pagamenti vorrebbe prima avere i dati di pagamento e generare in tempo reale lo IUV (chunque dei due voglia cedre, è un’altra personalizzazione pure questa).
Per dare un’idea dei costi (che saranno poi pubblicati dove di dovere per i doverosi obblighi di trasparenza nell’uso dei soldi pubblici), solo questo dettaglio dell’avvio del pagamento da un software diverso da quello del PT costa, per le “personalizzazioni” da applicare a entrambi i software, almeno quattro o cinque volte il canone annuale di uso dei software, che, rigorosamente, sono SaaS.
La risposta tipo degli esperti è che “tutto questo è estraneo al perimetro di PagoPA”. Io insisto a dire che standardizzare o almeno dare indicazioni organizzative o funzionali per i vari componenti del sistema complessivo di pagamenti è assolutamente necessario. Non si può continuare a pensare che 20mila e piu’ pubbliche ammnistrazioni italiane si inventino ciascuna un suo metodo per avviare un pagamento (o per gestirne la scadenza ecc.). Non si puo’ continuare ad accettare che ogni operazione di digitalizzazione e semplificazioni debba portarsi dietro costi di “personalizzazioni”, per poi trovarsi in situazioni in cui la semplificazione non e’ possibile semplicemente perche’, fra i vari software che concorrono alla gestione di un processo articolato, nessuno si fa carico di qualche operazione necessaria, ritenendo che sia fuori dal proprio perimetro di competenza.
Sottolineo: la TARI non si gestirà e pagherà in tutti i circa 8000 comuni italiani? Tutti gli 8000 comuni italiani devono quintuplicare le spese?
Concludo: il processo sopra descritto parzialmente, ovviamente, è una scelta specifica che abbiamo fatto. Ce ne sono anche altre, valutate anche quelle ed evidentemente ritenute meno soddisfacenti, ma garantisco che qualsiasi altra soluzione vagliata comportava i suoi costi di personalizzazione…
Anche se ti voglio bene 