Specifiche Attuative del Nodo dei Pagamenti-SPC versione 2.3.0¶

pagoPA è un sistema per rendere più semplici, sicuri e trasparenti tutti i pagamenti verso la Pubblica Amministrazione.

revisione	data	nota
2.2	gennaio 2020	nuova pubblicazione pagoPA
2.3.0	novembre 2020	Richiesta catalogo Dati (deprecato) RT push asincrona, Revoca e Storno (deprecato); Pagamento on-Line con codice convenzione

Sezione 1 - Funzionamento Generale del Sistema¶

Funzionamento Generale del Sistema

SEZIONE I – FUNZIONAMENTO GENERALE DEL SISTEMA

Funzionamento generale del sistema¶

Obiettivo strategico del Sistema pagoPA è quello di facilitare e diffondere gli strumenti di pagamento elettronici, in particolare, quelli riferiti agli incassi della Pubblica Amministrazione, che da un lato migliorino, nel rispetto delle situazioni già in essere, la gestione dei servizi di tesoreria, dall’altro consentano alla Pubblica Amministrazione e ai gestori di Servizi Pubblici di esporre ai cittadini e alle imprese servizi evoluti di pagamento, assicurando nel contempo un coordinamento a livello nazionale della concreta attuazione ed evoluzione nel tempo del sistema.

L’adesione a pagoPA consente agli Enti Creditori di eliminare gli onerosi processi di gestione del back office anche attraverso processi automatizzati di riconciliazione. Identico beneficio è atteso per ogni operatore del settore dei pagamenti che aderisca all’iniziativa che si inquadra, da un lato, nella più ampia regolamentazione europea in materia di servizi di pagamento introdotto con il progetto SEPA, dall’altro, nell’attuazione delle norme introdotte dal nuovo articolo 5 del CAD in tema di pagamenti informatici.

Le suddette norme trovano concreta attuazione tramite l’infrastruttura abilitante, denominata Nodo dei Pagamenti-SPC (NodoSPC). Tale infrastruttura si configura come una componente del Sistema Pubblico di Connettività che regola - a livello nazionale - le modalità organizzative e tecnico-infrastrutturali di funzionamento dei pagamenti verso la Pubblica Amministrazione, senza alterare i rapporti commerciali tra i diversi attori del processo, ma introducendo modalità semplificate di interazione.

In questo contesto l’impianto si configura come un sistema di livello nazionale definito anche come “Dominio dei Pagamenti della Pubblica Amministrazione” (Dominio), che ha assunto a partire dalla fine dell’anno 2014, con la registrazione del correlato marchio, la denominazione di Sistema pagoPA.

Il modello di funzionamento del Sistema fa riferimento ai principi del Four Corners model definito dall’European Payment Council ed è riportato nel diagramma di Figura 1, nel quale l’infrastruttura costituita dal NodoSPC si pone quale facilitatore del colloquio i vari soggetti coinvolti:

Utilizzatore finale

(Debtor)

Rappresenta il privato cittadino, il professionista o l’impresa, che effettua pagamenti a favore della Pubblica Amministrazione.

Nell’ambito del processo di pagamento si distingue il ruolo del soggetto debitore, cioè colui che ha contratto un debito a favore dell’Ente Creditore, ovvero che effettua un pagamento spontaneo per ottenere a un servizio dallo stesso Ente creditore. Nel rapporto con Ente Creditore l’Utilizzatore finale coincide con il soggetto debitore.

Si distingue infine il soggetto versante, ovvero come colui accede ai servizi informatici dal Prestatore dei Servizi di Pagamento, e dispone il pagamento a favore dell’Ente Creditore. Nel rapporto con il PSP l’Utilizzatore finale coincide con il soggetto versante.

Ente Creditore (EC)

(Creditor)

Soggetto che utilizza il sistema pagoPA per l’incasso delle somme a vario titolo dovute dall’Utilizzatore finale.

L’EC utilizza SPID per il riconoscimento dell’identità dell’Utilizzatore finale e per autorizzarne l’accesso ai propri servizi informatici. Per consentire il pagamento accede al NodoSPC direttamente o tramite un soggetto intermediario pubblico o privato.

Prestatore di Servizi di Pagamento (PSP)

(Debtor e Creditor Bank)

Soggetto abilitato dalle norme vigenti in materia ad eseguire le richieste di pagamento ricevute dall’EC tramite il NodoSPC al quale restituisce ricevuta telematica di pagamento.

Il PSP offre i propri servizi di pagamento, direttamente o tramite terze parti (intermediari), configurando sul NodoSPC canali di pagamento, fisici e telematici, con cui l’Utilizzatore finale può effettuare l’operazione.

L’utilizzo dell’infrastruttura del NodoSPC non altera in alcun modo i rapporti esistenti tra l’Ente Creditore ed il proprio istituto tesoriere.

image0

Figura 1 – EPC Four Corners model

Il perfezionamento delle operazioni disposte tramite pagoPA avviene attraverso il sistema di regolamento e compensazione (CSM) utilizzando le regole SEPA.

Il sistema supporta anche altri tipi di operazioni di pagamento che risultano dal collegamento tra più servizi di pagamento o tra servizi di pagamento e altre operazioni ad essi contigue, così come definito dal Provvedimento Banca d’Italia del 5 luglio 2011 in materia di diritti e obblighi delle parti nei servizi di pagamento.

Dal punto di vista organizzativo, la partecipazione al sistema pagoPA si attua attraverso la sottoscrizione di accordi di servizio tra l’Agenzia per l’Italia Digitale e i Prestatori di Servizi di Pagamento, nonché la sottoscrizione di lettere di adesione da parte delle Pubbliche Amministrazioni e dei Gestori di Pubblici Servizi: ciò consente di stabilire un rapporto di collaborazione “molti a molti”, accelerando il processo di attuazione del sistema.

Il sistema pagoPA prevede inoltre la possibilità che le attività legate all’effettuazione dei pagamenti siano eseguite, in tutto od in parte, da Intermediari tecnologici (soggetti pubblici e/o privati) per conto sia degli Enti Creditori che dei Prestatori di servizi di pagamento. A tale proposito si definisce:

Intermediario tecnologico un soggetto già aderente al NodoSPC , che risulta responsabile delle attività tecniche di interfacciamento del soggetto intermediato.
Partner tecnologico un fornitore del soggetto intermediato, utilizzato in via strumentale per l’esecuzione delle attività tecniche di interfacciamento con il NodoSPC, ferma restando la responsabilità nei confronti di AgID in capo al soggetto intermediato.

Si precisa che è consentita la multi intermediazione cioè l’utilizzo di diversi Intermediari o Partner tecnologici da parte del medesimo soggetto intermediato.

È consentito altresì che un PSP sia intermediato verso pagoPA da circuiti o consorzi costituiti in ambito finanziario, purché rimangano comunque inalterate le responsabilità del PSP nei confronti di terze parti e, in particolare, degli Utilizzatori finali.

Il ciclo di vita del pagamento gestito sul Sistema pagoPA¶

Nell’ambito delle relazioni tra l’Utilizzatore finale e gli Enti Creditori, la necessità di effettuare pagamenti a favore di questi ultimi è associata a procedimenti amministrativi che, in linea generale, seguono un preordinato “Ciclo di vita” schematizzato nella Figura 2.

image1

Figura 2 - Ciclo di vita del pagamento

L’esigenza del pagamento può nascere in due modi che innescano processi di business differenti:
- su iniziativa dell’Utilizzatore finale che necessita dell’erogazione di un servizio da parte dell’EC
- su iniziativa dell’EC che deve richiedere all’Utilizzatore finale l’estinzione di un debito creatosi nei suoi confronti.
L’esigenza del pagamento si concretizza attraverso la generazione di una posizione debitoria, cioè l’insieme di informazioni che l’Ente Creditore deve memorizzare in appositi archivi per consentire il pagamento e la successiva fase di riconciliazione.
Il Prestatore di Servizi di Pagamento scelto dall’Utilizzatore finale, completata l’operazione di pagamento in base alla richiesta di pagamento dell’EC, incamera i fondi da destinare all’Ente Creditore.
Il Prestatore di Servizi di Pagamento esegue il regolamento contabile dell’operazione accreditando il conto indicato dall’Ente Creditore nella richiesta di pagamento con un SEPA Credit Transfer, salvo le eccezioni previste dalla vigente normativa di settore.
L’Ente Creditore estingue la posizione debitoria e esegue la fase di riconciliazione contabile del pagamento.
L’Ente Creditore rilascia ricevuta all’Utilizzatore finale e, se previsto, la quietanza di pagamento.

L’esecuzione di pagamenti tramite pagoPA prevede l’interazione tra i sistemi informativi dei vari attori aderenti al Dominio. Il NodoSPC è il centro stella del sistema e assicura l’interoperabilità dei vari sistemi dei soggetti aderenti, rendendo disponibili primitive e metodi per l’interscambio dei flussi di dati, nonché una interfaccia per la selezione del Prestatore di Servizi di Pagamento da parte del pagatore.

A tal fine il NodoSPC gestisce diversi workflow applicativi che prevedono lo scambio di oggetti contenenti le informazioni necessarie a garantire la corretta gestione dei processi. Sebbene tali workflow siano dettagliati nella sezione III se ne fornisce qui una sommaria descrizione.

Per tutti i workflow applicativi le funzioni primarie sono assicurate dall’interscambio dei seguenti oggetti e informazioni:

Identificativo Univoco Versamento (IUV). Codice generato dall’Ente Creditore per identificare una posizione debitoria, conformemente alle regole di cui alla Sezione I del documento “Specifiche attuative dei codici identificativi di versamento, riversamento e rendicontazione” allegato A alle “Linee guida per l’effettuazione dei pagamenti a favore delle pubbliche amministrazioni e dei gestori di pubblici servizi”.
Richiesta Pagamento Telematico (RPT). Emessa dall’Ente Creditore per richiedere il pagamento di una posizione debitoria, reca i parametri necessari all’esecuzione dell’intero ciclo di vita del pagamento;
Ricevuta Telematica (RT). Generata dal PSP per ogni RPT ricevuta per qualificare l’esito dell’operazione di pagamento. Se il pagamento è andato a buon fine costituisce elemento liberatorio per il soggetto debitore nei confronti dell’EC;
Codice Contesto Pagamento (CCP). Codice che caratterizza la singola operazione di pagamento di una posizione debitoria, consentendo la rilavorazione dei pagamenti non andati a buon fine;
Flusso di Rendicontazione (FR). Documento informatico messo a disposizione dal PSP che raccoglie il dettaglio di un accredito cumulativo di un conto specificato dalla RPT ricevuta da un EC.

La piattaforma tecnologica del NodoSPC provvede all’istradamento di tali oggetti per inizializzare il pagamento e rendicontarne gli esiti:

L’Utilizzatore finale, innescando il pagamento, rende disponibile a un PSP di sua scelta la RPT relativa alla posizione debitoria che intende pagare. Le modalità variano se l’interazione è avvenuta con i sistemi degli EC o dei PSP
L’Utilizzatore finale può autorizzare un pagamento, tramite canali fisici o telematici messi a disposizione dal PSP.
Indipendentemente dal canale utilizzato, il PSP incassa il pagamento richiesto dall’EC, genera una RT, consegna all’Utilizzatore finale un’attestazione di pagamento e, nei tempi previsti dalle norme di settore, accredita i conti dell’EC.
La ricevuta telematica attraverso il NodoSPC è consegnata all’Ente Creditore che, in caso di esito positivo, può erogare il servizio richiesto.
L’EC può eseguire la riconciliazione dei pagamenti, sulla base delle RT e dei FR, e rilasciare quietanza.

Nell’ambito delle funzionalità esposte dal NodoSPC è previsto lo scambio di ulteriori oggetti applicativi e servizi applicativi opzionali che verranno dettagliati nella Sezione III.

L’adesione al Sistema pagoPA¶

L’insieme degli Enti Creditori, Prestatori di Servizi di Pagamento aderenti e dei loro intermediari tecnologici, costituisce, come già detto, il “Dominio dei Pagamenti dell’Ente Creditore” (o più brevemente Dominio). Implicitamente con il termine di Dominio ci si riferisce anche alle componenti tecnico-organizzative di tali attori.

L’utilizzo dei servizi messi a disposizione dal NodoSPC è attivato attraverso apposite procedure, descritte in maggior dettaglio nella Sezione IV, che prevedono:

per le Pubbliche Amministrazioni e i Gestori di Pubblici Servizi l’invio all’Agenzia per l’Italia Digitale di lettere di adesione unilaterali da loro sottoscritte;
per i PSP la sottoscrizione con l’Agenzia per l’Italia Digitale, su base volontaria, di atti bilaterali denominati “Accordi di Servizio”.

Ogni soggetto aderente che, per lo svolgimento delle attività tecniche di interfacciamento al NodoSPC, utilizza soggetti intermediari, rimane comunque responsabile in quanto mittente o destinatario logico dei flussi informativi.

Nel Dominio, le attività di pertinenza di ogni soggetto sono effettuate conformemente ai requisiti di riservatezza e di protezione da accessi non autorizzati previsti dalla normativa vigente.

Obblighi degli Enti Creditori¶

Al fine di gestire nel modo migliore l’iter del processo di pagamento gli Enti Creditori hanno l’obbligo di rendere disponibili direttamente all’Utilizzatore finale, attraverso opportuni servizi informatici offerti direttamente o tramite intermediari:

le modalità per effettuare i pagamenti informatici e ogni altra informazione che abbia il fine di agevolarne l’esecuzione;
l’accesso all’archivio delle RT relative ai pagamenti disposti. Fino a prescrizione, è fatto obbligo all’Ente Creditore di conservare le informazioni di ogni pagamento;
le modalità di gestione, nel rispetto della normativa vigente, delle procedure attinenti ai pagamenti (reclami, rimborsi, storni), anche usufruendo delle funzionalità messe a disposizione dalla piattaforma.

Si sottolinea inoltre che l’Ente Creditore, responsabile della relazione con il soggetto pagatore, dovrà erogare un adeguato servizio di assistenza agli utenti, opportunamente pubblicizzato e con adeguata disponibilità temporale.

Ogni Ente Creditore infine ha l’obbligo di costituire un tavolo operativo per interloquire con l’analoga struttura del NodoSPC e collaborare alla risoluzione delle anomalie o incidenti che si dovessero verificare. La disponibilità del tavolo operativo è la stessa dei sistemi di pagamento per i quali è necessario un presidio.

Interfaccia WISP¶

Per garantire la trasparenza dell’operazione di pagamento nei confronti dell’Utilizzatore finale, il NodoSPC mette a disposizione una applicazione che consente ai PSP di esporre on line i costi del servizio, differenziati per strumento e/o canale di pagamento, in modo da rendere consapevole la scelta effettuata dagli Utilizzatori finali.

Tali informazioni sono rese disponibili da una interfaccia WEB, denominata WISP (Wizard Interattivo per la Scelta del PSP), caratterizzata dalla stessa user experience, indipendentemente dall’EC che ha innescato il pagamento.

Per supportare gli Enti Creditori nello sviluppo di App mobile è disponibile un SDK (Software Development Kit) fornito in modalità nativa per le tecnologie IOS e Android.

La funzione WISP mantiene inalterata la facoltà in capo al Prestatore di Servizi di Pagamento di stabilire costi di servizio di maggior favore per gruppi o singoli Utilizzatori finali, purché non ricada sul NodoSPC l’onere di promuovere e pubblicizzare tali specificità.

Funzioni accessorie di controllo¶

Il Sistema prevede modalità di controllo focalizzate sulla verifica della corretta applicazione degli Standard di Servizio (p.e. norme di comportamento, livelli di Servizio garantiti, ecc.) e dei processi che da questi derivano.

A supporto di tali funzioni, ogni soggetto (Enti Creditori e Prestatori di Servizi di Pagamento aderenti, NodoSPC) deve registrare all’interno del proprio sistema ogni singolo evento significativo dal punto di vista applicativo al fine di tenerne traccia.

L’insieme di tali registrazioni, indipendentemente dalle peculiarità tecniche delle soluzioni adottate da ciascun soggetto che definisce in autonomia tali aspetti, costituisce il “Giornale degli Eventi” che riporta gli estremi di tutte le situazioni verificatesi nell’esecuzione dell’operazione di pagamento nelle varie tratte coinvolte (tra Enti Creditori e NodoSPC, nel NodoSPC, tra NodoSPC e Prestatori di Servizi di Pagamento).Tali informazioni devono essere rese disponibili ai tavoli operativi nei formati definiti in Sezione III).

Sicurezza e conservazione¶

Tutte le informazioni trattate nell’ambito del Sistema saranno gestite dai diversi attori che interagiscono con il NodoSPC, ciascuno nell’ambito della propria competenza e responsabilità, nel rispetto della vigente normativa in materia di conservazione dei documenti informatici e di sicurezza dei dati.

In merito, si rammenta che la conservazione è finalizzata a proteggere nel tempo i documenti informatici e i dati ivi contenuti, assicurandone, tra l’altro, l’integrità al fine di preservare il valore probatorio del documento informatico.

Sezione 2 - Gestione della posizione debitoria¶

Gestione della posizione debitoria

SEZIONE II – REGOLE DI FUNZIONAMENTO DEL SISTEMA

I due diversi workflow gestiti sul Sistema pagoPA si differenziano principalmente in base al soggetto che innesca il pagamento. Avremo quindi un processo diverso se l’utilizzatore finale accede al servizio di pagamento attraverso tecnologie e funzioni messe a disposizione da un Ente Creditore ovvero attraverso tecnologie e funzioni messe a disposizione da un Prestatore di Servizi di Pagamento

Nella presente sezione è modellato il processo di scambio dati tra i sistemi informativi dei tre soggetti che partecipano a ogni processo di pagamento mediati dal NodoSPC.

La modellazione risultante descrive quindi, da una parte, le specifiche che definiscono il comportamento progettato del NodoSPC, riportando un set di informazioni certe e conosciute (le primitive rese disponibili dai Web Services, i dati di configurazione, etc.) e, in un’altra parte, il comportamento atteso dei sistemi intermediati riportando l’insieme di informazioni minime indispensabili alle funzioni informatiche effettivamente sviluppate dai soggetti aderenti in qualità di Enti Creditori o Prestatori di Servizi di Pagamento.

I dettagli delle primitive utilizzate in ciascun workflow, i tracciati, gli errori e tutte le informazioni tecniche necessarie per integrare servizi di Enti Creditori e Prestatori di Servizi di Pagamento con il NodoSPC sono descritti nella sezione III.

La modellazione segue le notazioni dello standard Business Process Model and Notation (BPMN) versione 2.0, di cui si riporta, in Figura 1, i simboli utilizzati e il loro significato.

image0

Figura 1: Notazioni BPMN 2.0 utilizzate

Gestione della posizione debitoria¶

Come previsto dalle Linee guida, tutte le tipologie di pagamento gestite dal Sistema pagoPA prevedono che l’Ente Creditore, per rendere realizzabile un pagamento, registri nei propri archivi le informazioni necessarie per effettuare il pagamento e le metta a disposizione dell’utilizzatore finale. Definiamo l’insieme di tali informazioni con il termine di “posizione debitoria”.

Nel Sistema pagoPA ogni pagamento presuppone la creazione propedeutica, nel sistema informativo dell’Ente Creditore, di una posizione debitoria. All’Ente Creditore compete la gestione degli stati del ciclo di vita della posizione debitoria, che, in linea generale, corrispondono alle attività di:

Creazione. La posizione debitoria viene creata dall’Ente Creditore e posta nello stato di “Aperta”. Si sottolinea che in questa sede si definisce “posizione debitoria” sia la creazione che avviene su iniziativa dell’Ente Creditore (es. maturazione delle condizioni per il pagamento di una imposta) sia quella che avviene su iniziativa dell’Utilizzatore finale (es. richiesta di un servizio), anche se in quest’ultimo caso l’Utilizzatore finale stesso non è effettivamente in debito con l’Ente Creditore.
Aggiornamento. La posizione debitoria viene aggiornata dall’Ente Creditore ogni qualvolta intervengano eventi che ne modificano le informazioni associate (es sanzioni per decorrenza dei termini). L’attività di aggiornamento provoca un avanzamento di versione della posizione debitoria che permane nello stato di “Aperta”.
Blocco. La posizione debitoria viene bloccata e posta nello stato “In pagamento”, a discrezione dell’Ente Creditore, nelle more del perfezionamento di un pagamento, onde evitare la possibilità di pagamenti ripetuti.
Trasferimento. La posizione debitoria è posta nello stato di “Trasferita” nel caso in cui la competenza dell’incasso passi a un altro Ente Creditore (es. iscrizione in ruolo).
Chiusura. L’Ente Creditore pone la posizione debitoria nello stato “Chiusa” ogni qualvolta viene effettuato un pagamento che salda il debito o intervengano eventi che la rendano non più pagabile. Tale stato è reversibile nel caso in cui intervenga una revoca del pagamento che pone di nuovo la posizione debitoria in una nuova versione dello stato di “Aperta”.

Contestualmente alla creazione di una posizione debitoria, l’Ente Creditore, se ne ricorrono le condizioni, deve predisporre un avviso di pagamento che rappresenta lo strumento che rende possibile l’innesco del pagamento stesso presso i PSP.

L’Ente Creditore genera il tradizionale avviso di pagamento analogico (sotto forma di avviso cartaceo o file stampabile) ogni qualvolta le norme lo obbligano a notificare a un debitore (cittadino o impresa) l’insorgenza di una posizione debitoria aperta nei suoi confronti. Tutte le norme di dettaglio che regolano la produzione di un avviso di pagamento analogico sono incluse nel documento collegato “Il nuovo avviso di pagamento analogico nel sistema pagoPA”.

L’EC continua a recapitare l’avviso analogico all’Utilizzatore finale con le modalità tradizionali a cui può affiancare funzioni di stampa a carico dell’Utilizzatore finale dopo il downloading del documento.

L’avviso di pagamento analogico, oltre al logotipo del Sistema pagoPA, contiene le informazioni indispensabili per l’esecuzione del pagamento, che sono dettagliate nella sezione III.

Si attira l’attenzione sulla circostanza che l’importo dell’avviso di pagamento contenuto nell’avviso analogico è quello corrispondente al momento della produzione di tale documento e quindi può essere soggetto a variazioni (in più o in meno) al momento in cui ne viene richiesto il pagamento da parte dell’utilizzatore finale, nel caso sia intervenuto un aggiornamento della posizione debitoria, purché tale possibilità sia stata effettivamente esplicitata in una avvertenza sull’avviso.

La peculiarità di alcune postazioni messe a disposizione dai Prestatori di Servizi di Pagamento rende necessario automatizzare l’acquisizione dei dati presenti sull’avviso di pagamento. Per questo motivo tale documento deve essere corredato, oltre che dati essenziali sopra citati, anche da un insieme di elementi grafici facilmente leggibili e decodificabili da apposite apparecchiature.

I processi di creazione, aggiornamento, chiusura o annullamento di una posizione debitoria sono interni al sistema informativo dell’Ente Creditore. Nei casi previsti tali operazioni scatenano l’invio di un avviso di pagamento con strumenti digitali (avvisatura digitale), il cui processo è tracciato nel seguito.

PagoPA consente all’Ente Creditore di affiancare all’avviso analogico un avviso digitale di natura bonaria che, conservando lo stesso contenuto informativo, permette la distribuzione e il pagamento in modalità totalmente dematerializzata.

Con l’avvisatura digitale l’Ente Creditore permette agli utenti di accedere allo stato corrente della propria posizione debitoria. Attraverso il Sistema pagoPA è possibile gestire due tipologie di avvisatura digitale:

Avvisatura digitale push, quando la distribuzione dell’avviso avviene per iniziativa dell’Ente Creditore
Avvisatura digitale pull, quando la distribuzione avviene per iniziativa di un Prestatore di Servizi di Pagamento per soddisfare una richiesta dell’Utilizzatore finale.

I paragrafi che seguono descrivono i workflow gestiti da pagoPA nei due casi.

Avvisatura digitale push (su iniziativa dell’Ente Creditore)¶

La funzione di avvisatura digitale in modalità push è un servizio messo a disposizione dal Sistema pagoPA attraverso il NodoSPC che consente agli Utilizzatori finali di ricevere avvisi in formato elettronico, in modo che il correlato pagamento possa essere effettuato in modalità semplice e sicura utilizzando il Sistema pagoPA. Salvo diverso avviso le notifiche digitali hanno un carattere bonario e quindi si affiancano a quelle tradizionali, già previste dalla normativa, senza sostituirle. Tuttavia, per consentire ai propri clienti la più ampia possibilità di utilizzare tale strumento innovativo, l’Ente Creditore è incentivato a utilizzarle anche nelle circostanze in cui la normativa non pone un obbligo formale di notifica.

Per poter ricevere un avviso digitale l’utilizzatore finale dovrà dotarsi di un “cassetto digitale” che il NodoSPC utilizzerà per il recapito, mediante la sottoscrizione di uno specifico contratto con un soggetto abilitato da AgID a erogare tale servizio. I Prestatori di Servizi di Pagamento hanno la possibilità di integrare con essa ulteriori funzioni quali, a titolo di esempio, i servizi di pagamento offerti sul Sistema pagoPA, notifiche sui dispositivi da essi gestiti, (app su PC, tablet e smartphone, servizio di home banking, ecc.), gestione delle scadenze, ecc.

Si puntualizza che l’Utilizzatore finale, ossia il soggetto destinatario dell’avvisatura da parte dell’Ente Creditore, è sempre il soggetto debitore identificato dall’Ente Creditore. PagoPA non preclude tuttavia la possibilità che l’Utilizzatore finale chiamato a eseguire il relativo pagamento possa essere un terzo (soggetto versante) in nome e per conto del debitore (soggetto pagatore).

L’adesione al servizio da parte dei Prestatori di Servizi di Pagamento è facoltativa, mentre gli Enti Creditori che generano un avviso analogico pagabile presso i Prestatori di Servizi di Pagamento dovranno obbligatoriamente sviluppare tale funzionalità e distribuire una versione digitale di ogni avviso analogico generato.

Il servizio in oggetto è monodirezionale in quanto prevede la distribuzione di avvisi digitali da parte degli Enti Creditori verso gli Utilizzatori finali, ma non prevede risposta da parte di questi ultimi. L’iscrizione al servizio di avvisatura effettuata dall’utilizzatore finale presso il Prestatore di Servizi di Pagamento avrà efficacia per la ricezione di avvisi da parte di tutti gli Enti Creditori aderenti al Sistema pagoPA.

L’utente finale può iscriversi al servizio di avvisatura presso più Prestatori di Servizi di Pagamento: in questo caso, in fase di iscrizione presso un altro Prestatore di Servizi di Pagamento dovrà ricevere una segnalazione di iscrizione “multipla” da parte del Prestatore di servizi di pagamento che sta trattando l’operazione.

La revoca dell’iscrizione al servizio di avvisatura deve essere richiesta al Prestatore di Servizi di Pagamento, che ne stabilisce le modalità.

Nel processo di avvisatura push (Figura 2) sono coinvolti quattro soggetti:

utilizzatore finale
Ente Creditore
NodoSPC
Prestatore Servizi di Pagamento dell’Utilizzatore finale

image1

Figura 2: Il processo di gestione dell’avvisatura push

Il processo di avvisatura push è iniziato dall’Ente Creditore quando genera una posizione debitoria (Task T1.1.1). Una volta generata la posizione debitoria, l’Ente Creditore invia al NodoSPC gli avvisi digitali da recapitare (Task T1.1.2).

Il NodoSPC (Task T1.1.3) esegue azioni differenti a seconda che l’utilizzatore finale sia iscritto o meno al servizio presso un Prestatore Servizi di Pagamento (Gateway G1.1.1):

Nel caso in cui l’utilizzatore finale sia iscritto tramite Prestatore Servizi di Pagamento, il NodoSPC invia l’avviso digitale al Prestatore Servizi di Pagamento (Task T1.1.3) che lo storicizza in un proprio database e ne dà notifica all’Utilizzatore finale (Task T1.1.4) in modo che sia a disposizione dello stesso (Task T1.1.5)
Negli altri casi, il NodoSPC non esegue alcuna azione.

Nel caso in cui l’Ente Creditore modifichi uno dei dati obbligatori dell’avviso (ad esempio: l’importo), dovrà inviare al NodoSPC una nuova copia dell’avviso digitale con l’indicazione che si tratta di un aggiornamento.

Nel caso in cui l’Ente Creditore annulli un avviso digitale o tale avviso risulti pagato con modalità diverse dal Sistema pagoPA, dovrà inviare al NodoSPC una nuova copia dell’avviso digitale con l’indicazione che si tratta di una cancellazione.

Il processo di aggiornamento e annullamento dell’avviso digitale è analogo a quello della generazione (Figura 3).

Avvisatura digitale pull (verifica della posizione debitoria)¶

L’avvisatura pull è una funzionalità che l’Ente Creditore mette a disposizione dell’Utilizzatore finale per consentirgli di accedere alla propria posizione debitoria.

Il Sistema pagoPA rende disponibili opportune funzioni di interscambio affinché la posizione debitoria di un utilizzatore finale possa essere interrogata attraverso altre funzioni messe a disposizione da Prestatore di Servizi di Pagamento . Tale servizio viene erogato con un’interrogazione della base dati dell’Ente Creditore di competenza, integrato con il “cassetto digitale”, e avviene secondo uno schema sincrono, attivato dall’Utilizzatore finale stesso attraverso le stesse modalità descritte nel paragrafo precedente.

Nel processo in oggetto (Figura 3) sono coinvolti quattro soggetti:

Utilizzatore finale
Ente Creditore
NodoSPC
Prestatore Servizi di Pagamento dell’Utilizzatore finale

image2

Figura 3: Il processo di gestione dell’avvisatura pull

Il processo segue i seguenti passi:

L’utilizzatore finale accede ad una degli strumenti messi a disposizione dal Prestatore di Servizi di Pagamento richiedendo di conoscere la sua (Task T1.3.1) posizione debitoria
Il Prestatore di servizi di Pagamento inoltra la richiesta all’Ente Creditore attraverso il NodoSPC (Task T1.3.2 e T1.3.3)
L’Ente Creditore predispone la lista delle Posizione Debitorie relative all’utilizzatore finale (Task T1.3.4) e le inoltra al Prestatore di Servizi di Pagamento attraverso il NodoSPC (Task T1.3.5).
Il Prestatore di servizi di Pagamento riceve la posizione debitoria dell’Utilizzatore finale e può informarlo (Task T1.3.6)
L’utilizzatore finale a questo punto ha a disposizione la propria posizione debitoria (Task T1.3.7)

Al fine di prevenire utilizzi non consoni, il NodoSPC si riserva la possibilità di applicare apposite regole di throttling (limitazioni nell’utilizzo). Le eventuali regole di throttling sono indicate nel documento “Indicatori di qualità per i Soggetti Aderenti”.

Il Processo di pagamento attivato presso l’Ente Creditore¶

Rientrano in questa categoria di pagamenti quelli richiesti dall’Utilizzatore finale attraverso i siti web o mobile app o altri strumenti tecnologici messi a disposizione dagli Enti Creditori per i pagamenti elettronici. Il processo di pagamento attivato presso l’Ente Creditore risulta particolarmente congeniale al caso di pagamenti spontanei (con generazione della posizione debitoria), ma deve gestire anche il caso in cui l’utilizzatore finale abbia ricevuto un avviso di pagamento.

Le attività a carico degli Enti Creditori per gestire il processo sono rappresentate dalla realizzazione delle procedure di pagamento (sia in termini organizzativi, che informatici); le procedure di pagamento potranno essere più o meno strettamente integrate con i servizi cui fanno riferimento.

Il diagramma di Figura 1 descrive il processo di pagamento attraverso l’Ente Creditore. Al fine di rendere tale diagramma immediatamente leggibile la descrizione del workflow è stata aggregata in sotto-paragrafi secondo lo schema logico che segue.

image0

Figura 1 Schema logico del processo di business del pagamento presso l’Ente Creditore

Nel processo schematizzato in Figura 2 sono coinvolti quattro soggetti:

Utilizzatore finale
Ente Creditore
NodoSPC
Prestatore Servizi di Pagamento dell’utilizzatore finale

image1

Figura 2 Il processo del pagamento da Ente Creditore

Avvio del pagamento¶

Come descritto nei paragrafi precedenti, l’utilizzatore finale può eseguire un pagamento per ragioni diverse che generano due diramazioni distinte (gateway G2.1.1) nel caso abbia disponibile o meno un avviso di pagamento (digitale e analogico).

In entrambi i casi l’Ente Creditore rende disponibile all’Utilizzatore finale un’interfaccia utente al fine di reperire i dati necessari a comporre una o più RPT e innescare il pagamento.

Generazione posizione debitoria¶

La generazione di una posizione debitoria è l’evento propedeutico al pagamento sul Sistema pagoPA.

In determinate circostanze, previste nello specifico dalla vigente normativa, un soggetto matura un debito in favore di una Pubblica Amministrazione (centrale o locale). In questo caso lo stesso Ente Creditore assume l’iniziativa di generare una posizione debitoria e provvede, se del caso, a notificare l’avviso di pagamento al soggetto pagatore. Questa casistica prende il nome di pagamento dovuto. Nel caso che l’EC sia tenuto ad accompagnare la notifica con un avviso di pagamento analogico, provvede anche a inviare al NodoSPC un avviso digitale.

Nel caso non sussistano le circostanze sopra indicate, l’Utilizzatore finale può comunque assumere l’iniziativa di avviare il pagamento (si parla in questo caso di pagamento spontaneo) accedendo al portale messo a disposizione dall’Ente Creditore; in tal caso l’Ente Creditore genera la relativa posizione debitoria (Task T2.1.1). È facoltà dell’EC esporre delle funzioni che producano, per lo stesso pagamento, un avviso (analogico o digitale), da utilizzare in seguito per disporre il pagamento presso un Prestatore di Servizi di Pagamento.

Scelta canale di pagamento¶

L’utilizzatore finale accede ai sistemi dell’EC per pagare uno o più avvisi che gli sono stati recapitati e/o uno o più pagamenti spontanei e l’Ente Creditore genera il carrello di richieste di pagamento telematico reindirizzando l’utilizzatore finale sul portale WISP (Task T2.1.2).

Il NodoSPC prende in carico il carrello delle richieste di pagamento telematico (Task T2.1.3) mentre l’Utilizzatore finale sceglie il Prestatore di Servizi di Pagamento e il canale di pagamento.

Per gli utilizzatori finali che scelgono di registrarsi al Sistema pagoPA sono a disposizione funzioni di supporto che consentono di memorizzare le scelte di pagamento effettuate per poterle richiamare e riutilizzare nelle successive occasioni. In questo caso è possibile eleggere una delle scelte come predefinita così da avere un’esperienza quanto più possibile simile alla modalità one-click tipica dei siti di e-commerce.

I dati personali raccolti saranno trattati, nel rispetto della normativa vigente, solo per consentire l’erogazione dei servizi richiesti.

Pertanto, detti dati saranno trattati esclusivamente per consentire agli utenti delle pubbliche amministrazioni e degli altri soggetti aderenti al Sistema pagoPA di richiedere e ottenere i servizi di pagamento erogati dai Prestatori di Servizi di Pagamento abilitati sul Sistema pagoPA, nonché per richiedere e ottenere parimenti i servizi di identificazione e memorizzazione erogati da AgID sul Sistema pagoPA.

Il conferimento dei dati ed il trattamento degli stessi da parte di AgID per tali finalità è dunque obbligatorio e non richiede un esplicito consenso, pena l’impossibilità per l’AgID di erogare i servizi sopra citati.

Autorizzazione del pagamento¶

Il processo di pagamento segue percorsi differenti a seconda del servizio del PSP scelto dall’Utilizzatore finale:

In caso di pagamento con carta (di credito o di debito) (Gateway G2.1.2), l’Utilizzatore finale immette (o recupera nel caso li abbia precedentemente memorizzati) i dati della carta (Task T2.1.4) e quindi decide se autorizzare il pagamento (Gateway G2.1.5).
- Il pagamento con carta è gestito da un POS virtuale del NodoSPC con due differenti esperienze utente. Nel caso di pagamento on us il NodoSPC riconosce dai dati della carta immessi che il PSP emittente (issuer) è aderente al sistema pagoPA e quindi lo propone come gestore del pagamento (acquirer) di default. Altrimenti, casistica not on us, tale scelta è compiuta esplicitamente dall’Utilizzatore finale a cui viene proposta una lista di PSP.
- I Prestatori di Servizi di Pagamento che offrono il servizio di gestione del pagamento con carta devono preventivamente configurarsi come tali. I dettagli delle procedure da seguire sono riportati nella sezione IV.
Per tutte le altre tipologie di pagamento, dopo che l’Utilizzatore finale ha selezionato un PSP sul front-end del sistema, il NodoSPC inoltra in back-end il carrello allo stesso Prestatore di Servizi di Pagamento responsabile dell’esecuzione (Task T2.1.5).
- L’esperienza utente del processo di pagamento può proseguire in un front-end gestito dal Prestatore di Servizi di Pagamento (quindi esterno al sistema pagoPA), che prevede l’identificazione del soggetto versante (Task T2.1.8) e la successiva autorizzazione (Gateway G2.1.4).
- In caso contrario, l’Utilizzatore finale viene reindirizzato al front-end dell’Ente Creditore da cui era stato avviato il pagamento (Task T2.1.7). In questo caso l’autorizzazione del pagamento da parte dell’Utilizzatore finale avviene mediante l’interazione con strumenti messi a disposizione dal Prestatore di Servizi di Pagamento. L’esecuzione del pagamento ed il rilascio della relativa attestazione (RT) avvengono in funzione delle modalità di autorizzazione del pagamento adottate dal Prestatore di Servizi di Pagamento. Si distingue quindi l’autorizzazione:
  - contestuale alla richiesta effettuata, in funzione dei livelli di servizio pattuiti con il Prestatore di Servizi di Pagamento, se l’utilizzatore finale ha pre-autorizzato il pagamento (ad esempio: lettera di manleva o altro strumento contrattuale);
  - non contestuale, se l’autorizzazione viene rilasciata successivamente alla ricezione della richiesta di pagamento telematico da parte del Prestatore di Servizi di Pagamento, attraverso canali da questo messi a disposizione (ad esempio: home banking, notifica su app per smartphone o tablet, ecc.).
  - Tutte i percorsi precedenti, incluso il ramo derivante dall’autorizzazione al pagamento con carta, confluiscono nel punto in cui risulta noto l’esito del pagamento disposto dall’Utilizzatore finale e quindi il PSP possa inoltrare le RT da esso prodotte (Task T2.1.12).

L’Ente Creditore riceve tutte le RT, comprese quelle negative generate dal NodoSPC (Task T2.1.14). Il Prestatore di Servizi di Pagamento deve restituire la ricevuta telematica nei tempi stabiliti dal documento “Indicatori di qualità per i soggetti aderenti” pubblicato sul sito istituzionale dell’AgID, in modo da consentire all’Utilizzatore finale di usufruire dei servizi per cui ha pagato.

L’Ente Creditore può mettere a disposizione dell’Utilizzatore finale una ricevuta (Task T2.1.15) e terminare il processo. Sul portale dell’Ente Creditore devono essere messe a disposizione le funzioni che permettono all’Utilizzatore finale di interrogare lo stato della sua richiesta di pagamento, scaricare una copia di ricevuta o quietanza di pagamento, scaricare copia analogica e/o duplicato del documento informatico Ricevuta Telematica.

Accredito e rendiconto¶

Nella giornata successiva all’incasso, il Prestatore di Servizi di Pagamento accredita le somme sul conto dell’Ente Creditore (Task T2.1.16).

Nella giornata successiva all’accredito, il Prestatore di Servizi di Pagamento invia al NodoSPC i dati relativi alla rendicontazione (Task T2.1.17).

Il NodoSPC mantiene disponibili per l’Ente Creditore i dati di rendicontazione nei dieci giorni successivi (Task T2.1.18).

L’Ente Creditore recupera i dati di rendicontazione (Task T2.1.19) e può quindi avviare il processo di riconciliazione.

Processo di pagamento attivato presso il Prestatore di Servizi di Pagamento¶

Questo processo prevede che l’esecuzione del pagamento avvenga presso le infrastrutture messe a disposizione dal Prestatore di Servizi di Pagamento quali, ad esempio, sportelli ATM, applicazioni di Home banking e mobile payment, uffici postali, punti della rete di vendita dei generi di Monopolio (Tabaccai), SISAL e Lottomatica, casse predisposte presso la Grande Distribuzione Organizzata, ecc.

L’Ente Creditore beneficiario del pagamento deve rendere accessibile ai Prestatori di Servizi di Pagamento, con le modalità mediate dal NodoSPC, un archivio nel quale siano state preventivamente memorizzate le posizioni debitorie (Archivio Pagamenti in Attesa).

Per rendere possibile il pagamento l’Ente Creditore ha l’obbligo di recapitare all’utilizzatore finale un avviso con gli estremi del pagamento da effettuare. Tale recapito deve obbligatoriamente avvenire sia in modalità analogica (tramite servizi postali), che digitale. L’Ente Creditore può inoltre adottare ulteriori misure per la diffusione degli avvisi di pagamento, per esempio rendere disponibili funzioni di stampa on line tramite il proprio sito.

Nello schema di Figura 10 è trattato il caso in cui l’utilizzatore finale, già in possesso dell’avviso di pagamento analogico fornito dall’Ente, si rechi presso le strutture del Prestatore di Servizi di Pagamento e comunichi il codice dell’avviso di pagamento. Si tenga presente che il caso d’uso descritto non dipende dalla concreta modalità in cui tale dato entra in possesso del Prestatore di Servizi di Pagamento: il codice potrebbe essere comunicato a un operatore di sportello, letto automaticamente tramite dispositivi ottici, inserito manualmente dal soggetto versante su interfacce messe a disposizione dai Prestatori di Servizi di Pagamento (un terminale ATM, una pagina WEB, ecc.), ovvero, da ultimo, comunicato tramite avviso digitale.

Il diagramma di Figura 10 descrive il processo pagamento operato presso il Prestatore di Servizi di Pagamento. Al fine di rendere tale diagramma immediatamente leggibile la descrizione del workflow è stata aggregata in paragrafi secondo lo schema logico che segue (Figura 1).

image0

Figura 1 Schema logico del processo di business del pagamento presso il Prestatore di Servizi di Pagamento

Nel processo in oggetto (Figura 2) sono coinvolti quattro soggetti:

Utilizzatore finale
Ente Creditore
NodoSPC
Prestatore Servizi di Pagamento dell’Utilizzatore finale

image1

Figura 2 Il processo del pagamento attivato presso il Prestatore di Servizi di Pagamento

Avvio del pagamento¶

L’Utilizzatore finale può eseguire un pagamento con due itinerari distinti (gateway G2.2.1) discriminati dal fatto che esista una posizione debitoria. Nel caso che la posizione debitoria esista l’Utilizzatore finale dispone di un avviso di pagamento, altrimenti occorre che il PSP interagisca con l’Ente Creditore per generarne una.

Generazione posizione debitoria per pagamento spontaneo¶

La generazione della posizione debitoria è l’evento che costituisce la premessa al pagamento sul Sistema pagoPA.

In determinate circostanze, previste nello specifico dalla vigente normativa, un soggetto matura un debito in favore di una Pubblica Amministrazione (centrale o locale). In questo caso lo stesso Ente Creditore assume l’iniziativa di generare una posizione debitoria e provvede a notificare l’avviso di pagamento al soggetto pagatore. Questa casistica prende il nome di pagamento dovuto. Nel caso che l’EC sia tenuto ad accompagnare la notifica con un avviso di pagamento analogico, provvede anche a inviare al NodoSPC di un avviso digitale. Con questi strumenti si innesca il pagamento presso il PSP.

Nel caso in cui non sussistano le circostanze sopra indicate e quindi l’Utilizzatore finale non sia in possesso di un avviso digitale, l’Utilizzatore stesso può assumere l’iniziativa di avviare il pagamento (pagamento spontaneo), purché il PSP disponga della relativa funzione. In questo caso l’Utilizzatore finale interagisce con uno specifico servizio messo a disposizione dal Prestatore di Servizi di Pagamento e, tramite questo, richiede all’Ente Creditore la generazione della posizione debitoria (Task T2.2.1). L’Ente Creditore risponde con l’invio al Prestatore Servizi di Pagamento di un avviso (Task T2.2.2) che può entrare nella disponibilità all’Utilizzatore finale (Task T2.2.3) il quale dunque dispone degli elementi per decidere se autorizzare il pagamento (Task T2.2.8). Dopo tale fase preliminare il workflow di pagamento risulta indistinguibile da quello innescato da un avviso.

Verifica posizione debitoria e attivazione della richiesta di pagamento¶

Nel caso in cui l’Utilizzatore finale inneschi il pagamento con un avviso, il PSP dispone di due primitive per gestire il workflow:

La funzione opzionale di verifica per controllare lo stato della posizione debitoria attraverso l’Ente Creditore, verificando la sussistenza e la consistenza del debito, che può aver subito variazioni decorsi i termini del pagamento (per esempio potrebbe essere variato l’importo a causa dell’aggiungersi di interessi di mora)
La funzione necessaria di attivazione che, dopo aver eseguito gli stessi controlli previsti dalla funzione di verifica, richiede all’Ente Creditore l’invio di una Richiesta di pagamento telematica (RPT), ovvero il documento necessario a regolare il pagamento.

È facoltà del Prestatore di Servizi di Pagamento eseguire preliminarmente la verifica della posizione debitoria (Gateway G2.2.3) dando luogo a una diramazione del processo:

Nel caso venga eseguita la verifica l’Ente Creditore risponde (Task T2.2.5) fornendo i dati previsti riguardo lo stato della posizione debitoria, nonché le possibili variazioni dell’importo dovute ad eventi successivi all’invio dell’avviso. L’invocazione della funzione di verifica non ha effetti sullo stato della posizione debitoria. In caso di sussistenza della posizione debitoria l’Utilizzatore finale deve decidere se procedere (Gateway G2.2.2)
1. Se l’Utilizzatore finale rifiuta di procedere il processo termina (Task T2.2.4), senza alcuna segnalazione all’EC.
2. Se l’Utilizzatore finale decide di procedere, il PSP esegue l’incasso e il processo prosegue, nella seconda diramazione, con l’attivazione della RPT (Task T2.2.7) e la generazione di una RT positiva (Task T2.2.11)
Il PSP, che ha facoltà di non eseguire la diramazione precedente, richiede l’attivazione della RPT (Task T2.2.6). L’Ente Creditore risponde (Task T2.2.7) fornendo, come nel caso della funzione di verifica, i dati riguardo lo stato della posizione debitoria, nonché le possibili variazioni dell’importo dovute ad eventi successivi all’invio dell’avviso. L’invocazione della funzione di attivazione provoca l’invio della RPT e quindi ha effetto sullo stato della posizione debitoria che viene posta nello stato “In pagamento” dall’EC. il PSP chiede all’Utilizzatore finale di autorizzare il pagamento (Gateway G2.2.4):

Se il pagamento è autorizzato, il Prestatore di Servizi di Pagamento incassa il pagamento (Task T2.2.9) e genera una RT positiva (Task T2.2.11)
Se il pagamento non è autorizzato, il Prestatore di Servizi di Pagamento genera una RT negativa (Task T2.2.10)

Nel caso di emissione di ricevuta telematica positiva il Prestatore di Servizi di Pagamento consegna all’Utilizzatore finale un’attestazione di pagamento, contenente le informazioni specificate nella sezione III. Tale attestazione è opponibile all’EC.

Le ricevute telematiche vengono trasmesse al NodoSPC. Il NodoSPC mette la ricevuta telematica a disposizione dell’Ente Creditore (Task 2.2.12) che a sua volta può mettere a disposizione dell’Utilizzatore finale una ricevuta (Task T2.2.13).

L’Utilizzatore finale a questo punto può ottenere la ricevuta (Task T2.2.14) e terminare il processo.

Trasmissione dati di accredito e rendicontazione¶

Dopo aver effettuato il pagamento, il Prestatore Servizi di Pagamento accredita il conto dell’Ente Creditore specificato dalla richiesta di pagamento telematico ed invia al NodoSPC i dati relativi alla ricevuta telematica accreditata (Task T2.2.15

Nel caso che in cui venga effettuato un accredito cumulativo il Prestatore Servizi di Pagamento invia i dati relativi alla rendicontazione al NodoSPC (Task T2.2.16).

Il NodoSPC mette a disposizione i dati di rendicontazione per l’Ente Creditore (Task T2.2.17). Quando l’Ente Creditore scarica i dati di rendicontazione (Task T2.2.18).

Attivazione della richiesta di pagamento¶

Il NodoSPC non controlla l’effettiva sequenza operativa scelta dal Prestatore di Servizi di Pagamento, relativa alle fasi del processo descritte in precedenza: pertanto, un Prestatore di Servizi di Pagamento potrebbe effettuare la richiesta di attivazione della richiesta di pagamento telematico senza aver preventivamente effettuato la fase di verifica. Con questo approccio è sconsigliato far precedere l’incasso alla richiesta di attivazione della richiesta di pagamento telematico (Task T2.2.6), in quanto sul Sistema pagoPA non è gestito automaticamente il caso in cui l’Ente Creditore non riesca a inviare la richiesta di pagamento telematico prevista dal workflow: per esempio, nel caso in cui il pagamento sia già stato eseguito con un altro canale oppure perché l’importo dovuto sia diverso da quello stampato sull’avviso.

In questo caso il Prestatore di Servizi di Pagamento avrebbe incassato dei fondi ai quali non può essere associata una Ricevuta Telematica da inviare all’Ente Creditore. Per questo caso, nella sezione III, sono previste delle gestioni semi-manuali. A tal proposito si ricorda che, ai sensi delle Linee guida, i pagamenti effettuati attraverso il NodoSPC sono liberatori del debito a condizione che la Ricevuta Telematica sia congruente con le informazioni presenti sulla relativa richiesta di pagamento telematico e quindi sull’archivio dei pagamenti in attesa.

Funzioni accessorie¶

Revoca della Ricevuta Telematica¶

Qualora l’utilizzatore finale - ai sensi degli articoli 13 e 14 del decreto legislativo 27 gennaio 2010, n. 11, ovvero per richieste regolamentate connesse all’utilizzo di carte di pagamento (c.d.: procedura di charge back, nella quale non rientrano i casi di frode ma unicamente i casi in cui l’Utilizzatore finale richieda un rimborso per un pagamento effettuato a fronte di un servizio di cui non ha usufruito) chieda al proprio prestatore di servizi di pagamento il rimborso di un pagamento già completato, il Sistema pagoPA mette a disposizione di Prestatori di Servizi di Pagamento e Enti Creditori idonee funzionalità per gestire la revoca della ricevuta telematica inviata in precedenza.

Come indicato in Figura 1, la revoca della ricevuta telematica si esplica nell’invio di una richiesta di revoca (RR) da parte del Prestatore di Servizi di Pagamento, contenente i riferimenti della ricevuta telematica oggetto della revoca e nella risposta da parte dell’Ente Creditore contenente l’esito della revoca (ER).

bpmn_revoca

Figura 1: Il processo di revoca

Il processo è iniziato dall’Utilizzatore finale, che richiede la revoca al proprio Prestatore di Servizi di Pagamento (Task T3.1), a seguito della quale quest’ultimo inoltra la richiesta all’Ente Creditore (Task T3.2) attraverso il NodoSPC (Task T3.3).

L’Ente Creditore esamina la richiesta (Gateway G3.1):

L’Ente Creditore non consente la revoca di una ricevuta telematica se il pagamento associato è contestuale all’erogazione di un servizio (ad esempio: acquisto di biglietti per musei o trasporti pubblici, prestazioni sanitarie già eseguite, ecc.) inviando un ER di esito negativo (Task T3.4) che viene trasmesso dal NodoSPC al Prestatore di servizi di Pagamento (Task T3.5) e da questi all’Utilizzatore finale (Task T3.6) che apprende l’esito (Task T3.5)
In caso contrario l’Ente Creditore, entro tempi compatibili con il procedimento richiesto, esamina la richiesta e invia l’esito della revoca, aggiornando i propri archivi informatici e riaprendo la posizione debitoria se necessario (Task T3.8). L’esito positivo è trasmetto dal NodoSPC al Prestatore di Servizi di Pagamento (Task T3.9), il quale esegue il riaccredito verso l’Utilizzatore finale (Task T3.10), il quale lo riceve direttamente senza l’intervento del NodoSPC (Task T3.7). Il Prestatore di servizi di Pagamento recupera la somma dovuta compensandola sui successivi accrediti da effettuare verso l’Ente Creditore ed espone la cifra (negativa) sul successivo rendiconto (Task T3.11), che viene trasmesso all’Ente Creditore attraverso il NodoSPC (Task T3.12). A questo punto l’Ente Creditore è in grado di riconciliare correttamente gli importi (Task T3.13)

In ogni caso, l’Ente Creditore deve predisporre - e darne evidenza sul proprio sito attraverso il quale sono effettuati i pagamenti - apposite procedure amministrative di back-office al fine di gestire, nel rispetto della normativa vigente, i flussi relativi a reclami, rimborsi e revoche sia dal punto di vista amministrativo, sia dal punto di vista contabile.

Annullo tecnico¶

L’annullo tecnico è una casistica dell’invio di una richiesta di revoca che indica che la RT inviata è tecnicamente errata, dunque il Prestatore di Servizi di Pagamento può invocarla unicamente ricorra uno dei seguenti casi di errori procedurali:

Invio di una Ricevuta Telematica (RT) con esito positivo, tuttavia l’utilizzatore finale non ha ricevuto nessun addebito né il Prestatore di Servizi di Pagamento ha emesso alcuna attestazione di pagamento (scontrino, ricevuta, e-mail, ecc.);
Invio di una Ricevuta Telematica (RT) con esito negativo, tuttavia l’utilizzatore finale ha ricevuto un addebito e il Prestatore di Servizi di Pagamento ha emesso un’attestazione di pagamento (scontrino, ricevuta, e-mail, ecc.).

Il processo di annullo tecnico, descritto in Figura 2, è il seguente

image1

Figura 2: Processo di annullo tecnico

Il Prestatore di servizi di Pagamento invia la richiesta di annullo tecnico al NodoSPC (Task T4.1), che verifica la casistica del caso (Gateway G4.1):

Nel caso in cui sia stata inviata una ricevuta telematica positiva senza l’avvenuto pagamento, il nodo aggiorna lo stato del pagamento ed invia l’informazione all’Ente Creditore (Task T4.2), il quale aggiorna i suoi archivi informatici (Task T4.4)
Nel caso in cui sia stata inviata una ricevuta telematica negativa a fronte di un avvenuto pagamento, in NodoSPC invia l’informazione di effettuare l’annullo tecnico (Task T4.3) sia all’Ente Creditore, in quale aggiorna i propri archivi informatici (Task T4.4), che al Prestatore di servizi di Pagamento, il quale può procedere all’invio dell’accredito (Task T4.6), che viene ricevuto dall’Ente Creditore (Task T4.8) attraverso il NodoSPC (Task T4.7), che all’inoltro della rendicontazione (Task T4.9), che viene anch’esso ricevuto dall’Ente Creditore (Task T4.11) attraverso il NodoSPC (Task T4.10)

Storno del pagamento¶

Qualora l’Utilizzatore finale chieda a vario titolo l’annullamento (storno) di un pagamento all’Ente Creditore presso il quale questo è stato disposto, il sistema mette a disposizione dell’Ente Creditore e del Prestatore di Servizi di Pagamento idonee funzionalità del NodoSPC per gestire detta operazione.

L’Ente Creditore deve predisporre - e darne evidenza sul proprio sito attraverso il quale sono effettuati i pagamenti - apposite procedure amministrative di back-office al fine di gestire, nel rispetto della normativa vigente, le richieste di storno del pagamento ed i relativi flussi economici (Figura 3).

image2

Figura 3: Processo di storno di un pagamento

Il processo di storno viene iniziato dall’Utilizzatore finale che lo richiede all’Ente Creditore (Task T5.1)

L’Ente Creditore esamina la richiesta (Gateway G5.1):

In caso di esito negativo, l’Ente Creditore comunica l’informazione all’Utilizzatore finale (Task T5.2) che apprende l’esito (Task T5.3)
In caso contrario l’Ente Creditore, entro tempi compatibili con il procedimento richiesto, esamina la richiesta e invia l’esito dello storno, aggiornando i propri archivi informatici e riaprendo la posizione debitoria se necessario (Task T5.4). L’esito positivo è trasmesso dal NodoSPC al Prestatore di Servizi di Pagamento (Task T5.5), il quale esegue il riaccredito verso l’Utilizzatore finale (Task T5.6) che lo riceve direttamente senza l’intervento del NodoSPC (Task T5.7). Il Prestatore di Servizi di Pagamento recupera la somma dovuta compensandola sui successivi accrediti da effettuare verso l’Ente Creditore ed espone la cifra (negativa) sul successivo rendiconto (Task T5.8) che viene trasmesso all’Ente Creditore attraverso il NodoSPC (Task T5.8). A questo punto l’Ente Creditore è in grado di riconciliare correttamente gli importi (Task T5.10).

Attestazione del pagamento¶

L’attestazione di avvenuto pagamento è rappresentata dal documento informatico (Ricevuta Telematica) che l’Ente Creditore riceve dal Prestatore di Servizi di Pagamento.

L’Ente Creditore deve rendere disponibile, su richiesta dell’utilizzatore finale, tale documento, sia sotto forma di duplicato informatico che sotto forma di copia analogica dello stesso. Poiché nelle ricevute telematiche possono essere contenuti da 1 a 5 pagamenti aventi lo stesso ente beneficiario, sarà cura dell’Ente Creditore, se del caso, produrre tante copie analogiche quanti sono i pagamenti effettuati contenuti nella stessa ricevuta telematica.

Laddove l’Ente Creditore sia chiamato a predisporre un’attestazione del pagamento ricevuto da parte del pagatore e debba indicare in tale attestazione la data e l’orario del pagamento, si dovrà tenere conto della data e dell’orario dell’interazione che il pagatore ha eseguito per finalizzare il pagamento con l’Ente Creditore o con il PSP, rispettivamente per i pagamenti eseguiti presso l’Ente Creditore e per i pagamenti eseguiti presso il PSP.

In particolare, l’Ente Creditore dovrà comportarsi come segue:

per i pagamenti eseguiti presso l’Ente Creditore, fa fede la data e l’orario indicato nella RPT, a condizione ovviamente che tale RPT abbia dato come esito una RT positiva;
per i pagamenti eseguiti presso il PSP, fà fede la data e l’orario indicati nell’attestazione (scontrino) rilasciato dal PSP.

Nel caso di pagamento attivato presso il Prestatore di Servizi di Pagamento, questi fornisce direttamente all’Utilizzatore finale un documento (ricevuta, scontrino, ecc.) che rappresenta un estratto analogico del documento informatico che il Prestatore di Servizi di Pagamento invierà successivamente all’Ente Creditore. Tale documento può essere utilizzato dall’Utilizzatore finale per ottenere quietanza da parte dell’EC.

Le copie analogiche prodotte dall’Ente Creditore o dai Prestatori di Servizi di Pagamento devono necessariamente contenere, oltre al logo del Sistema pagoPA, almeno le seguenti informazioni:

Data e ora dell’operazione
Codice fiscale e denominazione dell’Ente Creditore
Identificativo univoco versamento (IUV) - Identificativo univoco assegnato dall’Ente Creditore
Codice identificativo del Prestatore di Servizi di Pagamento
Numero univoco assegnato al pagamento dal Prestatore di Servizi di Pagamento
Importo dell’operazione
Causale del versamento indicata nella richiesta di pagamento telematico.

Riconciliazione dei pagamenti¶

Con rifermento alle macro-fasi del processo, una volta effettuata la fase di “Regolamento contabile” da parte del Prestatore di Servizi di Pagamento, l’Ente Creditore provvede a riconciliare le ricevute telematiche (RT) con le informazioni contabili fornite dal proprio istituto tesoriere o da Poste Italiane in relazione agli incassi avvenuti sui c/c postali (ad esempio: Giornale di Cassa per le Pubbliche Amministrazioni che utilizzano il formato OIL/OPI; altre modalità per le Pubbliche Amministrazioni centrali che possono richiedere tali informazioni alla Ragioneria Generale dello Stato).

Secondo quanto indicato dalle Linee guida e dal suo Allegato A “Specifiche attuative dei codici identificativi di versamento, riversamento e rendicontazione”, il Prestatore di Servizi di Pagamento che riceve l’ordine dal proprio cliente o che esegue l’incasso per conto dell’Ente Creditore può regolare contabilmente l’operazione in modalità singola o in modalità cumulativa, il che comporta per l’Ente Creditore due diverse modalità di riconciliazione.

Riconciliazione in modalità singola¶

Qualora, a fronte di ogni singolo set di informazioni contenuto in una richiesta di pagamento, il Prestatore di Servizi di Pagamento effettui una singola disposizione di pagamento nei confronti dell’Ente Creditore per regolare contabilmente l’operazione (ad esempio: l’utilizzo della forma tecnica “bonifico di tesoreria”), si parla di riconciliazione in modalità singola.

L’operazione di riconciliazione in modalità singola viene effettuata dall’Ente Creditore sulla base della seguente coppia di informazioni presenti sulla ricevuta telematica inviata dal Prestatore di Servizi di Pagamento all’Ente Creditore:

Identificativo univoco versamento (IUV) che deve coincidere con la componente identificativo univoco versamento della causale della disposizione di accredito inviata al Prestatore di Servizi di Pagamento dall’Ente Creditore, secondo le indicazioni di cui alla Sezione I dell’Allegato A alle Linee guida;
ì-esima occorrenza del dato relativo al singolo importo pagato della Ricevuta Telematica che deve coincidere con il dato presente nell’informazione della disposizione di accredito inviata al Prestatore di Servizi di Pagamento dall’Ente Creditore.

Riconciliazione in modalità multipla¶

Qualora il Prestatore di Servizi di Pagamento effettui un’unica disposizione cumulativa di pagamento nei confronti dell’Ente Creditore per regolare contabilmente i pagamenti relativi agli esiti contenuti in una o più ricevute telematiche, si parla di Riconciliazione in modalità multipla che viene effettuata dall’Ente Creditore sulla base dei dati forniti dal proprio istituto tesoriere e di quelli contenuti nel flusso di rendicontazione che il Prestatore di Servizi di Pagamento deve inviare all’Ente Creditore stesso.

La riconciliazione in questo caso deve essere effettuata in due fasi:

nella prima fase il dato identificativo del flusso - presente nella causale del SEPA Credit Transfer inviato dal Prestatore di Servizi di Pagamento all’Ente Creditore - deve essere abbinato con quello presente nel Flusso di rendicontazione inviato all’Ente Creditore dal Prestatore di Servizi di Pagamento che ha eseguito i pagamenti.
Nella seconda fase della riconciliazione l’Ente Creditore abbinerà i dati contenuti nel Flusso di rendicontazione di cui sopra con i dati presenti nelle ricevute telematiche (RT) memorizzate presso di sé sulla base della seguente coppia di informazioni:
1. Identificativo univoco versamento presente sulla ricevuta telematica inviata all’Ente Creditore che deve coincidere con lo stesso dato presente nella struttura dati del Flusso di rendicontazione;
2. importo presente sulla ricevuta telematica inviata all’Ente Creditore che deve coincidere con il dato omonimo presente nella struttura dati del Flusso di rendicontazione.

Il NodoSPC fornisce apposite funzioni centralizzate a disposizione dei Prestatori di Servizi di Pagamento e degli Enti Creditori, con le quali i primi possono inviare il Flusso di rendicontazione e gli altri ricevere i dati ivi contenuti.

Pagamento contenente più accrediti¶

Qualora l’utilizzatore finale presenti al Prestatore di Servizi di Pagamento una RPT contenente più pagamenti ovvero presenti un “carrello” di richieste di pagamento telematico aventi più beneficiari, il Prestatore di Servizi di Pagamento deve effettuare un unico addebito verso l’Utilizzatore finale al quale attribuisce lo stesso identificativo univoco di riscossione: pertanto l’Ente Creditore dovrà opportunamente tenerne conto nelle proprie procedure applicative di riconciliazione.

Altre funzioni accessorie¶

Seppur meno utilizzate nella pratica comune, si citano di seguito alcune ulteriori funzione accessorie messe a disposizione dal Sistema pagoPA:

Richiesta di una copia della ricevuta telematica
Richiesta dell’elenco delle richieste di pagamento telematico pendenti
Gestione della ricevuta telematica di notifica decorrenza termini

I dettagli relativi alle suddette funzioni sono riportati nella sezione III

componenti tecniche del NodoSPC¶

Il NodoSPC definisce modalità standard per la gestione dei flussi finanziari:

adotta gli standard XML ISO 20022 per i tracciati dei flussi finanziari correlati alle singole operazioni;
introduce uno standard per la richiesta di pagamento telematico e per la ricevuta telematica di pagamento adottato a livello nazionale su qualunque

canale di pagamento, al fine di automatizzare la tratta G2B (Government to Bank);
nell’ambito delle attività legate al commercio elettronico abilita l’interconnessione con i circuiti internazionali di autorizzazione di tali

pagamenti;
assicura l’univocità del pagamento attraverso la definizione di un codice identificativo del pagamento (IUV). Al suddetto identificativo può essere

associato uno o più oggetti grafici (codice a barre, glifo, QR-code, ecc.), al fine di consentire e facilitare l’effettuazione del pagamento attraverso qualunque canale oggi esistente;
de-materializza tutte le ricevute di pagamento restituite all’Ente Creditore;
de-materializza gli avvisi di pagamento.

Nella Figura 1 sono evidenziate le componenti ed i soggetti che interagiscono tra di loro per consentire lo svolgersi del processo di pagamento telematico secondo i modelli descritti in precedenza.

image0

Figura 1: Schema architetturale del Sistema pagoPA

Gestore del Workflow Applicativo¶

È la macro-componente principale che ha lo scopo di coordinare l’esecuzione delle richieste di servizio, richiamando componenti di utilità (quali ad esempio, il modulo per la diagnostica) ed interfacciare l’infrastruttura di Rete SPC.È la macro-componente principale che ha lo scopo di coordinare l’esecuzione delle richieste di servizio, richiamando componenti di utilità quali ad esempio, il modulo per la diagnostica, e di interfacciare l’infrastruttura di Rete.

Il Gestore del Workflow Applicativo interfaccia sia le applicazioni degli Enti Creditori da cui provengono le richieste di servizio e a cui devono essere indirizzate le relative risposte applicative, sia i Prestatori di Servizi di Pagamento che abilitano il pagamento sui diversi canali.

Comprende vari agenti software tra cui i principali sono quelli che permettono:

la gestione del “Giornale degli Eventi” dove sono registrati - per ogni operazione - tutti gli scambi necessari alla corretta esecuzione del

processo;
la gestione del “Tavolo Operativo” dove sono monitorati tutti i componenti del sistema e lo stato di esecuzione delle operazioni;
l’indirizzamento ai singoli servizi e/o sotto-servizi in funzione delle richieste e delle risposte previste dai diversi modelli di funzionamento;
la memorizzazione e la gestione delle “richieste di servizio” per la tracciatura delle operazioni e la gestione delle eccezioni;
la gestione degli errori;
il mantenimento del sincronismo temporale.

Gestore della Connessione¶

La connessione al NodoSPC in applicazione al vigente modello di interoperabilità avviene nelle forme e nei metodi descritti nel documento collegato “Specifiche di Connessione al sistema pagoPA”, pubblicato sul sito istituzionale di AgID.

Gestore della Porta di Dominio¶

Questa componente, deprecata e mantenuta per retro compatibilità, si occupa dello scambio dei messaggi da e verso SPC per il colloquio con l’Ente Creditore secondo gli accordi di servizio stabiliti dalle regole tecniche SPCoop e pubblicati sui registri SICA. In coerenza con le logiche SPCoop, permette di reindirizzare i messaggi alle Pubbliche Amministrazioni aderenti a SPC anche in via indiretta attraverso le reti territoriali, eventualmente per mezzo di soggetti intermediari.

Tra le principali attività svolte dalla componente si richiamano, a titolo esemplificativo:

incapsulamento delle chiamate dei metodi Web service, rendendole disponibili in forma mediata verso la Porta di Dominio;
memorizzazione temporanea e trattamento, secondo la priorità indicata, dei messaggi verso la Porta di Dominio;
tracciamento dei riferimenti univoci dei messaggi;
trattamento degli header dei messaggi scambiati via Porta di Dominio ai fini della correlazione applicativa attuata dalla Porta di Dominio stessa;
gestione degli errori e delle conferme di natura trasmissiva;
generazione e propagazione dei messaggi d’errore di natura applicativa;
mantenimento di un proprio registro degli eventi finalizzato all’aggiornamento del Giornale degli Eventi;
mantenimento del sincronismo temporale.

Interfaccia di Canale¶

Le attività svolte da questa componente sono analoghe a quelle svolte dal gestore della Porta di Dominio per gli Enti Creditori, ma istanziate per il rapporto con i singoli Prestatori di Servizi di Pagamento. A tale scopo, il NodoSPC espone una modalità standard di colloquio verso i Prestatori di Servizi di Pagamento, descritta nella Sezione IV. Nel caso di peculiari modalità tecnico trasmissive richieste dai Prestatori di Servizi di Pagamento, sempre che di validità generale, possono essere realizzate allo scopo specifiche interfacce software.

Qualora il Prestatore di Servizi di Pagamento lo richieda, la componente permette di interfacciare il Prestatore di Servizi di Pagamento attraverso un intermediario (soggetto giuridico o circuito) scelto dallo stesso Prestatore di Servizi di Pagamento. Tutti gli oneri derivanti sono a carico del Prestatore di Servizi di Pagamento che mantiene la titolarità del rapporto con il NodoSPC.

Di seguito le principali attività svolte dalla componente:

incapsulamento delle chiamate al fine di renderle disponibili in forma mediata verso gli specifici canali;
memorizzazione temporanea dei messaggi applicativi verso i canali;
tracciamento dei riferimenti univoci dei messaggi memorizzati/inviati;
gestione degli errori e delle conferme di natura trasmissiva;
generazione e propagazione dei messaggi d’errore di natura applicativa;
mantenimento di un proprio registro degli eventi finalizzato all’aggiornamento del Giornale degli Eventi;
mantenimento del sincronismo temporale.

Repository ricevute telematiche¶

Il Repository costituisce l’archivio in cui sono memorizzate tutte le ricevute telematiche processate dal NodoSPC e non ancora consegnate, finalizzato al buon funzionamento del sistema.

Il Repository consente una verifica in merito al corretto trattamento dei flussi di pagamento del NodoSPC.

Componente Web-FESP¶

La componente “Web-FESP” permette di effettuare il pagamento reindirizzando l’Utilizzatore finalee verso una landing page messa a disposizione dal Prestatore di Servizi di Pagamento.

In questo caso:

il Prestatore di Servizi di Pagamento consente all’Utilizzatore finale di eseguire il pagamento con i diversi strumenti di pagamento;
la componente Web-FESP agisce da normalizzatore e provvede ad uniformare le informazioni ricevute, re-inviandole attraverso il NodoSPC all’Ente

Creditore per consentire di completare l’operazione di pagamento.

Componente WISP¶

La componente “WISP” (Wizard Interattivo di Scelta del Prestatore di Servizi di Pagamento) consente all’utilizzatore finale di effettuare la scelta del Prestatore di Servizi di Pagamento in modalità accentrata presso il NodoSPC, che mette a disposizione apposite pagine che standardizzano a livello nazionale la user experience dei pagamenti verso la Pubblica Amministrazione, garantendo ai Prestatori di Servizi di Pagamento aderenti che l’esposizione dei servizi da loro offerti sia proposta all’Utilizzatore finale attraverso schemi che consentano pari opportunità di trattamento, concorrenza e non discriminazione.

La componente WISP inoltre fornisce all’Utilizzatore finale funzioni di supporto introducendo vari accorgimenti per semplificare la user experience, anche nel caso di pagamento con dispositivi mobili. Inoltre l’Utilizzatore finale potrà memorizzare gli strumenti di pagamento utilizzati, evitando di dover effettuare una nuova ricerca nelle occasioni successive.

Componente per la gestione dell’avvisatura digitale in modalità push (DEPRECATO)¶

La gestione dell’avvisatura digitale in modalità push avviene attraverso l’utilizzo di componenti del NodoSPC che consentono:

agli Enti Creditori l’invio degli avvisi sia in modalità SFTP (File transfer sicuro), sia attraverso l’utilizzo di appositi web service;
ai Prestatore di Servizi di Pagamento di inviare via web service al NodoSPC le richieste di iscrizione al servizio;
al NodoSPC di:
- inviare gli avvisi digitali ai Prestatori di Servizi di Pagamento via web service;
- inviare gli avvisi digitali agli Utilizzatori finali tramite e-mail (protocollo SMTP);
- notificare ai servizi di Cittadinanza Digitale gli avvisi digitali (predisposizione per funzionalità future).

File Transfer sicuro¶

Il NodoSPC mette a disposizione dei soggetti aderenti una piattaforma client-server per il trasferimento sicuro dei dati in modalità File Transfer. Tale piattaforma sostituirà progressivamente l’utilizzo delle primitive oggi impiegate per lo scambio di informazioni in modalità massiva (ad esempio: i flussi di rendicontazione, i totali di traffico, ecc.).

Giornale degli Eventi¶

È la componente che raccoglie tutte le informazioni attinenti ad ogni singola operazione sintetizzando le registrazioni effettuate dalle singole componenti del NodoSPC: FESP; Web FESP; Repository, ecc.

Le principali attività svolte dalla componente riguardano:

la raccolta delle informazioni attinenti alle operazioni svolte dalle componenti del NodoSPC, come ad esempio:
- tipo di operazione (RPT; RT; …),
- identificativo univoco associato all’operazione,
- timestamp dell’evento e della registrazione, componente in cui si verifica l’evento (FESP; Web-FESP; Repository);
esposizione di un’interfaccia di interrogazione per l’accesso alle registrazioni degli eventi che consente:
- la selezione degli eventi in base a criteri di ricerca (tipo di operazione, id, ecc.),
- l’esame nel dettaglio di un evento selezionato;
- la disponibilità di dati di sintesi (totali di tipo di operazione per stato, per intervallo temporale, ecc.).

Componenti di utilità¶

Le componenti di utilità rappresentano un insieme di componenti “di servizio” invocate, in base alle necessità, dal Workflow Applicativo per svolgere ruoli informativi specifici e utilizzabili da più servizi applicativi all’interno del NodoSPC:

traduttore XML: struttura e assembla i messaggi XML dei servizi;
modulo crittografia: cifra/decifra informazioni e gestisce i certificati crittografici;
modulo diagnostico: effettua controlli di natura sintattica e alcuni controlli semantici.

Ognuna delle componenti di utilità, oltre ad attività specifiche alla propria funzione, svolge le attività di interfacciamento ed integrazione con il gestore del Workflow Applicativo.

Sistema di monitoring¶

Il sistema di monitoring svolge attività di controllo complessivo per quanto attiene alle tematiche di monitoraggio. Tale componente deve essere considerata come una entità logica indipendente, con un proprio workflow specifico e proprie regole di funzionamento, in grado, quindi, di verificare malfunzionamenti e condizioni di errore di qualsiasi altro modulo.

Nel sistema di monitoring è allocata la funzione di throttling che limita l’utilizzo del Sistema pagoPA oltre le possibilità di carico da cui possa conseguire il verificarsi di disservizi generali. Tale funzionalità viene innescata automaticamente nel caso in cui un Ente Creditore tenti di avviare, nell’unità di tempo, un numero di operazioni di pagamento superiori ai fabbisogni da esso stesso dichiarati. Le regole di throttling sono indicate nel documento “Indicatori di qualità per i Soggetti Aderenti” pubblicato sul sito istituzionale dell’Agenzia per l’Italia Digitale.

Sistema di Gestione del Tavolo Operativo¶

Il sistema ha lo scopo di fornire il supporto necessario alle attività del Tavolo Operativo, monitorando le altre componenti applicative e avendo accesso alle informazioni relative ad ogni richiesta di intervento.

Fra le funzioni di supporto al Tavolo operativo è messo a disposizione un sistema di Interactive Voice Response (IVR, Risposta Vocale Interattiva) per istradare le chiamate vocali, integrato a un sistema di trouble-ticketing per tracciare tutte le attività di assistenza.

Controlli¶

Tutti i flussi/dati scambiati e previsti dai Servizi di Nodo devono risultare conformi agli Standard di Servizio.

Qualora fosse riscontrata una mancata conformità a detti Standard di Servizio, il soggetto ricevente ha l’obbligo:

di bloccare l’esecuzione del relativo flusso elaborativo e di trattamento dei dati;
rendere disponibile un’evidenza dello stato del flusso a fronte di una eventuale situazione di blocco del flusso stesso.

Servizi applicativi opzionali¶

Rientrano in questa tipologia le funzioni che il Servizio mette a disposizione dei soggetti appartenenti al Dominio e che possono da questi essere utilizzate nell’ambito dello svolgimento delle proprie attività.

Totali di traffico¶

Il servizio di quadratura dei flussi di traffico mette a disposizione dei soggetti appartenenti al Dominio che ne facciano richiesta, un flusso periodico relativo a tutte le interazioni (RPT e RT) transitate attraverso il NodoSPC e di stretta pertinenza del singolo richiedente.

Il NodoSPC mette a disposizione dell’Ente Creditore e del Prestatore di Servizi di Pagamento gli strumenti per la ricezione di tali flussi.

Il periodo temporale durante il quale saranno disponibili i flussi relativi ai “Totali di Traffico” non potrà superare i 10 giorni di calendario e sarà comunque pubblicato sul sito dell’Agenzia per l’Italia Digitale.

Sezione 3 - Specifiche Tecniche¶

specifiche tecniche pagoPA

Questa sezione contiene una descrizione delle specifiche tecniche per l’integrazione di EC e PSP alla piattaforma pagoPA. I dettagli di tutte le interfacce e la documentazione di dettaglio è reperibile tramite il repository github [pagopa-api] (https://github.com/pagopa/pagopa-api) o in formato web tramite [portale degli sviluppatori](https://pagopa.github.io/pagopa-api/).

** Nota: All’interno della sezione, è possibile che vengano fatti esempi di scenari di pagamento. Questi devono essere presi come esempi e non indicano alcun comportamento verso l’EC. **

Specifiche Tecniche Generali¶

Stazioni e Canali¶

I soggetti aderenti EC e PSP, si connettono alla piattaforma per mezzo rispettivamente di stazioni e canali che rappresentano le piattaforma tecnologiche di partner ed intermediari connessi tramite public-internet o connessioni VPN dedicate.

Modello dei dati¶

Durante la descrizione delle interfacce si farà riferimento ad alcune informazioni le cui relazioni vengono mostrate dal seguente diagramma

modello dei dati

Posizione Debitoria : rappresenta l’entità ( il servizio ) per la quale l’EC vuole ricevere pagamenti tramite la piattaforma. E’ identificato in maniera univoca dalla coppia codice-fiscale / numero avviso.

Avviso di Pagamento : rappresenta la notifica (cartacea o digitale ) della posizione debitoria verso il cittadino.

Pagamento ( o Richiesta di Pagamento ) : descrive nel dettaglio l’operazione di pagamento correlata ad un avviso e contiene informazioni di incasso e di accredito.

Ricevuta : descrive l’esito di un pagamento, contiene i dettagli dell’incasso e la previsione dell’accredito. Contiene al suo interno anche il riferimento all’avviso di pagamento.

Flusso di Rendicotnazione : dettaglia il riversamento effettuato verso i conti correnti di un EC da parte di un PSP. Contiene l’elenco di tutti i pagamenti ( o quota parte ).

Carrello di pagamento : un insieme di pagamenti.

Autenticazione¶

Ogni connessione verso la piattaforma avviene tramite canale HTTPS con mutua autenticazione. Per dettagli di come instaurare la connessione con la piattaforma vedi ( link )

Autenticazione EC¶

Ogni chiamata verso la piattaforma pagoPA è autenticata per mezzo di due parametri contenuti all’interno del body del messaggio SOAP:

identificativoStazioneIntermediarioPA : identificativo della stazione configurata all’interno del PDA, che rappresenta il client dell’EC.
password : password associata alla stazione

Qualsiasi messaggio viene autorizzato verificando che la stazione riportata sia stata configurata all’interno della piattaforma e la password sia valida.

Autenticazione PSP¶

Ogni chiamata verso la piattaforma pagoPA è autenticata per mezzo di tre parametri contenuti all’interno del body del messaggio SOAP:

-idPSP : identificativo del PSP per conto del quale si sta effettuando la chiamata -intermeidBrokerPSPdiarioPSP : identificativo dell’intermediario che sta effettuando la chiamata -idChannel : identificativo del canale utilizzato per effettuare la chiamata -password : password del canale

Qualsiasi messaggio viene autorizzato verificando che il canale dell’intermediario sia associato al PSP indicato all’interno della configurazione della piattaforma e la password sia valida.

Sezione 3 - Specifiche Tecniche EC¶

Quest’area raccoglie tutte le specifiche tecniche di riferimento per un EC

Pagamento On-Line¶

Tramite la piattaforma pagoPA, un EC può innescare un pagamento on-line di uno o più posizioni debitorie (carrelli).

pagamento on line

l’EC compone il carrello di richieste di pagamento delle posizioni debitorie tramite la primitiva nodoInviaCarrelloRPT. Ogni RPT contenuta all’interno del messaggio descrive il pagamento di una posizione debitoria.
la piattaforma crea una sessione di pagamento
la piattaforma pagoPA restituisce la checkout url a cui rendirizzare il browser dell’utente per eseguire il pagamento.
Il browser dell’utente viene redirezionato verso la url ottenuta corredandola eventualmente dei query parameter di lingua e logo.
Viene mostrata la landingPage del WISP
L’utente naviga la webapp denominata WISP per l’autenticazione e la selezione dello strumento di pagamento. E’ possibile eseguire operazioni di pagamento sia in modalità anomina (inserendo esclusivamente una mail) oppure in modalità registrata utilizzando credenziali SPID.
viene eseguito il pagamento utilizzando lo strumento utilizzato.
Al termine delle operazioni on-line, l’utente viene re-indirizzato sulla pagina dell’EC impostata in configurazione (vedi link ) corredata dall’esito dell’operazione.
l’EC riceve inoltre una ricevuta telematica che descrive l’intera operazione di pagamento.
l’EC comunica la ricezione della ricevuta.

Descrizione UX ( WISP )¶

Il WISP (Wizard Interattivo di Scelta del Prestatore di Servizi di Pagamento) è un’applicazione web che consente ad un utente la navigazione degli strumenti di pagamento resi disponibili dai PSP aderenti alla piattaforma pagoPA.

Tutte gli strumenti di pagamento sono raggrupati in tre categorie :

Pagamento con carte : attraverso questa sezione è possibile effettuare un pagamento con una carta di credito/debito abilitata a pagamenti on-line.
Addebito conto corrente: all’interno di questa categorie sono raccolti strumwenti di pagamento che permettono l’interazione con l’home-banking del proprio istituto bancario.
Altri Metodi : all’interno di questa categoria rientrano strumenti di pagamento elettronici.

La navigazione del WISP può avvenire sia in modalità anomina ( verrà richiesta una mail dove inviare l’esito dell’operazione ), oppure come utente registrato utilizzando le proprie credenziali SPID ( livello 2 ).

Per gli utenti registrati sarà possibile salvare lo strumento di pagamento utilizzato per poterlo selezionare più velcemente durante i prossimi pagamenti.

Selezione della Lingua¶

Il WISP supporta 5 lingue :

Italiano ( default)
Inglese
Francese
Sloveno
Tedesco

l’EC può selezionare la lingua di avvio del WISP aggiungendo il query-parameter lang. I valori ammessini sono :

it ( it-IT ) : Italiano
en ( en-US ) : Inglese
fr ( fr-FR ) : Francese
sl ( sl-SI ) : Sloveno
de ( de-DE ) : Tedesco

Qualora il paramentro non sia presente o errato, verrà proposta la lingua di default

Personalizzazione del logo¶

E’ possibile sostituire il logo pagoPA all’interno della landing-page del WISP con un proprio logo ( formato 220x220 , png/jpg ) inserendo il query-parameter logo valorizzato con l’identificativo del logo caricato all’interno del Portale delle Adesioni, sezione EC->Gestione Logo.

Compatibilità Browser¶

Lo sviluppo del WISP segue le linee guida di design per i servizi digitali della PA.

In particolare viene assicurata la compatibilità con versioni dei browser che abbiano una penetrazione media tra la popolazione di almeno 1 persona ogni 100 abitati

Ciò significa che con i dati disponibili oggi ( Dicembre 2020 ) i browser supportati sono :

Chrome
Safari
Firefox
Samsung Internet
Edge
Opera

Nota: il browser Internet Explorer 11 (IE-11) non rientra tra la lista dei browser supportati. Nel dettaglio, IE-11 non supporta gli standard web moderni ed è un freno all’implementazione all’interno delle nostre piattaforme di API web moderne e misure di sicurezza più avanzate rispetto a quanto disponibile nel 2015

Pagamento multi beneficiario¶

E’ possibile che per talune posizioni debitorie la somma totale del debito debba essere ripartita tra più Enti Creditori ( tutti aderenti alla piattaforma pagoPA).

In tali casi la stessa posizione debitoria dovrà essere scomposta in diverse RPT ognuna delle quali afferente ad un Ente Creditore coinvolto, tenendo conto delle seguenti osservazioni:

la prima RPT dell’elenco dovrà essere riferita all’EC che sta inizializzando il carrello.
Ogni RPT dovrà contenere la descrizione della quota parte di pagamento del singolo EC.
Ogni RPT contiene conti di accredito intestati all’EC a cui è riferita l’RPT.

Le ricevute di tale pagamento saranno consegnate a :

alla stazione dalla quale è partita la richiesta di pagamento
tutte le stazioni degli EC coinvolti e dedite alla ricezione di pagamento per conto terzi ( paramentro della stazione broadcast )

Esempio : Prendiamo ad esempio il pagamento di un tributo TARI/TEFA pari ad un totale di 110 EUR. In tale scenario il comune ( codice fiscale 777777777 ) dovrà istruire un pagamento per l’accredito del contributo TARI (100 EUR) verso lo stesso comune, ed il contributo TEFA ( 10EUR ) verso la sua provincia di competenza ( codice fiscale 999999999 ).

Il carrello dovrà essere così composto da due RPT così composte

RPT1

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RPT xmlns="http://www.digitpa.gov.it/schemas/2011/Pagamenti/">
  <versioneOggetto>6.2.0</versioneOggetto>
  <dominio>
    <identificativoDominio>77777777777</identificativoDominio>
  </dominio>
  <identificativoMessaggioRichiesta>...</identificativoMessaggioRichiesta>
  <dataOraMessaggioRichiesta>...</dataOraMessaggioRichiesta>
  <autenticazioneSoggetto>...</autenticazioneSoggetto>
  <soggettoVersante> ... </soggettoVersante>
  <soggettoPagatore>... </soggettoPagatore>
  <enteBeneficiario>
    <identificativoUnivocoBeneficiario>
      <tipoIdentificativoUnivoco>G</tipoIdentificativoUnivoco>
      <codiceIdentificativoUnivoco>77777777777</codiceIdentificativoUnivoco>
    </identificativoUnivocoBeneficiario>
    <denominazioneBeneficiario>Comune</denominazioneBeneficiario>
    <indirizzoBeneficiario>....</indirizzoBeneficiario>
    <civicoBeneficiario>..</civicoBeneficiario>
    <capBeneficiario>...</capBeneficiario>
    <localitaBeneficiario>...</localitaBeneficiario>
    <provinciaBeneficiario>...</provinciaBeneficiario>
    <nazioneBeneficiario>...</nazioneBeneficiario>
  </enteBeneficiario>
  <datiVersamento>
    <dataEsecuzionePagamento>...</dataEsecuzionePagamento>
    <importoTotaleDaVersare>100.00</importoTotaleDaVersare>
    <tipoVersamento>BBT</tipoVersamento>
    <identificativoUnivocoVersamento>...</identificativoUnivocoVersamento>
    <codiceContestoPagamento>...</codiceContestoPagamento>
    <ibanAddebito>...</ibanAddebito>
    <firmaRicevuta>0</firmaRicevuta>
    <datiSingoloVersamento>
      <importoSingoloVersamento>100.00</importoSingoloVersamento>
      <ibanAccredito>...</ibanAccredito>
      <ibanAppoggio>...</ibanAppoggio>
      <credenzialiPagatore>n/a</credenzialiPagatore>
      <causaleVersamento>...</causaleVersamento>
      <datiSpecificiRiscossione>...</datiSpecificiRiscossione>
    </datiSingoloVersamento>
  </datiVersamento>
</RPT>

RPT 2

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RPT xmlns="http://www.digitpa.gov.it/schemas/2011/Pagamenti/">
  <versioneOggetto>6.2.0</versioneOggetto>
  <dominio>
    <identificativoDominio>77777777777</identificativoDominio>
  </dominio>
  <identificativoMessaggioRichiesta>...</identificativoMessaggioRichiesta>
  <dataOraMessaggioRichiesta>...</dataOraMessaggioRichiesta>
  <autenticazioneSoggetto>...</autenticazioneSoggetto>
  <soggettoVersante> ... </soggettoVersante>
  <soggettoPagatore>... </soggettoPagatore>
  <enteBeneficiario>
    <identificativoUnivocoBeneficiario>
      <tipoIdentificativoUnivoco>G</tipoIdentificativoUnivoco>
      <codiceIdentificativoUnivoco>999999999</codiceIdentificativoUnivoco>
    </identificativoUnivocoBeneficiario>
    <denominazioneBeneficiario>Provincia</denominazioneBeneficiario>
    <indirizzoBeneficiario>....</indirizzoBeneficiario>
    <civicoBeneficiario>..</civicoBeneficiario>
    <capBeneficiario>...</capBeneficiario>
    <localitaBeneficiario>...</localitaBeneficiario>
    <provinciaBeneficiario>...</provinciaBeneficiario>
    <nazioneBeneficiario>...</nazioneBeneficiario>
  </enteBeneficiario>
  <datiVersamento>
    <dataEsecuzionePagamento>...</dataEsecuzionePagamento>
    <importoTotaleDaVersare>10.00</importoTotaleDaVersare>
    <tipoVersamento>BBT</tipoVersamento>
    <identificativoUnivocoVersamento>...</identificativoUnivocoVersamento>
    <codiceContestoPagamento>...</codiceContestoPagamento>
    <ibanAddebito>...</ibanAddebito>
    <firmaRicevuta>0</firmaRicevuta>
    <datiSingoloVersamento>
      <importoSingoloVersamento>10.00</importoSingoloVersamento>
      <ibanAccredito>...</ibanAccredito>
      <ibanAppoggio>...</ibanAppoggio>
      <credenzialiPagatore>n/a</credenzialiPagatore>
      <causaleVersamento>...</causaleVersamento>
      <datiSpecificiRiscossione>...</datiSpecificiRiscossione>
    </datiSingoloVersamento>
  </datiVersamento>
</RPT>

Marca da Bollo ( @e.bollo )¶

Tramite la piattaforma pagoPA è possibile richiedere pagamenti di posizioni debitorie che contengano una marca da bollo digitale ( @e.bollo ).

Per poter inserire il pagamento di una marca da bollo, è necessario compilare il campo datiMarcaBolloDigitale all’interno dell’RPT avendo cura di inserire:

tipoBollo : tipologia del bollo
hashDocumento : Contiene l’impronta informatica (digest), rappresentata in “base 64 binary”, del documento informatico o della segnatura di protocollo cui è associata la marca da bollo digitale
provinciaResidenza : Sigla automobilistica della provincia di residenza del soggetto pagatore.

Inoltre la RPT non deve contenere, nella struttura datiSingoloVersamento relativa alla Marca da Bollo Digitale, la valorizzazione del parametro ibanAccredito.

Per maggiori dettagli su @e.bollo, valdità e casi d’uso , fare riferimento alla sezione sul dell’Agenzia delle Entrate.

Convenzioni con PSP¶

pagoPA disintermedia l’associazione tra EC e PSP, ciò vuol dire che che l’EC non deve necessariamente più stipulare convenzioni con alcun PSP al fine di poter disporre di strumenti di pagamento al cittadino. Ogni cittadino / utilizzatore della piattaforma potrà selezionare lo strumento di pagamento tra tutti quelli offerti tra i PSP aderenti per completare l’operazione di pagamento.

Ciò nonostante, viene comunque consentita la possibilità di stipulare convenzioni specifiche con uno o più PSP al fine di poter offrire strumenti di pagamento ad un costo di commissioni agevolato.

Per poter usufruire di una convenzione in essere tra PSP ed EC è necessario inserire all’interno della primitiva nodoInviaCarrelloRPT

Esempio : Request

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ppt="http://ws.pagamenti.telematici.gov/ppthead" xmlns:ws="http://ws.pagamenti.telematici.gov/">
   <soapenv:Header>
      <ppt:intestazioneCarrelloPPT>
         <identificativoIntermediarioPA>90000000001</identificativoIntermediarioPA>
         <identificativoStazioneIntermediarioPA>90000000001_01</identificativoStazioneIntermediarioPA>
         <identificativoCarrello>IUV5129-2020-07-23-12:21:26.581</identificativoCarrello>
      </ppt:intestazioneCarrelloPPT>
   </soapenv:Header>
   <soapenv:Body>
      <ws:nodoInviaCarrelloRPT>
         <password>pwdpwdpwd</password>
         <identificativoPSP>AGID_01</identificativoPSP>
         <identificativoIntermediarioPSP>97735020584</identificativoIntermediarioPSP>
         <identificativoCanale>97735020584_02</identificativoCanale>
         <listaRPT>
            <elementoListaRPT>
               <identificativoDominio>90000000001</identificativoDominio>
               <identificativoUnivocoVersamento>0000000000000010101</identificativoUnivocoVersamento>
               <codiceContestoPagamento>CCD01</codiceContestoPagamento>
               <rpt>....</rpt>
            </elementoListaRPT>
         </listaRPT>
         <codiceConvenzione>CONV1</codiceConvenzione>
      </ws:nodoInviaCarrelloRPT>
   </soapenv:Body>
</soapenv:Envelope>

Response:

<soapenv:Envelope xmlns:ppthead="http://ws.pagamenti.telematici.gov/ppthead" xmlns:tns="http://NodoPagamentiSPC.spcoop.gov.it/servizi/PagamentiTelematiciRPT" xmlns:ppt="http://ws.pagamenti.telematici.gov/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <ppt:nodoInviaCarrelloRPTRisposta>
         <esitoComplessivoOperazione>OK</esitoComplessivoOperazione>
         <url>[urlWisp2.0]/wallet/welcome?idSession=bd0e73e0-1890-4157-a471-6098925cc1b4</url>
      </ppt:nodoInviaCarrelloRPTRisposta>
   </soapenv:Body>
</soapenv:Envelope>

Una volta rendirizzato l’utente verso l’url ottenuta in risposta, il WISP mostrerà gli strumenti di pagamento con commissioni in linea con il codiceConvenzione indicato.

Qualora la convenzione in essere tra EC e PSP indichi eventuali costi di transazione a carico dell’Ente Creditore, le RT generate conterranno il paramentro commissioniApplicatePA valorizzato con l’importo da sostenere dall’EC creditore.

Avviso di Pagamento¶

Tramite la piattaforma pagoPA, un EC può innescare un pagamento presso un qualsiasi canale dei PSP aderenti tramite un codice numero avviso abbinato al codice fiscale dell’EC.

Il numero avviso è composto da 18 caratteri e deve identificare in maniera univoca la posizione debitoria all’interno degli archivi dell’EC. Tenuto conto che ogni EC può connettersi alla piattaforma tramite uno o più stazioni e che ogni stazione potrebbe gestire un insieme ( disgiunto ) di posizioni debitorie, il numero avviso dovrà essere composto seguendo il seguente pattern

<aux-digit>(1n)<position-global-id>(17)

L’ aux-digit ( che può assumere i valori 0,1,3 ) codifica il tipo di configurazione dell’EC alla piattaforma, a seconda del suo valore il campo position-global-id può assumere codifiche differenti.

aux-digit=1¶

l’EC dispone di un unica stazione, pertanto il position-global-id identifica in maniera univoca la posizione debitoria all’interno dell’EC.

Aux-digit 3 o 0¶

l’EC dispone di diverse stazioni, l’identificazione della posizione debitoria è composta da:

<station-id>(2n)<position-local-id>(13n)<check-digit>(2n)

station-id : identificativo della stazione all’interno della quale risiede la posizione debitoria.
position-local-id : identificativo univoco della posizione debitoria all’interno della stazione.
check-digit : codice di controllo del numero avviso.

check-digit¶

il check-digit viene calcolato come resto della divisione per 93 del numero ottenuto concatenando tutti i caratteri precedenti

Verifica di una posizione debitoria¶

un EC connesso alla piattaforma deve offrire il servizio di interrogazione delle proprie posizioni debitorie con la primitiva paaVerifyPaymentNotice;

Ogni posizione debitoria ottenuta, può contenere più opzioni di pagamento. Ogni opzione di pagamento definisce un importo, data di scadenza, ed una descrizione.

I casi più comuni sono :

Rateizzazione della posizione debitoria
Opzione multipla di pagamento
Pignoramenti/ Acconti

Rateizzazione della posizione debitoria¶

In tale scenario, il medesimo avviso di pagamento fà riferimento ad una posizione debitoria la quale può essere pagata in una soluzione unica oppure con un piano rateale. Prendiamo ad esempio il pagamento del tributo TARI dell’anno 2021 per il quale il comune vuole mettere a disposizione le seguenti opzioni:

rata unica pari a 100EUR con scadenza entro 31/03/2021
prima rata semestrale , pari a 50EUR con scadenza 30/06/2021
seconda rata semestrale , pari a 50 EUR con scadenza 31/12/2021

Attraverso la paaVerifyPaymentNotice l’EC viene interrogato per verificare quali sono contestualmente le opzioni disponibili al cittadino, ad esempio

Se interrogato in data antecedente al 31/03/2021, la risposta dovrebbe contenere solamente le opzioni rata unica e prima rata semestrale.

Nel caso l’utente non effettui alcun pagamento entro la data di scadenza della rata unica, qualora l’EC venisse interrogato in data successiva al 31/03/2021, l’unica opzione disponibile sarebbe la prima rata semestrale (l’opzione rata unica risulterebbe scaduta e l’opzione di pagamento seconda rata dovrebbe essere mostrata solamente dopo il pagamento della prima rata )

Nel caso invece l’utente abbia pagamento la rata unica, da quel momento in poi la posizione debitoria risulterebbe pagata e quindi senza alcun opzione di pagamento.

Nel caso in cui l’utente effettui il pagamento della prima rata, l’unica opzione disponibile ( dal momemto della ricezione della ricevuta ) sarà la seconda rata semestrale.

Opzione Multipla di Pagamento¶

In tale scenario il medesimo avviso di pagamento fà riferimento ad una posizione debitoria il cui ammontare può variare a seconda delle condizioni al contorno. Prendiamo ad esempio il caso di un pagamento di una multa stradale che tipicamente prevede tre opzioni di pagamento :

pagamento scontato del 30%, se pagato entro 5gg dalla notifica
pagamento dell’importo totale riportato nell’avviso se pagato entro 60gg dalla notifica
pagamento con more se pagamento oltre i 60gg dalla notifica

Solitamente non essendo nota a priori la data di notifica, la data di scadenza delle opzioni di pagamento è puramente indicativa.

Attraverso la paaVerifyPaymentNotice verranno quindi proposte tutte le opzioni disponibili fino a quando non si verifichi uno dei seguenti eventi :

viene notificata una ricevuta di pagamento, pertanto la posizione debitoria risulta chiusa e nessuna opzione di pagamento disponibile.
l’EC diviene in possesso della data di notifica, pertanto può aggiornare le opzioni di pagamento inserendo la data di scadenza corretta per ognuna delle opzioni.

Pignoramenti/ Acconti¶

In tale scenario l’avviso di pagamento fa riferimento ad una posizione debitoria la quale indica un importo figurativo , ma ammette la possibilità che sia l’utente , di volta in volta, a definire l’importo da versare. La posizione debitoria si considererà conclusa una volta raggiunta la somma totale riportata all’interno dell’avviso. Prendiamo ad esempio il caso di un pignoramento, dove l’avviso di pagamento viene notificato, ma l’utente ha disponibilità solo parziale dell’importo richiesto.

In tal caso esiste un unica opzione di pagamento che specifica un importo totale il quale può ammettere valori minori al dato mostrato. Pertanto una qualsiasi richiesta di pagamento verrà accettata per importi anche diversi ( <= ) da quello riportato all’interno della risposta della chiamata.

paaVerificaRPT¶

L’interfaccia paaVerificaRPT già contenuta nelle prcedenti versioni, continuerà ad essere utilizzata e supportata sino al 31/12/2021.

Richiesta di un pagamento¶

Un EC connesso alla piattaforma deve offire un servizio il quale restituisce un pagamento legato ad una posizione debitoria attraverso la funzione getPayment

Ogni richiesta viene specificata attraverso i paramentri amount e due_date che sono stati restituiti dalla paaVerifyPayment ed un altro paramentro transferType che definisce il tipo di accredito che il PSP vorrebbe disporre ( attualmente l’unica opzione è la necessità di un conto corrente postale).

Nel caso questi paramentri non siano presenti, sarà l’EC ad impostare l’importo attualizzato.

In risposta, l’EC resitutisce tutti i dati necessari per il pagamento ed autorizza la piattaforma a proseguire con l’eventuale incasso ed accreditamento delle somme. In aggiunta, l’EC può definire una data di validità delle informazioni inviate. Se presente, la piattaforma sarà autorizzata a gestire autonomamente richieste similari senza necessariamente contattare l’EC.

paaAttivaRPT¶

L’interfaccia paaAttivaRPT già contenuta nelle prcedenti versioni, continuerà ad essere utilizzata e supportata sino al 31/12/2021.

paaAttivaRPT

la piattaforma richiede un occorrenza di pagamento ( distinta da un codice di contesto pagamento ) all’EC tramite la primitiva paaAttivaRPT specificando l’avviso di pagamento ( identificato da IUV e CF ).
l’EC verifica lo stato della posizione debitoria correlata e restituisce i dati necessari per il pagamento ( importo ed iban di accreditamento)
Successivamente, l’EC invia una richiesta di pagamento ( RPT ) contenente tutti i dettagli del pagamento.

Ricevute di pagamento¶

A fronte di qualsiasi pagamento avvenuto sulla piattaforma viene generata e notificata tempestivamente una ricevuta che attesta il pagamento avvenuto con i riferimenti alla posizione debitoria e con i dettagli.

Le ricevute vengono inviate:

nel caso di pagamento online alla stazione richiedente del pagamento
nel caso di pagamento tramite avviso di pagamento alla stazione indicata all’interno dell’avviso
a tutte le stazioni identificate come “broadcast” qualora l’ente-beneficiario contenuto all’interno del pagamneto non sia ssociato alle stazioni descritte precedentemente.

Per poter ricevere tali ricevute, l’EC deve disporre dell’operazione sendRT e paaInviaRT.

La piattaforma tenterà per 5 volte di inviare ls ricevuta all’EC. In caso di mancata notifica della ricevuta verrà attivato il tavolo operativo ed eventualmente ripristinata l’operazione di invio.

Nota : le ricevute non possono essere rifiutate, l’esistenza della ricevuta stessa attesta l’avvenuto pagamento secondo i processi descritti e notifica future operazioni di accreditamento. Eventuali storni/annulli dovranno essere gestiti direttamente dall’EC.

Rendicontazione ed Accredito¶

Ogni PSP aderente alla piattaforma, a D+2 rendiconta il dettaglio dei riversamenti effettuati verso i conti di accredito dei pagamenti avvenuti nella giornata operativa S.

l’EC può recuperare i flussi di rendicontazione prodotti seguendo il seguente scehma

sd_ec_richiesta_flussi

l’EC richiede l’elenco dei flussi di rendicontazione disponibili
la piattaforma restituisce l’elenco dei flussi di rendicontazione
l’EC richiede puntualmente ogni flusso di rendicontazione presente all’interno della lista
la piattaforma restituisce il flusso di rendicontazione ed elimina il flusso dall’elenco dei flussi disponibili.

Il Flusso di rendicontazione ottenuto descrive l’elenco dei pagamenti (datiSingoloPagamento) riversati, ognuno dei quali è associabile ad una ricevuta di pagamento.

ricevuta tramite paaInviaRT¶

L’interfaccia paaInviaRT già contenuta nelle prcedenti versioni, continuerà ad essere utilizzata e supportata sino al 31/12/2021. In tali casi, è possibile rintracciare la ricevuta di un versamento contenuto all’interno del flusso di rendicontazione tramite i parametri :

identificativoUnivocoVersamento
identificativoUnivocoRiscossione

La ricevuta potrebbe contenere diversi versamenti, per identificare il versamento corrispondente è possibile utilizzare il campo indiceDatiSingoloPagamento.

ricevuta paSendRT¶

E’ possibile rintracciare la ricevuta di un cersamento contenuto all’interno del flusso di rendicontazione tramite il parametro identificativoUnivocoRiscossione che conterrà il valore del campo request-id della ricevuta.

La ricevuta potrebbe contenere diversi versamenti, per identificare il versamento corrispondente è possibile utilizzare il campo indiceDatiSingoloPagamento che conterrà il valore del trasfer-id all’interno della ricevuta.

Sezione 4 - Adesione¶

adesione al sistema pagoPA

SEZIONE IV – PROCESSO DI ADESIONE ED ESERCIZIO

Adesione al sistema pagoPA¶

Le Pubbliche Amministrazioni sono tenute per legge ad aderire al sistema di pagamento pagoPA. Le PA che non hanno rapporti diretti con cittadini e imprese, possono essere esentate dall’adesione al sistema, purché abbiano inviato ad AgID la specifica dichiarazione per tale esenzione disponibile sul sito dell’Agenzia.

L’obbligo di adesione al sistema pagoPA è esteso anche ai gestori di pubblici servizi e alle società a controllo pubblico. Il D.Lgs. n. 179/2016 (G.U. n. 214 del 13.9.2016) e il D.Lgs n. 217/2017 (G.U. n. 9 del 12.01.2018) hanno rispettivamente modificato e corretto l’articolo 2, comma 2, del CAD introducendo nel perimetro soggettivo del CAD anche i gestori di pubblici servizi e le società a controllo pubblico, come definite nel decreto legislativo adottato in attuazione dell’articolo 18 della legge n. 124 del 2015, escluse le società quotate. Il D.Lgs. n. 175/2016, all’articolo 2, lettera m), ha delineato il concetto di società a controllo pubblico. In particolare, le società a controllo pubblico sono definite come quelle società in cui una o più amministrazioni pubbliche esercitano poteri di controllo ai sensi dell’articolo 2359 del codice civile.

I Prestatori di Servizi di Pagamento (PSP), come le banche, le poste, gli istituti di pagamento e ogni altro soggetto abilitato da Banca d’Italia ad eseguire servizi di pagamento, aderiscono su base volontaria al sistema pagoPA per erogare i propri servizi di pagamento a cittadini e imprese.

Il Decreto legislativo 13 dicembre 2017, n. 217 (G.U. n. 9 del 12.01.2018) a correzione del CAD, ha introdotto all’articolo 65, comma 2, del Codice «L’obbligo per i prestatori di servizi di pagamento abilitati di utilizzare esclusivamente la piattaforma di cui all’articolo 5, comma 2, del decreto legislativo n. 82 del 2005 per i pagamenti verso le pubbliche amministrazioni decorre dal 1° gennaio 2019». Pertanto, i PSP autorizzati ad operare in Italia dalla Banca d’Italia non potranno in alcun modo eseguire servizi di pagamento che non transitino per il sistema pagoPA, ove abbiano come beneficiario un soggetto pubblico che risulti obbligato all’adesione al sistema.

Pertanto, i soggetti pubblici obbligati all’adesione a pagoPA, alla data del 1 gennaio 2019, ove non aderenti ancora a pagoPA, non potranno più incassare in proprio attraverso l’attività di un PSP, salvo l’affidamento di tutte le loro entrate ad un riscuotitore speciale che sia già aderente a pagoPA.

L’adesione a pagoPA avviene con procedure e modalità definite da AgID e disciplinate nelle Linee Guida. L’iter è differenziato per tipologia di soggetto aderente (Ente Creditore o Prestatore di Servizi di Pagamento) e può avvenire, per entrambe le tipologie, sia in modalità diretta che in modalità indiretta. Le indicazioni relative alla procedura di adesione da parte degli Enti Creditori e dei Prestatori di Servizi di Pagamento sono disponibili sul sito istituzionale dell’Agenzia.

La procedura di adesione:

Individua gli obblighi e le responsabilità inerenti l’utilizzo del Sistema pagoPA;
Consente il censimento degli Enti Creditori (PA, gestori di pubblici servizi e società a controllo pubblico) e dei PSP aderenti al Sistema pagoPA nel dominio gestito dal sistema stesso;
Prevede la comunicazione da parte degli Enti Creditori aderenti dei dati di configurazione necessari alla fruizione del servizio, ivi inclusi i codici IBAN dei conti di accredito;
Prevede la comunicazione da parte dei Prestatori di Servizi di Pagamento dei dati necessari alla fruizione del servizio, come specificati nell’Accordo di servizio.

Adesione di un Ente Creditore.¶

Per aderire a pagoPA in qualità di Ente Creditore, le PA, i gestori di pubblici servizi e le società a controllo pubblico devono utilizzare il Portale delle Adesioni che rende disponibili funzionalità per la compilazione, in via automatica, della lettera di adesione e l’invio della stessa all’Agenzia per l’Italia Digitale.

Il Portale delle Adesioni è uno strumento Web predisposto da AgID al fine di supportare gli Enti Creditori nei processi di adesione e di attivazione su pagoPA ed è messo a disposizione di tutti i soggetti che, con ruoli differenti, intervengono in tali processi.

Per accedere al Portale delle Adesioni, gli Enti devono richiedere ad AgID (via PEC all’indirizzo protocollo@pec.agid.gov.it) le credenziali di primo accesso. Preventivamente alla compilazione della lettera di adesione, l’Ente Creditore dovrà aver individuato il nominativo del “Referente dei Pagamenti”, ossia della persona indicata quale interlocutore unico con l’Agenzia per l’Italia Digitale relativamente alle attività di carattere amministrativo ed al quale l’Agenzia provvederà tramite PEC ad inviare le credenziali nominali di accesso.

Tutti i passi che deve compiere il Referente dei Pagamenti per portare a termine l’adesione dell’Ente Creditore sono descritti nel Manuale Utente del Portale delle Adesioni disponibile sul sito dell’AgID.

L’Ente Creditore, esclusivamente tramite il Portale delle Adesioni, deve inviare ad AgID la Lettera di Adesione, sottoscritta digitalmente dal rappresentante legale dell’Ente e, solo successivamente all’accettazione di essa, avrà ultimato la procedura di adesione.

Prerequisito per l’adesione da parte degli Enti Creditori è l’accreditamento nell’archivio IPA (Indice delle Pubbliche Amministrazioni).

Adesione di un Prestatore di Servizi di Pagamento¶

I Prestatori di Servizi di Pagamento come le banche, le poste, gli istituti di pagamento e ogni altro soggetto abilitato da Banca d’Italia ad eseguire servizi di pagamento, aderiscono su base volontaria al sistema pagoPA per erogare i propri servizi di pagamento a cittadini e imprese.

Sia i PSP che i consorzi o le associazioni di categoria possono aderire in qualità di “intermediari tecnologici” a supporto di altri PSP o degli Enti Creditori.

Per formalizzare l’adesione i PSP o soggetti che vogliano erogare servizi ai PSP sottoscrivono con l’AgID appositi Accordi di servizio, secondo i seguenti modelli:

Accordo di servizio per PSP, nel caso in cui il PSP voglia aderire al Sistema pagoPA esclusivamente per l’erogazione di servizi di pagamento, eventualmente anche usufruendo dell’attività di intermediazione di un PSP già aderente;
Accordo di servizio per PSP anche intermediario tecnologico, nel caso in cui il PSP voglia aderire al Sistema pagoPA svolgendo anche l’attività di intermediazione per altri soggetti.
Accordo di servizio per solo intermediario tecnologico, nel caso in cui un soggetto non PSP voglia aderire al Nodo dei Pagamenti-SPC svolgendo la sola attività di intermediazione per PSP.

Tali modelli, validati anche dall’ABI-Associazione Bancaria Italiana, sono pubblicati sul sito dell’Agenzia per l’Italia Digitale.

L’accordo di servizio deve essere compilato e sottoscritto digitalmente dal legale rappresentante del PSP o da chi ha potere di firma. L’accordo, così completato, deve essere inviato tramite PEC all’indirizzo protocollo@pec.agid.gov.it, specificando nell’oggetto della email “Adesione al sistema dei Pagamenti”.

Con la sottoscrizione dell’accordo di servizio e la conseguente accettazione di quanto stabilito nelle Linee Guida e nei relativi allegati, il PSP, a titolo gratuito, autorizza l’Agenzia per l’Italia Digitale a utilizzare e pubblicare il marchio identificativo del PSP aderente, nonché ogni proprio ulteriore marchio identificativo dei servizi da questo erogati attraverso il Nodo-SPC.

Inoltre, in forza dell’integrazione automatica stabilita negli accordi di servizio sottoscritti con i PSP, ogni nuova disposizione e/o previsione contenuta nelle Linee Guida e nei relativi allegati e/o documentazione monografica di riferimento risulterà inserita e/o richiamata nell’accordo di servizio già sottoscritto, quale parte integrante dello stesso, anche in sostituzione delle clausole difformi apposte in esso, senza alcun ulteriore consenso tra le parti sottoscrittrici.

Sempre in forza della stabilita integrazione automatica, gli stessi accordi di servizio già sottoscritti risulteranno altresì automaticamente integrati con ogni nuova disposizione e/o previsione contenuta nel nuovo modello standard di accordo di servizio, anche in sostituzione delle clausole difformi apposte, senza alcun ulteriore consenso tra le parti sottoscrittrici.

L’adesione formale a pagoPA consente il censimento del soggetto nel Dominio dei soggetti aderenti. Il “Referente” per l’attuazione dell’accordo, ovvero la persona indicata nell’accordo di servizio, è l’unico interlocutore del PSP con l’Agenzia per l’Italia Digitale.

Intermediari e Partner tecnologici nel sistema pagoPA¶

Gli Enti Creditori e i PSP aderenti al Sistema pagoPA, si possono avvalere di uno o più soggetti terzi, intermediari tecnologici, che, in nome e per conto del soggetto aderente, si occuperanno di gestire le attività di interconnessione all’infrastruttura del Nodo-SPC, mantenendo inalterate le responsabilità di Ente Creditore e PSP nei confronti delle proprie controparti diverse dall’AgID e, in particolare, degli utilizzatori finali.

L’Intermediario tecnologico è un soggetto già aderente e attivo sul Sistema e come tale ha già accettato in proprio e si è obbligato in proprio al rispetto delle Linee Guida e dei relativi allegati.

Gli Enti Creditori possono interconnettersi al Nodo di Pagamenti-SPC delegando le attività tecniche ad un Intermediario tecnologico oppure ad un Partner tecnologico.

Il Partner tecnologico è un fornitore dell’Ente Creditore che si occupa delle attività tecniche necessarie per l’interfacciamento con il Nodo-SPC, ferma restando la responsabilità nei confronti di AgID in capo all’Ente Creditore. AgID esclude l’adesione al sistema pagoPA da parte del Partner tecnologico in quanto tale.

Un Ente Creditore può avvalersi contemporaneamente di uno o più Intermediari e/o Partner potendo i servizi essere erogati da una molteplicità di soggetti, sempre nel rispetto delle Linee Guida.

L’Agenzia conserva le informazioni relative ad Intermediari e Partner tecnologici nelle proprie basi dati e pubblica sul proprio sito istituzionale l’elenco di tali soggetti.

Attivazione sul sistema pagoPA¶

Gli Enti Creditori, nel processo di attivazione sul Sistema pagoPA, sono supportati dal Portale delle Adesioni messo a disposizione di tutti i soggetti che, con ruoli differenti, intervengono in tale processo ovvero:

I soggetti incaricati dagli Enti Creditori (Referenti Pagamenti);
Le figure tecniche degli Enti Creditori direttamente connessi al Nodo (eventualmente Intermediari) e dei Partner tecnologici (Referenti Tecnici);
Gli operatori del Nodo-SPC;
l’Agenzia per l’Italia Digitale.

Il Referente Pagamenti (RP) è la figura incaricata dall’Ente Creditore, mediante delega del legale rappresentante, che opera nell’ambito del Sistema pagoPA per attivare e gestire le connessioni logiche dell’Ente Creditore, per nominare il Referente Tecnico in caso di connessione diretta, per gestire la lista degli IBAN dei conti di accredito che l’Ente Creditore intende utilizzare per l’incasso delle somme dovute. Uno stesso Referente Pagamenti può essere designato da più Enti Creditori.

Il Referente Tecnico (RT) è la figura tecnica di riferimento di un soggetto direttamente connesso al Nodo-SPC (Ente o Partner tecnologico). Ogni connessione logica di un Ente Creditore prevede un Referente Tecnico: quello nominato dal Referente Pagamenti dell’Ente Creditore (in caso di connessione diretta) oppure quello nominato dall’Intermediario/Partner Tecnologico (in caso di connessione intermediata). Il Referente Tecnico sarà lo stesso per tutti gli enti per i quali l’Intermediario/Partner tecnologico svolge tale ruolo.

I Prestatori di Servizi di Pagamento aderenti sono supportati nel processo di attivazione sul Sistema pagoPA dalla struttura di AgID che per tutte le attività tecniche ed organizzative si interfaccia con il Referente dei Servizi nominato dal Prestatore nell’Accordo di Servizio.

Il Referente dei servizi (RS) è la figura delegata dal Prestatore aderente ad eseguire ogni comunicazione all’Agenzia tramite sistemi di PEC, inerente tutti i dati tecnici e amministrativi, ivi inclusi quelli bancari, necessari all’attivazione e alla configurazione del servizio e le eventuali modifiche e/o aggiornamenti che dovessero intervenire.

Il Prestatore aderente delega altresì il Referente dei servizi a ricevere ogni comunicazione proveniente dall’Agenzia, anche nel caso in cui esse comportino la pronta attuazione delle indicazioni ivi contenute.

Il dettaglio del processo di attivazione sul sistema pagoPA è disponibile sul documento intitolato “Processo di avvio in esercizio di soggetti collegati direttamente al Nodo dei Pagamenti-SPC”, disponibile sul sito istituzionale dell’Agenzia.

Attivazione di un EC direttamente connesso¶

Il Referente Pagamenti di un Ente Creditore che abbia deciso di attivarsi su pagoPA collegandosi direttamente all’infrastruttura del Nodo-SPC, deve censire sul Portale delle Adesioni una connessione logica diretta indicando i modelli di pagamento su cui l’Ente Creditore intende attivarsi; contestualmente è tenuto a nominare la figura del Referente Tecnico.

Il Referente Tecnico, ricevuta la nomina e le credenziali di accesso al Portale delle Adesioni, dovrà innanzitutto individuare la soluzione più adeguata per realizzare il collegamento fisico al Nodo-SPC.

Il collegamento fisico si riferisce alla tipologia del supporto di rete utilizzato per connettere la piattaforma del soggetto aderente al Nodo-SPC; l’individuazione del collegamento fisico prevede la raccolta delle informazioni tecniche che lo rendono possibile: indirizzi IP, porte assegnate, ecc.

Le modalità di collegamento con cui un Ente Creditore può connettersi al Nodo-SPC sono descritte nel documento “Specifiche di connessione al Sistema pagoPA”.

Il Nodo-SPC è strutturato in due ambienti distinti e indipendenti: un ambiente di Test Esterno (disponibile per eseguire tutti i test di attivazione e integrazione previsti da AgID) ed uno per l’Esercizio.

Ogni aderente al Nodo potrà quindi, in qualsiasi momento, effettuare test di integrazione interfacciandosi, presso l’ambiente di test del Nodo-SPC, o con un emulatore PSP o con gli ambienti di test predisposti dai PSP aderenti al Nodo.

Gli ambienti del Nodo-SPC saranno allineati alle Specifiche Attuative di riferimento, pubblicate sul sito istituzionale dell’Agenzia, tranne nei periodi transitori di modifica per l’implementazione di nuove specifiche.

Processo di avvio in Esercizio¶

Il processo di avvio in Esercizio di un Ente Creditore collegato direttamente all’infrastruttura del Nodo-SPC prevede il soddisfacimento di alcuni prerequisiti riguardanti la predisposizione di un ambiente di Collaudo e di un ambiente di Esercizio e un piano per il disaster recovery.

L’Ente Creditore che intenda infatti iniziare il processo che lo porterà a rendere disponibili i propri servizi attraverso l’esecuzione di operazioni di pagamento sul Sistema pagoPA secondo i modelli dichiarati, sarà tenuto ad attivare un collegamento fisico (di Collaudo) con l’ambiente di Test Esterno del Nodo-SPC ed un collegamento fisico (di Esercizio) con l’ambiente di Esercizio del Nodo-SPC.

Per completare le configurazioni dovrà inoltre fornire tutte le informazioni necessarie all’attivazione di almeno una Stazione in ambiente di Collaudo ed almeno una Stazione in ambiente di Esercizio. La definizione della Stazione è di competenza del soggetto collegato direttamente all’infrastruttura del Nodo-SPC.

Ogni collegamento fisico può avere un numero variabile di Stazioni, in funzione dei modelli di pagamento implementati e delle regole/preferenze del soggetto direttamente connesso al Nodo. La configurazione di un Ente sul Nodo-SPC si completa con l’associazione dell’Ente stesso ad almeno una delle sue Stazioni. Il RT può portare a termine tutte le attività descritte utilizzando il Portale delle Adesioni (per i dettagli si rimanda al Manuale Utente disponibile sul sito dell’Agenzia).

Per completare il processo di avvio in Esercizio l’Ente Creditore deve soddisfare un ulteriore requisito: la compilazione di un documento di manleva all’esecuzione dei servizi oggetto dei casi di test indicati da AgID. Il documento di manleva deve essere recapitato ad AgID, firmato digitalmente, dal Referente Tecnico dell’Ente Creditore al fine di completare il processo di attivazione in Esercizio.

Nel documento di manleva il RT dichiara di voler rendere disponibili i propri servizi attraverso l’esecuzione di operazioni di pagamento sul sistema pagoPA e garantisce di aver effettuato con esito positivo, sia in ambiente di Test Esterno che in ambiente di Esercizio, tutti i casi di test previsti da AgID alla data di sottoscrizione del documento. Il documento di manleva è disponibile sul sito istituzionale dell’Agenzia.

Soddisfatti tutti i requisiti iniziali il Referente Tecnico, utilizzando il Portale delle Adesioni, può avviare il processo procedendo come segue:

Accede alla funzionalità preposta e crea una nuova pianificazione indicando tutti i Modelli di Pagamento su cui intende attivare l’Ente Creditore.
Decide se procedere o meno con l’esecuzione dei test previsti in ambiente di Collaudo con il supporto del personale AgID. Se decide di eseguire i test deve:
1. Fornire gli IBAN di accredito da utilizzare in ambiente di Collaudo;
2. Proporre ad AgID una data di inizio dei test al fine di coordinare le attività previste;
Configurati gli IBAN di Collaudo ed ultimati i test con il supporto di AgID, il RT deve compilare il “Verbale di Collaudo” e rimanere in attesa che AgID lo validi per chiudere formalmente la fase di Collaudo;
Terminata la fase di Collaudo (3.c) oppure avendo deciso di non coinvolgere AgID in tale fase, il RT esprime la volontà di procedere o meno con l’esecuzione dei test previsti in ambiente di Esercizio con il supporto del personale AgID. Se decide di eseguire i test deve:
1. Fornire gli IBAN di accredito da utilizzare in ambiente di Esercizio (ne potrebbe inserire di nuovi o utilizzare IBAN già attivi per quell’Ente);
2. Proporre ad AgID una data di inizio dei test al fine di coordinare le attività previste;
3. Configurati gli IBAN in fase di Pre-Esercizio ed ultimati i test con il supporto di AgID, il RT deve compilare il “Verbale di Pre-Esercizio” e rimanere in attesa che AgID lo validi per chiudere le attività di Pre-Esercizio.
Ultimata la fase di Pre-Esercizio oppure avendo deciso di non coinvolgere AgID in tale fase, il RT deve compilare il documento di manleva affinchè AgID lo possa validare e chiudere formalmente la fase di Pre-Esercizio;
Al fine di completare la procedura di avvio in esercizio dell’Ente Creditore il RT deve:
1. Fornire la “Tabella delle Controparti”;
2. Indicare tutte le informazioni riguardanti il “Tavolo operativo”.
AgID autorizza all’Esercizio l’Ente Creditore invitando il Referente Pagamenti dell’Ente ad attivare sul PdA (qualora non ne esistano) almeno un IBAN di accredito.

Per tutti i dettagli fare riferimento al Manuale Utente disponibile sul sito dell’Agenzia.

ATTIVAZIONE DI UN PSP SUL SISTEMA PAGOPA¶

Per aderire a pagoPA il PSP sottoscrive con AgID un atto, l’Accordo di servizio, che delinea oneri e responsabilità connesse al ruolo, permette di utilizzare l’infrastruttura del Nodo-SPC e di usufruire dei servizi di supporto connessi.

Come previsto dalle Linee Guida, un PSP eroga su pagoPA servizi di pagamento direttamente o può altresì utilizzare il servizio di intermediazione tecnologica erogato da terzi per altri servizi di pagamento. In altri termini, un PSP può risultare - a sua scelta - sia erogatore di servizi, sia soggetto intermediato, a seconda del servizio di pagamento offerto.

Con l’Accordo di servizio è nominato il “Referente dei Servizi” (RS) del PSP che svolge funzioni di unico interlocutore nei confronti di AgID per ogni attività tecnica ed è delegato a gestire ogni informazione inerente dati tecnici e amministrativi, ivi inclusi quelli bancari, necessari alla configurazione e all’attivazione del PSP nonché gestire tutti gli aggiornamenti che dovessero intervenire successivamente.

Il Catalogo dei Dati Informativi, la cui struttura è ampiamente descritta nella Sezione III delle SANP, è lo strumento con il quale il PSP comunica ad AgID le informazioni basilari relative ai servizi di pagamento offerti comprese le condizioni di utilizzo ed i costi massimi di commissione applicati.

Il processo di avvio in Esercizio sul sistema pagoPA di un PSP dipende dai modelli di pagamento e/o dai servizi di pagamento che il PSP intende erogare.

Se il PSP aderente intende implementare i modelli di pagamento attivati presso l’Ente Creditore e/o quelli attivati presso il PSP è necessario che si colleghi direttamente all’infrastruttura del Nodo-SPC oppure si faccia intermediare da un altro PSP già attivo su quei modelli di pagamento.

Se il PSP aderente intende erogare servizi di pagamento CBill e MyBank non è necessario che si colleghi direttamente al Nodo-SPC. Anche nel caso in cui un PSP aderente intenda svolgere il ruolo di Acquirer sul sistema pagoPA non è necessario che si colleghi direttamente al Nodo-SPC.

Attivazione di un PSP che si collega direttamente al Nodo¶

Il Referente dei Servizi di un PSP che debba attivarsi su pagoPA collegandosi direttamente all’infrastruttura del Nodo-SPC, deve configurare un collegamento fisico con l’infrastruttura del Nodo-SPC individuando la soluzione più adeguata per realizzarlo e garantire i livelli di servizio imposti dall’Agenzia, prevedendo anche un piano per il disaster recovery.

Per collegarsi al Nodo-SPC i PSP devono utilizzare una linea dedicata.

Il processo di avvio in Esercizio di un PSP collegato direttamente all’infrastruttura del Nodo-SPC prevede il soddisfacimento di alcuni prerequisiti: l’attivazione di un collegamento fisico (di Collaudo) con l’ambiente di Test Esterno del Nodo-SPC ed un collegamento fisico (di Esercizio) con l’ambiente di Esercizio del Nodo-SPC.

Per completare il processo di avvio il PSP deve soddisfare un ulteriore requisito: la compilazione di un documento di manleva all’esecuzione dei servizi oggetto dei casi di test indicati da AgID.

Il documento di manleva firmato digitalmente deve essere recapitato ad AgID dal Referente dei Servizi del PSP al fine completare il processo di attivazione in Esercizio. In esso il Referente garantisce di aver effettuato con esito positivo, sia in ambiente di Test Esterno che in ambiente di Esercizio tutti i casi di test previsti da AgID alla data di sottoscrizione del documento.

Il documento di manleva è disponibile sul sito istituzionale dell’Agenzia.

Soddisfatti tutti i pre-requisiti il Referente dei Servizi, può avviare il processo operando come segue:

Compila il Catalogo Dati Informativi da utilizzare in ambiente di Collaudo;
Fornisce al Nodo tutti le informazioni necessarie a completare la configurazione dei Canali di Pagamenti presenti nel Catalogo;
Decide di procedere o meno con l’esecuzione dei test previsti in ambiente di Collaudo con il supporto del personale AgID. Se decide di eseguire i test deve:
1. Proporre ad AgID una data di inizio dei test al fine di coordinare le attività previste;
2. Ultimati i test con il supporto di AgID, il RS deve compilare il “Verbale di Collaudo” e rimanere in attesa che AgID lo validi per chiudere formalmente la fase di Collaudo;
Terminata la fase di Collaudo (3.b) oppure avendo deciso di non coinvolgere AgID in tale fase, il RS compila il Catalogo Dati Informativi da utilizzare in ambiente di Esercizio;
Fornisce al Nodo tutte le informazioni necessarie a completare la configurazione dei Canali di Pagamenti presenti nel Catalogo di Esercizio;
Decide di procedere o meno con l’esecuzione dei test previsti in fase di Pre-Esercizio con il supporto del personale AgID. Se decide di eseguire i test deve:
1. Proporre ad AgID una data di inizio dei test al fine di coordinare le attività previste;
2. Terminati i test con il supporto di AgID, il RS deve compilare il “Verbale di Pre-Esercizio” e rimanere in attesa che AgID lo validi per chiudere le attività di Pre-Esercizio.
Ultimata la fase di Pre-Esercizio oppure avendo deciso di non coinvolgere AgID in tale fase, il RS deve compilare il documento di manleva affinchè AgID lo possa validare e chiudere formalmente la fase di Pre-Esercizio;

Al fine di completare il processo, il RS deve fornire ad AgID tutte le informazioni riguardanti il “Tavolo operativo”.

Configurazione del POS virtuale¶

I PSP che intendono accettare pagamenti con carta tramite pagoPA devono configurare, sul POS virtuale centralizzato esposto dal WISP, una coppia di punti vendita per ogni circuito, uno dei quali sarà dedicato alla transazione prive di CVV (MO/TO).

Per ogni punto vendita è necessario che il PSP comunichi i seguenti dati: ShopName, Circuito, Merchant Id, Terminal Id e UID 3DS.

Per poter instradare correttamente i pagamenti con carta su pagoPA il CDI del PSP deve includere almeno un canale specializzato a tale tipologia di pagamenti. I canali, ognuno potenzialmente con diverso profilo commissionale, che il PSP può includere sono di due tipi:

Tipo “not on us”: canale utilizzato sul WISP per la selezione del PSP da parte dell’Utilizzatore finale;
Tipo “on us”: dedicato alle transazioni con carte emesse dallo stesso PSP (transazioni “on us”), che non prevedono una esplicita selezione del PSP. Tale canale sarà identificato da un IdCanale concatenato alla stringa “_ONUS”.

Per completare la configurazione il PSP comunica l’associazione fra canali e punti vendita e i bin table range che il NodoSPC utilizza per riconoscere le transazioni di tipo “on us”.

Attivazione di un PSP che offre il servizio MyBank¶

Il servizio MyBank consente di ottenere, in tempo reale, un’autorizzazione per il trasferimento di fondi dal conto bancario del cliente a quello dell’esercente online, utilizzando un bonifico SEPA.

Il modello di funzionamento del servizio si identifica con il “processo di pagamento con re-indirizzamento online”.

La sottoscrizione dell’Accordo di servizio è un atto formale indispensabile per poter utilizzare il servizio MyBank. I PSP possono svolgere sul Nodo-SPC sia il ruolo di banca del debitore (c.d. Buyer Bank) sia il ruolo di banca dell’esercente (c.d. Seller Bank).

PSP che intendono svolgere il ruolo di Banca Buyer¶

I PSP che intendono svolgere il ruolo di Banca Buyer devono inviare ad AgID tutte le informazioni necessarie sul loro Catalogo Dati Informativi. La procedura di abilitazione per l’avvio in esercizio viene attivata su richiesta del RS ed ha l’obiettivo di verificare che l’operatività dei modelli di pagamento implementati corrisponda alle specifiche attuative vigenti e viene certificata mediante un verbale semplificato in cui si attesta la corretta esecuzione di almeno un bonifico SCT.

I dettagli del CDI per PSP di Buyer Bank sono riportati nella monografia intitolata “Erogazione del servizio MyBank attraverso il Nodo del Pagamenti-SPC” disponibile sul sito istituzionale dell’Agenzia.

PSP che intendono svolgere il ruolo di Banca Seller¶

I PSP che intendono offrire servizi sul Nodo-SPC attraverso il servizio MyBank in qualità di Seller Bank per le operazioni di pagamenti eseguite in favore degli Enti Creditori che abbiano in essere un rapporto di conto corrente con il Prestatore Aderente devono rispettare quanto previsto nella monografia intitolata “Transazioni MyBank attraverso il Nodo dei Pagamenti-SPC”, disponibile sul sito istituzionale dell’Agenzia. Anche in questo caso, i PSP che intendono svolgere il ruolo di Banca Seller devono inviare ad AgID tutte le informazioni necessarie sul loro Catalogo Dati Informativi.

Al fine di consentire all’utilizzatore finale di eseguire operazioni di pagamento in favore di un Ente Creditore mediante la soluzione MyBank, con accredito su un conto corrente intestato a detto Ente, il PSP aderente nel ruolo di Seller Bank presterà il servizio di Routing Service, anche tramite uno specifico soggetto terzo detto Routing Service Provider, purché rispetti le specifiche di interfacciamento del servizio di routing.

La Seller Bank accrediterà gli importi versati dagli utilizzatori finali in favore di Singoli Enti Creditori mediante il Nodo-SPC, assicurando il rispetto della normativa di riferimento pro tempore vigente.

Attivazione di un PSP che offre il servizio CBILL¶

In questo paragrafo sono descritte le attività che devono essere effettuate dai Prestatori di Servizi di Pagamento che intendono utilizzare il servizio CBILL del consorzio CBI (Customer to Business Interaction) per interagire con il Nodo-SPC.

I dettagli sul funzionamento del servizio CBILL in pagoPA sono riportati nella monografia intitolata “Erogazione del servizio CBILL attraverso il Nodo dei Pagamenti-SPC”, disponibile sul sito dell’Agenzia.

La sottoscrizione dell’Accordo di servizio è un atto formale indispensabile per poter utilizzare il servizio CBILL, tuttavia i PSP che intendono offrire il servizio CBILL sul sistema pagoPA hanno un iter di attivazione facilitato, in quanto le fasi di realizzazione del collegamento al Nodo-SPC sono già state effettuate dal Consorzio CBI, che assume il ruolo di “Intermediario Tecnologico” nei confronti dei propri aderenti. Per completare la fase di avvio in esercizio è necessario inviare ad AgID tutte le informazioni relative al “Catalogo Dati Informativi” utilizzato.

Invece, i PSP che sono già aderenti a pagoPA ed al Nodo-SPC, e che vogliono erogare i servizi di pagamento in argomento, devono fare riferimento alle sole attività previste per l’invio delle informazioni relative al “Catalogo Dati Informativi”.

Attivazione di un PSP intermediato

I PSP aderenti che intendono utilizzare il Sistema pagoPA indirettamente, possono servirsi di Intermediari a cui delegano lo svolgimento di tutte le attività tecniche (connessione al Nodo-SPC). Per tutte le attività in carico al Referente Servizi il PSP farà riferimento alla figura tecnica designata dall’intermediario tecnologico scelto, senza facoltà di nomina o sostituzione in forza dell’avvenuta delega delle attività tecniche.

Sarà cura dell’Agenzia censire i PSP che intendono aderire al sistema pagoPA e completare il processo di adesione, indicando le modalità per procedere con la configurazione dei canali di connessione e del catalogo dati informativo.

Configurare uno strumento di pagamento in Convenzione¶

Ogni strumento di pagamento ( o Canale ) messo a disposizione dal PSP per il pagamento on-line presso L’ente creditore può essere profilato con diversi profili di commissione ognuno dei quali legati ad un codice convenzione

Il codice Convenzione è un codice ( stringa, max 35 caratteri) generato dal PSP stesso e comunicato direttamente dal PSP verso gli EC abilitati.

Attivazione del codice convenzione:¶

Il condice convenzione viene attivato tramite una richiesta al servizio di assistenza specificando:

Il codice convenzione.
Lo strumento di pagamento interessato (identificativoCanale).
Il costo commissione applicato per ognuna delle fasce di pagamento accettate

Adempimenti durante l’erogazione del servizio¶

Gli adempimenti che gli Enti Creditori, i Prestatori di Servizi di Pagamento e i Partner Tecnologici sono tenuti ad osservare durante l’erogazione del servizio, dipendono dalle modalità di collegamento degli stessi.

Adempimenti dei soggetti direttamente collegati al Nodo-SPC¶

Tutti i soggetti collegati direttamente al Nodo-SPC devono farsi carico degli obblighi e adempimenti di seguito descritti.

Tavoli operativi¶

Il processo di avvio in Esercizio sul Sistema pagoPA di tutti i soggetti collegati direttamente al Nodo-SPC obbliga tali soggetti a dotarsi di un Tavolo Operativo che sia in grado di fornire il supporto necessario a rilevare e gestire eventuali anomalie di funzionamento in Esercizio.

Il Referente Tecnico dell’Ente Creditore e del Partner Tecnologico ed il Referente dei Servizi del Prestatore di Servizi di Pagamento sono tenuti a fornire all’Agenzia per l’Italia Digitale tutte le informazioni relative al Tavolo Operativo, che costituisce un ulteriore punto di contatto per l’Agenzia nel caso in cui pervengano segnalazioni di anomalie di funzionamento.

I Tavoli Operativi devono essere attivi 24 ore su 24, 7 giorni su 7. I Referenti Tecnici e i Referenti dei Servizi hanno l’onere di garantire che il Tavolo Operativo possa far fronte sia alla operatività ordinaria (rilevazione e gestione di specifiche anomalie di funzionamento) che a procedure di emergenza da attivare in caso di gravi malfunzionamenti.

Monitoraggio e controllo¶

I soggetti direttamente collegati al Nodo-SPC devono:

Utilizzare un sistema che monitori lo stato del servizio e sia disponibile anche al Tavolo Operativo;
Implementare il “Giornale degli Eventi”, come indicato nella Sezione III;
Registrare e classificare le segnalazioni pervenute al Tavolo Operativo al fine di favorire lo scambio di informazioni con l’Agenzia.
1. Business continuity e Disaster Recovery

Ogni soggetto collegato direttamente al Nodo-SPC è tenuto a predisporre ed implementare soluzioni tecniche ed organizzative atte a garantire la Business Continuity e il Disaster Recovery come previsto dalla normativa vigente (in particolare nel “Codice dell’amministrazione digitale”, D. Lgs. N. 82/2005 s.m.i. - artt. 50-bis e 51).

Qualora si verifichino eventi che pregiudichino la Business Continuity è fatto altresì obbligo al soggetto di darne tempestiva comunicazione all’Agenzia per l’Italia Digitale.

Archiviazione dei dati¶

Fatti salvi gli obblighi di legge in tema di tenuta e conservazione della documentazione attinente alle attività svolte per l’erogazione del Servizio e la fruizione delle Funzioni, nonché le disposizioni previste dalla normativa vigente relativa alla privacy, ogni soggetto collegato direttamente al Nodo-SPC (Ente Creditore o Prestatore di Servizi di Pagamento) è tenuto ad archiviare, senza alcuna modifica, i dati trasmessi e ricevuti tramite il Servizio.

Ulteriori adempimenti¶

Gli Enti Creditori collegati direttamente al Nodo-SPC devono:

Comunicare al proprio utilizzatore finale gli eventuali vincoli, disponibilità dei propri servizi con particolare riferimento ai pagamenti attivati presso le strutture dei Prestatori di Servizi di Pagamento;
Comunicare all’utilizzatore finale le caratteristiche tipiche dei servizi di pagamento offerti attraverso il Nodo-SPC;
Attivare tutti i servizi di pagamento destinati all’utilizzatore finale attraverso il sistema pagoPA;
Rispettare le disponibilità di servizio indicate;
Mantenere disponibili le figure del Referente Pagamenti e del Referente Tecnico e provvedere ad aggiornare l’Agenzia per l’Italia Digitale in caso di loro avvicendamento.

I PSP collegati direttamente al Nodo-SPC devono inoltre:

Mantenere aggiornato il Catalogo Dati Informativi;
Mantenere disponibile la figura del Referente Servizi indicata nell’accordo di servizio e provvedere ad aggiornare l’Agenzia per l’Italia Digitale in caso di suo avvicendamento;
Se offrono servizi presso proprie strutture e/o punti di prossimità, comunicare agli utilizzatori finali tale possibilità, esponendo in loco l’apposito “Logo” registrato dall’Agenzia per l’Italia Digitale;
Comunicare e mantenere aggiornati i dati relativi ai canali di pagamento disponibili (es. sportello fisico, home banking, app mobile, ATM).
1. Adempimenti dei soggetti non direttamente collegati al Nodo-SPC

Tutti i soggetti non direttamente collegati al Nodo-SPC devono farsi carico degli adempimenti di seguito descritti.

Per quanto riguarda i Tavoli Operativi, il soggetto aderente al Sistema pagoPA che abbia deciso di delegare le attività tecniche ad uno o più Intermediari tecnologici e/o ad uno o più Partner Tecnologici deve garantirsi la possibilità di comunicare con i Tavoli Operativi di tutti i suoi Intermediari/Partner.

Deve inoltre garantirsi che i propri Intermediari/Partner abbiano implementato tutte le soluzioni previste riguardanti:

Sistemi di monitoraggio e controllo;
Business Continuity e Disaster Recovery;
Archiviazione dei dati.

Tutti gli Enti Creditori non direttamente collegati al Nodo-SPC hanno altresì l’obbligo di:

Comunicare al proprio utilizzatore finale gli eventuali vincoli, disponibilità dei propri servizi con particolare riferimento ai pagamenti attivati presso le strutture dei Prestatori di Servizi di Pagamento;
Comunicare all’utilizzatore finale le caratteristiche tipiche dei servizi di pagamento offerti attraverso il Nodo-SPC;
Attivare tutti i servizi di pagamento destinati all’utilizzatore finale attraverso il sistema pagoPA;
Rispettare le disponibilità di servizio indicate;
Mantenere disponibile la figura del Referente Pagamenti nominata in fase di adesione e provvedere ad aggiornare l’Agenzia per l’Italia Digitale in caso di suo avvicendamento.

I PSP non collegati direttamente al Nodo-SPC devono inoltre:

Mantenere aggiornato il Catalogo Dati Informativi;
Mantenere disponibile la figura del Referente Servizi indicata nell’accordo di servizio e provvedere ad aggiornare l’Agenzia per l’Italia Digitale in caso di suo avvicendamento;
Se offrono servizi presso proprie strutture e/o punti di prossimità, comunicare agli utilizzatori finali tale possibilità, esponendo in loco l’apposito “Logo” registrato dall’Agenzia per l’Italia Digitale;

Comunicare e mantenere aggiornati i dati relativi ai canali di pagamento disponibili (es. sportello fisico, home banking, app mobile, ATM).

Livelli di Servizio¶

I livelli di servizio, intesi come tempi massimi di risposta applicativa percepiti dall’utilizzatore finale del sistema pagoPA, devono essere conformi a quanto specificato nel documento dal titolo “Indicatori di qualità per i soggetti aderenti”, disponibile sul sito istituzionale dell’Agenzia.

Indicatori di qualità del Nodo-SPC¶

Gli indicatori di qualità inerenti i servizi erogati dal Nodo-SPC ai soggetti aderenti sono valutati sulla base di indicatori di performance (KPI) la cui struttura è dettagliata nel citato documento “Indicatori di qualità per i Soggetti Aderenti”, disponibile sul sito istituzionale dell’Agenzia.

Le statistiche relative a tali indicatori saranno rese disponibili attraverso il Servizio di Reporting del Nodo-SPC.

Responsabilità dei soggetti aderenti¶

Di seguito sono indicati gli oneri in capo ai soggetti aderenti al Nodo-SPC.

Responsabilità dell’Ente Creditore¶

L’Ente Creditore è responsabile anche sotto il profilo giuridico:

Della qualità, della correttezza e della completezza dei dati che trasmette, ivi incluso l’IBAN del conto da accreditare;
Del corretto aggiornamento dei dati del proprio sistema informativo;
Della sicurezza all’interno del proprio dominio;
Se del caso, dell’assegnazione delle firme digitali ai soggetti autorizzati e del controllo del corretto utilizzo delle stesse.

L’Ente Creditore è altresì responsabile dell’errata e/o omessa indicazione dei dati comunicati all’utilizzatore finale e/o pubblicati per l’esecuzione del pagamento nei propri confronti.

Nel caso in cui l’Ente Creditore proceda all’identificazione del soggetto pagatore, l’Ente Creditore risulterà responsabile della correttezza e dell’autenticità dei dati identificativi del pagatore ai fini del buon esito del pagamento.

L’Ente Creditore è responsabile della omessa verifica della coincidenza tra i dati inseriti nella Richiesta di Pagamento Telematico (RPT) rispetto a quelli propri della relativa Ricevuta Telematica (RT) al fine del rilascio della quietanza di pagamento.

L’Ente Creditore autorizza, sin da ora, l’Agenzia per l’Italia Digitale e/o suoi aventi causa, a monitorare l’erogazione dei servizi offerti oggetto delle presenti specifiche tecniche, nonché alla pubblicazione dei dati rivenienti dal relativo monitoraggio.

Responsabilità del Prestatore di Servizi di Pagamento¶

Il Prestatore di Servizi di Pagamento è tenuto a eseguire l’operazione di pagamento richiesta dall’utilizzatore finale secondo le modalità e le tempistiche previste dal D.lgs. del 27 gennaio 2010, n. 11 e relativi provvedimenti attuativi emanati dalla Banca d’Italia.

Il Prestatore di Servizi di Pagamento è responsabile anche sotto il profilo giuridico:

Della qualità, della correttezza e della completezza dei dati che trasmette;
Del corretto aggiornamento dei dati del proprio sistema informativo;
Della sicurezza all’interno del proprio dominio;
Se del caso, dell’assegnazione delle firme digitali ai soggetti autorizzati e del controllo del corretto utilizzo delle stesse.

A prescindere dall’identificazione del pagatore eseguita dall’Ente Creditore, se del caso, anche per il tramite del proprio Intermediario/Partner Tecnologico, il Prestatore di Servizi di Pagamento, resta responsabile dell’identificazione del soggetto Versante (titolare del C/C di addebito), in quanto suo cliente.

Il Prestatore di Servizi di Pagamento autorizza, sin da ora, l’Agenzia per l’Italia Digitale e/o suoi aventi causa, a monitorare l’erogazione dei servizi offerti oggetto delle presenti specifiche attuative, nonché alla pubblicazione dei dati rivenienti dal relativo monitoraggio.