Specifiche Attuative del Nodo dei Pagamenti-SPC versione 2.2.6¶

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

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.

Software Development KIT per applicazioni “mobile”¶

Per supportare lo sviluppo di App mobile rilasciate dagli Enti Creditori, che includano funzionalità di pagamento, l’Agenzia per l’Italia Digitale rende disponibile un SDK (Software Development Kit) che consente una rapida integrazione delle funzioni del NodoSPC.

Lo SDK è disponibile in download, previa sottoscrizione di un apposito disclaimer, fra gli strumenti GitHub del sito https://developers.italia.it/ e fornito in modalità nativa per le due principali tecnologie presenti sul mercato: IOS e Android.

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.). Assimilabile a tale tipologia è il caso di una transazione Mybank: il carrello si ferma a una componente del Nodo, il Wrapper, che quindi ingaggia la componente Initiating Party della Seller Bank, per la gestione delle fasi successive.
  - 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 Wrapper MyBank¶

Nell’ambito del collegamento tra il NodoSPC ed il circuito e-commerce MyBank, la componente “Wrapper MyBank” si occupa di effettuare le necessarie conversioni di tracciati e di gestire il colloquio tra il NodoSPC e la componente Initiating Party messa a disposizione dalla Seller Bank, rendendo possibile l’inoltro della richiesta di pagamento alla Buyer Bank ed il ritorno dell’esito del pagamento stesso.

In tale contesto, le Seller Bank aderenti al NodoSPC sono tenute ad utilizzare le specifiche di interfacciamento della componente “Wrapper MyBank”.

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

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

Modello dei dati¶

Pagamenti¶

In questo paragrafo sono descritti i seguenti documenti XML scambiati tra gli attori del sistema nell’ambito dei processi di pagamento:

Richiesta di Pagamento Telematico (RPT);
Ricevuta Telematica (RT);
Flusso di rendicontazione (FR);
Richiesta di Revoca (RR);
Esito Revoca (ER).

Ogni elemento è caratterizzato da un campo versioneOggetto che ne indica la versione di riferimento, ogni versione è composta dalla tripletta numerica Major.Minor.Patch, che viene incrementata a seguito dei seguenti eventi:

un avanzamento di Major revision è causato da modifiche alla struttura dell’oggetto tali che impediscono la retro-compatibilità con le versioni precedenti dello stesso oggetto;
un avanzamento di Minor revision è ancora causato da modifiche all’oggetto ma tali che comunque garantiscono la retro-compatibilità con le versioni precedenti;
un avanzamento di Patch revision è invece causato dalla necessità di apportare correzioni o precisazioni di scarso impatto.

Il seguente class diagram mostra le relazioni che si instaurano tra gli elementi durante un tentativo di pagamento andato a buon fine.

Figura 1: Diagramma delle classi del pagamento

In particolare:

come specificato all’interno dell’Allegato A delle linee guida, ogni Posizione Debitoria di un EC è identificata all’interno di pagoPA da un codice identificativo denominato identificativoUnivocoVersamento (IUV). Tale codice è univocamente generato da un EC;
per chiudere una Posizione Debitoria, l’Utilizzatore finale esegue una operazione di pagamento attraverso pagoPA con un PSP da lui stesso determinato. Ogni operazione (o tentativo) di pagamento, quindi, presuppone necessariamente l’esistenza di una Posizione Debitoria;
l’operazione di pagamento è univocamente identificata da un codice denominato codiceContestoPagamento (CCP) generato dal soggetto che innesca il pagamento;
IUV e CCP congiuntamente consentono di associare ogni RPT alla corrispondente RT.
ad ogni operazione di pagamento, corrisponde uno solo degli oggetti RPT, RT e Flusso di Rendicontazione. Nella eventualità che sia richiesta la revoca di un’operazione già conclusa si genera un’unica coppia di oggetti RR/ER;
ad un Flusso di Rendicontazione di uno specifico conto di accredito di un determinato EC corrispondono tutte le operazioni di pagamento andate a buon fine disposte nella singola giornata operativa;
ad ogni RPT corrisponde una ed una sola RT;
ad una RR corrisponde una ed una sola RT;
ad un ER corrisponde una ed una sola RR.

Richiesta di Pagamento Telematica (RPT)¶

La RPT descrive una richiesta di pagamento di una Posizione Debitoria.

image1

Figura 2: Diagramma delle classi della RPT

In particolare, una RPT è composta dai seguenti elementi:

dominio: identifica il mittente della richiesta tramite i dati di configurazione;
soggettoVersante: identifica la persona, fisica o giuridica, che effettua il pagamento;
soggettoPagatore: identifica la persona fisica o giuridica associato alla Posizione Debitoria;
enteBeneficiario: identifica l’EC beneficiario del pagamento;
datiVersamento: descrive i dettagli necessari del (dei) versamento (i) utili al PSP per completare l’operazione di pagamento verso l’EC.

La trasmissione della RPT è infine identificata dai seguenti parametri generati dall’EC:

data di generazione della RPT (dataOraMessaggioRichiesta).
codice IdentificativoMessaggioRichiesta, univoco nell’ambito della stessa data di generazione della RPT.

Nel seguito si descrivono nel dettaglio gli elementi della RPT all’interno dello schema XSD a meno che non siano palesemente auto-esplicativi; inoltre sono specificati i parametri associati agli attributi che vengono utilizzati per filtrare i PSP in grado di erogare il servizio di pagamento richiesto durante il processo di selezione degli stessi da parte dell’Utilizzatore finale.

Figura 3: Diagramma delle classi del versamento

Un versamento è caratterizzato dai seguenti attributi principali:

dataEsecuzionePagamento: indica la data in cui l’EC richiede che venga effettuato il versamento;
ImportoTotaleDaVersare: specifica l’importo totale del versamento, anche nel caso che includa l’acquisto di eventuali marche da bollo; la valorizzazione di tale parametro istruisce il NodoSPC a filtrare i servizi di pagamento dei PSP sulla base del massimo importo pagabile contenuto nel Catalogo Dati Informativi;
Tipo Versamento: descrive il tipo di versamento. I possibili valori ammessi sono:
- BBT, Bonifico Bancario di Tesoreria; pagamento con bonifico anche utilizzato per indicare l’innesco di un pagamento online presso l’EC
- BP, Bonifico Postale.
- AD, Addebito Diretto.
- CP, Carta di Pagamento.
- PO, pagamento presso PSP. utilizzato per innescare un pagamento presso uno dei canali del PSP.
- OBEP, Online Banking E-Payment; utilizzato per descrivere un pagamento tramite canale MyBank.
- OTH, Others; Altre forme di versamento.
identificativoUnivocoVersamento: riferimento univoco assegnato al versamento da parte dell’EC (vedi allegato A alle Linee guida); identifica la Posizione Debitoria;
CodiceContestoPagamento: codice univoco necessario a definire il contesto nel quale viene effettuato il versamento; identifica il tentativo di pagamento;
ibanAddebito e bicAddebito: parametri opzionali che definiscono rispettivamente l’International Bank Account Number (ISO 13616) e il Bank Identifier Code (ISO 9362) del conto da addebitare;
firma ricevuta: campo mantenuto per retro-compatibilità, sempre valorizzato a 0.

Un unico pagamento disposto dall’Utilizzatore finale può comportare per il PSP, per richiesta dell’EC, la necessità di operare molteplici accrediti (massimo cinque) su diversi conti dell’EC come specificato nella struttura datiSingoloVersamento che contiene i dati di dettaglio necessari per tali operazioni:

importoSingoloVersamento: importo del singolo accredito (NB la somma dei singoli importi deve corrispondere al dato ImportoTotaleDaVersare);
ibanAccredito e bicAccredito: entrambi i campi identificano univocamente il conto corrente specificato dall’EC da accreditare dell’importo del singolo versamento, che deve essere configurato sul NodoSPC;
ibanAppoggio e bicAppoggio: entrambi i campi identificano univocamente il conto corrente alternativo al conto di accredito che il PSP può utilizzare per gestire l’operazione di pagamento. La scelta di utilizzare il conto alternativo a quello di accredito è demandata al PSP in base alle proprie necessità operative, purché preventivamente dichiarate nella propria configurazione e purché la scelta rimanga coerente per tutti i singoli versamenti. In un caso d’uso notevole nella prassi tali campi sono valorizzati con il conto corrente postale, in alternativa a un conto bancario specificato come conto di accredito. Nello XSD il dato è facoltativo per gestire il caso in cui l’EC effettivamente non disponga di un conto corrente alternativo; viceversa, se presente, il conto corrente deve essere configurato sul NodoSPC;
causaleVersamento: rappresenta la descrizione estesa della causale del versamento che deve essere conforme a quanto indicato nella Sezione I dell’Allegato A alle Linee guida;
datiSpecificiRiscossione: rappresenta l’indicazione dell’imputazione della specifica entrata per esporre la natura contabile del pagamento, specificando il tipo e codice contabilità.

Richiesta di acquisto Marca da Bollo Digitale¶

L’EC può consentire all’Utilizzatore finale, con un unico versamento, il contestuale acquisto di uno o più Marche da bollo digitali, con le modalità previste dall’Agenzia per le Entrate. A tal fine è necessario che almeno un singolo versamento contenga i seguenti campi:

tipoBollo: contiene uno dei tipi di Marca da Bollo Digitale per i quali l’Agenzia per le Entrate consente l’acquisto tramite pagoPA. A ogni tipo di bollo è associato un costo che deve essere coerente con il valore del campo importoSingoloVersamento;
hashDocumento: contiene l’impronta informatica (digest) del documento digitale a cui è associata la Marca da Bollo Digitale. L’algoritmo di hash da utilizzare per produrre l’impronta è lo SHA-256. La stringa di 256 bit (32 ottetti) risultato di tale algoritmo deve essere convertita in base64;
provinciaResidenza: sigla automobilistica della provincia di residenza del soggetto pagatore. Nel caso di soggetto residente all’estero indicare la provincia della sede legale dell’Ente Creditore

La valorizzazione della presente struttura dati istruisce il NodoSPC a rendere disponibili all’Utilizzatore finale, durante il processo di selezione dei PSP, quelli convenzionati con l’Agenzia delle Entrate per l’acquisto della Marca da Bollo Digitale (sistema @e.bollo).

Ricevuta Telematica (RT)¶

La RT restituisce all’EC il documento che conclude il flusso innescato da una richiesta di pagamento (RPT) ed attesta, qualora l’esito sia positivo, l’esecuzione del versamento e la chiusura della Posizione Debitoria.

Figura 4: Diagramma delle classi della RT

Questi sono i principali elementi:

dominio: identifica il mittente della richiesta tramite i dati di configurazione;
soggettoVersante: identifica la persona fisica o giuridica che effettua le operazioni di versamento;
soggettoPagatore: identifica la persona fisica o giuridica a cui è intestata la posizione debitoria;
istitutoAttestante: descrive il Prestatore di Servizi di Pagamento utilizzato per le operazioni
enteBeneficiario: identifica l’EC destinatario del pagamento l’EC che richiesto l’acquisto della Marca da Bollo Digitale;
datiPagamento: descrive il dettaglio del pagamento effettuato (con esito).

La trasmissione della RT è infine identificata dai seguenti parametri generati dal PSP:

dataOraMessaggioRicevuta: indica la data e l’ora del pagamento, liberatoria per l’Utilizzatore finale. Corrisponde con la data e ora del pagamento indicata dal PSP nell’attestazione.
riferimentoMessaggioRichiesta: nella generazione di una RT il PSP deve settare tale campo in modo che sia identico al campo identificativoMessaggioRichiesta della univoca RPT di riferimento.

Richiesta di revoca (RR)¶

La RR contiene tutte le informazioni necessarie per gestire sia la revoca che lo storno di un pagamento, definiti in sezione II.

Figura 5: Diagramma delle classi della Richiesta di Revoca

In particolare, la RR è composta dai seguenti elementi:

dominio: identifica il mittente della richiesta tramite i dati di configurazione;
soggettoVersante: identifica la persona fisica o giuridica che ha effettuato le operazioni di versamento;
soggettoPagatore: identifica la persona fisica o giuridica a cui è riferita la Posizione Debitoria di cui è richiesto il rollback;
istitutoAttestante: descrive il Prestatore di Servizi di Pagamento che ha emesso a RT e che ne richiede la revoca;
datiRevoca: descrive il dettaglio dell’operazione di revoca.

Esito Della Revoca (ER)¶

La ER descrive l’esito di una RR di un pagamento effettuato.

image5

Figura 6: Diagramma delle classi dell’Esito della Revoca

In particolare la ER è composta dai seguenti elementi:

dominio: identifica il mittente della richiesta tramite i dati di configurazione;
soggettoVersante: identifica la persona fisica o giuridica che ha effettuato le operazioni di versamento;
soggettoPagatore: identifica la persona fisica o giuridica a cui è riferita la Posizione Debitoria di cui è richiesto il rollback;
istitutoAttestante: descrive il Prestatore di Servizi di Pagamento che ha emesso a RT e che ne richiede la revoca;
datiRevoca: descrive il dettaglio dell’operazione di revoca.
riferimento: insieme dei campi che identificano la RR effettuata.

Flusso di rendicontazione (FR)¶

Il FR referenzia i singoli pagamenti accreditati tramite bonifico cumulativo di un conto corrente dell’EC, conformemente a quanto stabilito nell’Allegato A delle Linee Guida.

Le informazioni che devono essere messe a disposizione dell’EC sono organizzate in flussi omogenei di dati e devono essere rese disponibili ai soggetti interessati a cura del PSP che ha effettuato l’operazione di accredito. Il FR deve essere reso disponibile all’EC nella giornata successiva a quella durante la quale è stato disposto il bonifico (D+2).

Figura 7: Diagramma delle classi del Flusso di Rendicontazione

In particolare, il FR è identificato dai seguenti parametri:

identificativoFlusso: riferimento al componente <idFlusso> della causale del SEPA Credit Transfer di Riversamento (dato “Unstructured Remittance Information” – attributo AT-05)
identificativoUnivocoRegolamento: identificativo assegnato dal PSP all’operazione di trasferimento fondi, che può alternativamente essere così valorizzato:
- Transaction Reference Number (TRN, attributo AT-43 Originator Bank’s Reference), qualora il PSP, al momento della generazione del flusso di riversamento, disponga di tale dato;
- EndToEndId (attributo AT-41 Originator’s Reference): identificativo univoco assegnato dal PSP, nel caso in cui al momento della generazione del flusso di riversamento non sia disponibile il TRN;
istitutoMittente: struttura che identifica il PSP mittente che genera il FR;
istitutoRicevente: identifica l’EC destinatario del flusso;
datiSingoloPagamento: struttura che riporta la distinta dei versamenti cumulati all’interno del flusso SCT; ciascun versamento viene messo in relazione con i seguenti elementi:
- la Posizione Debitoria, attraverso l’identificativoUnivocoVersamento (IUV);
- le RT prodotte dal PSP, attraverso l’identificativoUnivocoRiscossione (IUR) ed eventualmente l’indiceDatiSingoloPagamento che specifica l’indice (numero d’ordine) nella lista di versamenti all’interno della RT.

Messaggi di errore¶

In caso di errori verificatisi nel colloquio tra i vari soggetti aderenti (EC e PSP) ed il NodoSPC, i relativi messaggi di errore vengono descritti utilizzando la struttura faultBean mostrata nel seguente diagramma.

Figura 8: Oggetto faultBean

La struttura contiene i seguenti parametri:

id: identificativo del soggetto che emette l’errore, valorizzato con idDominio (nel caso di EC), identificativoPSP (nel caso di PSP) e da una costante “NodoDeiPagamentiSPC” nel caso di errore identificato da parte del NodoSPC;
faultCode: codice dell’errore, composto secondo il seguente formato:

faultString: specifica del codice dell’errore. Ogni soggetto emittente valorizza tale parametro sulla base delle indicazioni fornite nella tabella dei Codici di errore di seguito riportata.
description: descrizione aggiuntiva dell’errore impostata dal soggetto che emette l’errore. Nella emissione di un faultCode PAA_SEMANTICA (EC) o CANALE_SEMANTICA (PSP), i soggetti erogatori (EC o PSP) dovranno indicare nel presente dato lo specifico errore legato all’elaborazione dell’oggetto ricevuto. Nel caso in cui il NodoSPC trasmetta verso un soggetto un errore di Controparte con faultCode valorizzato, a seconda del caso, a PPT_ERRORE_EMESSO_DA_PAA o PPT_CANALE_ERRORE, il campo è valorizzato con l’errore emesso dalla Controparte.
serial: posizione dell’elemento nella lista a cui fa riferimento. Utile quando si fornisce un parametro in forma di vettore (ad esempio, nella primitiva nodoInviaCarrelloRPT). Nel caso in cui l’errore sia generato dall’EC o dal PSP, il dato riporta il valore del dato faultBean.serial impostato dall’EC o dal PSP;
originalFaultCode: codice dell’errore generato dalla Controparte. Non è presente se il soggetto che emette l’errore è il NodoSPC;
originalFaultString: specifica dell’errore generato dalla Controparte. Non è presente se il soggetto che emette l’errore è il NodoSPC;
originalDescription: descrizione aggiuntiva dell’errore generato dalla Controparte. Non è presente se il soggetto che emette l’errore è il NodoSPC.

La tabella sottostante riporta l’elenco dei codici di errore (faultCode) che i soggetti dovranno utilizzare al verificarsi delle condizioni di errore (faultString).

faultCode	faultString
CANALE_AVVISO_DUPLICATO	Messaggio di warning per Avviso duplicato
CANALE_BUSTA_ERRATA	Messaggio dismesso
CANALE_ER_DUPLICATA	ER duplicata
CANALE_FIRMA_SCONOSCIUTA	Messaggio dismesso
CANALE_INDISPONIBILE	Servizio non disponibile
CANALE_RICHIEDENTE_ERRATO	Identificativo richiedente non valido
CANALE_RPT_DUPLICATA	RPT duplicata.
CANALE_RPT_RIFIUTATA	RPT rifiutata
CANALE_RPT_SCONOSCIUTA	RPT sconosciuta
CANALE_RT_NON_DISPONIBILE	RT non disponibile
CANALE_RT_SCONOSCIUTA	RT sconosciuta
CANALE_SEMANTICA	Errore semantico
CANALE_SINTASSI_EXTRAXSD	Errore di sintassi extra XSD
CANALE_SINTASSI_XSD	Errore di sintassi XSD
CANALE_SYSTEM_ERROR	Errore generico
PAA_ATTIVA_RPT_IMPORTO_NON_VALIDO	L’importo del pagamento in attesa non è congruente con il dato indicato dal PSP
PAA_ER_DUPLICATA	Esito Revoca duplicato
PAA_ERRORE_FORMATO_BUSTA_FIRMATA	Formato busta di firma errato o non corrispondente al tipoFirma
PAA_FIRMA_ERRATA	Errore di firma
PAA_FIRMA_INDISPONIBILE	Impossibile firmare
PAA_ID_DOMINIO_ERRATO	La PAA non corrisponde al Dominio indicato
PAA_ID_INTERMEDIARIO_ERRATO	Identificativo intermediario non corrispondente
PAA_PAGAMENTO_ANNULLATO	Pagamento in attesa risulta annullato all’Ente Creditore
PAA_PAGAMENTO_DUPLICATO	Pagamento in attesa risulta concluso all’Ente Creditore
PAA_PAGAMENTO_IN_CORSO	Pagamento in attesa risulta in corso all’Ente Creditore
PAA_PAGAMENTO_SCADUTO	Pagamento in attesa risulta scaduto all’Ente Creditore
PAA_PAGAMENTO_SCONOSCIUTO	Pagamento in attesa risulta sconosciuto all’Ente Creditore
PAA_RPT_SCONOSCIUTA	La RPT risulta sconosciuta
PAA_RT_DUPLICATA	La RT è già stata accettata
PAA_RT_SCONOSCIUTA	RT sconosciuta
PAA_SEMANTICA	Errore semantico
PAA_SINTASSI_EXTRAXSD	Errore di sintassi extra XSD
PAA_SINTASSI_XSD	Errore di sintassi XSD
PAA_STAZIONE_INT_ERRATA	Stazione intermediario non corrispondente
PAA_SYSTEM_ERROR	Errore generico
PAA_TIPOFIRMA_SCONOSCIUTO	Il campo tipoFirma non corrisponde ad alcun valore previsto
PPT_AUTENTICAZIONE	Errore di autenticazione
PPT_AUTORIZZAZIONE	Il richiedente non ha i diritti per l’operazione
PPT_CANALE_DISABILITATO	Canale conosciuto ma disabilitato da configurazione
PPT_CANALE_ERR_PARAM_PAG_IMM	Parametri restituiti dal Canale per identificare il pagamento non corretti
PPT_CANALE_ERRORE	Errore restituito dal Canale
PPT_CANALE_ERRORE_RESPONSE	La response ricevuta dal Canale è vuota o non corretta sintatticamente o semanticamente
PPT_CANALE_INDISPONIBILE	Nessun Canale utilizzabile e abilitato
PPT_CANALE_IRRAGGIUNGIBILE	Errore di connessione verso il Canale
PPT_CANALE_NONRISOLVIBILE	Il Canale non è specificato, e nessun Canale risulta utilizzabile secondo configurazione
PPT_CANALE_SCONOSCIUTO	Canale sconosciuto
PPT_CANALE_SERVIZIO_NONATTIVO	Il servizio applicativo del Canale non è attivo
PPT_CANALE_TIMEOUT	Timeout risposta dal Canale
PPT_CODIFICA_PSP_SCONOSCIUTA	Valore di codificaInfrastruttura PSP non censito
PPT_DOMINIO_DISABILITATO	Dominio disabilitato
PPT_DOMINIO_SCONOSCIUTO	IdentificativoDominio sconosciuto
PPT_ERRORE_EMESSO_DA_PAA	Errore restituito dall’Ente Creditore
PPT_ERRORE_FORMATO_BUSTA_FIRMATA	Formato busta di firma errato o non corrispondente al tipoFirma
PPT_FIRMA_INDISPONIBILE	Impossibile firmare
PPT_IBAN_NON_CENSITO	Il codice IBAN indicato dall’Ente Creditore non è presente nella lista degli IBAN comunicati al sistema pagoPA
PPT_ID_CARRELLO_DUPLICATO	Identificativo Carrello RPT duplicato
PPT_ID_FLUSSO_SCONOSCIUTO	Identificativo flusso sconosciuto
PPT_ISCRIZIONE_NON_PRESENTE	Iscrizione non presente in archivio
PPT_OPER_NON_REVOCABILE	Operazione non revocabile
PPT_OPER_NON_STORNABILE	Operazione non stornabile
PPT_PSP_DISABILITATO	PSP conosciuto ma disabilitato da configurazione
PPT_PSP_SCONOSCIUTO	PSP sconosciuto
PPT_RPT_DUPLICATA	RPT duplicata
PPT_RPT_NON_INOLTRABILE	La RPT richiesta e fornita dalla PA non può essere inoltrata in quanto non corretta formalmente
PPT_RPT_SCONOSCIUTA	RPT sconosciuta
PPT_RT_DUPLICATA	La RT inviata dal PSP è già stata inviata (RT push)
PPT_RT_NONDISPONIBILE	RT non ancora pronta
PPT_RT_SCONOSCIUTA	RT sconosciuta
PPT_SEMANTICA	Errore semantico
PPT_SINTASSI_EXTRAXSD	Errore di sintassi extra XSD
PPT_SINTASSI_XSD	Errore di sintassi XSD
PPT_STAZIONE_INT_PA_DISABILITATA	Stazione disabilitata
PPT_STAZIONE_INT_PA_IRRAGGIUNGIBILE	Errore di connessione verso la Stazione
PPT_STAZIONE_INT_PA_SCONOSCIUTA	Identi ficativoStazioneRichiedente sconosciuto
PP T_STAZIONE_INT_PA_SERVIZIO_NONATTIVO	Il Servizio Applicativo della Stazione non è attivo
PPT_SUPERAMENTOSOGLIA	Una qualche soglia fissata per PPT è temporaneamente superata e la richiesta è quindi rifiutata
PPT_SYSTEM_ERROR	Errore generico
PPT_TIPOFIRMA_SCONOSCIUTO	Il campo tipoFirma non corrisponde ad alcun valore previsto
PPT_ULTERIORE_ISCRIZIONE	Ulteriore iscrizione precedentemente censita
PPT_WISP_SESSIONE_SCONOSCIUTA	La tripletta idDomini o+keyPA+keyWISP non corrisponde ad alcuna sessione memorizzata nella componente WISP
PPT_WISP_TIMEOUT_RECUPERO_SCELTA	La tripletta idDomini o+keyPA+keyWISP è relativa ad una scelta effettuata scaduta
PPT_STAZIONE_INT_PA_TIMEOUT	Il messaggio non riesce ad essere inoltrato nei tempi attesi alla controparte EC

Tabella 1: Codici di errore

Avvisatura digitale¶

Paragrafo soggetto a proposta di modifica

Questo paragrafo descrive gli elementi scambiati tra il NodoSPC e gli attori coinvolti per realizzare la funzione di Avvisatura Digitale.

In particolare, gli elementi principali che vengono scambiati sono:

Avvisatura, rappresenta il dato attraverso il quale un EC notifica ad un Soggetto Pagatore un avviso di pagamento digitale. Può essere scambiato singolarmente o attraverso una lista.
Esito Inoltro Avvisatura, rappresenta la notifica dell’avvenuta consegna dell’avviso precedentemente inviato.
Iscrizione Servizio, rappresenta la richiesta di un utente finale di ricezione degli avvisi di pagamento tramite uno dei canali messi a disposizione dai PSP.

Il seguente Diagramma delle classi rappresenta la relazione tra i diversi oggetti scambiati ed altri oggetti già descritti nei paragrafi precedenti.

image9

Figura 9: Diagramma delle classi dell’avvisatura

Avviso digitale¶

L’Avvisatura rappresenta il documento telematico con il quale un EC notifica ad un Soggetto Pagatore un Avviso di Pagamento.

image10

Figura 10: Diagramma delle relazioni degli attributi dell’Avvisatura

Una Avvisatura è descritta dai seguenti parametri:

codiceAvviso: è il numero dell’avviso di pagamento, composto come descritto nell’allegato A delle Linee Guida;
tassonomiaAvviso: classificazione dell’avviso;
dataScadenzaPagamento: rappresenta la data ultima entro la quale si richiede che venga pagato l’avviso di pagamento;
dataScadenzaAvviso: Indica la data, successiva alla data di scadenza del pagamento, sino alla quale si ritiene valido l’avviso;
importoAvviso: rappresenta l’importo da pagare, potrebbe subire delle variazioni;
descrizionePagamento: testo libero che descrive la natura dell’avviso;
urlAvviso: URL di una pagina web messa a disposizione dall’EC dove l’Utilizzatore finale può consultare l’avviso di pagamento;
tipoPagamento : indica la natura del pagamento;
tipoOperazione: indica il tipo di operazione connessa con l’avviso. Può assumere i seguenti valori:

Inoltre contiene informazioni in merito a:

anagrafica beneficiario: descrive l’EC che ha emesso l’avviso di pagamento;
identificativo dominio: contiene il codice fiscale del soggetto direttamente connesso che invia l’avviso Digitale;
soggetto pagatore: identifica il soggetto destinatario dell’avviso;
dati Singolo Pagamento: descrive i dettagli del pagamento da effettuare.

Il tipo ListaAvvisiDigitali è la struttura composta dall’insieme di più avvisi, purché di numero inferiore a 100.000 elementi.

Esito Inoltro Avvisatura¶

È un oggetto informatico, predisposto dal Nodo-SPC, che permette all’EC di conoscere l’esito del relativo inoltro massivo di Avvisi digitali.

image11

Figura 11: Diagramma delle classi dell’esito inoltro avvisatura

Contiene al suo interno informazioni riguardo a:

identificativoMessaggioRichiesta: riferimento all’avviso inviato
identificativoDominio: il codice fiscale del soggetto direttamente connesso che ha inviato l’avviso Digitale di cui il NodoSPC sta fornendo l’Esito.
EsitoAvvisatura: struttura che descrive l’esito dell’inoltro dell’avvisatura.

L’esito di un avvisatura è descritto dai seguenti parametri:

tipoCanaleEsito: tipologia di canale usato per inviare l’avviso all’utente;
IdentificativoCanale: identificativo del canale “mobile” a cui si riferisce l’esito dell’avvisatura;
codiceEsito: esito dell’invio riferito al singolo canale;
descrizioneEsito: testo libero che, in caso di esito negativo (codiceEsito<>0), descrive l’evento stesso.

Iscrizione al servizio¶

Definisce lo schema secondo il quale un PSP richiede al NodoSPC di ricevere le avvisature destinate ad un Soggetto Pagatore.

Figura 12: Diagramma delle classi dell’iscrizione al servizio

Contiene al suo interno informazioni riguardo a:

IdentificativoUnivocoSoggetto: descrizione del Soggetto Pagatore del quale si vuole ricevere le avvisature.

È descritto dai seguenti parametri:

azioneDiAggiornamento: Indica il tipo di aggiornamento richiesto, può assumere i seguenti valori:
- ‘A’= Attivazione
- ‘D’= disattivazione

Configurazione¶

In questo paragrafo vengono descritte tutte le informazioni necessarie al NodoSPC per configurare opportunamente gli attori ad esso connessi, ovvero EC e PSP.

Per la comunicazione di tali informazioni il NodoSPC mette a disposizione l’applicazione web Portale delle Adesioni. Per ulteriori dettagli consultare la Sezione IV.

Ente Creditore¶

L’oggetto Ente Creditore viene identificato nel sistema attraverso il proprio codice fiscale (campo idDominio) e caratterizzato dai seguenti attributi:

Descrizione dell’erogazione dei servizi;
Dettaglio di eventuali servizi disponibili per pagamento spontaneo disposto presso il PSP;
Dettaglio dei conti correnti di accredito e di appoggio incasso utilizzati.

Il documento che raccoglie la porzione pubblica di tali informazioni che deve essere resa disponibile alle controparti è raccolta nel documento Tabella delle Controparti che il NodoSPC rende disponibile tramite primitive SOAP descritte fra le funzioni ausiliarie.

Figura 13: Diagramma delle classi per la configurazione di un EC

PSP¶

L’oggetto PSP viene identificato nel sistema (campo identificativoPSP) attraverso il codice BIC oppure da un codice formato dalla concatenazione della stringa “ABI” con il valore del codice ABI del PSP. (La scelta fra i due identificativi deve essere compiuta dal PSP al momento della prima configurazione ed è irreversibile). Ogni PSP è caratterizzato dalle seguenti proprietà:

specifica sulla pubblicazione delle informazioni;
dettaglio dei servizi di pagamento attivati (canali).

Figura 14: Diagramma delle classi per la configurazione di un PSP

Il documento che raccoglie la porzione pubblica di tali informazioni che deve essere resa disponibile alle controparti EC è raccolta nel documento InformativaPSP che il NodoSPC rende disponibile tramite primitive SOAP descritte fra le funzioni ausiliarie.

Inoltre, per la configurazione delle modalità di pagamento nel sistema pagoPA, il PSP produce il documento Catalogo Dati Informativi, come riportato nella sezione IV.

Pubblicazione¶

All’interno di questa struttura, il PSP specifica gli attributi comuni a tutti i servizi di pagamento che rende disponibili sul sistema:

dataPubblicazione: data e ora relativa all’invio dell’ultimo aggiornamento delle informazioni;
release:
dataInizioValidita: data e ora di inizio validità delle informazioni;
urlInformazioniPSP: indirizzo di una pagina web gestita dal PSP rivolta all’Utilizzatore finale per la divulgazione di informazioni specifiche relative ai servizi di pagamento resi disponibili;
LogoPSP: logotipo del PSP;
stornoPagamento: flag che indica la capacità tecnica di gestire il processo di storno di un pagamento.
marcaBolloDigitale: flag che individua un PSP convenzionato con l’Agenzia delle Entrate come rivenditore della Marca da bollo digitale attraverso il sistema @e.bollo.

Canale¶

La struttura raccoglie tutte le informazioni relative a un servizio di pagamento messo a disposizione dal PSP sul sistema pagoPA:

identificativoIntermediario: identificativo dell’Intermediario del PSP che fornisce lo specifico accesso (Canale) al PSP per l’erogazione del servizio. L’intermediario può coincidere con il PSP stesso;
identificativoCanale: identificativo del canale attraverso il quale viene effettuata la transazione;

TipoVersamento: codice che identifica il tipo di versamento utilizzato dal canale;

Tipo Versamento	C odice	Descrizione
Pagamento con Carta	CP	Il PSP è abilitato a gestire pagamenti con carta di credito o debito
Pagamento mediante MyBank	OBEP	Il PSP è abilitato a gestire pagamenti MyBank on line
Pagamento attivato presso il PSP	PO	Il PSP è abilitato a gestire pagamenti interfacciando l’Utilizzatore finale.
Pagamento mediate	BP	Canale che identifica un canale on line
Poste Italiane		gestito da Poste Italiane

Tabella 2: Tipi di versamento

modelloPagamento: codice che identifica il modello di pagamento gestito dal canale; i calori utilizzabili sono elencati nella seguente tabella.

Modello di pagamento	Codice	Descrizione
Processo di pagamento con re indirizzamento on-line	0	Il PSP è abilitato a gestire pagamenti inizializzati dalla primitiva nodoInviaRPT
Processo di pagamento con re indirizzamento on-line tramite carrello	1	Il PSP è abilitato a gestire pagamenti inizializzati dalla primitiva * nodoInviaCarrelloRPT*
Processo di pagamento con autorizzazione gestita dal PSP	2	Il PSP è abilitato a gestire pagamenti con autorizzazione differita
Processo di pagamento attivato presso il PSP	4	Il PSP è abilitato ad inizializzare un
		processo di pagamento

Tabella 3: Modelli di pagamento

priorità: campo boolean mantenuto per retro-compatibilità da valorizzare a ‘false’;
canaleApp: indica se il canale in questione può essere inserito all’interno della categoria “Altri Metodi di Pagamento”;
servizioAlleImprese: campo boolean che indica se il servizio erogato dal PSP è destinato ad un utilizzo solo da parte delle imprese.

Inoltre, un canale è definito dagli attributi di seguito descritti in paragrafi dedicati:

Servizio¶

La struttura descrive come verrà visualizzato all’Utilizzatore finale per selezionare il PSP sul sistema WISP:

nomeServizio: nome commerciale del servizio / app
logoServizio: logotipo del servizio / app. Con risoluzione 400x128px.

Informazioni dettaglio Servizio¶

codiceLingua: identifica la lingua utilizzata per le informazioni di dettaglio della presente struttura. Le lingue supportate dal sistema pagoPA sono l’italiano e l’inglese oltre a quelle delle minoranze linguistiche tutelate (tedesco, francese e sloveno);
descrizioneServizio: testo libero a disposizione del PSP per specificare il servizio;
disponibilitàServizio: testo libero utilizzato dal PSP per specificare gli orari di erogazione tecnica del servizio;
limitazioniServizio: informazioni in formato testo che riportano eventuali limitazioni poste dal PSP nell’erogazione del servizio, (esempio: Servizio dedicato ad una particolare categoria di professionisti o imprese);
urlInformazioniCanale: URL di una pagina web contenente informazioni relative allo specifico servizio;
tavoloOperativo: indica i riferimenti del presidio tecnico predisposto per cooperare con il Tavolo Operativo del NodoSPC.

Plugin¶

La struttura permette al PSP di definire un set di parametri personalizzato da utilizzare per interpretare i parametri della redirect di risposta alla pagina di erogazione del servizio WISP.

Costi¶

La struttura definisce la policy del calcolo delle commissioni che il sistema pagoPA deve applicare.

È possibile gestire le seguenti policy per il calcolo della commissione:

Numero dei versamenti (tipoCostoTransazione = 0): tale policy calcola il costo della commissione in base al numero di versamenti da effettuare. In questo caso:
- il numero delle occorrenze della struttura fasceCostoServizio dovrà essere pari a 1;
- l’elemento tipoCommissione dovrà essere 0 (in valore assoluto);
- l’elemento costoFisso dovrà essere 0.
Totale versamento (tipoCostoTransazione = 1): tale policy calcola il costo della commissione in base al totale della transazione da effettuare. In questo caso è possibile specificare il costo della commissione in base alla fascia di prezzo.

Acquirer¶

L’Acquirer è un soggetto che ha instaurato un rapporto con un PSP aderente a pagoPA al fine di gestire le transazioni con le carte di pagamento, interagendo con il VPOS-AgID.

L’Acquirer viene configurato attraverso i seguenti parametri:

TerminalID: Terminal Identification Number (TID);
MerchantID: Merchant Identification Number (MID) che identifica il PSP relazionato con l’Aquirer;
Bin: lista di Issuer Identification Number (IIN) che identifica le carte emesse dal PSP relazionato con l’Aquirer. Il pagamento con una carta il cui BIN è incluso in tale lista è autorizzato dall’Aquirer senza la necessità di accedere ai circuiti internazionali. Il NodoSPC gestirà questa tipologia di pagamenti inoltrando le relative RPT verso il canale ONUS del PSP. Il canale NOT_ON_US è utilizzato dal PSP per gestire i pagamenti con carte emesse da altri soggetti.

Giornale degli eventi¶

Il Giornale degli Eventi (GDE) ha l’obiettivo di consentire la tracciabilità di ogni operazione di pagamento (andata a buon fine o abortita) per il tramite del NodoSPC.

L’operazione di pagamento si sviluppa mediante la cooperazione applicativa tra sistemi diversi degli EC, del NodoSPC e dei PSP. È quindi necessario, per ricostruire il processo complessivo, che ognuno dei sistemi interessati dal pagamento telematico si doti di funzioni specifiche per registrare in modo standardizzato i passaggi principali del trattamento dell’operazione di pagamento. Gli eventi di ingresso e di uscita dal sistema, ovvero le attività che comportano l’attraversamento di una interfaccia, sono punti cardine da tracciare obbligatoriamente. Sul Giornale degli Eventi si devono altresì annotare i cambi di stato intermedi significativi per il sistema pagoPA.

Le tracce registrate dai singoli sistemi, in caso di richiesta di verifica, devono poter essere tempestivamente estratte, inviate al Tavolo Operativo presidiato dal NodoSPC in modo da essere confrontate con le analoghe informazioni prodotte da tutti i sistemi di collaborazione coinvolti nell’operazione in esame.

Ai fini del confronto sono state individuate tre aree di interesse da monitorare per poter tracciare un pagamento e risolvere eventuali anomalie:

i messaggi scambiati tramite le interfacce esterne (SOAP/http/SFTP);
gli oggetti scambiati durante un pagamento (RPT, RT, ecc.);
le operazioni interne più significative (rappresentate nei capitoli successivi all’interno della presente sezione dalle operazioni associate e descritte per i diversi attori).

Nella tabella Tabella sottostante sono indicate le informazioni e le specifiche di rappresentazione dei dati che i soggetti appartenenti al Dominio sono tenuti a fornire per le verifiche di cui sopra. Questi dati sono altresì le informazioni “minime” da archiviare nel Giornale degli Eventi. Tali informazioni devono essere memorizzate presso le strutture che scambiano le informazioni (EC, PSP, Intermediari tecnologici, NodoSPC) e devono essere accessibili a richiesta, nei formati che saranno concordati.

Dato	Liv	Genere	Occ	Len	Contenuto
data OraEvento	1	an	1..1	19	Indica la data e l’ora de ll’evento secondo il formato ISO 8601, alla ri soluzione del mil lisecondo e sempre riferito al GMT. Formato [YYYY]- [MM]-[ DD]T[hh ]: [mm]:[s s.sss]
i dentifica tivoDomin io	1	an	1..1	1..35	Campo alf anumerico c ontenente il codice fiscale dell’EC che invia la richiesta di p agamento.
i dentifica tivoUnivo coV ersamento	1	an	1..1	1..35	Ri ferimento univoco assegnato al pagamento dall’ente ben eficiario e presente nel messaggio che ha originato l’evento.
c odiceCont estoPagam ento	1	an	1..1	1..35	Codice univoco n ecessario a definire il contesto nel quale viene e ffettuato il v ersamento presente nel messaggio che ha originato l’evento.
i dentifica tivoPrest ato reServizi Pagamento	1	an	1..1	1..35	ident ificativo del PSP univoco nel Dominio scelto dall’uti lizzatore finale e/o dall’EC
tipoV ersamento	1	an	0..1	1..35	Forma tecnica di pagamento presente nel messaggio che ha originato l’evento.
c omponente	1	an	1..1	1..35	Sistema o sot tosistema che ha generato l’evento (es. FESP, WFESP)
catego riaEvento	1	an	1..1	1..35	IN TERNO/INT ERFACCIA, indica se l’evento tracciato è relativo un’o perazione di in terfaccia con altri sistemi oppure se ra ppresenta un’o perazione interna (es. cambio di stato) al proprio sistema
t ipoEvento	1	an	1..1	1..35	Ident ificativo del tipo di evento. Nel caso di in terazioni SOAP è il nome del metodo SOAP.
sottoT ipoEvento	1	an	1..1	1..35	Nel caso di in terazioni SOAP sincrone assume i valori req/rsp per indicare rispet tivamente SOAP Request e SOAP R esponse.
i dentifica tivoFruit ore	1	an	1..1	1..35	Nel caso di eventi di tipo IN TERFACCIA si deve u tilizzare l’Ident ificativo del sistema del Soggetto ri chiedente ne ll’ambito del Dominio. (Es. ide ntificati voStazion eInterme diarioPA nel caso della nodoI nviaRPT) Nel caso di eventi di tipo INTERNO, si può u tilizzare un nome di c omponente o sotto c omponente che genera l’evento.
i dentifica tivoEroga tore	1	an	1..1	1..35	Nel caso di eventi di tipo IN TERFACCIA si deve u tilizzare l’Ident ificativo del sistema del Soggetto ri spondente ne ll’ambito del Dominio. (Es. “No doDeiPaga mentiSPC” nel caso della nodoI nviaRPT) Nel caso di eventi di tipo INTERNO, si può u tilizzare un nome di c omponente o sotto c omponente che processa l’evento. Per que st’ultima tipologia il valore può c oincidere con l’ identifi cativoFru itore, qualora non vi sia un c omponente che risponde a ll’evento stesso.
i dentifica tivoStazi oneInterm ediarioPA	1	an	0..1	1..35	ident ificativo della Stazione dell’inte rmediario dell’EC nel sistema del NodoSPC, da cui è t ransitata la RPT/RT.
canale Pagamento	1	an	0..1	1..35	ident ificativo del Canale del PSP nel sistema del NodoSPC da cui è tran sitata/si vuole far t ransitare la RPT/RT.
p arametriS pecificiI n terfaccia	1	an	0..1	1..512	parametri specifici u tilizzati nell’in terfaccia dal PSP o d all’ECnel modello di pagamento 1 o 3
Esito	1	an	0..1	1..35	Campo opzionale in base allo stato dell’o perazione al momento della regi strazione del l’evento. Obb ligatorio nel caso di richieste SOAP.

Tabella 4: Informazioni “minime” da archiviare nel “Giornale degli Eventi “

Il GDE dovrà contenere sia tutti gli eventi andati a buon fine, sia quelli abortiti fra cui quelli che hanno dato seguito ad un errore (evidenziando la categoria dell’errore ricevuto).

Qualora alcune delle informazioni richieste non fossero disponibili per una data operazione, i corrispondenti campi dovranno essere comunque valorizzati in uno dei due seguenti modi:

N/A: nel caso il valore del campo non sia applicabile al sistema pagoPA per l’operazione tracciata (es. identificativoErogatore per un evento interno);
UNKNOW, nel caso il campo sia applicabile, ma non sia stato possibile tracciare l’informazione richiesta.

Per quanto riguarda i PSP si precisa che deve essere sempre registrato, all’interno del Giornale degli Eventi, l’evento relativo alla generazione della RT (indipendentemente dall’esito del relativo pagamento) così valorizzando i seguenti campi del giornale:

categoriaEvento a “INTERNO”;
identificativoErogatore a “GENERAZIONE-RT”.

Pagamento presso l’ente creditore¶

Attori e casi d’uso¶

All’interno di questo capitolo vengono descritti i casi d’uso per il pagamento innescato dall’Utilizzatore Finale attraverso l’interazione con i sistemi degli Enti Creditori aderenti al Sistema pagoPA.

Gli attori coinvolti nel processo di pagamento sono i seguenti:

Ente Creditore: rappresenta un soggetto aderente a pagoPA che rende disponibile all’Utilizzatore finale la possibilità di comporre un carrello pagabile online tramite un Portale web o una mobile app;
PSP: rappresenta un Prestatore di Servizi di Pagamento aderente a pagoPA che rende disponibile almeno un canale di pagamento accessibile tramite la componente WISP del NodoSPC;
Utilizzatore finale, rappresenta una persona fisica e/o giuridica che si interfaccia con le risorse web o mobile dell’EC al fine di ottenere un servizio.
Acquirer: è il soggetto attraverso il quale un PSP gestisce le transazioni con le carte di pagamento.

Lo scenario di utilizzo è descritto dal seguente caso d’uso nominale:

Pagamento online con guida interattiva di selezione del PSP (WISP): un Utilizzatore finale effettua il pagamento tramite il Portale web dell’EC. La scelta dello strumento di pagamento è guidata tramite apposita interfaccia web resa disponibile dal NodoSPC.

Pagamento online con guida interattiva di selezione del PSP (WISP)¶

Pre-Condizione	L’Utilizzatore finale innesca il processo di pagamento riferito a una Posizione Debitoria aperta.
Trigger	L’Utilizzatore finale esce dalla pagina di check-out sul Portale dell’EC innescando il processo di pagamento di un carrello di RPT
Descrizione	L’EC compone il carrello di RPT e lo invia al NodoSPC Il NodoSPC valida il carrello e replica all’EC fornendo la URL di redirect per re-direzionare il browser dell’Utilizzatore finale sulla pagina WISP per la scelta interattiva del PSP L’Utilizzatore finale accede al WISP e procede alla selezione del servizio di pagamento reso disponibile da un PSP. Il NodoSPC invia al canale del PSP scelto dall’Utilizzatore finale il carrello di RPT; Il PSP genera le RT attestanti l’esito del pagamento e la restituisce al NodoSPC L’EC riceve le RT completando la transazione, potendo così erogare il servizio all’Utilizzatore finale
Post-Condizione	Al termine delle operazioni il pagamento transisce allo stato RT-EC

Tabella 1: Caso d’uso del processo di pagamento online con guida interattiva di selezione del PSP

L’evoluzione nel tempo del processo di pagamento è la seguente:

Figura 1: Diagramma di sequenza del processo di pagamento iniziato presso l’EC

L’Utilizzatore finale, dopo aver eseguito le operazioni di composizione del carrello, esegue il check-out sul Portale dell’EC.
Il Portale dell’EC compone il carrello di RPT e lo invia al NodoSPC mediante la primitiva nodoInviaCarrelloRPT.
Il NodoSPC valida formalmente sintassi e semantica dell’invocazione. Tra i parametri sottoposti a controllo si menzionano:
1. identificativoCarrello: deve risultare univoco all’interno del Sistema pagoPA; il codice deve essere composto secondo il seguente formato:

ibanAccredito: deve risultare inserito nella lista dei conti correnti dell’EC configurati sul NodoSPC;
ibanAppoggio: deve risultare inserito nella lista dei conti correnti dell’EC configurati sul NodoSPC;

Il NodoSPC fornisce la risposta all’invocazione precedente, modificando lo stato del pagamento in RPT Inviata e restituendo come parametri di output:
1. URL di re-direzione: risorsa a cui re-indirizzare il browser dell’Utilizzatore finale, contenente anche una query string “idSession=<idSession>” che identifica univocamente la sessione;
2. esitoComplessivoOperazione: rappresenta l’esito complessivo dell’operazione di invocazione che può assumere i valori OK e KO.
l’EC predispone l’http REDIRECT verso la URL fornita nella response alla primitiva di cui al precedente punto 2.
Il browser dell’Utilizzatore finale è re-direzionato verso il NodoSPC e l’Utilizzatore finale viene guidato nella selezione del servizio di pagamento.

A seconda delle scelte operate dall’Utilizzatore finale, sono possibili due differenti scenari alternativi:

Pagamento con carta;
Pagamento con altri strumenti.

Pagamento con carta

Dopo che l’Utilizzatore finale ha inserito i dati della Carta di Pagamento, selezionato l’Acquirer da utilizzare per la transazione (eventualmente proposto dal NodoSPC), visualizzato l’importo totale del pagamento e autorizzato lo stesso, il NodoSPC esegue verso l’Acquirer una richiesta di prenotazione del credito sulla carta di pagamento inserita.
L’Acquirer, a valle delle proprie verifiche, decide se autorizzare la prenotazione del credito.
A conclusione del passo precedente, l’Acquirer restituisce al NodoSPC l’esito dell’operazione.
In caso di esito positivo, il NodoSPC informa l’Utilizzatore finale, tramite apposito messaggio, di aver preso in carico la transazione.
Il NodoSPC costruisce la URL di redirect per re-direzionare l’Utilizzatore finale sul Portale dell’EC.
Il browser dell’Utilizzatore finale è indirizzato sul Portale dell’EC specificando i seguenti parametri:
1. idDominio: identificativo dell’EC che ha eseguito la richiesta di pagamento
2. idSession: identificativo della sessione precedentemente creata
3. esito: descrive l’esito dell’operazione, contiene sempre il valore DIFFERITO
A seguito dell’esito positivo della richiesta di prenotazione del credito, il PSP, collegato all’Acquirer selezionato, riceve dal NodoSPC il carrello di RPT, attraverso la primitiva pspInviaCarrelloRPTCarte.
A seguito della ricezione del carrello, il PSP esegue il controllo semantico del carrello.
Il PSP replica al NodoSPC mediante response positiva valorizzando il parametro di output esitoComplessivoOperazione con il valore OK.
Il NodoSPC esegue verso l’Acquirer una richiesta di contabilizzazione del credito prenotato sulla carta di pagamento inserita, modifica lo stato del pagamento in RT PSP e invia una mail all’Utilizzatore finale fornendo l’esito positivo dell’operazione.

Pagamento mediante altri strumenti

Se l’Utilizzatore finale ha selezionato un servizio di pagamento diverso dalla carta, il NodoSPC invia il carrello di RPT al PSP a cui afferisce il servizio di pagamento selezionato mediante la primitiva pspInviaCarrelloRPT.
Il PSP replica all’invocazione precedente fornendo eventualmente una URL di re-direct. Lo stato del pagamento transisce a RT PSP.

Pagamento mediante re-indirizzamento on-line
Pagamento mediante autorizzazione gestita dal PSP

Pagamento mediante re-indirizzamento on-line

Il NodoSPC utilizza la URL ricevuta per re-direzionare il browser dell’Utilizzatore finale.
L’Utilizzatore finale raggiunge le pagine messe a disposizione dal PSP per finalizzare il processo di pagamento.
L’Utilizzatore finale completa la transazione sulle pagine messe a disposizione dal PSP.
Il PSP predispone la http REDIRECT verso la URL del NodoSPC.
Il browser dell’Utilizzatore finale raggiunge il NodoSPC.

Pagamento mediante autorizzazione gestita dal PSP

Nel caso in cui il PSP replichi alla primitiva pspInviaCarrelloRPT fornendo la URL di re-direct con valore null, l’Utilizzatore finale autorizza il pagamento interagendo direttamente con il PSP. Tale casistica verrà approfondita al § 9.1.2.2.

Indipendentemente dal servizio di pagamento selezionato, l’Utilizzatore finale visualizza l’esito del pagamento.

Il NodoSPC mostra la pagina di riepilogo (“thank you page”) indicando che il pagamento è stato preso in carico.
Il NodoSPC re-indirizza verso l’EC accodando alla URL il parametro esito opportunamente valorizzato (OK, ERROR, DIFFERITO).
Il PSP genera la RT.
Il PSP invia la RT all’EC attraverso il NodoSPC mediante la primitiva nodoInviaRT.
Il NodoSPC inoltra la RT all’EC attraverso la primitiva paaInviaRT.
L’EC replica all’invocazione precedente e lo stato del pagamento transisce a RT EC ad indicare che la ricevuta telematica è stata consegnata all’Ente Creditore.
Il NodoSPC inoltra la response fornita dall’EC al PSP.

Caso acquisto Marca da bollo digitale¶

Il pagamento di una Marca da Bollo Digitale avviene attraverso il medesimo workflow applicativo decritto nel paragrafo precedente. Si fa presente che sarà necessario valorizzare nella RPT la struttura dati descritta al §8.2.2.

In particolare, l’EC nella predisposizione della RPT deve specificare, oltre all’importo richiesto per la Marca da Bollo Digitale, i seguenti dati:

il tipo di bollo da erogare (parametro tipoBollo);
l’impronta del documento da bollare (parametro hashDocumento);
la provincia di residenza del soggetto pagatore (parametro provinciaResidenza).

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

Caso autorizzazione gestita dal PSP¶

Nel caso in cui il metodo di pagamento scelto dall’Utilizzatore finale preveda un processo autorizzativo gestito dal PSP, i meccanismi di autorizzazione avvengono al di fuori del sistema pagoPA, tramite accordi specifici tra il PSP e l’Utilizzatore finale (soggetto versante). I sistemi informatici del PSP acquisiscono tramite la RPT i dati del soggetto versante e procedono all’autenticazione dell’identità dichiarata autorizzando, se del caso, l’accesso ai sistemi di pagamento.

Un esempio di tale casistica è rappresentato dalla sottoscrizione da parte dell’Utilizzatore finale di una manleva nei confronti del PSP, riguardante la possibilità di addebito del proprio conto corrente per le richieste di pagamento provenienti da uno specifico EC. In questo specifico caso l’acquisizione dei dati del soggetto versante è effettuata tramite il parametro ibanAddebito valorizzato dall’EC, all’interno della RPT, con il codice IBAN del conto corrente del soggetto versante.

Prenotazione Rifiutata¶

Si descrive nel seguito lo scenario secondario che si verifica quando l’Acquirer non autorizza il pagamento con carta.

P re-condizione	L’Utilizzatore finale effettua pagamento tramite carta
Descrizione	Alla richiesta di prenotazione del credito effettuata dal NodoSPC all’Acquirer, questi risponde con esito negativo
Po st-condizione	Lo stato del pagamento transisce a Pagamento rifiutato

Figura 2: Diagramma di sequenza della prenotazione rifiutata

L’evoluzione temporale è la seguente:

dopo che l’Utilizzatore finale ha confermato la volontà di pagare mediante Carta di Pagamento, il NodoSPC esegue verso l’Acquirer una richiesta di prenotazione del credito sulla carta di pagamento inserita.
l’Acquirer esegue le verifiche del caso.

A questo punto sono possibili le due seguenti alternative:

l’Acquirer comunica l’esito negativo della prenotazione del credito;

il NodoSPC riscontra condizioni di timeout.

Il pagamento transisce a PAGAMENTO_RIFIUTATO.

la componente WISP del NodoSPC mostra all’Utilizzatore finale l’esito negativo delle operazioni;
il NodoSPC costruisce la URL di redirect verso il Portale dell’EC;
l’Utilizzatore finale è re-diretto verso il Portale dell’EC;
Il NodoSPC genera RT negativa.

Il workflow si conclude riprendendo dal punto 28 dello scenario nominale.

Gestione degli errori¶

Il paragrafo descrive la gestione degli errori nel processo di Pagamento attivato presso l’Ente Creditore secondo le possibili eccezioni riportate nel Paragrafo precedente.

Carrello di RPT rifiutato dal Nodo

Pre-condizione	L’EC compone e sottomette al NodoSPC un carrello di RPT
Descrizione	Il NodoSPC rifiuta il carrello di RPT
P ost-condizione	Lo stato del pagamento transisce a RPT Rifiutata

Figura 3: Scenario RPT rifiutata dal Nodo

l’Utilizzatore finale esegue il check-out sul portale dell’EC.
l’EC sottomette al NodoSPC il carrello di RPT mediante la primitiva nodoInviaCarrelloRPT.
il NodoSPC valida la richiesta.
il NodoSPC replica fornendo response con esito KO indicando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato.

L’EC notifica all’Utilizzatore finale l’errore tecnico invitandolo a contattare il supporto messo a disposizione dall’EC stesso.

Le possibili azioni di controllo sono riportate nella tabella seguente.

Strategia di risoluzione	Tipologia Errore	Azione preventiva Suggerita
	PPT_SINTASSI_EXTRAXSD	Verificare la composizione del carrello RPT (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa pri mitiva/FAULT_CODE) e i parametri di invocazione della primitiva SOAP
	PPT_SINTASSI_XSD
	P PT_ID_CARRELLO_DUPLICATO	Utilizzare l’algoritmo specificato per creare un ide ntificativoCarrello univoco nel sistema pagoPA
	PPT_SEMANTICA	Verificare la composizione del documento XML RPT controllando la correttezza di valorizzazione dei campi (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa pri mitiva/FAULT_CODE)
	PPT_IBAN_NON_CENSITO	Verificare preventivamente che il valore dei parametri ibanAccredito ed ibanAppoggio presenti nelle RPT siano presenti fra quelli forniti in fase di configurazione e attivati al momento dell’utilizzo

Tabella 2: Strategie di risoluzione per lo scenario carrello RPT rifiutato dal Nodo

Pagamento non Contabilizzato

Pre-condizione	L’Utilizzatore finale paga con carta
Descrizione	Il PSP rifiuta il carrello di RPT inviato dal NodoSPC
P ost-condizione	Lo stato del pagamento transisce a Pagamento rifiutato

Figura 4: Diagramma di sequenza del pagamento non contabilizzato

L’evoluzione temporale è la seguente:

il NodoSPC esegue la richiesta di prenotazione del credito;
l’Acquirer esegue la verifica della richiesta;
l’Acquirer autorizza la richiesta di prenotazione del credito;
il NodoSPC mediante la componente WISP mostra all’Utilizzatore finale la “thank you page” con il messaggio di presa in carico della richiesta;
il NodoSPC costruisce la URL di redirect verso il Portale dell’EC;
il browser dell’Utilizzatore finale è re-direzionato sul portale dell’EC. Il parametro esito sarà impostato al valore DIFFERITO.
il Nodo invia il carrello di RPT al PSP.

il PSP replica negativamente alla richiesta precedente fornendo esito KO alla primitiva di cui al punto 7;

il NodoSPC annulla la prenotazione del credito precedentemente effettuata
il NodoSPC genera RT negativa ed il processo riprende dal punto 28 dello scenario di pagamento nominale.

il NodoSPC riscontra condizioni di timeout della controparte;
il NodoSPC attiva i meccanismi di rientro procedendo ad interrogare la controparte sull’esito positivo o meno dell’inoltro della RPT di cui al punto 7 mediante la primitiva pspChiediStatoRPT fornendo in ingresso la chiave di pagamento.
il PSP ricerca nei propri archivi la RPT richiesta dal NodoSPC.

A questo punto possono verificarsi i seguenti scenari:

il PSP replica fornendo esito OK alla primitiva di cui al punto 12. Essendo la RPT giunta al PSP il NodoSPC non compie alcuna azione ed attende la generazione della RT da parte del PSP.

Lo stato del pagamento transisce a RT PSP.

il PSP replica fornendo esito KO alla primitiva di cui al punto 12 emettendo un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato:
- CANALE_RPT_SCONOSCIUTA: il PSP non ha ricevuto alcun carrello di RPT da parte del NodoSPC o l’ha ricevuto parziale;
- CANALE_RPT_RIFIUTATA: il PSP ha ricevuto la RPT da parte del NodoSPC scartandola a seguito di errori di validazione;
il Nodo annulla la prenotazione del credito precedentemente effettuata;
il Nodo genera RT negativa.

RT rifiutata dal NodoSPC

Pre-condizione

Il pagamento si trova nello stato RT PSP

Descrizione

Il PSP invia la RT al NodoSPC

Il NodoSPC rifiuta la RT fornendo response negativa

P ost-condizione

Lo stato del pagamento permane in RT PSP

Figura 5: Scenario RT rifiutata Nodo

L’evoluzione temporale è la seguente:

il PSP invia la RT attestante l’esito del pagamento mediante la primitiva nodoInviaRPT;
il NodoSPC replica negativamente fornendo response con esito KO emanando un faultBean il cui faultBean.faultCode è valorizzato al variare dell’errore riscontrato; in particolare:
- PPT_RT_DUPLICATA nel caso in cui il PSP sottometta nuovamente una RT già invita in precedenza;
- PPT_SEMANTICA nel caso in cui il NodoSPC riscontri errori di significato nei dati contenuti nella RT.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	PPT_SINTASSI_EXTRAXSD	Verificare l’invocazione della primitiva (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa p rimitiva/FAULT_CODE)
	PPT_SINTASSI_XSD
	PPT_RT_DUPLICATA	Gestire il caso di RT duplicata il NodoSPC ha già ricevuto la RT verificando i propri sistemi
	PPT_SEMANTICA	Verificare il controllo fallito effettuato dal NodoSPC (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa p rimitiva/FAULT_CODE)

Tabella 3: Strategia di risoluzione del caso RT rifiutata dal Nodo

RT rifiutata dall’EC

P re-condizione	Il pagamento si trova nello stato RT_PSP
Descrizione	L’EC rifiuta la RT inviata dal NodoSPC producendo uno specifico codice di errore; il NodoSPC propaga l’errore al PSP
Po st-condizione	Lo stato del pagamento permane in RT_PSP

Figura 6: Scenario RT rifiutata dall’EC

L’evoluzione temporale è la seguente:

il PSP sottomette al NodoSPC una RT mediante la primitiva nodoInviaRT;
il Nodo sottomette all’EC la RT ricevuta mediante la primitiva paaInviaRT;
l’EC replica negativamente fornendo response con esito KO emettendo un faultBean dove il valore del campo faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PAA_RT_DUPLICATA nel caso in cui il NodoSPC abbia sottomesso una RT precedentemente inviata;
- PAA_RPT_SCONOSCIUTA nel caso in cui alla RT consegnata non risulti associata alcuna RPT;
- PAA_SEMANTICA nel caso in cui si riscontrano errori nel tracciato XML della RT;
il NodoSPC propaga l’errore riscontrato dall’EC emanando un faultBean il cui faultBean.faultCode è pari a PPT_ERRORE_EMESSO_DA_PAA.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	PPT_ERRORE_EMESSO_DA_PAA	Attivazione TAVOLO OPERATIVO

Pagamento presso il PSP¶

Attori e casi d’uso¶

All’interno di questo capitolo vengono descritti i casi d’uso relativi ai possibili processi di pagamento da parte di un Utilizzatore finale, attraverso uno dei canali messi a disposizione da un PSP, mediante la presentazione di un Avviso di Pagamento notificatogli da un EC. L’Avviso di pagamento predisposto dall’EC dove essere conforme a quanto previsto nel documento “Il nuovo avviso di pagamento analogico nel sistema pagoPA Versione 2.2.1 - Dicembre 2018”.

Gli attori coinvolti sono i seguenti:

PSP: rappresenta un canale (fisico o digitale) che offre un servizio di pagamento all’Utilizzatore finale.
Ente Erogatore: soggetto che si incarica di abilitare all’interno del sistema pagoPA uno o più servizi di pagamento spontaneo.
Ente Creditore: rappresenta un soggetto aderente a pagoPA in grado di gestire i pagamenti attivati presso i PSP predisponendo e notificando (per mezzo cartaceo o digitale) agli utilizzatori finali un avviso di pagamento. Interagisce inoltre con l’Ente Erogatore per la gestione del caso di pagamento spontaneo
Utilizzatore Finale, rappresenta una persona fisica e/o giuridica che interagisce con uno dei canali messi a disposizione dal PSP al fine di pagare un servizio anche senza disporre di un avviso di pagamento.

Gli scenari di utilizzo sono descritti dai seguenti casi d’uso nominali:

Pagamento mediante Avviso (scenario principale): l’Utilizzatore finale utilizza un canale (fisico o digitale) messo a disposizione da un PSP presentando un Avviso di Pagamento. Il pagamento viene perfezionato a valle della ricezione della RPT da parte del PSP.
Pagamento mediante Avviso (scenario alternativo): l’Utilizzatore finale utilizza un canale (fisico o digitale) messo a disposizione da un PSP presentando un Avviso di Pagamento. Il pagamento viene effettuato a valle della verifica della correttezza dell’avviso ma prima della richiesta di attivazione della RPT da parte del PSP.
Pagamento spontaneo presso il PSP: l’Utilizzatore finale utilizza un canale (fisico o digitale) predisposto dal PSP per innescare il pagamento spontaneo di un servizio messo a disposizione da un Ente Erogatore. In tale scenario potrebbe non esistere alcuna posizione debitoria pre-esistente all’interno degli archivi di pagamento in attesa dell’EC.

Pagamento mediante Avviso (scenario principale)¶

Pre-condizioni	L’Utilizzatore finale è in possesso di un Avviso di Pagamento notificato dall’EC.
Trigger	L’Utilizzatore finale si presenta presso uno dei canali messi a disposizione dal PSP (ad esempio sportello fisico, ATM, Home Banking, mobile app, etc.) con l’Avviso di Pagamento.
Descrizione	Il PSP acquisisce le informazioni contenute nell’avviso tramite la lettura di uno degli elementi grafici presenti (QR-Code / Data matrix). Deve comunque essere reso possibile l’inserimento manuale degli stessi dati. Il PSP, tramite il NodoSPC, richiede l’attivazione del pagamento descritto all’interno dell’avviso di pagamento. Tale operazione verifica la sussistenza della posizione debitoria collegata all’avviso di pagamento e determina l’importo del versamento richiesto dall’EC. Nel caso in cui l’importo recuperato con tale operazione prevale sul dato presente nell’Avviso di Pagamento. Il PSP riceve, tramite il NodoSPC, la relativa richiesta di pagamento telematico (RPT). l’Utilizzatore finale, consapevole degli eventuali differenze rispetto ai dati riportati sull’avviso, autorizza il pagamento con le modalità previste dal canale PSP. Il PSP rilascia l’attestazione di pagamento all’Utilizzatore finale. Il PSP, tramite il NodoSPC, invia la ricevuta telematica con esito positivo
Post-Condizione	Al termine del caso d’uso il pagamento risulta completato con lo stato RT EC.

Figura 1: Pagamento mediante Avviso

l’Utilizzatore finale presenta un avviso di pagamento presso uno dei canali messi a disposizione dal PSP;
il PSP acquisisce le informazioni contenute dall’avviso di pagamento tramite lettura del codice QR-Code (ISO 18004). La lettura del QR-Code riporta una stringa composta dalla concatenazione dei seguenti campi.

Dato	Contenuto
Numero Avviso	Contiene il Numero Avviso la cui formattazione è descritta nell’Allegato A alle Linee Guida
I dentificati vo Ente	Contiene l’idDominio dell’Ente Creditore che corrisponde al Codice fiscale dell’Ente Creditore
Importo	Importo del pagamento espresso in centesimi di euro

Nel caso che la lettura ottica dei codici non sia prevista, o possibile, le stesse informazioni sono imputate in maniera manuale o dall’operatore PSP allo sportello o dall’Utilizzatore finale attraverso user interface messe a disposizione dal PSP.

il PSP richiede, attraverso la primitiva nodoAttivaRPT, l’attivazione del pagamento per la posizione debitoria collegata all’avviso di pagamento. Al fine di completare la richiesta, il campo codificaInfrastruttura e la struttura codIdRPT dovranno essere così valorizzati:

co dificaInfra s trutturaPSP	Assume il valore fisso: “QR-CODE”
codIdRPT	Struttura dati composta da:
CF	Codice Fiscale dell’Ente Creditore, valore del campo Identificativo Ente, letto tramite QR-Code.
CodStazPA	Contiene il valore dell’application code o codice segregazione estratto dal numero di avviso (se presente)
AuxDigit	Contiene il codice aux-digit estratto dal numero avviso
CodIUV	Identificativo Univoco Versamento estratto dal Numero di Avviso

il Nodo effettua i controlli semantici e sintattici;
il NodoSPC provvede ad instradare la richiesta di attivazione all’EC che ha emesso l’avviso, tramite la chiamata paaAttivaRPT.
l’EC verifica le informazioni relative all’avviso e lo stato del pagamento. In caso di esito positivo, l’EC imposta lo stato del pagamento in IN_PAGAMENTO e genera una RPT che verrà successivamente inviata al NodoSPC tramite la primitiva nodoInviaRPT.
l’EC fornisce al NodoSPC l’esito dell’attivazione del pagamento restituendo le seguenti informazioni:

Importo del versamento (ImportoSingoloVersamento)
IBAN del conto corrente da accreditare (IBANAccredito)
Ente Creditore (enteBeneficiario)
Descrizione del Versamento (causaleVersamento)

il NodoSPC inoltra le informazioni in risposta al PSP che ha effettuato la richiesta.
il PSP riporta il risultato dell’operazione di attivazione all’Utilizzatore finale evidenziando il dettaglio dell’importo da pagare e la descrizione del versamento;
l’Utilizzatore finale autorizza il pagamento con le modalità proprie del canale utilizzato;
il PSP, a seguito dell’autorizzazione da parte dell’Utilizzatore finale, effettua il pagamento.
Il PSP, a seguito dell’avvenuto pagamento, rilascia all’Utilizzatore finale un attestato di pagamento
l’EC genera, a fronte della precedente richiesta di attivazione, una RPT valorizzata specificando il PSP indicato nella chiamata nodoAttivaRPT, in particolare:
- il parametro IdentificativoPSP deve essere valorizzato al pari del medesimo campo ricevuto dal messaggio paaAttivaRPT;
- il parametro codiceContestoPagamento deve essere valorizzato al pari del medesimo campo ricevuto dal messaggio paaAttivaRPT;
- la RPT deve contenere il campo TipoVersamento pari al valore “PO” che indica un pagamento iniziato presso il PSP;
il NodoSPC effettua controlli semantici e sintattici della richiesta pervenuta.
il NodoSPC risponde alla RPT generata;
il Nodo instrada la richiesta di pagamento ricevuta verso il PSP indicato all’interno della RPT
alla ricezione della pspInviaRPT, il PSP verifica l’univocità e la correttezza formale della RPT comunicando, tramite la response positiva, la presa in carico della richiesta di pagamento.
in merito all’operazione di pagamento, il PSP compone la RT e la invia al NodoSPC;
il NodoSPC effettua controlli semantici e sintattici della richiesta pervenuta;
il NodoSPC instrada la RT all’EC;
l’EC, ricevuta la RT, procede ad aggiornare l’Archivio dei Pagamenti in Attesa, lo stato del pagamento viene modificato in PAGATO;
l’EC notifica l’avvenuta ricezione della RT al NodoSPC;
il NodoSPC notifica al PSP la ricezione dell’RT da parte dell’EC.

Pagamento mediante Avviso (scenario alternativo) DEPRECATO¶

Pre-condizioni	L’Utilizzatore finale è in possesso di un Avviso di Pagamento.
Trigger	L’Utilizzatore finale si presenta presso uno dei canali messi a disposizione del PSP (ad esempio sportello fisico, punti di presenza, ATM, Home Banking, mobile app, etc.) con l’Avviso di Pagamento.
Descrizione	In questo scenario il PSP decide di effettuare il pagamento dopo aver verificato l’Avviso di Pagamento, ma senza aver mai ricevuto alcuna RPT da parte dell’EC. Il PSP acquisisce le informazioni contenute nell’avviso tramite la lettura di uno degli elementi grafici presenti (QR-Code / Data matrix). Deve comunque essere reso possibile l’inserimento manuale degli stessi dati. Il PSP, tramite il NodoSPC, verifica la sussistenza della posizione debitoria collegata all’avviso di pagamento e determina l’importo del versamento richiesto dall’EC. L’Utilizzatore finale, consapevole degli eventuali differenze rispetto ai dati riportati sull’avviso, autorizza il pagamento con le modalità previste dal canale PSP. Il PSP rilascia l’attestazione di pagamento all’Utilizzatore finale. Il PSP, tramite il NodoSPC, richiede l’attivazione della RPT relativa all’avviso di pagamento. Il PSP riceve, tramite il NodoSPC, la relativa richiesta di pagamento telematico (RPT). Il PSP, tramite il NodoSPC, invia all’EC la relativa ricevuta telematica con esito positivo.
Post-Condizione	Al termine del caso d’uso il pagamento risulta completato con lo stato RT EC.

Figura 2: Diagramma di sequenza del pagamento con avviso di pagamento ( scenario alternativo)

l’Utilizzatore finale presenta un avviso di pagamento (di cui al documento “L’avviso di Pagamento Analogico nel Sistema pagoPA”, pubblicato sul sito istituzionale dell’Agenzia) presso uno dei canali messi a disposizione dal PSP;
il PSP acquisisce le informazioni contenute dall’avviso di pagamento tramite lettura del codice QR-Code (ISO 18004). La lettura del QR-Code riporta una stringa composta dalla concatenazione dei seguenti campi.

Dato	Contenuto
Numero Avviso	Contiene il Numero Avviso la cui formattazione è descritta nell’Allegato A alle Linee Guida
Ide ntificati vo Ente	Contiene l’idDominio dell’Ente Creditore che corrisponde al Codice fiscale dell’Ente Creditore
Importo	Importo del pagamento espresso in centesimi di euro

Nel caso che la lettura ottica dei codici non sia prevista o possibile le stesse informazioni sono imputate in maniera manuale o dall’operatore PSP allo sportello o dall’utilizzatore finale attraverso user interface messe a disposizione dal PSP.

una volta acquisite le informazioni necessarie, il PSP richiede attraverso la primitiva nodoVerificaRPT i dettagli del pagamento per la posizione debitoria collegata all’avviso di pagamento. Al fine di completare la richiesta, il campo codificaInfrastruttura e la struttura codIdRPT dovranno essere così valorizzati:

codificaInfra strutturaPSP	Assume il valore fisso: “QR-CODE”.
codIdRPT	Struttura dati composta da
CF	Codice Fiscale dell’Ente Creditore, valore del campo Identificativo Ente, letto tramite QR-Code.
CodStazPA	Contiene il valore dell’aplication code o codice segregazione estratto dal numero di avviso ( se presenti)
AuxDigit	Contiene il codice aux-digit estratto dal numero avviso
CodIUV	Identificativo Univoco Versamento estratto dal Numero di Avviso

il Nodo effettua i controlli semantici e sintattici;
superati i controlli, il NodoSPC provvede ad instradare la richiesta all’EC che ha emesso l’avviso tramite la chiamata paaVerificaRPT riempita con le informazioni contenute nella nodoVerificaRPT.
alla ricezione della chiamata paaVerificaRPT, l’EC ricerca all’interno del proprio Archivio dei Pagamenti in Attesa (APA) la posizione debitoria utilizzando come chiave di ricerca lo IUV ed il CCP contenuto all’interno dei parametri della primitiva e verificandone le informazioni e lo stato del pagamento.
l’EC fornisce al NodoSPC l’esito della ricerca aggiornando le informazioni relative all’avviso di pagamento, specificando:
- Importo del versamento (ImportoSingoloVersamento)
- IBAN del conto corrente (IBANAccredito)
- identificativo della banca (opzionale, bicAccredito)
- Ente Creditore (enteBeneficiario)
- Dettagli del soggetto pagatore (credenzialiPagatore)
- Descrizione del versamento (causaleVersamento)
il NodoSPC inoltra la risposta al PSP che ha effettuato la richiesta.
il PSP riporta il risultato dell’operazione all’Utilizzatore finale;
l’Utilizzatore finale autorizza il pagamento;
il PSP, procede al pagamento del servizio identificato dall’Avviso di Pagamento.
Il PSP rilascia l’attestazione del pagamento all’Utilizzatore finale.
il PSP richiede al NodoSPC l’inoltro all’Ente Creditore della RPT. La primitiva nodoAttivaRPT sarà composta utilizzando i valori codificaInfrastrutturaPSP, codiceIdRPT e datiPagamentoPSP acquisiti nella fase precedente;
il NodoSPC effettua controlli semantici e sintattici della richiesta;
il NodoSPC inoltra la richiesta di attivazione del pagamento attraverso la primitiva paaNodoAttivaRPT, con le informazioni ricevute da parte del PSP.
alla ricezione della primitiva paaAttivaRPT, l’EC verifica le informazioni relative all’avviso e lo stato del pagamento. In caso di esito positivo, l’EC imposta lo stato del pagamento in IN_PAGAMENTO e genera una RPT che verrà successivamente inviata al NodoSPC tramite la primitiva nodoInviaRPT.
l’ente Creditore risponde alla richiesta di attivazione;
il NodoSPC inoltra l’esito della risposta al PSP;
l’EC genera, a fronte della precedente richiesta, una RPT valorizzata specificando il PSP indicato nella chiamata nodoAttivaRPT, in particolare:
- il parametro IdentificativoPSP deve essere valorizzato al pari del medesimo campo ricevuto dal messaggio paaAttivaRPT;
- il parametro codiceContestoPagamento deve essere valorizzato al pari del medesimo campo ricevuto dal messaggio paaAttivaRPT;
- la RPT deve contenere il campo TipoVersamento pari al valore “PO” che indica un pagamento iniziato presso il PSP;
il NodoSPC effettua controlli semantici e sintattici della richiesta pervenuta.
il NodoSPC risponde alla RPT generata;
il Nodo instrada la richiesta di pagamento ricevuta verso il PSP indicato all’interno della RPT;
alla ricezione della pspInviaRPT, il PSP notifica l’univocità e la correttezza formale della RPT; In tale scenario, avendo il PSP già incassato, non è consensito rifiutare la ricezione della RPT consegnata dal nodo.
a fronte del pagamento avvenuto precedentemente, il PSP compone la RT.
il PSP invia la RT al NodoSPC;
il NodoSPC effettua controlli semantici e sintattici della richiesta pervenuta;
il NodoSPC instrada la RT all’Ente Creditore;
l’EC, ricevuta la RT, procede ad aggiornare l’Archivio dei Pagamenti in Attesa, lo stato del pagamento viene modificato in PAGATO;
l’EC notifica l’avvenuta ricezione della RT al NodoSPC;
il NodoSPC notifica al PSP la ricezione dell’RT da parte dell’EC;
il PSP può concludere il pagamento.

Pagamento spontaneo¶

Pre-condizioni	Un Ente Erogatore ha messo a disposizione del NodoSPC un servizio per il quale non è necessario inviare un Avviso di Pagamento poiché l’Utilizzatore finale è già in possesso di tutti i dati necessari per avviare il pagamento.
Trigger	L’Utilizzatore finale si presenta presso uno dei canali messi a disposizione dal PSP in possesso di tutte le informazioni necessarie per avviare il pagamento.
Descrizione	Attraverso il canale messo a disposizione dal PSP, l’Utilizzatore finale (o l’operatore del PSP) ricerca e seleziona il servizio messo a disposizione da un Ente Erogatore. Il PSP acquisisce (mediante una propria soluzione specifica) da parte dell’Utilizzatore finale i dati necessari alla richiesta di attivazione del pagamento spontaneo. Il PSP invia, per mezzo del NodoSPC, la richiesta di pagamento spontaneo all’Ente Erogatore del servizio. L’Ente Erogatore, in base ai dati ricevuti, identifica l’Ente Creditore del pagamento al quale invia, tramite NodoSPC, la richiesta di pagamento spontaneo. L’Ente Creditore, in base alla richiesta ricevuta, crea (o ricerca) la relativa posizione debitoria all’interno dell’Archivio dei Pagamenti in Attesa. L’Ente crea un avviso digitale relativo alla posizione debitoria e lo invia al NodoSPC. L’Ente Creditore risponde alla richiesta dell’Ente Erogatore restituendo, tramite NodoSPC, l’avviso digitale relativo alla posizione debitoria. L’Ente Erogatore, tramite NodoSPC, invia al PSP l’avviso digitale relativo alla posizione debitoria creata. Il PSP propone all’Utilizzatore finale, il pagamento dell’avviso digitale. l’Utilizzatore finale autorizza il pagamento che prosegue come un pagamento presso il PSP.
Post-Condizione	Al termine di tale caso d’uso lo stato del pagamento è RT_EC. L’Utilizzatore finale possiede uno scontrino che attesta il pagamento del servizio e l’Ente Beneficiario ha ricevuto la RT.

Il sequence di tale processo è ancora in fase di definizione.

Gestione degli errori¶

Il paragrafo descrive la gestione degli errori nel processo di Pagamento attivato presso il PSP secondo le possibili eccezioni riportate nel Paragrafo precedente.

Errore di Attivazione/Verifica

Pre-condizioni

Il PSP compone e sottomette una richiesta di attivazione o verifica di una RPT.

Descrizione

Il NodoSPC rifiuta l’attivazione o la verifica della RPT.

Per semplicità il sequence riporta esclusivamente il caso della chiamata nodoAttivaRPT, ma il comportamento sarà il medesimo nel caso dell’invocazione della primitiva nodoVerificaRPT

Post-condizione

Lo stato del pagamento non viene modificato

Figura 3: Errore di Attivazione/Verifica

il PSP richiede l’attivazione di un pagamento mediante la primitiva nodoAttivaRPT;
il NodoSPC valida la richiesta;
il NodoSPC replica fornendo response con esito KO indicando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato.
il PSP notifica all’Utilizzatore finale l’errore tecnico con un messaggio di errore esplicativo invitando eventualmente a contattare il servizio clienti.

Le possibili azioni di controllo sono riportate nella Tabella seguente:

Strategia di risoluzione

Tipologia Errore

Azione di Controllo Suggerita

PPT_SINTASSI_XSD

PPT_SINTASSI_EXTRAXSD

Verificare la composizione della richiesta ed i parametri di invocazione della primitiva SOAP.

PPT_SEMANTICA

Verificare la composizione del documento XML RPT controllando la correttezza di valorizzazione dei campi

PPT_IBAN_NON_CENSITO

Verificare il valore dei parametri ibanAccredito ed ibanAppoggio presenti nelle RPT

Tabella 1: Possibili azioni di controllo

Pagamento non eseguibile

Pre-condizioni

Il PSP è in possesso dei dati di pagamento ottenuti mediante lettura dell’avviso di pagamento.

Descrizione

L’EC, a seguito della ricezione di una primitiva paaAttivaRPT o paaVerificaRPT, verifica lo stato del pagamento all’interno del proprio Archivio Pagamenti in Attesa e riscontra uno stato del pagamento non conforme con la richiesta pervenuta. Possono essere segnalati i seguenti codici di errore:

PAA_PAGAMENTO_SCONOSCIUTO nel caso in cui la ricerca all’interno dell’Archivio Pagamenti in Attesa non abbia dato alcun risultato.
PAA_PAGAMENTO_DUPLICATO nel caso che lo stato della posizione debitoria risulti essere PAGATO.
PAA_PAGAMENTO_IN_CORSO nel caso che lo stato della posizione debitoria sia PAGAMENTO_IN_CORSO.
PAA_PAGAMENTO_ANNULLATO nel caso che lo stato della posizione debitoria sia ….
PAA_PAGAMENTO_SCADUTO nel caso che la posizione debitoria non sia più solvibile. stato della posizione debitoria sia ….
PAA_ATTIVA_RPT_IMPORTO_NON_ VALIDO, nel caso in cui l’importo contenuto all’interno dell’Archivio dei Pagamenti in Attesa sia diverso da quanto ricevuto.

Per semplicità il sequence riporta esclusivamente il caso della chiamata paaAttivaRPT, ma il medesimo comportamento viene replicato nel caso della primitiva paaVerificaRPT .

Post-Condizione

Lo stato del pagamento non viene modificato

Figura 4: Pagamento non eseguibile

il PSP richiede l’attivazione di un pagamento mediante la primitiva nodoAttivaRPT;
il NodoSPC inoltra la richiesta di attivazione all’EC tramite la primitiva paaAttivaRPT;
l’EC valida la richiesta, verificando lo stato e l’importo (solo nel caso di attivazione) del pagamento all’interno del proprio Archivio dei Pagamenti in Attesa.
L’EC notifica uno dei possibili fault_code:
- PAA_PAGAMENTO_DUPLICATO
- PAA_PAGAMENTO_IN_CORSO
- PAA_PAGAMENTO_ANNULLATO
- PAA_PAGAMENTO_SCADUTO
- PAA_PAGAMENTO_SCONOSCIUTO
- PAA_ATTIVA_RPT_IMPORTO_NON_VALIDO (solo in caso di attivazione)
Il NodoSPC inoltra l’errore al PSP tramite la response alla primitiva nodoAttivaRPT con fault_code PPT_ERRORE_EMESSO_DA_PAA.

Le possibili azioni di controllo sono riportate nella Tabella seguente.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	P AA_PAGAMENTO_DUPLICAT O PAA_PAGAMENTO_IN_CORS O	Il pagamento deve essere interrotto in modo da evitare possibili pagamenti duplicati.
	PAA_PAGAMENTO_SCADUTO P AA_PAGAMENTO_ANNULLAT O	Il pagamento deve essere interrotto in quanto l’EC non accetta più il pagamento. È necessario che l’utente contatti il supporto messo a disposizione dall’EC al fine di poter proseguire con il pagamento.
	P AA_PAGAMENTO_SCONOSCI UTO	Il pagamento deve essere interrotto. E’ necessario attivare un TAVOLO OPERATIVO al fine di risolvere l’anomalia.
	PAA_ATTIVA_RPT_IMPORT O_NON_VALIDO	Il pagamento deve essere nuovamente attivato con l’importo corretto riportato all’interno della risposta.

Tabella 2: possibili azioni di controllo

Pagamento eseguito in assenza di RPT

Pre-condizioni

Il PSP ha richiesto, con esito positivo, l’attivazione di un pagamento tramite la primitiva nodoAttivaRPT.

.

Descrizione

Sono possibili due scenari:

Il PSP non riceve in tempi utili la RPT attesa:
1. Qualora non abbia già proceduto all’incasso nella fase di verifica, sulla base delle informazioni ottenute tramite la primitiva nodoAttivaRPT , il PSP procede al pagamento nonostante l’assenza dell’RPT.
2. Non avendo i dati della RPT, il PSP non può procedere con la generazione della RT e dovrà rendicontare l’avvenuto pagamento attraverso la predisposizione di un flusso di rendicontazione con codiceEsitoPagamento con valore 9.
3. Al fine di notificare l’EC e risolvere eventuali segnalazioni, il PSP attiva un TAVOLO OPERATIVO indicando i pagamenti incassati per i quali non è stata disponibile alcuna RPT. Per ogni IUV, sarà necessario specificare l’esito delle chiamate nodoVerificaRPT (OK, NOT OK,TimeOut) e nodoAttivaRPT (OK,NOT OK, TimeOut).
Il PSP riceve la RPT, ma a valle di controlli di validità notifica al nodo l’impossibilità di accettazione della richiesta di pagamento (tale scenario non è consentito nel caso di scenario Alternativo,dove il PSP ha già effettuato l’incasso):
1. Il PSP invia una response negativa al nodo alla primitiva pspInviaRPT
2. Estrapolando i codici identificativi della RPT, il PSP genera una RT negativa
3. Il PSP invia la RT- al NodoSPC

Post-Condizione

N/A

Figura 5: Pagamento eseguito in assenza di RPT

L’evoluzione temporale è la seguente:

Il PSP richiede l’attivazione del pagamento tramite la primitiva nodoAttivaRPT
Il NodoSPC, dove aver contattato l’EC, risponde positivamente alla primitiva nodoAttivaRPT
Il PSP non riceve in tempi utili alcuna RPT relativa al pagamento attivato precedentemente
Qualora non abbia già proceduto all’incasso nella fase di verifica, sulla base delle informazioni ottenute tramite la primitiva nodoAttivaRPT , il PSP procede al pagamento nonostante l’assenza dell’RPT.
Il PSP predispone, per il pagamento in oggetto, un flusso di rendicontazione 9. Contestualmente notifica al tavolo operativo l’avvenuto incasso dello IUV in oggetto.
Il PSP riceve da parte del nodo la RPT richiesta, tramite la primitiva pspInviaRPT
Il PSP valida la RPT ricevuta rilevando delle anomalie
Nel caso l’anomalia riscontrata sia riconducibile ad una duplicazione di RPT, il PSP notifica la response negativa con fault bean CANALE_RPT:DUPLICATA e nessuna altra azione è necessaria.
Nel caso di errore semantico, il PSP notifica una response negativa al NodoSPC con un codice faultBean descrittivo dell’errore rilevato.
A seguito del rifiuto dell’RPT in arrivo, il PSP genera una RT negativa
Il PSP invia la RT generata al punto precedente tramite la primitiva nodoInviaRT

Nota Bene: Il secondo scenario (punti dal 6 al 10 ) non può avvenire se il PSP ha già incassato a seguito della fase di verifica ( pagamento presso PSP , scenario alternativo)

Le possibili azioni di controllo sono riportate nella Tabella seguente.

Strategia di risoluzione

Tipologia Errore

Azione di Controllo Suggerita

CANALE_RPT_DUPLICATA

Il pagamento è stato già processo, non sono necessarie ulteriori azioni.

CANALE_SEMANTICA

CANALE_SINTASSI_XSD

C ANALE_SINTASSI_EXTRAX SD

Il pagamento deve essere interrotto in quanto il PSP non ritiene valida la RPT consegnata. E’ necessario generare una RT negativa.

RT respinta dal NodoSPC

P re-condi zioni

Il PSP ha effettuato il pagamento ed ha generato la RT da inviare all’EC. Lo stato del pagamento risulta RT presso PSP.

D escrizio ne

Il NodoSPC non prende in carico la RT inviata dal PSP in seguito al verificarsi di uno dei seguenti scenari alternativi:

Il NodoSPC evidenzia un’incoerenza nello stato del pagamento, l’RT inviata risulta sia già stata consegnata all’EC
Il NodoSPC evidenzia un’incoerenza tra l’esito della RT e quello restituito durante l’operazioni di re-direct on-line.
Il NodoSPC è indisponibile.

P ost-Cond izione

Al termine di tale scenario, lo stato del pagamento non viene variato.

Figura 6: RT respinta dal NodoSPC

L’evoluzione temporale è la seguente:

Il PSP invia la RT al NodoSPC affinché possa essere recapitato all’EC descritto nella RT.
Il NodoSPC effettua i controlli semantici sulla richiesta.
I controlli eseguiti dal NodoSPC evidenziano che una RT caratterizzata dagli stessi parametri chiave è già stata recapitata all’EC.
Il PSP deve essere in grado di gestire la segnalazione di RT duplicata evitando che la richiesta sia reiterata automaticamente e, eventualmente, ingaggiando il tavolo operativo per ogni altra casistica.
Il NodoSPC non fornisce una risposta entro i termini previsti.
A seguito di una mancata risposta nei tempi previsti dai livelli di servizio da parte del NodoSPC, il PSP archivia la RT al fine che possa essere recuperata attraverso la modalità PULL.

Le possibili azioni di controllo sono riportate nella Tabella seguente.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	PPT_RT_DUPLICATA	L’errore riscontrato non comporta alcuna ripercussione in merito al pagamento in corso.
	Timeout	In caso di mancata risposta da parte del NodoSPC , la RT generata deve essere archiviata al fine di essere reperita successivamente dal NodoSPC.

RT non consegnata all’EC

Pre-condizioni

Il PSP ha effettuato il pagamento ed ha generato la RT, accettata dal NodoSPC e da inviare all’EC

Descrizione

L’EC non riceve la RT, a causa dell’impossibilità da parte del NodoSPC a recapitare la RT consegnata dal PSP.

Gli scenari che possono portare a tale casistica sono tre:

L’EC evidenzia una incoerenza nello stato del pagamento, la RT ricevuta risulta già pervenuta ed elaborata.
L’EC non può accettare la RT consegnata in quanto evidenzia un errore oppure non riconosce la posizione debitoria associata.
L’EC non è raggiungibile.

Post-Condizione

Al termine di tale scenario, il PSP deve archiviare la RT all’interno del proprio archivio al fine di poter essere recuperata dal NodoSPC attraverso la modalità PULL

Figura 7: RT non consegnata all’EC

L’evoluzione temporale è la seguente:

Il NodoSPC invia la RT all’EC tramite la chiamata paaInviaRT
L’EC evidenzia all’interno dei propri sistemi la presenza della medesima RT in arrivo, e risponde utilizzando il fault code PAA_RT_DUPLICATA
Il Nodo inoltra l’errore al PSP incapsulandolo all’interno del fault code PPT_ERRORE_EMESSO_DA_PAA
Il PSP a seguito dell’inoltro dell’errore verifica lo stato del pagamento all’interno dei propri sistemi.
L’EC evidenzia un errore all’interno della RT ricevuta, in particolare verifica la conformità della RT e l’associazione della stessa con un pagamento presente all’interno del proprio archivio pagamenti in attesa nello stato IN_PAGAMENTO.
Il NodoSPC inoltra l’esito ricevuto dall’Ente, incapsulandolo all’interno del fault code PPT_ERRORE_EMESSO_DA_PAA
Il PSP, presa nota dell’impossibilità da parte dell’EC di accettare la RT emessa, attiva il TAVOLO OPERATIVO al fine di risolvere l’anomalia.
Il NodoSPC rileva che non è stato possibile contattare l’EC nei tempi previsti.
Il NodoSPC notifica l’impossibilità di consegnare la RT all’EC tramite il fault code PPT_STAZIONE_INT_PA_IRRAGGIUNGIBILE
Il PSP archivia la RT al fine che possa essere recuperata attraverso la modalità PULL.

Le possibili azioni di controllo sono riportate nella Tabella seguente.

Strategia di risoluzione

Tipologia Errore

Azione di Controllo Suggerita

PAA_RT_DUPLICATA

Nessuna azione, l’errore riscontrato non comporta alcuna anomalia di pagamento.

PAA_SEMANTICA

PAA_RPT_SCONOSCIUTA

A seguito di tale errore è necessario attivare il TAVOLO OPERATIVO per risolvere l’anomalia

PPT_STAZIONE_INT_PA_ IRRANGIUNGIBILE

In caso di mancata risposta da parte del NodoSPC , la RT generata deve essere archiviata al fine di essere reperita dal NodoSPC successivamente

Tabella 3: possibili azioni di controllo

RT non generata

Pre-condizioni

L’EC (nel giorno D) ha prodotto ed inviato senza alcun errore una RPT. Alla scadenza della data indicata all’interno del campo dataEsecuzionePagamento contenuto nell’RPT inviata (D+1), l’EC non riceve alcuna RT associata al pagamento richiesto.

Lo stato della posizione debitoria associata alla RPT è nello stato IN PAGAMENTO.

Descrizione

l’EC identifica lo IUV associato alla RPT alfine di ricercarlo attraverso il motore di riconciliazione all’interno dei flussi di rendicontazione del giorno D.

Sono possibili due scenari alternativi:

Qualora sia stato effettivamente eseguito il pagamento il flusso di rendicontazione conterrà lo IUV indicato all’interno della RPT con un codiceEsitoPagamento pari a 9 e L’EC provvederà a modificare lo stato del pagamento in PAGATO e procedere con le operazioni di riconciliazione.
Qualora all’interno del flusso di rendicontazione non venga ritrovato lo IUV atteso, l’EC attiva un TAVOLO OPERATIVO coinvolgendo il PSP indicato all’interno della RPT

Post-Condizione

Al termine di tale scenario, lo stato del pagamento è PAGATO

Funzioni e strategie di recupero¶

Scenari, casi d’uso e attori¶

Le funzionalità ausiliarie disponibili all’interno del Sistema pagoPA rappresentano funzionalità accessorie per la gestione dei processi correlati alle operazioni di pagamento e possono essere utilizzate dagli EC per il rientro da situazioni anomale o per le quali si renda necessario il ripristino di situazioni precedenti.

Tali funzioni sono utilizzate anche dai PSP al fine di interrogare le basi di dati messe a disposizione dal NodoSPC per l’esercizio del ciclo di vita del pagamento. Si fa presente che le funzionalità ausiliarie sono offerte dal NodoSPC attraverso interfacce SOAP consumabili dagli attori coinvolti. A sua volta, anche il NodoSPC, in qualità di fruitore, utilizza le funzionalità ausiliarie messe a disposizione dai PSP per la verifica e gestione degli errori nei processi di pagamento.

Figura 1: Rappresentazione degli erogatori e fruitori delle funzionalità di supporto

Funzioni Ausiliarie per L’Ente Creditore¶

Il paragrafo si focalizza sulle funzioni ausiliarie del NodoSPC, ovvero quelle funzioni, dedicate all’EC, che permettono l’espletamento dei processi correlati alle operazioni di pagamento e/o consentono la risoluzione di eventuali situazioni anomale o il rientro a stati preesistenti.

Richiesta della copia di una RT¶

L’EC ha facoltà di richiedere una copia della RT precedentemente recapitata.

Pre -Cond i zione	L’EC riscontra delle condizioni anomale sui pagamenti effettuati dagli utilizzatori finali o riscontra la perdita di una o più RT
Tr igger	Necessità di ripristino di una RT
Des crizi one	L’EC sottomette la richiesta di ricevere una specifica RT precedentemente ricevuta
Pos t-Con di zione	L’EC riceve la RT

Tabella 1: Richiesta della copia di una RT

Figura 2: Richiesta della copia di una RT

L’EC sottomette al NodoSPC la richiesta di ricevere una copia della RT mediante la primitiva nodoChiediCopiaRT;
La RT è correttamente trovata dal NodoSPC e restituita all’EC in allegato alla response positiva alla primitiva di cui al punto 1;
Il NodoSPC replica negativamente alla richiesta precedente fornendo response KO alla primitiva di cui al punto 1 emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_SINTASSI_XSD: nel caso di errore di validazione della richiesta
- PPT_SINTASSI_EXTRAXSD: nel caso di errore di validazione della SOAP request
- PPT_SEMANTICA: nel caso di errori semantici
- PPT_RT_SCONOSCIUTA: i parametri di input specificati nella richiesta non consentono di trovare alcuna RT
- PPT_RT_NONDOSPONIBILE: la RT richiesta non è disponibile.

Richiesta della Lista delle RPT Pendenti¶

L’EC ha facoltà di domandare la lista delle RPT correttamente inviate al PSP tramite il NodoSPC per le quali ancora non sono state ricevute le RT.

Pre -Condizion e	L’EC ha sottomesso al NodoSPC un certo numero di RPT e non ha ricevuto le RT
Trigger	Necessità di riconciliazione o chiusura delle posizioni pendenti
D escrizione	L’EC sottomette la richiesta di ricevere la lista delle RPT pendenti
Pos t-Condizio ne	L’EC riceve la lista delle RPT

Tabella 2: Richiesta della Lista delle RPT Pendenti

Figura 3: Richiesta della Lista delle RPT Pendenti

l’EC, mediante la primitiva nodoChiediListaPendentiRPT richiede al NodoSPC il numero e le RPT correttamente sottomesse ai PSP per le quali ancora non è stata ricevuta alcuna RT;
il NodoSPC replica con esito OK indicando il numero totale e le RPT pendenti consegnate al PSP scelto dall’Utilizzatore finale per le quali ancora non è stata consegnata al NodoSPC alcuna RT;
il NodoSPC replica con esito KO alla primitiva di cui al punto 1 emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_SINTASSI_EXTRAXSD: nel caso di errori nella SOAP request
- PPT_SEMANTICA: nel caso di errori semantici.

Verifica dello stato di una RPT¶

Pre -Condizione	L’EC ha sottomesso al NodoSPC una RPT
Trigger	L’EC necessita di conoscere l’evoluzione temporale di una specifica RPT
Descrizione	L’EC sottomette la richiesta di conoscere lo stato di una specifica RPT
Pos t-Condizion e	L’EC riceve le informazioni inerenti lo stato della RPT

Tabella 3: Verifica dello stato di una RPT

Figura 4: Verifica dello stato di una RPT

L’evoluzione temporale è la seguente:

l’EC richiede di conoscere lo stato di una RPT mediante la primitiva nodoChiediStatoRPT.

Caso OK

il NodoSPC replica positivamente alla primitiva di cui al punto 1 fornendo nella response le informazioni peculiari per il tracciamento della RPT stessa; in particolare:
- Redirect: specifica se il pagamento prevede o meno una redirect
- URL: eventuale URL di redirezione
- STATO: stato della RPT
- Descrizione: descrizione dello stato della RPT
- versamentiLista: struttura contenente una lista di elementi che identificano gli stati assunti da ogni singolo versamento presente nella RPT da quando la RPT è stata ricevuta dal PSP. Ogni elemento della lista è costituito da:
  - progressivo: numero del versamento nella RPT
  - data: data relativa allo stato del versamento
  - stato: stato della RPT alla data indicata
  - descrizione: descrizione dello stato alla data

Caso KO

il NodoSPC fornisce esito KO alla primitiva di cui al punto 1 emanando un fault.Bean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_RPT_SCONOSCIUTA: la RPT di cui si chiede lo stato non è stata trovata
- PPT_SEMANTICA: nel caso di errori semantici
- PPT_SINTASSI_EXTRAXSD: Errore nella composizione della SOAP request

Richiesta Catalogo Dati Informativi¶

Pre -Condi zione	n.a.
T rigger	L’EC necessita di conoscere il Catalogo Dati Informativi elaborato dal NodoSPC per verificare i servizi erogati dai PSP
Des crizio ne	L’EC sottomette la richiesta di scaricare il Catalogo Dati Informativi messo a disposizione dal NodoSPC
Pos t-Cond izione	L’EC riceve il Catalogo Dati Informativi

Tabella 4: Richiesta Catalogo Dati Informativi

Figura 5: Richiesta Catalogo Dati Informativi

L’evoluzione temporale è la seguente:

l’EC richiede al NodoSPC il Catalogo Dati Informativi mediante la primitiva nodoChiediInformativaPSP;
il NodoSPC replica all’invocazione precedente fornendo response OK ed il file XML relativo al Catalogo Dati Informativi dei PSP codificato in Base64;
il NodoSPC replica negativamente alla richiesta di cui al punto 1 emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_SINTASSI_EXTRAXSD: Errore nella SOAP request
- PPT_SEMANTICA: Errore semantico
- PPT_INFORMATIVAPSP_PRESENTE: il NodoSPC ha già depositato il file XML richiesto nella directory assegnata all’EC sulla componente SFTP_NodSPC
- PPT_SYSTEM_ERROR: errore nella generazione del file XML richiesto.

Funzioni ausiliarie per il PSP¶

Richiesta del Catalogo dei Servizi¶

Il PSP interroga la base di dati del NodoSPC al fine di scaricare l’ultima versione del Catalogo dei Servizi offerti dagli EC, da utilizzare nell’ambito del Pagamento Spontaneo presso i PSP.

Pre-Condizione	Il PSP decide di supportare i pagamenti spontanei pressi i propri sportelli
Trigger	Necessità di conoscere i servizi offerti dalle PA
Descrizione	Il PSP sottomette la richiesta di ricevere il file XML Catalogo dei Servizi attestante i servizi offerti dagli EC o da uno specifico Ente
Post-Condizione	Il PSP riceve il Catalogo dei Servizi degli EC

Tabella 5: Richiesta del Catalogo dei Servizi

Figura 6: Richiesta del Catalogo dei Servizi

il PSP richiede al NodoSPC di ricevere il Catalogo dei Servizi offerto dagli EC mediante la primitiva nodoChiediCatalogoServizi;
il NodoSPC replica con response OK fornendo il tracciato XML del Catalogo dei Servizi codificato in Base64;
Il NodoSPC replica con response KO emanando un faultBean il cui faultBean.faultCode è PPT_SINTASSI_EXTRAXSD.

Richiesta template del Catalogo Dati Informativi¶

Il PSP ha facoltà di richiedere al NodoSPC l’ultima versione del Catalogo Dati Informativi comunicato per motivazioni di verifica o aggiornamenti

Pre -Condizi one	Il PSP ha (o meno) precedentemente comunicato al Nodo il Catalogo Dati Informativi
Trigger	Necessità del PSP di aggiornare il proprio Catalogo
Des crizione	Il PSP sottomette la richiesta di ricevere il file XML attestante l’ultimo Catalogo Dati inviato
Pos t-Condiz ione	Il PSP riceve il Catalogo Dati Informativi di propria competenza (o il template)

Tabella 6: Richiesta template del Catalogo Dati Informativi

Figura 7: Richiesta template del Catalogo Dati Informativi

il PSP richiede al NodoSPC, attraverso la primitiva nodoChiediTemplateInformativaPSP, l’ultima versione del Catalogo Dati Informativi precedentemente inviato;
il PSP riceve response OK ed il file XML del Catalogo Dati Informativi in formato Base64 precedentemente inviato;
il PSP riceve response OK e solo il template del Catalogo Dati Informativi;
il PSP riceve response KO emanando un faultBean il cui faultBean.faultCode è PPT_SINTASSI_EXTRAXSD.

Richiesta informativa PA¶

Pre -Condiz ione	L’EC ha sottomesso al Nodo la Tabella delle Controparti
Trigger	Il PSP necessita di conoscere la disponibilità dei servizi offerti dagli EC e i dati ad essi correlati
Des crizion e	Il PSP sottomette al NodoSPC la richiesta della Tabella delle Controparti
Pos t-Condi zione	Il PSP riceve dal Nodo la Tabella delle Controparti

Tabella 7: Richiesta informativa PA

Figura 8: Richiesta informativa PA

il PSP, mediante la primitiva nodoChiediInformativaPA, richiede al NodoSPC la Tabella delle Controparti degli EC.
il NodoSPC replica con esito OK fornendo in output il documento XML codificato in Base64 rappresentante la Tabella delle Controparti degli EC;
il NodoSPC replica con esito KO emanando un faultBean il cui faultBean.faultCode è PPT_SINTASSI_EXTRAXSD.

Richiesta Stato Elaborazione Flusso di Rendicontazione¶

Pre -Cond i zione	Il PSP ha sottomesso un file XML di rendicontazione al NodoSPC (mediante SOAP request o componente SFTP_NodoSPC)
Tr igger	Il PSP necessita di conoscere lo stato di elaborazione del file XML di rendicontazione
Des crizi one	Il PSP sottomette la richiesta passando come parametro di input l’identificativoFlusso del flusso di rendicontazione inviato
Pos t-Con di zione	Il NodoSPC replica fornendo lo stato di elaborazione del flusso di rendicontazione

Tabella 8: Richiesta Stato Elaborazione Flusso di Rendicontazione

Figura 9: Richiesta Stato Elaborazione Flusso di Rendicontazione

il PSP, attraverso la primitiva nodoChiediStatoFlussoRendicontazione, sottomette al NodoSPC la richiesta di conoscere lo stato di elaborazione di un flusso XML di rendicontazione precedentemente inviato valorizzando il parametro di input identificaficativoFlusso

Caso OK

il NodoSPC replica positivamente alla primitiva precedente fornendo lo stato di elaborazione del flusso XML; in particolare:
1. FLUSSO_IN_ELABORAZIONE: il flusso XML è in fase di elaborazione/storicizzazione sulle basi di dati del NodoSPC
2. FLUSSO_ELABORATO: Il flusso è stato correttamente elaborato e storicizzato dal NodoSPC
3. FLUSSO_SCONOSCIUTO: il Nodo non conosce il flusso richiesto
4. FLUSSO_DUPLICATO: il Nodo rileva che il flusso inviato è già stato sottomesso.

Caso KO

Il NodoSPC il NodoSPC replica con esito KO emanando un faultBean il cui faultBean.faultCode è PPT_SEMANTICA.

Strategie di retry per il recapito della RT¶

Pre-Condizione	Il pagamento è nello stato RT-PSP
Trigger	Il PSP ha tentato l’invio di una RT e il NodoSPC ha replicato mediante response KO emanando un faultBean il cui faultBean.faultCode è pari a PPT_STAZIONE_INT_PA_TIMEOUT oppure PPT_STAZIONE_INT_PA_IRRAGGIU NGIBILE oppure non ha ricevuto risposta entro i termini previsti
Descrizione	Il PSP esegue fino a cinque tentativi di invio della RT in modalità PUSH attendendo intervalli di tempo crescenti. Se l’esecuzione di tutti i tentativi di invio non ha esito positivo, pone la RT nella coda PULL
Post-Condizione	Al termine della procedura il pagamento transisce nello stato RT_EC

Tabella 9: Strategie di retry per il recapito della RT

Figura 10: meccanismi di recovery per RT PUSH

Il PSP sottomette al NodoSPC la RT attraverso la primitiva nodoInviaRT:

Si possono presentare i seguenti due scenari alternativi:

EC indisponibile

Il NodoSPC replica emanando un faultBean il cui faultBean.faultCode è pari a: PPT_STAZIONE_INT_PA_TIMEOUT (indisponibilità funzionale della controparte) oppure PPT_STAZIONE_INT_PA_IRRAGGIUNGIBILE (mancata raggiungibilità della controparte); il PSP pone la RT nella coda PULL.

NB: nel caso di indisponibilità funzionale della controparte, per gestire l’eventualità di interruzione del servizio di breve durata, il PSP ha facoltà di reiterare l’invio della RT in modalità PUSH.

Nodo non disponibile

Il PSP non riceve alcuna risposta alla primitiva di cui al punto 1
Il PSP ritenta nuovamente l’invio della RT in modalità PUSH per un massimo di ulteriori cinque tentativi di recupero, attenendosi alla seguente schedulazione:

# Tentativo di recupero	Attesa (secondi)
1	5
2	10
3	20
4	40
5	80

Si possono presentare i seguenti due scenari alternativi:

Response ad uno dei tentativi di recupero

Il PSP riceve la response, termina qualsiasi attività di recupero della RT

Esaurimento dei tentativi di recupero

Il PSP non riceve alcuna response nei tempi previsti all’invocazione di cui al punto 4
Il PSP colloca la RT nella coda PULL terminando le azioni di recupero

Processo di recupero RT in modalità PULL

Il NodoSPC, mediante la SOAP request pspChiediListaRT chiede al PSP la lista delle RT da recuperare
Il PSP replica alla primitiva di cui al punto precedente fornendo response OK e la lista delle RT da prelevare
Il NodoSPC preleva la RT mediante la primitiva pspChiediRT
Il PSP replica con response OK fornendo al RT richiesta
Il NodoSPC valida la RT prelevata precedentemente

Si possono presentare i seguenti due scenari alternativi:

In caso di RT corretta

Il NodoSPC invia conferma al PSP dell’avvenuta ricezione della RT mediante la primitiva pspInviaAckRT. Il messaggio di ackRT riporterà nel dato statoMessaggioReferenziato il valore ACTC.
Il PSP elimina la RT dalla coda PULL
Il PSP replica fornendo esito OK alla primitiva di cui al punto 14.

In caso di RT non corretta

Il NodoSPC notifica al PSP il rifiuto della RT mediante la primitiva pspInviaAckRT. Il messaggio di ackRT riporterà nel dato statoMessaggioReferenziato il valore RJCT.
Il PSP replica fornendo esito OK alla primitiva di cui al punto precedente

Funzioni Ausiliarie per il NodoSPC¶

Richiesta avanzamento RPT¶

Pre -Condizi one	Il NodoSPC ha sottomesso una RPT o un carrello di RPT al PSP
Trigger	Il NodoSPC necessita di verificare lo stato di avanzamento di una RTP o di un
Des crizione	Il NodoSPC sottomette la richiesta di ricevere lo stato di una RPT o di un carrello di RPT
Pos t-Condiz ione	Il NodoSPC riceve lo stato della RPT o del carrello di RPT

Tabella 10: Richiesta avanzamento RPT

Figura 11: Richiesta avanzamento RPT

il NodoSPC, mediante la primitiva pspChiediAvanzamentoRPT, richiede al PSP informazioni in merito allo stato di avanzamento di una RPT o di un carrello di RPT.

Caso OK

il PSP replica con esito OK fornendo lo stato della RPT o del carrello di RPT;

Caso KO

il PSP replica con esito KO emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- CANALE_RPT_SCONOSCIUTA: non è possibile trovare la RPT o il carrello di RPT per cui si richiede lo stato di elaborazione
- CANALE _RPT_RIFIUTATA: la RPT o il carrello di RPT sottomessi dal NodoSPC sono stati rifiutati dal PSP.

Richiesta di avanzamento RT¶

Pre -Cond i zione	Il NodoSPC verifica lo stato avanzamento di una RT
Tr igger	Il NodoSPC necessita di verificare lo stato di avanzamento della produzione della RT associata ad una RPT o a un carrello di RPT
Des crizi one	Il NodoSPC sottomette la richiesta di ricevere lo stato di una RT
Pos t-Con di zione	Il NodoSPC riceve lo stato della RT

Tabella 11: Richiesta di avanzamento RT

Figura 12: Richiesta di avanzamento RT

il NodoSPC, mediante la primitiva pspChiediAvanzamentoRT, richiede al PSP informazioni in merito allo stato di avanzamento della RT;
Il PSP ricerca la RT nel proprio archivio;
il PSP replica con esito OK fornendo lo stato della RT, specificando eventualmente il tempo richiesto per la sua generazione ed invio;
il PSP replica con esito KO emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- CANALE_RT_SCONOSCIUTA: non è stata trovata la RT per la quale si richiede di conoscere lo stato di avanzamento
- CANALE_RT_RIFIUTATA_EC: la RT è stata rifiutata dall’EC.

Back-office¶

Revoca e storno¶

Il NodoSPC mette a disposizione servizi di interscambio che i soggetti aderenti possono utilizzare per realizzare indifferentemente processi di storno e/o revoca di pagamento, purché siano intesi come funzionalità di supporto del sistema pagoPA a cui ricorrere unicamente per sanare situazioni di eccezione. Ogni soggetto aderente rileva la disponibilità della controparte ad avviare tali processi mediante dati di configurazione.

Come specificato nella figura successiva, tali funzionalità sono istanziate per scopi di business ben definiti; ad esempio per il rientro da situazioni anomale o di incoerenza nei documenti prodotti durante il ciclo di vita del pagamento, rispetto allo stato di fatto del pagamento stesso. Al variare del soggetto istanziante e delle motivazioni che innescano l’esecuzione del processo, possono verificarsi le situazioni mostrate nella figura seguente.

Figura 1: Attori coinvolti nell’innesco dei processi di revoca e storno di una RT

Processo	Innesco
RevocaRT	Avviato dal PSP
Storno	Avviato dall’EC

Tabella 1: Soggetti che istanziano i processi di Revoca e Storno di un pagamento

Il processo di revoca può essere a sua volta diversificato sulla base delle motivazioni che ne determinano l’innesco, come da tabella successiva:

Pr o ces s o*

Tipol ogia*

Descrizione

R evo c aRT

A nnullo T ecnico

Innescato dal PSP quando, in casi assolutamente eccezionali, lo stato effettivo del pagamento non è coerente con i documenti in possesso dell’Utilizzatore finale:

il PSP ha emesso una RT negativa e l’importo dovuto risulta addebitato al soggetto versante il quale è in possesso di una attestazione di pagamento
Il PSP ha emesso una RT positiva ma il soggetto versante non è stato addebitato della somma dovuta né è in possesso di una attestazione di pagamento

Si fa presente che è fatto obbligo per il PSP di implementare le funzionalità di annullo tecnico e per EC di predisporre le opportune soluzioni tecniche per la gestione di tali richieste.

charge -back* Utente

Innescato dal PSP nel caso in cui l’Utilizzatore finale chieda il riaccredito delle somme versate per un pagamento conclusosi con esito positivo

S tor no

Storno

L’Utilizzatore finale richiede all’EC lo storno delle somme precedentemente pagate al PSP.

Si fa presente che non è fatto obbligo al PSP implementare tale funzionalità

Tabella 2: Descrizione sintetica delle motivazioni per l’innesco dei processi di revoca e storno

Processo di Revoca per Annullo Tecnico¶

Il processo di revoca di una ricevuta telematica per Annullo Tecnico consente il rientro da situazioni anomale o di incoerenza nello stato di fatto del pagamento rispetto a quanto rappresentato dalla RT generata dal PSP attestante il pagamento. Il caso d’uso nominale è rappresentato nella tabella successiva.

P re-Con d izione	è stata recapitata all’EC una RT positiva, ma l’Utilizzatore finale non è stato addebitato è stata recapitata all’EC una RT negativa, ma l’Utilizzatore finale è stato addebitato la richiesta di Annullo Tecnico è avanzata entro le ore 01:00 del giorno solare successivo a quello di creazione della RT (dataOraMessaggioRicevuta)
T rigger	Il PSP ha evidenza di una squadratura puntuale fra incasso e relativa RT .
D escriz ione	il PSP sottomette al NodoSPC la richiesta di revoca di una RT; il NodoSPC valida la richiesta e la accetta; l’EC riceve mediante il NodoSPC la richiesta di revoca; l’EC valida la richiesta di revoca producendo il relativo esito; l’EC invia al PSP, mediante il NodoSPC, l’esito della richiesta di revoca Il PSP produce e invia la RT che sovrascrive quella revocata
P ost-Co n dizion e	Il pagamento transisce allo stato Pagamento_revocato

Tabella 3: Caso d’uso del processo di revoca per annullo tecnico

L’evoluzione temporale del processo di revoca è il seguente:

Figura 2: Diagramma di sequenza del processo di revoca di una RT per Annullo Tecnico

il PSP compone il documento XML per la richiesta di revoca e lo sottomette all’EC attraverso il NodoSPC mediante la primitiva nodoInviaRichiestaRevoca;
1. In questo caso il valore del campo tipoRevoca all’interno della struttura datiRevoca sarà pari ad 1;
il NodoSPC valida la richiesta inviata dal PSP;
il NodoSPC inoltra la richiesta di revoca all’EC mediante la primitiva paaInviaRichiestaRevoca;
l’EC replica al PSP fornendo esito positivo mediante response alla primitiva precedente;
il NodoSPC inoltra la replica dell’EC al PSP fornendo response positiva alla primitiva di cui al punto 1.
l’EC esegue il rollback del sistema relativamente alla posizione debitoria interessata e predispone il documento informativo XML ER attestante l’esito della revoca;
l’EC invia il documento ER al PSP mediante il Nodo attraverso la primitiva nodoInviaRispostaRevoca;
il NodoSPC valida il documento ER ricevuto;
il NodoSPC inoltra il documento ER al PSP mediante la primitiva pspInviaRispostaRevoca;
il PSP conferma la ricezione del messaggio di esito della revoca fornendo response OK alla primitiva precedente;
il NodoSPC conferma all’EC la ricezione dell’esito della revoca da parte del PSP fornendo response OK alla primitiva di cui al punto

Il workflow si conclude con l’invio da parte del PSP della RT che andrà a sovrascrivere quella revocata. In questo caso il parametro Forzacontrollosegno nella SOAP request nodoInviaRT deve essere impostato a 1.

Processo di Revoca di una Ricevuta Telematica per charge-back¶

Il processo di revoca per charge-back di una RT è innescato dal PSP solo verso l’EC che aderisce al servizio e sarà realizzabile solo per i pagamenti effettivamente revocabili (sono esclusi tutti i pagamenti a fronte di servizi già erogati al momento della richiesta di charge-back) purché la posizione debitoria dell’utilizzatore finale risulti pagata. Il caso d’uso nominale è così descritto:

P re-Condiz ione	Pagamento effettuato con esito positivo – Stato Pagamento: RT_EC Adesione dell’EC al servizio di revoca per charge-back Il pagamento è rimborsabile dall’EC
Trigger	L’Utilizzatore finale avanza la richiesta di revoca al PSP con cui ha effettuato il pagamento
D escrizion e	Il PSP sottomette al NodoSPC la richiesta di revoca della RT Il NodoSPC valida la richiesta e la accetta L’EC riceve mediante il NodoSPC la richiesta di revoca L’EC valida la richiesta di revoca, esegue il rollback del sistema e produce il relativo esito L’EC invia al PSP mediante il NodoSPC l’esito della richiesta di revoca Il workflow si conclude senza l’invio di una nuova RT
P ost-Condi zione	Il pagamento transisce allo stato Pagamento Revocato

Tabella 4: Scenario d’uso del processo di revoca di una RT per charge-back

Al pari dei casi d’uso riportati nei capitoli precedenti, l’evoluzione temporale e le primitive coinvolte nel processo di revoca sono riportate nella figura successiva, avendo cura di notare che il caso d’uso rappresenta lo scenario in cui le cui invocazioni SOAP si concludono con esito positivo (esito: OK come parametro di output).

Figura 3: Diagramma di sequenza del processo di revoca per charge-back

l’Utilizzatore finale richiede al PSP attestante il pagamento la revoca della RT per charge-back;
il PSP compone il documento informativo XML Richiesta di Revoca (RR) e la invia al NodoSPC mediante la primitiva SOAP nodoInviaRichiestaRevoca;
il NodoSPC valida la richiesta di revoca;
il NodoSPC invia la richiesta di revoca all’EC mediante la primitiva paaInviaRichiestaRevoca;
l’Ente Creditore, accettata la RR, replica al PSP attraverso il NodoSPC fornendo response OK;
il NodoSPC inoltra al PSP la replica positiva dell’EC fornendo response OK alla primitiva di cui al punto 2.
l’EC, dopo aver verificato positivamente la possibilità di revoca della RT, riporta la Posizione Debitoria allo stato precedente al pagamento e procede alla generazione del documento informativo XML Esito Revoca (ER);
l’EC invia il documento ER al PSP mediante il Nodo attraverso la primitiva nodoInviaRispostaRevoca;
il NodoSPC valida il documento ER ricevuto;
il NodoSPC inoltra il documento ER al PSP mediante la primitiva pspInviaRispostaRevoca;
il PSP conferma la ricezione del messaggio di esito della revoca fornendo response OK alla primitiva precedente;
il NodoSPC conferma all’EC la ricezione dell’esito della revoca da parte del PSP fornendo response OK alla primitiva di cui al punto 8;
il PSP notifica l’Utilizzatore finale circa l’esito positivo della procedura di revoca della ricevuta telematica.

Processo di Storno di un pagamento¶

Il processo di storno di un pagamento, attivato dall’EC, è innescato quando l’Utilizzatore finale richieda a vario titolo la cancellazione di un pagamento precedentemente avvenuto. Il caso d’uso nominale e l’evoluzione temporale sono mostrate nella figura successiva.

P re-Condi zione	Il PSP utilizzato per il pagamento supporti le funzionalità di storno Il pagamento si trova nello stato RT EC
Trigger	L’utilizzatore richiede lo storno di un pagamento precedentemente avvenuto
D escrizio ne	L’Ente Creditore sottomette al PSP mediante il nodo una richiesta di storno generando il documento RR-Richiesta Revoca Il PSP replica positivamente e genera il documento ER inviato all’Ente Creditore mediante il NodoSPC.
P ost-Cond izione	Il pagamento si trova nello stato RT Stornata

Tabella 5: Caso d’uso del processo di storno di un pagamento

Figura 4: Evoluzione temporale del processo di storno di un pagamento

l’Utilizzatore finale richiede lo storno di un pagamento effettuato all’EC;
l’EC genera il documento XML RR;
mediante la primitiva nodoInviaRichiestaStorno l’EC invia al NodoSPC il documento RR;
il NodoSPC valida il documento RR ricevuto;
il NodoSPC inoltra al PSP la RR generata dall’EC mediante la primitiva pspInviaRichiestaStorno;
il PSP replica positivamente alla primitiva precedente fornendo Esito OK;
il NodoSPC inoltra la replica precedente all’EC fornendo response OK alla primitiva di cui al punto 3;
il PSP predispone il documento Esito Revoca – RR;
il PSP inoltra all’EC mediante il NodoSPC l’esito della revoca attraverso la primitiva nodoInviaEsitoStorno;
il NodoSPC valida il documento ER;
il NodoSPC inoltra all’Ente Creditore il documento ER mediante la primitiva paaInviaEsitoStorno;
l’EC replica positivamente al PSP mediante il NodoSPC fornendo response OK alla primitiva di cui al punto 11;
il NodoSPC inoltra la replica precedente al PSP fornendo response OK mediante la primitiva nodoInviaEsitoStorno;
l’EC informa l’Utilizzatore finale in merito all’esito delle operazioni di storno.

Riconciliazione¶

All’interno di questo paragrafo vengono descritti i casi d’uso che descrivono il processo contabile operato dall’Ente Creditore al fine di riconciliare i pagamenti effettuati dall’Utilizzatore finale.

Attori del processo di Riconciliazione Contabile e casi d’uso¶

Gli attori coinvolti nel processo di riconciliazione sono i seguenti:

Ente Creditore: rappresenta una Pubblica Amministrazione che ha ricevuto i pagamenti effettuati dall’Utilizzatore finale e necessita di riconciliare i pagamenti a suo favore
PSP: rappresenta un Prestatore di Servizi di Pagamento che ha accreditato il conto di un EC con le somme incassate nella giornata operativa
Banca Tesoriera/ Cassiera: rappresenta il Prestatore di Servizi di Pagamento che gestisce il conto di incasso di un EC. E’ il destinatario del flusso di riversamento SCT e notifica all’EC l’avvenuto incasso su sistemi esterni a pagoPA.

Worflow di Riconciliazione¶

Il processo di riconciliazione comporta il seguente workflow dove saranno utilizzati i seguenti termini:

Giorno D: giorno lavorativo in cui è stato eseguito il pagamento
Giorno D+1: giorno lavorativo successivo al giorno D
Giorno D+2: giorno lavorativo successivo al giorno D+1
Cut-off: orario di termine della giornata operativa. (NB la giornata operativa pagoPA termina alle ore 13)

P re-C o ndiz ione	L’EC ha ricevuto dei pagamenti su un conto destinato all’incasso tramite pagoPA Entro D+1 il PSP accredita (con uno o più SCT) il conto dell’EC per l’importo delle somme relative a RPT con valore del tag dataOraMessaggioRichiesta antecedente al cut-off della giornata operativa pagoPA del giorno D. Per ogni SCT cumulativo di più pagamenti, il PSP genera un flusso di rendicontazione, contenente la distinta dei pagamenti cumulati. Entro D+2 il PSP sottomette al NodoSPC il flusso di rendicontazione di cui al punto precedente. Il Nodo valida la richiesta e archivia il flusso rendendolo disponibile per l’EC.
T rigg er	L’EC riconcilia gli accrediti SCT ricevuti sul conto indicato nelle RPT
D escr i zion e	L’EC richiede la lista dei flussi disponibili sul Nodo relativa ai pagamenti da riconciliare. L’EC richiede il flusso di interesse, lo riceve e procede alla riconciliazione dei pagamenti.
P ost- C ondi z ione	Il pagamento transisce allo stato Pagamento Rendicontato

Tabella 7: Worflow di Riconciliazione

L’evoluzione temporale è la seguente:

Figura 5: Diagramma di sequenza del processo di riconciliazione contabile

il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64;
il PSP accredita con SCT il conto di un EC. L’importo dello SCT può essere pari all’importo di un singolo pagamento ovvero pari all’importo cumulativo di più pagamenti, purché tali pagamenti siano stati incassati a favore del medesimo EC nella medesima giornata operativa pagoPA.

Nel caso di riversamento cumulativo, l’SCT dovrà riportare all’interno dell’attributo AT-05 (Unstructured Remittance Information) il valore:

/PUR/LGPE-RIVERSAMENTO/URI/<identificativoFlusso>,

dove identificativoFlusso specifica il dato relativo all’informazione di rendicontazione inviata al NodoSPC.

Nel caso di riversamento singolo, l’SCT dovrà riportare all’interno dell’attributo AT-05 (Unstructured Remittance Information) il valore della causale di versamento indicato nella RPT.

il PSP, mediante la primitiva nodoInviaFlussoRendicontazione, invia al NodoSPC il flusso di rendicontazione generato, valorizzando i parametri di input identificativoFlusso con l’identificativo del flusso di rendicontazione da trasmettere e il parametro xmlRendicontazione con il file XML di rendicontazione codificato in base64.
il NodoSPC verifica il file XML di rendicontazione;
il NodoSPC elabora il file XML di rendicontazione;
il NodoSPC esegue l’archiviazione del flusso di rendicontazione sulle proprie basi di dati;
il NodoSPC replica fornendo esito OK alla primitiva nodoInviaFlussoRendicontazione;
l’EC, mediante la primitiva nodoChiediElencoFlussiRendicontazione, richiede al NodoSPC la lista dei flussi di rendicontazione disponibili;
il NodoSPC elabora la richiesta;
il NodoSPC, a seguito della validazione della richiesta, replica con response OK fornendo in output la lista completa di tutti i flussi disponibili per l’EC;
l’EC richiede al NodoSPC uno specifico flusso di rendicontazione presente nella lista, mediante la primitiva nodoChiediFlussoRendicontazione valorizzando nella request il parametro di input identificativoFlusso con l’identificativo del flusso di rendicontazione richiesto;
il NodoSPC elabora la richiesta.
il Nodo invia all’Ente Creditore il flusso richiesto mediante response positiva alla primitiva di cui al punto 11.
l’EC elabora il flusso di rendicontazione veicolandolo verso i propri sistemi di riconciliazione;
l’EC riceve dalla propria Banca di Tesoreria in modalità digitale un flusso contenente i movimenti registrati sul proprio conto; in caso di utilizzo da parte dell’EC di SIOPE+, tale flusso è rappresentato dal Giornale di Cassa nel formato OPI;
L’EC, sulla base dell’identificativo flusso ricevuto nel file XML di rendicontazione e delle RT archiviate, effettua la riconciliazione contabile.

Motore di Riconciliazione¶

L’obiettivo del presente paragrafo è quello di tratteggiare in termini essenziali il modello concettuale di un algoritmo (il Motore di riconciliazione) che consenta al singolo EC di riconciliare i flussi informativi degli incassi messi a disposizioni da pagoPA con quelli finanziari. Nel flusso sono altresì riportate, sempre in ottica del singolo EC, le attività che ci si attende siano compiute dalla singola controparte PSP.

Nell’ipotesi semplificativa in cui la data richiesta per il pagamento coincida con la data di invio della richiesta di pagamento, il processo di riconciliazione opera riproducendo ricorsivamente un ciclo di quattro passi da compiersi nella successione riportata di seguito per ogni PSP aderente al NodoSPC:

Descrizione	Attività EC	Attività PSP
Quadratura degli incassi	A chiusura del giorno lavorativo (D), il motore individua le RPT inviate prima del cut-off. Per ognuna di tali RPT il motore seleziona le corrispondenti RT, ne controlla la quadratura e distingue, accantonandole, quelle relative a un incasso (RT+). Ai fini dei successivi passi del processo di rendicontazione sarà altresì necessario individuare gli IUV per i quali, a causa di una eccezione, l’incasso, benché sia stato effettuato non corrisponde a una RT. Tali incassi saranno rendicontati mediante co diceEsitoSingol oPagamento 9 nel caso di riversamento cumulativo.	A chiusura della giornata operativa il PSP, controlla la quadratura degli incassi eseguiti per l’EC determinando: Gli IUV per cui ha emesso RT+ Gli IUV da rendicontare con codice 9 Determina inoltre gli importi dello SCT Cumulativo e degli SCT singoli da eseguire.
Ricezione SCT	nel giorno D+1, la Banca Cas siera/Tesoriera dell’EC riceve dal PSP, tramite SCT, i flussi finanziari relativi agli incassi del giorno D. In generale, per ogni PSP, l’EC può ricevere un SCT cumulativo e un numero indeterminato di SCT singoli relativi a una sola RT+	Esegue SCT di cui al punto 1
Quadratura FDR	nel giorno D+2 il motore, interrogando il NodoSPC, può effettuare il downloading del Flusso di Rendicontazione (FDR) relativo al giorno D. Il motore può quindi controllare la quadratura dello FDR, abbinando ad esso, in base allo IUV, le RT+ relative al giorno D, gli ulteriori incassi non corrispondenti a una RT e gli ER (Esito Revoca) eventualmente contenuti nel FDR. In questo ultimo caso il motore esclude gli ER rendicontati dal novero degli ER da controllare. Inoltre il motore, nel processo di quadratura, distingue gli importi a compensazione (in eccesso o difetto) eventualmente contenuti nel FDR. Per ogni PSP, il motore distingue e accantona le RT+ non abbinate a un FDR (RTS)	Il PSP genera il FDR, associandolo allo SCT di cui al punto 2 con il dato ide ntificativoFlus so, indicando: Gli IUV per i quali ha emesso RT+ codiceEsitoSin goloPagamento pari a 0 Gli IUV rendicontati con codiceEsitoSin goloPagamento pari a 9 IUV associati a un Estio Revoca accettato dall’EC (ER+) Infine mette a disposizione dell’EC il FDR relativo al giorno D
Quadratura riversamenti SCT	A chiusura del giorno lavorativo D+2 il motore elabora tutte le notifiche di incasso relative al giorno D+1 ricevute dalla Banca Cas siera/Tesoriera (nel caso SIOPE+ la notifica è rappresentata dal “Giornale di Cassa” OPI). Per ogni PSP il motore conclude il processo di riconciliazione eseguendo le seguenti elaborazioni: Esegue la quadratura di ogni riversamento singolo in abbinamento con la corrispondente RTS controllando che: L’Identificati vo univoco versamento (IUV) che identifica la singola RTs coincida con la componente “identificativ o univoco versamento” nel dato “Unstructured Remittanced Information” di cui al tracciato del SEPA Credit Transfer nel caso di versamento effettuato tramite SCT ovvero nel campo causale nel caso di versamento effettuato tramite bollettino di conto corrente postale. Il valore del tag importoTotale Pagato della stessa RTs corrisponda con l’importo effettivamente trasferito. Esegue la quadratura di ogni riversamento cumulativo, in abbinamento con il corrispondente FDR controllando che: L’Identificati vo del FDR coincida con la componente “identificativ o flusso versamento” nel dato “Unstructured Remittance Information” di cui al tracciato del SEPA Credit Transfer nel caso di versamento effettuato tramite SCT Il valore del tag importoTotale Pagamenti nel FDR corrisponda con l’importo effettivamente trasferito.

Tabella 8: Motore di Riconciliazione

Gestione degli errori¶

Il paragrafo mostra le strategie di risoluzione per gli errori che possono verificarsi durante l’esecuzione del processo di quadratura mediante il motore di riconciliazione, rispetto ai passi presi in esame nella descrizione dell’MDR stesso.

Passo3: Quadratura FDR¶

FDR non quadra

Passo4: Quadratura riversamenti SCT¶

Riversamento in difetto
SCT ad integrazione di un riversamento Cumulativo in difetto: la Causale del SCT dovrà essere valorizzata come segue: /PUR/LGPE-INTEGRAZIONE/URI/< identificativoFlusso > identificativoFlusso identifica lo FDR per il quale è stato effettuato un riversamento in difetto.
SCT ad integrazione di un riversamento Singolo: la causale del SCT dovrà essere valorizzata come segue:
- /RFS/<IUV>/<importo>[/TXT/Integrazione]
/RFB/<IUV>[/<importo>][/TXT/Integrazione]
Riversamento in eccesso

Nel presente scenario l’EC riscontra condizioni di squadratura in eccesso tra gli SCT riversati dai PSP e le somme specificate nella RTs o dal FDR nel caso di riversamento singolo o cumulativo, rispettivamente. In tale circostanza la compensazione avviene in modalità manuale da concordare tra le controparti attraverso il tavolo operativo.

Gestione degli errori¶

Gestione degli errori di revoca¶

Il paragrafo mostra i casi di errore che si possono verificare durante il processo di richiesta di revoca di una Ricevuta Telematica, sia nel caso di revoca per Annullo Tecnico che per Charge-Back. Con assoluta generalità si documentano nei paragrafi successivi le tipologie di errori che afferiscono alle categorie “Errori Controparte” ed “Errori Validazione”; come specificato nel paragrafo Architettura Funzionale. Nell’analisi degli scenari si assume l’ulteriore semplificazione che l’interazione applicativa tra il NodoSPC ed i soggetti fruitori dei servizi esposti dal Nodo stesso non sia soggetta a fenomeni di timeout o congestione di rete. Si fa presente che nella gestione del ciclo di vita del pagamento tutti i casi riportati in seguito comportano la mancata ricezione del documento ER attestante l’esito positivo o meno del processo di revoca del pagamento.

RR Rifiutata dal NodoSPC

Pre -cond i zione	Il PSP sottomette all’EC una Richiesta di Revoca di una RT
Des crizi one	Il NodoSPC esegue la validazione del documento RR replicando esito KO all’invocazione di invio richiesta revoca da parte del PSP.
Pos t-con di zione	Lo stato del pagamento è in Revoca Rifiutata

Tabella 9: RR Rifiutata dal NodoSPC

Figura 6: Diagramma di sequenza nel caso di RR rifiutata dal Nodo

L’evoluzione temporale è la seguente:

l’utilizzatore finale richiede la revoca di una RT [1];
il PSP sottomette al NodoSPC il documento RR mediante la primitiva nodoInviaRichiestaRevoca;
il NodoSPC valida la richiesta;
il NodoSPC emana response KO emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_SINTASSI EXTRAXSD: in caso di errori nella SOAP request
- PPT_SINTASSI_XSD: in caso di errori nel documento XML RR
- PPT_RR_DUPLICATA: in caso di sottomissione di una richiesta di revoca precedentemente sottomessa
- PPT_OPER_NON_REVOCABILE: nel caso non sussistano le condizioni per poter fruire del servizio di revoca (vedi caso d’uso nominale)
- PPT_SEMANTICA: nel caso di errori semantici
il PSP comunica all’Utilizzatore Finale l’impossibilità di procedere nell’operazione di revoca [2].

Le azioni di controllo suggerite sono riportate nella Tabella successiva

Str ategi a di ris oluzi one	Tip ologi a E rrore	Azione di Controllo Suggerita
	PP T_OPE R_ NON_ REV OCABI LE	Verificare la revocabilità dell’operazione
	P PT_RR _DU PLICA TA	Verificare la composizione del documento XML RR e della SOAP request (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)
	PP T_SIN TA SSI_E XT RAXSD
	PP T_SIN TA SSI_X SD
	PP T_SEM A NTICA	Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)

Tabella 10: Strategie di risoluzione nel caso di RR rifiutata dal Nodo

RR rifiutata dall’EC

P re-cond izione

Il PSP sottomette all’EC una Richiesta di Revoca di una RT

D escrizi one

Il NodoSPC valida positivamente il documento informativo RR:

l’EC risponde negativamente alla revoca
Il NodoSPC propaga al PSP l’errore emesso dall’EC mediante il faultBean il cui faultBean.faultCode è pari a PPT_ERRORE_EMESSO_DA_PAA

P ost-con dizione

Lo stato del pagamento è in Revoca Rifiutata

Figura 7: Diagramma di sequenza per il caso di errore di RR rifiutata dall’EC

L’evoluzione temporale del caso d’uso è la seguente (dal punto 4):

il Nodo invia all’EC la Richiesta di Revoca mediante la primitiva paaInviaRichiestaRevoca;
l’EC fornisce esito KO nella response emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PAA_RR_DUPLICATA nel caso il PSP sottomette una richiesta di revoca precedentemente gestita
- PAA_OPER_NON_REVOCABILE
il NodoSPC inoltra l’errore emesso dall’EC fornendo response KO alla primitiva di cui al punto 1 dello scenario precedente.

La Tabella successiva mostra le azioni di controllo suggerite per la risoluzione dell’anomalia.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	P PT_ERRORE_EMESSO_ DA_PAA	Attivazione del Tavolo Operativo

Tabella 11: Strategia di risoluzione dello scenario RR rifiutata dall’EC

ER Rifiutata dal NodoSPC

P re-condizio ne	L’EC ha verificato la revocabilità di una RT a seguito di una richiesta di revoca
Descrizione	L’EC compone il documento informativo di esito revoca ER e lo invia al NodoSPC Il NodoSPC esegue la validazione replicando con esito negativo
P ost-condizi one	Lo stato del pagamento è in Esito Revoca Rifiutata

Figura 8: Diagramma di sequenza per lo scenario di ER rifiutata dal Nodo

L’evoluzione temporale dello scenario è il seguente:

l’EC predispone il documento ER;
l’EC invia al NodoSPC il documento ER mediante la primitiva nodoInviaRispostaRevoca;
il NodoSPC valida negativamente il documento ER;
Il Nodo fornisce esito KO nella response della primitiva di cui al punto 2 dove il valore del parametro faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_ER_DUPLICATA nel caso di sottomissione di una ER già inoltrata
- PPT_RR_SCONOSCIUTA nel caso in cui rispetto all’ER inviato non risultasse alcuna RR precedentemente gestita

La Tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie

Str ategi a di ris oluzi one	Tip ologi a di E rrore	Azione di Controllo Suggerita
	PP T_OPE R_ NON_ REV OCABI LE	Verificare la revocabilità dell’operazione
	P PT_RR _DU PLICA TA	Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) e della SOAP request
	PP T_SIN TA SSI_E XT RAXSD
	PP T_SIN TA SSI_X SD
	PP T_SEM A NTICA	Verificare la composizione del documento XML RR

Tabella 12: Azioni di controllo per la risoluzione dello scenario di ER rifiutata dal Nodo

ER Rifiutata dal PSP

Pre -condizio ne	Il NodoSPC ha validato il documento ER
De scrizione	Il PSP replica con esito KO alla invio della Esito della Revoca da parte dell’EC
Pos t-condizi one	Lo stato del pagamento è in Esito Revoca Rifiutata

Figura 9: Diagramma di sequenza per il caso ER rifiutata dal PSP

L’evoluzione dello scenario in esame è il seguente (si assume validazione positiva da parte del NodoSPC, punto 3)

il Nodo sottomette l’ER al PSP mediante la primitiva pspInviaRispostaRevoca;
il PSP replica negativamente alla primitiva precedente fornendo response KO dove il valore del parametro faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- CANALE_ER_DUPLICATA nel caso di ricezione di un ER precedentemente sottomessa
- CANALE_RR_SCONOSCIUTA nel caso l’ER sottomesso dal NodoSPC non corrisponda ad una precedente RR.

La Tabella successiva mostra le azioni di controllo suggerite per la risoluzione dell’anomalia

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	P PT_ERRORE_EMESSO _DA_PAA	Attivazione del Tavolo Operativo

Tabella 13: Strategia di risoluzione dello scenario RR rifiutata dall’EC

Gestione degli errori di storno¶

Il paragrafo mostra i casi di errore che si possono verificare durante il processo di storno di un pagamento. Con assoluta generalità si documentano le tipologie di errori riportate nei paragrafi successivi che afferiscono alle categorie “Errori Controparte” ed “Errori Validazione”. Nell’analisi degli scenari si assume l’ulteriore semplificazione che l’interazione applicativa tra il NodoSPC ed i soggetti fruitori dei servizi esposti dal Nodo stesso non sia soggetta a fenomeni di timeout o congestione di rete. Si fa presente che nella gestione del ciclo di vita del pagamento tutti i casi riportati in seguito comportano la mancata ricezione del documento ER attestante l’esito positivo o meno del processo di storno del pagamento.

Richiesta Storno rifiutata dal Nodo

Pre -condizione	L’EC esegue una richiesta di storno
Descrizione	Il Nodo a seguito della validazione replica fornendo esito negativo
Pos t-condizion e	Il pagamento si trova in stato Storno Rifiutato

Figura 10: Diagramma di sequenza dello scenario richiesta storno rifiutata dal Nodo

L’evoluzione temporale è la seguente:

l’Utilizzatore finale richiede all’EC lo storno di un pagamento;
l’EC genera il documento xml RR;
l’EC sottomette al NodoSPC il documento RR mediante la primitiva nodoInviaRichiestaStorno;
il NodoSPC valida il documento RR;
il NodoSPC replica negativamente alla primitiva precedente fornendo response KO dove il valore del parametro faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_OPER_NON_STORNABILE nel caso in cui il PSP con il quale è stato effettuato il pagamento non supporta le funzionalità di storno
- PPT_RT_SCONOSCIUTA nel caso in cui la richiesta di storno non risulti associata ad alcuna RT positiva

La tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie.

Str ategi a di ris oluzi one	Tip olog ia Er rore	Azione di Controllo Suggerita
	PP T_SI NT ASSI _EX TRAX SD	Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) e della SOAP request
	PP T_SI NT ASSI _XSD
	PP T_RT _S CONO SC IUTA	Verificare la composizione del documento XML RR e della SOAP request con particolare riferimento alla congruenza tra dati RR e dati presenti nella RT attestante il pagamento da stornare
	PP T_OP ER _NON _S TORN A BILE	Verificare la composizione del documento XML RR e della SOAP request; verificare l’adesione del PSP alle funzionalità di storno.
	PP T_SE MAN TICA	Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)

Tabella 14: Azioni di controllo suggerite per lo scenario Richiesta Storno rifiutata dal Nodo

Richiesta Storno Rifiutata dal PSP

Pr e-condizione	Il NodoSPC ha validato la richiesta di storno sottomessa dall’EC
Descrizione	Il PSP valida la richiesta di storno e fornisce esito KO
Pos t-condizione	Il pagamento si trova in stato Storno Rifiutato

Figura 11: Evoluzione temporale dello scenario richiesta storno rifiutata dal PSP

L’evoluzione temporale è la seguente (dal punto 4):

il NodoSPC valida positivamente la richiesta di storno;
il NodoSPC sottomette la richiesta di storno mediante la primitiva pspInviaRichiestaStorno;
il PSP replica con esito KO indicando un fault.bean il cui fault.code specifica l’errore riscontrato; in particolare:
- CANALE_SEMANTICA nel caso di errori nel tracciato XML RR
- CANALE_OPER_NON_STORNABILE nel caso di operazione non stornabile dal PSP
- CANALE_RR_DUPLICATA nel caso in cui l’EC sottomette una richiesta di storno precedentemente inviata
- CANALE_RT_SCONOSCIUTA nel caso in cui non sussista corrispondenza tra la richiesta di storno e la RT attestante il pagamento da stornare
il NodoSPC emette esito KO alla primitiva nodoInviaRichiestaStorno inoltrando l’errore riscontrato dal PSP emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato.
l’EC notifica l’utilizzatore finale dell’esito KO dell’operazione.

La tabella successiva mostra le azioni di controllo suggerite per la risoluzione dell’anomalia.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	P PT_CANALE_ERROR E	Attivazione del Tavolo Operativo

Tabella 15: Azioni di controllo suggerite per lo scenario Richiesta Storno rifiutata dal PSP

Esito Storno Rifiutato dal Nodo

Pre -condi zione	Il PSP ha validato una richiesta di storno precedentemente sottomessa dal NodoSPC e procede ad inviare l’esito storno
Des crizio ne	Il NodoSPC valida negativamente l’Esito storno
Pos t-cond izione	Il pagamento si trova in stato Storno Rifiutato

Figura 12: Scenario Esito Storno rifiutato dal Nodo

L’evoluzione temporale è la seguente:

il PSP predispone il documento XML ER attestante l’esito delle operazioni di storno;
il PSP invia al NodoSPC il documento ER mediante la primitiva nodoInviaEsitoStorno;
il NodoSPC valida negativamente la richiesta precedente;
il NodoSPC fornisce response negativa mediante esito KO emanando un faultBean il cui faultBean.FaultCode è rappresentativo dell’errore riscontrato; in particolare:
- PPT_ER_DUPLICATA nel caso il PSP sottomette al NodoSPC un esito storno precedentemente inviato
- PPT_RR_SCONOSCIUTA nel caso il PSP sottomette al NodoSPC un documento ER non coerente con la precedente richiesta di storno
- PPT_SEMANTICA nel caso il NodoSPC riscontrasse errori nel tracciato XML ER.

La tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie.

Str ateg ia di ris oluz ione	Tip olog ia Er rore	Azione di Controllo Suggerita
	PP T_SI NT ASSI _EX TRAX SD	Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE) e della SOAP request
	PP T_SI NT ASSI _XSD
	PP T_ER _D UPLI CATA	Verificare la composizione del documento XML RR e della SOAP request con particolare riferimento alla congruenza tra dati RR e dati presenti nella RT attestante il pagamento da stornare
	PP T_RR _S CONO SC IUTA
	PP T_SE MAN TICA	Verificare la composizione del documento XML ER Verificare la composizione del documento XML RR (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)

Tabella 16: Strategie di risoluzione per il caso ER rifiutata dal Nodo

Esito Storno rifiutato dall’EC

Pre -condi zione	Il PSP ha validato una richiesta di storno precedentemente sottomessa dal NodoSPC e procede ad inviare l’esito storno
Des crizio ne	L’EC valida negativamente l’Esito storno
Pos t-cond izione	Il pagamento si trova in stato Storno Rifiutato

Figura 13: Scenario Esito Storno rifiutato da EC

L’evoluzione temporale dello scenario è il seguente (dal punto 4):

il NodoSPC invia il documento ER all’EC mediante la primitiva paaInviaEsitoStorno;
l’EC risponde negativamente all’invocazione precedente mediante esito KO emanando un faultBean il cui faultBean.faultCode è rappresentativo dell’errore riscontrato; in particolare:
1. PAA_ER_DUPLICATA nel caso l’esito storno risultasse precedentemente inviato
2. PAA_RR_SCONOSCIUTA nel caso in cui all’ER sottomessa non corrisponda alcuna RR precedentemente generata
3. PAA_SEMANTICA nel caso in cui si riscontrino errori nel tracciato ER
il NodoSPC propaga l’errore riscontato dall’EC mediante faultBean il cui faultBean.faultCode è pari a PPT_ERRORE_EMESSO_DA_PAA.

La tabella successiva mostra le azioni di controllo suggerite per la risoluzione delle anomalie

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	PPT_ERRORE_EMESSO _DA_PAA	Attivazione del Tavolo Operativo

Tabella 17: Strategie di risoluzione per il caso ER rifiutata dall’EC

ER Mancante per timeout delle controparti

Gli scenari di errore proposti nei paragrafi precedenti mostrano i possibili casi di ER mancante a causa di errori applicativi rappresentati dall’emanazione da parte degli attori coinvolti di un faultBean contenente un’eccezione applicativa appartenente ad una determinata famiglia di errori. Un ulteriore caso da prendere in esame è rappresentato dall’impossibilità di chiusura del processo di storno nel caso in cui le parti riscontrassero fenomeni di timeout.

Pre -co ndi zio ne	La posizione debitoria è nello stato Richiesta Storno Inviata
Des cri zi one	Il PSP e l’EC riscontrano fenomeni applicativo/infrastrutturali per i quali si manifestano condizioni di timeout nell’invocazione delle primitive e/o nella ricezione delle relative response.
Pos t-c ond izi one	Il pagamento permane in stato Richiesta Storno Inviata

Figura 14: Evoluzione temporale dello scenario Esito Storno mancate per timeout

L’evoluzione temporale è la seguente:

il PSP predispone il documento XML ER;

A questo punto sono possibili i seguenti scenari:

Timeout PSP in fase di invocazione

La primitiva nodoInviaEsitoStorno non va a buon fine a causa di fenomeni di congestione imputabili al NodoSPC.

Timeout EC

il PSP invia il documento ER mediante la primitiva nodoInviaEsitoStorno;
Il NodoSPC valida positivamente la richiesta.

Alternativamente

l’EC riscontra condizioni di timeout per le quali fallisce l’invocazione della primitiva paaInviaEsitoStorno;

oppure

l’EC riscontra condizioni di timeout imputabili al NodoSPC per le quali la response alla primitiva paaInviaEsitoStorno non giunge al PSP.

In ogni caso

il NodoSPC invia response KO alla primitiva nodoInviaEsitoStorno emanando un faultBean il cui faultCode è pari a PPT_STAZIONE_INT_PA_TIMEOUT.

Timeout PSP in ricezione response

il PSP invia il documento ER mediante la primitiva nodoInviaEsitoStorno;
Il NodoSPC valida positivamente la richiesta;
l’EC riceve l’esito storno mediante la primitiva paaInviaEsitoStorno;
l’EC emana response (di qualsiasi esito) alla primitiva precedente;
Il NodoSPC inoltra la response al PSP che fallisce per condizioni di timeout.

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	P PT_STAZIONE_INT_PA_ TIMEOUT	Attivazione del Tavolo Operativo
	Nessuna ricezione response

Tabella 18: strategia di risoluzione

Gestione degli errori di riconciliazione¶

Il paragrafo descrive la gestione degli errori che possono verificarsi durante l’esercizio del processo di riconciliazione contabile. In particolare sono prese in esame le eccezioni per le quali si riscontra il fallimento delle primitive in gioco oppure l’esito negativo del workflow di riconciliazione; tutte le eccezioni riportate non permettono al pagamento di transire allo stato “Pagamento riconciliato”. I casi di errore descritti prevedono l’attivazione del Tavolo Operativo

[3] nel caso in cui i soggetti erogatori e fruitori dei servizi

applicativi risultassero impossibilitati a procedere in autonomia nella risoluzione delle anomalie oppure l’azione di controllo suggerita non risultasse risolutiva.

SCT singolo in assenza di RPT

P re -c o nd iz io ne	Il PSP ha incassato diversi servizi
D es cr i zi on e	Nell’elaborare un SCT singolo di riversamento relativamente ad un flusso di rendicontazione in assenza di RPT ( codice 9 ), il PSP evidenzia la mancanza di il PSP non evidenzia la mancanza della RPT.
P os t- c on di z io ne	N/A

In caso di mancanza di RPT, il PSP non è in grado di valorizzare l’attributo AT-05 con la causale di versamento in quanto tale informazione sarebbe dovuta essere reperibile all’interno della RPT non ricevuta.

Le possibili azioni di controllo sono riportate nella tabella successiva:

Strategia di risoluzione	Tipologia Errore	Azione di Controllo Suggerita
	Flusso codice 9	E’ necessario attivare un TAVOLO OPERATIVO

Invio flusso rifiutato dal NodoSPC

Pre -condizion e	Il PSP invia al NodoSPC un flusso di rendicontazione
D escrizione	Il NodoSPC esegue la validazione del flusso fornendo response negativa
Pos t-condizio ne	Lo stato del pagamento permane in RT_PAGATA

errore flusso rendicontazione

Figura 15: Evoluzione temporale dello scenario flusso rifiutato dal Nodo

L’evoluzione temporale dello scenario è la seguente:

il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64;
il PSP, mediante la primitiva nodoInviaFlussoRendicontazione, invia al NodoSPC il flusso di rendicontazione generato, valorizzando i parametri di input identificativoFlusso con l’identificativo del flusso di rendicontazione da trasmettere e il parametro xmlRendicontazione con il file XML di rendicontazione codificato in base64.
il NodoSPC verifica il file XML di rendicontazione;

Eseguito uno degli scenari alternativi, il flusso procede come segue:

il Nodo replica negativamente alla primitiva precedente fornendo response con esito KO emanando un faultBean il cui faultBean.faultCode rappresenta l’errore riscontrato; in particolare:
- PPT_FLUSSO_SCONOSCIUTO: il NodoSPC non riscontra alcuna congruenza tra il valore del parametro di input identificativoFlusso della primitiva di richiesta ed il valore del parametro identificativoFlusso nel file XML di rendicontazione;
- PPT_SEMANTICA nel caso di riscontro di errori nel tracciato xml del file XML di rendicontazione.

Le possibili azioni di controllo sono riportate nella tabella successiva:

Str ategia di ris oluzio ne	Tip ologi a E rrore	Azione di Controllo Suggerita
	PP T_FLU SS O_SCO NOS CIUTO	Verificare la composizione della SOAP request nodoInviaFlussoRendicontazione ed il contenuto del file XML di rendicontazione
	PP T_SEM A NTICA	Verificare la composizione del file XML di rendicontazione (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)

Tabella 19: Strategia di risoluzione dello scenario Flusso rifiutato dal Nodo

Timeout invio flusso di rendicontazione

Il seguente scenario, nel trattare in generale il caso di timeout successivo all’invio del flusso di rendicontazione, si sofferma sulla gestione dei messaggi di errore maggiormente rappresentativi.

Pre -condiz ione	Il tempo di attesa della response del NodoSPC supera il timeout di cui al documento Livelli di Servizio
Des crizion e	Il NodoSPC manifesta condizioni di timeout ed il PSP esegue il relativo processo di gestione
Pos t-condi zione	Lo stato del pagamento permane in RT_EC

L’evoluzione temporale è la seguente:

Timeout FLusso

Figura 16: Timeout invio flusso di rendicontazione

il PSP genera il flusso di rendicontazione componendo il file XML di rendicontazione codificato in base64.
il PSP accredita con SCT il conto dell’EC per l’importo delle somme incassate (l’SCT contiene l’indicazione del flusso di rendicontazione)
il PSP invia al NodoSPC il file XML di rendicontazione da elaborare mediante la primitiva nodoInviaFlussoRendicontazione;

il NodoSPC non risponde manifestando una condizione di timeout;

il PSP richiede lo stato di elaborazione del flusso di rendicontazione inviato mediante la primitiva nodoChiediStatoElaborazioneFlussoRendicontazione valorizzando il parametro di input identificativoFlusso con il valore dell’identificativo flusso di cui richiedere lo stato;
Il NodoSPC effettua il controllo sullo stato di elaborazione del flusso inviato;
Il NodoSPC replica mediante response OK alla primitiva di cui al punto 8 fornendo lo stato di elaborazione del flusso di rendicontazione; in particolare:
- FLUSSO_IN_ELABORAZIONE: il NodoSPC deve terminare le operazioni di archiviazione dei flussi sulle proprie basi di dati;
- FLUSSO_ELABORATO: il NodoSPC ha elaborato il flusso di rendicontazione inviato dal PSP;
il PSP gestisce lo stato riscontrato dal NodoSPC eliminando il file XML di rendicontazione nel caso di FLUSSO_ELABORATO oppure attendendo oltre nel caso di FLUSSO_IN_ELABORAZIONE.

Richiesta lista flussi di rendicontazione rifiutata dal NodoSPC

Pre -cond i zioni	La posizione debitoria si trova nello stato PAGATA e lo stato del pagamento è in RT_EC. L’EC richiede la lista dei flussi di rendicontazione
Des crizi one	L’EC non riceve la lista dei flussi di rendicontazione richiesta ed è impossibilitato a procedere alla riconciliazione dei pagamenti
Pos t-con di zione	Lo stato del pagamento è in RT_EC

Figura 17: Richiesta lista flussi di rendicontazione rifiutata dal NodoSPC

L’evoluzione temporale dello scenario è la seguente:

l’EC richiede, mediante la primitiva nodoChiediElencoFlussiRendicontazione, la lista dei flussi di rendicontazione archiviata sul NodoSPC;
Il NodoSPC valida negativamente la richiesta ed emana response negativa con esito KO e faultBean.FaultCode rappresentativo dell’errore riscontrato.

Str ategia di ris oluzio ne	Tip ologi a E rrore	Azione di Controllo Suggerita
	PP T_SIN TA SSI_E XT RAXSD	Verificare la composizione della SOAP request (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)
	PP T_PSP _S CONOS CIUTO	Verificare il parametro identificativoPSP nella SOAP request

Tabella 20: Strategia di risoluzione dello scenario richiesta lista flussi rifiutata dal Nodo

Richiesta Flusso Rifiutata dal Nodo / Nessun flusso presente

Pre -con diz ione	La posizione debitoria si trova nello stato PAGATA e lo stato del pagamento è in RT_EC e L’EC richiede uno specifico flusso di rendicontazione
Des criz ione	L’Ente Creditore non riceve lo specifico flusso richiesto
Pos t-co ndi zion e	Lo stato del pagamento è in RT_EC

Figura 18: Evoluzione temporale dello scenario richiesta Flusso rifiutata dal Nodo / Flusso mancate

L’evoluzione temporale dello scenario è la seguente:

l’EC richiede al NodoSPC uno specifico flusso di rendicontazione mediante la primitiva nodoChiediFlussoRendicontazione;
il Nodo replica negativamente alla richiesta fornendo response con esito KO emanando un faultBean il cui faultBean.faultCode rappresenta l’errore riscontrato; in particolare:
- PPT_SINTASSI_EXTRAXSD: nel caso di errori di invocazione della SOAP request;
- PPT_ID_FLUSSO_SCONOSCIUTO: nel caso l’EC richieda un flusso il cui identificativoFlusso risulti non registrato nelle basi di dati del NodoSPC;
- PPT_SYSTEM_ERROR: nel caso in cui il NodoSPC riscontri errori di sistema nell’elaborazione della richiesta;

Str ategia di ris oluzio ne	Ti pologia Errore	Azione di Controllo Suggerita
	PP T_SINTA SS I_EXTRA XSD	Verificare la composizione della richiesta SOAP (vedi documento “Elenco Controlli Primitive NodoSPC” per la relativa primitiva/FAULT_CODE)
	PP T_SEMAN TICA
	P PT_ID_F LU SSO_SCO N OSCIUTO	Verificare il valore del parametro di input IDFLUSSO nella richiesta SOAP
	PP T_SYSTE M_ERROR	Ritentare nuovamente la richiesta del flusso di rendicontazione, altrimenti innescare il Tavolo Operativo

Tabella 21: Richiesta Flusso Rifiutata dal Nodo / Nessun flusso presente

[1]	Attività da considerarsi solo nel caso di Revoca per Charge-Back

[2]	Attività da considerarsi solo nel caso di Revoca per Charge-Back

[3]	Per i dettagli del Tavolo Operativo si rimanda alla sezione IV.

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.

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).

Utilizzo del marchio pagoPA¶

L’Agenzia per l’Italia Digitale ha realizzato e registrato il marchio pagoPA attraverso la definizione di un logotipo atto a individuare i soggetti aderenti e attivi sul Sistema pagoPA, siano essi Enti Creditori (pubbliche amministrazioni, società a controllo pubblico o gestori di pubblici servizi), siano essi Prestatori di Servizi di Pagamento.

In particolare, l’Agenzia per l’Italia Digitale, nell’intento di agevolare l’utilizzatore finale, ha previsto la diffusione di tale logotipo per fare comprendere all’utenza con più immediatezza e facilità se un soggetto pubblico - in qualità di beneficiario - oppure un soggetto privato - in qualità di PSP - sia attivo sul Sistema pagoPA.

In considerazione della valenza strategica e legale del “Logo”, anche al fine di evitare confusioni e/o frodi nei confronti della clientela privata, l’Agenzia per l’Italia Digitale ha provveduto alla registrazione del logotipo presso le competenti amministrazioni al fine di garantire allo stesso logotipo una tutela a livello nazionale.

In merito, si segnala che nel caso in esame non siamo di fronte alla registrazione di un semplice marchio d’impresa ma a quella di un marchio collettivo, ossia di un marchio il cui uso può essere concesso a soggetti che siano adeguati all’erogazione di servizi coerenti e in linea con il marchio stesso.

In virtù della qualificazione come marchio collettivo, unitamente alla registrazione di un esemplare del marchio, l’Agenzia per l’Italia Digitale ha registrato anche il Regolamento inerente l’uso del marchio collettivo registrato pagoPA, pubblicato sul sito istituzionale dell’Agenzia per l’Italia Digitale, che avrà cura di aggiornarlo nel tempo.

Pertanto, sia gli Enti Creditori, sia i PSP, in sede di adesione al Nodo-SPC, e precisamente, con l’accettazione di quanto stabilito nelle Linee Guida e nei relativi allegati:

Dichiarano di avere preso visione del “Regolamento inerente l’uso del marchio collettivo registrato pagoPA”, nella versione pubblicata sul sito istituzionale dell’Agenzia per l’Italia Digitale e di accettare incondizionatamente quanto in esso stabilito;
Si obbligano a rispettare integralmente quanto previsto nel “Regolamento inerente l’uso del marchio collettivo registrato pagoPA”, nella versione pubblicata sul sito istituzionale dell’Agenzia per l’Italia Digitale.

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.