menu di navigazione del network

Cosa avviene fuori dal perimetro. Un caso reale

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…

3 Mi Piace

Non posso che essere d’accordo in tutto e per tutto con te: PagoPA è destinato a fallire se non viene regolamentato, proceduralizzato e standardizzato in tutti i suoi aspetti rilevanti, anche al di fuori del perimetro stretto già gestito . Resto convinto che nei Comuni si resterà ancora per molto ancorati agli F24 per le entrate tributarie, del resto se sia come adattamento dei gestionali che come perdita di tempo per la duplice riconciliazione dell’entrata (come ragioneria e come tributi) il PagoPA è antieconomico si resiste per quanto si può alla transizione, mi sembra anche ovvio…

Non leggerò mai un post così lungo :slight_smile: Anche se ti voglio bene @frantheman

Siccome TVB anch’io, sunto: avviare un pagamento modello 1 da un portale terzo costa quanto un’automobile media, perche’ non esiste alcuna linea guida al riguardo e ognuno fa come gli pare :slight_smile:

Grazie per il sunto, è verissimo! Concordo!

Mi dispiace se non sempre un’analisi con intento costruttivo riesce a rientrare nei parametri di lunghezza del comunicare moderno, ma è anche vero che qui siamo un forum specialistico e non su tik tok o instagram.

A questo punto, rivolgo al gruppo PagoPA spa (@Giuseppe_Virgone, @Mauro_Bracalari) e anche a @nardil che consosce bene regole e perimetro pagoPA una domanda.

Sarebbe possibile prevedere l’invocazione di WISP (o altro) per avviare un pagamento online e gestire i riscontri, da un luogo che non sia né il partner tecnologico né il PSP? Ci sono controindicazioni tecniche?

Lo scenario e’ quello in cui un servizio online esposto al cittadino genera un’esigenza di pagamento, contatta il PT/IT/Sistema dei pagamenti dell’EC, crea il pagamento dovuto con IUV e tutto quanto e poi consente all’utilizzatore finale di avviare il pagamento integrato nella procedura che sta seguendo (es.: iscrizione a un concorso, pagamento di diritti di segreteria ecc.).

Se fosse il nodo dei pagamenti SPC a orchestrare l’avvio del pagamento si eviterebbe la complessità di far interagire i tanti possibili servizi online con i tanti possibili PT/implementazioni di sistemi di pagamento in assenza di uno schema di interoperabilità.

Grazie per l’attenzione.

1 Mi Piace

ricordo quando, ai corsi di formazione, grossi esperti che magari ora siedono ai posti di comando ci dicevano “dovete smetterla di usare applicativi verticali che non si integrano e non parlano col mondo esterno…”.

e che bei tempi quelli in cui per attivare un gateway bancario per pagamenti con carta di credito, bastava una telefonata alla banca di tesoreria e qualche decina di righe di codice in php…

e’ che in realta’ gli applicativi attuali parlare parlano, solo che ognuno parla la lingua sua. e, come gli umani, non tutti sono portati a imparare lingue straniere (talvolta nonostante costosissimi corsi di lingua)…

Seconda proposta/richiesta per PagoPA spa (@Giuseppe_Virgone, @Mauro_Bracalari) e per l’esperto @nardil.

Sarebbe possibile individuare e imporre un linguaggio e un’interfaccia standard per comunicare con il sistema dei pagamenti (del PT, dell’IT ecc.) per caricare un pagamento dovuto e gestire alcune interazioni di base (cancellare pagamento, ottenere notizie su stato, ricevere notizia in tempo reale del pagamento, ricevere copia della RT ecc.)? Cosi’ qualsiasi applicativo e’ in grado di creare un pagamento dovuto, basta fornirgli URL e credenziali di accesso ai servizi esposti dal gestore dei pagamenti.

Probabilmente si potrebbe partire da quanto ipotizzato per l’avvisatura digitale. Naturalmente si prevederanno campi nell’XML e nel JSON adottato per veicolare informazioni aggiuntive.

Si potrebbbe poi pensare che non appena un EC aderisce al mondo PagoPA, presenza e funzionamento di queste interfacce vengano testati (da un sistema automatico, ovviamente): ci si fa dare l’URL del servizio; si crea un pagamento dovuto; si prova a pagarlo col metodo richiesto nella richiesta di un paio di post sopra cosi’ si prova anche quello, con un pagamento portato a termine e uno abbandonato prematuramente; si verifica di ricevere le giuste risposte e la RT…

EDIT (20/10/2020): giusto per sgombrare il campo da equivoci, la richiesta non riguarda imporre ai player ITC come progettare o implementare i propri software o strumenti, ma solo di esporre delle interfacce interoperabili, un po’ come avviene in altri casi, tipo lo scambio di messaggi fra amministrazioni tramite interoperabilità di protocollo.

2 Mi Piace

intervengo solo per chiarire che non sono nel team pagoPA o AgID, ma solo un utente entusiasta :slight_smile:

1 Mi Piace