La ricevuta pagoPA su app IO: istruzioni per l’uso e divagazioni

Come raccontano le fonti ufficiali e conferma l’esperienza diretta, da qualche settimana tutte le ricevute dei pagamenti eseguiti tramite pagoPA arrivano su app IO, indipendentemente da come si sia avviato il pagamento. Un’indubbia comodità, ricevute tutte nello stesso posto, al sicuro e a portata di mano.

Fra le informazioni contenute nella ricevuta – disponibili sia nel corpo del messaggio IO sia come allegato in formato PDF – vi è anche l’oggetto del pagamento (o causale che dir si voglia). Io, per esempio, ho una ricevuta che riporta (gli asterischi sono per oscurare parzialmente il dato):

Oggetto: /RFB/222**43**995**19/***.40/TEXT//RFS/222**43**995**19/***.40

Un’indicazione ben poco significativa, in realtà. Ci si riconoscono, ripetuti due volte, l’identificativo IUV del pagamento e l’importo.

Scopo di questo post è:

• comprendere quale attore pagoPA ha controllo sul campo “oggetto” che compare su IO;
• valutare consapevolmente cosa è opportuno far comparire nell’oggetto;
• capire come intervenire nella pratica, dal punto di vista tecnico.

Prima di tutto, però, occorre un’introduzione sul funzionamento di massima di pagoPA.

Prima ancora una guida per la lettura per il post che è uscito più lungo del previsto: la parte operativa del post è nel paragrafo “Come intervenire“. Vai direttamente lì se hai fretta e/o non ti interessa il funzionamento di pagoPA con divagazioni varie.

pagoPA: cosa è e come si articola

pagoPa è una delle piattaforme previste dal Codice dell’amministrazione digitale che abilita i pagamenti elettronici verso la pubblica amministrazione e i gestori di pubblici servizi. È una piattaforma nel senso di insieme di regole di scrittura e comunicazione, con dati che sono distribuiti su un insieme di banche dati che comunicano fra loro con l’intermediazione di una componente informatica centralizzata.

Funzione di pagoPA è attivare e documentare, tramite scambio di informazioni in formato standard, i pagamenti verso la pubblica amministrazione. Il trasferimento “materiale” di denaro avviene tramite i “soliti” canali, anche combinati fra loro: bonifici, circuiti di carte di credito, app di pagamento ecc.

Attori e componenti informatiche di pagoPA sono:

• L’ente creditore (EC) che matura una esigenza di pagamento e che mette a disposizione della piattaforma il proprio archivio dei pagamenti in attesa (l’insieme delle posizioni debitorie);
• il partner tecnologico (PT, o intermediario) che rende disponibile all’ente creditore gli strumenti tecnologici per interfacciarsi con il mondo pagoPA;
• il nodo dei pagamenti SPC, la parte centrale dell’ecosistema in carico ala società pubblica PagoPA SPA, che smista il traffico e identifica gli attori;
• il prestatore di servizi di pagamento (PSP) – banca o simile – che, per sua vocazione, si occupa di trasferire denaro fra due soggetti e mette il suo sistema informatico in comunicazione con il Nodo;
• il debitore, cittadino e impresa, che è il soggetto che paga e che dovrebbe essere il destinatario, diretto e indiretto, dei benefici che derivano da implementazioni consapevoli e attente di pagoPA nelle attività degli altri attori.

Le regole che governano l’ecosistema pagoPA sono contenute nella specifiche attuative del nodo dei pagamenti (SANP), disponibili online con tanto di schemi di interoperabilità standard^[1]La standardizzazione delle comunicazioni è prevista solo per quelle che entrano, escono o passano dal Nodo. (primitive, nel linguaggio adottato da pagoPA) e in costante aggiornamento, anche sostanziale.

pagoPA: come funziona un pagamento

Per comprendere da dove arriva la ricevuta di pagamento ci si può concentrare sulla parte di processo che riguarda la parte di pagamento. Ci poniamo quindi nel caso comune in cui l’ente creditore ha creato il pagamento in attesa e ha “avvisato” il debitore tramite l’avviso di pagamento analogico^[2]L’avviso di pagamento “analogico” è ormai familiare, anche grazie alla veste grafica uniforme a livello nazionale, e riporta alcuni dei dati associati alla posizione debitoria. Il … Continue reading.

Il debitore si rivolge a un prestatore di servizi di pagamento^[3]Come lo raggiunge è accidentale: sportello fisico, sportello web, app di pagamento, mediazione della componente Checkout di PagoPA spa (ne parlo qui) ecc. e quanto avviene dopo è descritto nel seguente diagramma^[4]Il diagramma (sequence diagram) è tratto dall’ultima versione delle SANP; dall’alto in basso si percorre la sequenza delle interazioni fra gli attori del processo, descritte con una … Continue reading, che può essere interpretato intuitivamente:

Il PSP ricava dall’avviso ottenuto dal debitore il codice avviso (cosa pagare) e il codice fiscale del creditore (a chi pagare). Tramite il Nodo contatta l’ente creditore per avere conferma e farsi autorizzare al pagamento. Se l’ente creditore conferma il pagamento, trasmette alcuni dati essenziali fra cui l’importo^[5]L’importo potrebbe essere diverso da quello stampato sull’avviso, in ragione di sconti, interessi, spese variabili di notifica ecc. ) e la causale. Quando si paga online, per esempio tramite IO, la causale viene riproposta al debitore, anche per sua sicurezza. I dati forniti dall’ente creditore sono racchiusi in un file XML, che nelle prime versioni delle SANP – tuttora in uso – prendeva il nome di richiesta di pagamento telematico (RPT)^[6]Nelle SANP più recenti, che mantengono la tecnologia SOAP per le interazioni con il Nodo, i dati scambiati sono inseriti direttamente nella busta SOAP, con nomi dei tag diversi rispetto a quelli … Continue reading. Nel diagramma, che si riferisce alle nuove SANP, le informazioni sono veicolate nella response della primitiva paGetPayment^[7]Le nuove SANP parlano inglese.. A pagamento eseguito il PSP trasmette all’ente creditore, tramite il Nodo, altri dati in formato XML: la ricevuta telematica (RT), nome della precedente nomenclatura, che ripete i dati della RPT e ci aggiunge i dati della transazione di pagamento. Nelle SANP recenti i dati della ricevuta sono contenuti nella request della paSendRT.

Chi ha controllo sull’oggetto del pagamento?

Da quanto esposto circa il funzionamento di pagoPA, il dato dell’oggetto del pagamento proviene dall’archivio dei pagamenti in attesa dell’ente creditore e, tramite il partner tecnologico, è trasferito al PSP al momento del pagamento e poi confluisce nella ricevuta telematica (RT). IO sembrerebbe elaborare proprio la RT per comporre il messaggio di ricevuta e l’allegato PDF scaricabile.

Nelle regole dettate dalle prime versioni delle SANP (tuttora funzionanti), la causale è contenuta nel tag causaleVersamento della RPT (Richiesta di Pagamento Telematico) che l’ente creditore invia quando si avvia il pagamento di un avviso pagoPA. Questo viene ripetuto, si direbbe senza alterazioni, anche nel tag causaleVersamento contenuto nella RT. Bisognerebbe conoscere nel dettaglio il funzionamento di IO, ma è più che ragionevole che l’oggetto del pagamento che compare in IO non possa essere “migliore” di quanto esce dall’ente creditore al momento dell’emissione della RPT.

Ora, la stringa racchiusa nel tag causaleVersamento, nella pratica, è confezionata dal partner tecnologico, con logiche proprie. Non necessariamente questa coincide (anche solo parzialmente) con l’oggetto del pagamento inserito dall’ente creditore al momento della creazione del pagamento in attesa^[8]La creazione di un pagamento in attesa avviene, tipicamente, o tramite un’interfaccia web messa a disposizione del partner tecnologico oppure – per pagamenti massivi o comunque guidati da … Continue reading e/o con la stringa che descrive il pagamento sull’avviso analogico, alla voce “oggetto del pagamento”.

Talvolta, come sembrerebbe nel caso riportato in apertura di post, la causale veicolata tramite la RTP è una stringa alfanumerica del tutto tecnica, un codice non parlante (e, sempre limitatamente al caso esposto, anche poco significativa, visto che IUV e importo sono già tassativamente presenti in altri tag XML). Io ho osservato che il partner tecnologico del comune per il quale lavoro ignora del tutto l’oggetto inserito (manualmente o tramite altro software) come oggetto del pagamento e compone la causaleVersamento con una concatenazione di codice avviso e descrizione del servizio di pagamento generico (da tassonomia pagoPA).

Il controllo su quanto compare nella ricevuta che arriva su app IO, quindi, lo ha l’ente creditore che, in linea teorica, dovrebbe fornire indicazioni al partner tecnologico al riguardo. Nella pratica, si sa, gli enti non hanno (sempre) pieno controllo sulle scelte implementative dei fornitori ICT, ma quanto scrivere nei dati scambiati con il nodo dei pagamenti SPC può senz’altro essere oggetto di negoziazione, per garantire all’utente (debitore) la migliore esperienza possibile.

App IO, come del resto i PSP, non possono di certo andare oltre quanto contenuto nella RPT!

Qualcuno più attento potrebbe chiedersi come mai la ricevuta che si riceve dall’ente creditore (che solitamente arriva per e-mail o è depositata in qualche area personale alla quale si accede tramite SPID/CIE) contiene invece l’oggetto comprensibile e parlante, magari lo stesso che è presente sull’avviso analogico. E’ presto detto: l’ente creditore dispone, relativamente ai pagamenti in attesa, di più informazioni rispetto a quelle che transitano attraverso il Nodo^[9]Fra queste ci sono, per esempio, i dati per l’imputazione contabile (rendicontazione) dell’entrata. Può quindi integrare la ricevuta con dati ulteriori.. Vale la pena sottolineare che la ricevuta emessa dal PSP e riproposta da IO “attesta il pagamento eseguito” e non vale come quietanza liberatoria (che solo il creditore può rilasciare)^[10]Così è scritto in calce alla ricevuta PDF fornita da IO ed è corretto così: del resto ci si libera da un debito (quietanza liberatoria) solo dopo che il debitore abbia verificato che “tutto … Continue reading.

Nelle nuove SANP il percorso dell’oggetto del pagamento appare più tortuoso e passa da un soggetto all’altro, contenuto in tag con nomi che cambiano. Seguiamo – ma solo a uso dei nerd, gli altri vadano pure oltre – il percorso nel diagramma di sequenza riportato più in alto, partendo dalla prima freccia in uscita dall’ente creditore (EC):

E’ più che verosimile che IO riceva le informazioni per comporre il messaggio di ricevuta dal Nodo (stesso gestore PagoPA spa). Ammetto di non aver approfondito in quale punto del processo. Il concetto di fondo non cambia: qualunque cosa IO riceva dal Nodo, questa dipende da quanto il Nodo ha ricevuto dall’ente creditore (in uno dei tag evidenziati in grassetto nella tabella). Quindi, è compito dell’ente creditore, in accordo con il partner tecnologico scrivere qualcosa di sensato come oggetto del pagamento. Cosa si intende, però, per sensato?

Cosa è opportuno scrivere nell’oggetto (e come)

Nelle scelte su cosa far comparire nel campo “oggetto” e come e “quanto” scrivere, occorre, al solito, bilanciare esigenze di usabilità (chiarezza e immediatezza) e sicurezza per il debitore con le esigenze di protezione dei dati personali.

Su queste ultime mi concedo qualche riflessione, magari un po’ fuori tema, ma utile come spunto per le valutazioni:

• né il PSP né PagoPA spa (come gestore del Nodo dei pagamenti) hanno bisogno dell’oggetto dettagliato del pagamento per garantirne il buon esito: creditore e importo bastano e avanzano, il resto delle codifiche standard aiuta il creditore a riconciliare pagamento e debito e contabilizzare l’entrata;
• è comunque buona cosa che il PSP possa presentare al debitore l’oggetto di ciò che si appresta a pagare per una conferma finale a tutela della sicurezza e per evitare errori;
• uno dei rischi legati alla concentrazione di dati presso un soggetto è l’uso, non legittimo, che questi potrebbe farne. In altre parole chi detiene dati acquisiti per una certa finalità potrebbe essere tentato di avviare trattamenti eccedenti, che vanno oltre le finalità originarie, in assenza di una valida base giuridica. Ciò non deve preoccupare, perché nell’ambito di un rapporto legittimo e formalizzato, esistono gli strumenti per mitigare questo rischio: ci sono gli accordi, c’è il principio dell’accountability, ci sono i poteri ispettivi e sanzionatori degli organi preposti ecc.;
• ricordiamoci però anche che, fra i dati veicolati da RPT e RT c’è obbligatoriamente anche il cosiddetto “codice tassonomico“, che fa riferimento a una tabella elaborata da PagoPA spa che, per ogni tipologia di ente pubblico, individua numerosi “servizi di incasso”, cioè delle causali generiche del tipo “tassa sui rifiuti” o “tassa di partecipazione a un concorso”. L’oggetto del pagamento non è mai del tutto ignoto a PSP e Nodo dei pagamenti;
• un secondo rischio legato alla concentrazioni dei dati è l’accesso abusivo da parte di un soggetto non autorizzato, un furto di dati insomma. Per questo chi tratta dati personali deve dotarsi delle migliori tecnologie di protezione. Se, però, capita l’incidente, c’è poco da fare, non ci si può appellare al buon senso, all’accountability o alla forza persuasiva di qualche organo di controllo. Alla base di quel trattamento c’è un atto criminale, non ci si può ridurre a più miti consigli.

Ammetto che la parentesi di gusto GDPR non era preventivata, ma mi è parsa importante in corso d’opera. Del resto il “privacy-by-design” dovrebbe passare da valutazioni di questo tipo e questa dovrebbe essere l’essenza della protezione dei dati: non solo compilare e consegnare informative, effettuare nomine e dotarsi di procedure formalizzate, ma anche (e soprattutto) avere consapevolezza dei dati personali che girano e dei rischi^[11]Maneggiare dati personali è attività classificata rischiosa come trasportare materiale infiammabile. collegati.

Ammetto anche che, inizialmente, mi sarei sentito di consigliare, senza esitazione, di scrivere oggetti parlanti ma non troppo: ok “Prestazioni sanitarie” ma senza scendere nel dettaglio della specializzazione sanitaria; dove dal pagamento discendano benefici fiscali (deduzioni o detrazioni) la formula di rito che consente di accedervi e/o un riferimento normativo ecc. Adesso, invece, ammetto di essere più dubbioso e, addirittura, nutro dei dubbi anche sul codice tassonomico, anche perché non è chiarissima la sua finalità^[12]Qualificando il servizio di incasso, il codice tassonomico fornisce anche un’indicazione su quanti e quali processi della pubblica amministrazioni siano trasformati digitalmente, almeno per la … Continue reading : la contabilità pubblica è già standardizzata tramite il sistema SIOPE+ ed è possibile consultare i bilanci della pubblica amministrazione per voci di entrata/costo, se interessano le elaborazioni statistiche (per esempio: OpenBDAP | Scopri, Esplora e Analizza la Finanza degli Enti Territoriali (mef.gov.it)).

Come intervenire

Se lavori in un ente creditore aderente a pagoPA e sei curioso di sapere come appaiono le ricevute IO di pagamenti fatti verso il tuo ente, la via più pragmatica è fare una prova: crea un pagamento a tuo nome di importo minimo (anche un centesimo, dipende dal tuo partner), paga (l’ultima volta, tramite app IO e carta di credito la commissione era di 45 centesimi) e attendi il messaggio.

Se preferisci un approccio più teorico e metodico, puoi aprire il software dei pagamenti pagoPA, quello che di solito ogni partner tecnologico^[13]Non si è detto, ma un ente creditore può avere e, anzi, quasi sicuramente ha più di un partner tecnologico pagoPA. dell’ente mette a disposizione e ispezionare qualche ricevuta telematica che, mediamente, è proposta sia in formato PDF impaginato (con dati aggiuntivi) sia in formato XML (come dovrebbe essere stata ricevuta dal Nodo).

Ti interessa l’XML: cerca il tag causaleVersamento e vedi cosa c’è scritto dentro. Quello che comparirà su IO, se non ho detto castronerie fin qui, non dovrebbe discostarsi di molto da quanto contenuto in quel tag. Se il tag contiene qualcosa di incomprensibile, molto difficilmente il messaggio di IO conterrà qualcosa di intellegibile per il debitore (che, si è detto in apertura, dovrebbe essere il destinatario finale dei benefici ottenuti dai pagamenti elettronici).

Se il contenuto della causaleVersamento non ti piace, non c’è che una soluzione: attaccati al telefono e parlane con il partner tecnologico.

Quanto sopra dovrebbe valere in generale, ma, purtroppo, ogni partner tecnologico opera a modo suo, perché la parte standard del mondo pagoPA è solo quella che passa dal Nodo. A casa sua, invece, ogni EC/PT, di fatto, può fare come crede.

Due conclusioni fuori tema

Chiudo con due osservazioni a margine.

La prima di stampo diplomatistico, sul valore dei documenti “ricevuta” nell’ecosistema pagoPA: che si prenda la ricevuta XML prodotta dal PSP^[14]A essere precisi, secondo le nuove SANP, la ricevuta telematica che arriva all’ente creditore in formato XML è generata dal Nodo (passaggio “receipt generation” nel diagramma) che, … Continue reading o che si prenda una sua rielaborazione fatta dall’ente creditore, il documento non ha mai un valore di certificazione o attestazione in sé, ma vale solo come riferimento per verificare quanto risulta in una banca dati. Infatti, né l’XML che passa dal Nodo né le ricevute proposte da IO o dall’ente creditore portano con sé strumenti di validazione, quali potrebbero essere, per esempio, una firma o un sigillo digitale^[15]Le primissime versioni delle SANP prevedevano una firma XAdES sugli XMl scambiati tramite Nodo a partire da dati di firma e certificati prodotti internamente all’ecosistema pagoPA. La specifica … Continue reading. Sono dei promemoria e, a dirla male, non è particolarmente difficile creare oggetti con gli stessi caratteri formali ma contenuto di fantasia. In quest’ottica appare abbastanza inutile la prassi, in uso in alcuni enti per alcuni procedimenti, di farsi inviare una copia della “ricevuta pagoPA”: questa è già in possesso dell’ente che la richiede, al più basta farsi indicare il codice identificativo del pagamento fatto (se non già noto) e verificare l’effettivo pagamento sul sistema dei pagamenti pagoPA in uso.

La seconda è più una raccomandazione: in un momento storico in cui sempre più ci si sposta verso una composizione dei documenti guidata da software e procedure che prendono dati strutturati e li compongono in un documento dotato di forma prestabilita, si rischia di perdere consapevolezza e controllo sull’esito finale della composizione, anche per quanto riguarda il contenuto. Infatti, di fronte a campi proposti per la compilazione dalla maschera di un software, spesso la tentazione è di “fare veloce” e scrivere qualcosa di molto sintetico (se non approssimativo) o addirittura privo di senso (tre puntini bastano, se il campo non è obbligatorio). Poi però ci si trova in situazioni in cui quel campo viene riutilizzato per comporre un documento “tradizionale” con risultati scadenti. Magari quel documento viene prodotto e recapitato in automatico e nemmeno abbiamo la possibilità di rileggerlo. Chi lo riceve, però, lo legge eccome… E se poi manifesta insofferenza quando si chiede cosa possa mai essere quel “/RFB/222**43**995**19” che ha pagato mesi prima, tutti i torti non gli si possono dare!