Processo di pagamento con re indirizzamento on-line¶

Il workflow descritto, già denominato «Processo di pagamento con esecuzione immediata» nelle precedenti versioni di questo documento, prevede che l’autorizzazione del pagamento da parte dell’utilizzatore finale sia governata dal Nodo dei Pagamenti-SPC che, in funzione della modalità di pagamento scelta dall’utilizzatore finale, pilota il processo di autorizzazione di esecuzione del pagamento; il rilascio della relativa attestazione (RT) è contestuale alla richiesta effettuata sul portale dell’Ente Creditore dall’utilizzatore finale cliente (occasionale o abituale) del PSP.

La principale novità introdotta in questo ambito è la componente POS virtuale, esposta dal Nodo dei Pagamenti-SPC e deputata a raccogliere i dati della carta di pagamento.

Tale novità è stata introdotta per aumentare il tasso di convergenza di questo particolare servizio di pagamento, rimuovendo le cause di abbandono individuate tramite analisi statistiche: la principale risiedeva nella inusuale richiesta, incomprensibile per l’utilizzatore finale, di individuare il soggetto PSP a cui affidare il ruolo di merchant nel processo di pagamentoche non trova corrispondenza nei più diffusi sistemi di e-commerce.

Per ovviare a tale problema, fatti salvi i principi di trasparenza e imparzialità fra i PSP, sarà il sistema pagoPA a compiere tale scelta, sulla base di algoritmi pubblici progettati per individuare il soggetto che offre le condizioni di miglior favore per l’utente.

Tali algoritmi sono soggetti a modifiche e affinamenti nel tempo, e verranno messi in esercizio da AgID anche senza preavviso, nel caso che mutate condizioni di mercato lo richiedano in funzione del perseguimento dello stesso obiettivo precedentemente dichiarato.

Figura 3 - Processo di pagamento con re indirizzamento on-line

Con riferimento allo schema di Figura 3 ed al Sequence diagram di Figura 4 a pagina 31, si descrivono i passi del processo di pagamento (si tenga conto che con il termine RPT si intende includere anche il carrello di RPT). Per illustrare il processo di pagamento in esame utilizzeremo l’esempio specifico della modalità di incasso su iniziativa dell’Ente Creditore:

1. l’utilizzatore finale, che ha ricevuto un avviso di pagamento dall’Ente Creditore, si collega al portale dell’EC, ricerca il codice IUV indicato sull’avviso stesso e compone il carrello con il pagamento che intende effettuare;
2. l’Ente Creditore, tramite i propri Servizi telematici, trasmette al Nodo dei Pagamenti-SPC la Richiesta di Pagamento Telematico (RPT) o il carrello di RPT;
3. l’utilizzatore finale viene indirizzato sul WISP (vedi § 2.1.3) dove sceglie il Servizio che intende utilizzare (PSP e canale di pagamento);
4. in funzione della scelta effettuata dall’utilizzatore finale:

1. in caso di pagamento con carte:
   1. l’utilizzatore finale digita i dati della carta sul POS virtuale messo a disposizione dalla componete del NodoSPC denominata WISP;
   2. il NodoSPC individua il PSP che si farà carico del pagamento (mediante algoritmi che individuano il soggetto che offre le condizioni migliori per il versante;
   3. l’utilizzatore dispone il pagamento, avendo contezza dell’importo totale comprensivo delle commissioni dovute al PSP.
   4. il NodoSPC invia al PSP selezionato la RPT, insieme alle commissioni applicate e alle indicazioni relative all’autorizzazione del pagamento;
2. negli altri casi, il NodoSPC:
   1. invia la RPT al PSP;
   2. ridirige l’utilizzatore finale sulle pagine messe a disposizione dal PSP (nei grafici «Front-End PSP»), dove questi esegue il pagamento;
3. nel caso di non scelta dell’utente o di timeout sul WISP, il NodoSPC genera una o più RT negative e chiude il workflow;

1. l’utilizzatore finale è re-diretto su una «Thank You page» e conosce l’esito della transazione;
2. il PSP predispone la Ricevuta Telematica (RT ovvero il carrello di RT) e la invia attraverso il NodoSPC all’Ente Creditore;
3. l’utilizzatore finale è re-diretto sul portale dell’EC e può effettuare il download della quietanza.

Figura 4 – *Sequence diagram* del processo di pagamento con re indirizzamento on-line

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 e scaricare copia analogica e/o duplicato del documento informatico Ricevuta Telematica (RT.XML).

Negli schemi richiamati si è esemplificata la modalità di incasso «su iniziativa dell’Ente Creditore» nella quale l’utente - avendo ricevuto l’avviso di pagamento analogico o digitale - effettua la ricerca del pagamento da effettuare sul portale dell’ente, essendo questo già stato predeterminato a monte, quindi lo esegue con le modalità sopra esposte. Il modello di pagamento in esame consente di gestire anche la modalità di incasso cosiddetto «spontaneo».

Il regolamento dei pagamenti effettuati con questo tipo di workflow viene effettuato attraverso il bonifico bancario (SCT - SEPA Credit Transfer) ed il bollettino di conto corrente postale.

Pagamenti tramite il circuito MyBank¶

Nel caso che venga utilizzato il circuito e-commerce MyBank, che adotta gli schemi OBeP (On-line Banking ePayment), si riproduce un caso particolare dello stesso processo di pagamento descritto in precedenza.

Per ulteriori dettagli si rimanda al documento monografico «Transazioni MyBank attraverso il Nodo dei Pagamenti-SPC» pubblicato sul sito dell’Agenzia (vedi Appendice 4).

Si segnala comunque che questa modalità di pagamento è soggetta a restrizioni e può non essere sempre disponibile per tutte le tipologie di pagamento.

Processo di pagamento con autorizzazione gestita dal PSP¶

Questo workflow, già denominato «Processo di pagamento con esecuzione differita» nelle precedenti versioni del presente documento, prevede che l’autorizzazione del pagamento da parte dell’utilizzatore finale avvenga mediante l’interazione con strumenti messi a disposizione dal PSP.

La componente WISP del NodoSPC innesca tale processo inoltrando la RPT, in modo del tutto trasparente per l’Ente Creditore. I sistemi informatici del PSP acquisiscono i dati del soggetto pagatore (o versante se esiste) e procedono all’autenticazione dell’identità dichiarata, autorizzando, se del caso, l’accesso ai sistemi di pagamento.

Figura 5 – Processo di pagamento con autorizzazione gestita dal PSP

L’esecuzione del pagamento ed il rilascio della relativa attestazione (RT) avvengono in funzione delle modalità di autorizzazione del pagamento adottate dal PSP. Si distingue quindi l’autorizzazione:

• contestuale alla richiesta effettuata, in funzione dei livelli di servizio pattuiti con il PSP, se l’utilizzatore finale ha pre-autorizzato il pagamento (lettera di manleva o altro strumento contrattuale);
• non contestuale, se l’autorizzazione viene rilasciata successivamente alla ricezione della RPT da parte del PSP, attraverso canali da questo messi a disposizione (home banking, notifica su app per smartphone o tablet, ecc.).

In ogni caso il PSP deve restituire la RT in tempi certi e comunicati al proprio cliente prima del pagamento, in modo da consentire all’utilizzatore finale di usufruire dei servizi per cui ha pagato.

Figura 6 - *Sequence diagram* del processo di pagamento con autorizzazione gestita dal PSP

Lo schema di Figura 5 a pagina 32 ed il Sequence diagram di Figura 6 illustrano l’esempio della modalità di incasso «spontaneo», cioè quella che nasce da esigenze dell’utilizzatore finale eseguita con il modello di pagamento in parola e si concretizza negli stessi passi previsti dal workflow del «Processo di pagamento con re indirizzamento on-line» a pagina 29, con piccole eccezioni: al passo 4, l’utilizzatore finale sceglie PSP e canale di pagamento che non prevedono interazioni on-line (nei grafici manca «Front-End PSP»), pertanto il workflow prevede:

1. l’utilizzatore finale si collega al portale dell’EC, cerca il servizio da pagare e compone il carrello con il pagamento che intende effettuare;
2. l’Ente Creditore trasmette al Nodo dei Pagamenti-SPC la Richiesta di Pagamento Telematico (RPT);
3. l’utilizzatore finale viene indirizzato sul WISP (vedi § 2.1.3), dove sceglie il Servizio che intende utilizzare (PSP e canale di pagamento);
4. l’utilizzatore finale sceglie un PSP e un canale di pagamento che non prevedono interazioni on-line [1]:
5. invia la RPT al PSP;
6. l’utilizzatore finale è re-diretto sul portale dell’EC e informato che il suo pagamento è stato preso in carico dal PSP;
7. il PSP verifica condizioni per autorizzare il pagamento (pre-autorizzazione o altro, vedi sopra) e predispone la Ricevuta Telematica e la invia attraverso il NodoSPC all’Ente Creditore.

Nel caso di pre-autorizzazione del pagamento, resta salva la possibilità per l’utilizzatore finale di revocare il consenso rilasciato al PSP ad eseguire un’operazione di pagamento, in presenza delle condizioni previste all’articolo 17 del Decreto legislativo n. 11/2010.

Il regolamento dei pagamenti effettuati con questo tipo di workflow viene effettuato attraverso il bonifico bancario (SCT - SEPA Credit Transfer) o con il bollettino di conto corrente postale.

Scelta del servizio di pagamento da parte dell’utilizzatore finale¶

Dall’analisi del flusso dei processi di pagamento sino qui illustrati, è possibile sintetizzare nello schema di Figura 7 le varie fasi che portano l’utilizzatore finale, una volta definito il servizio o il pagamento di proprio interesse, a completare l’iter del procedimento: quello che nel lessico ecommerce è definito come fase di «check-out», cioè il momento di scelta delle modalità di pagamento e di esecuzione vera e propria della transazione finanziaria.

Il processo di scelta è attuato per mezzo della componente centralizzata - di seguito indicata con l’acronimo WISP (Wizard Interattivo di Scelta del PSP) - che permette all’utilizzatore finale di utilizzare la stessa interfaccia utente in ogni circostanza.

Le pagine della componente WISP guidano l’utilizzatore finale alla scelta del servizio di pagamento più conveniente, specificando in successione modalità e PSP, fino a una conclusiva pagina riassuntiva che permette di effettuare il pagamento.

I servizi offerti dai vari PSP aderenti al Nodo dei Pagamenti-SPC sono proposti all’utilizzatore finale assicurando a tutti i PSP aderenti le stesse opportunità di concorrenza, parità di trattamento e non discriminazione.

Nel rispetto di tale principio, WISP mette a disposizione del cittadino utente di pagoPA ulteriori funzioni di supporto che consentono di memorizzare le scelte di pagamento effettuate per poterle richiamare e riutilizzare nelle successive occasioni. Oppure di eleggere una delle scelte come predefinita così da avere un’esperienza quanto più possibile simile alla modalità one-click tipica dei siti di ecommerce.

Figura 7 – Check-out nel processo di pagamento attivato presso l’Ente Creditore

Lo schema di Figura 7 - che si applica sia al modello di pagamento con autorizzazione gestita on-line, sia al modello con autorizzazione gestita dal PSP, senza necessità per l’EC di implementare diverse modalità di gestione - mostra come, una volta scelta la modalità di pagamento, il workflow si articola su due percorsi diversi: uno sulle pagine del WISP stesso, l’altra sulle pagine messe a disposizione dal PSP prescelto.

Per i pagamenti con carta (di credito o di debito) il workflow è reso maggiormente performante perché sarà la componente WISP a selezionare, sulla base del PAN (Primary Account Number identificativo univoco di una carta), il PSP aderente a pagoPA che offre le condizioni più favorevoli.

Gli utenti registrati che memorizzano il pagamento comunque saranno liberi di modificare il PSP abbinato alla propria carta accedendo alle funzioni offerte dalla componente WISP.

Nello schema di Figura 8 è mostrato il percorso di scelta adottato per il WISP, nel corso del quale possono essere applicati filtri circa l’esposizione dei servizi offerti dai PSP in funzione del contenuto della RPT (o del carrello di RPT) ricevuto.

Si noti, che, qualora l’utilizzatore finale non effettui alcuna scelta, oppure si verifichi un timeout di sessione, il NodoSPC genererà una o più RT negative, così come indicato nei precedenti paragrafi.

Figura 8 – Percorso di scelta del PSP e del servizio di pagamento

Per una visione specialistica della funzionalità si può anche consultare il documento monografico «Wizard Interattivo di Scelta del PSP» pubblicato sul sito AgID.

Revoca della Ricevuta Telematica¶

Figura 9 – Modello di processo di revoca di un pagamento

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 - chieda al proprio prestatore di servizi di pagamento il rimborso di un pagamento già completato, il sistema mette a disposizione di PSP e Enti Creditori idonee funzionalità del Nodo dei Pagamenti-SPC per gestire la revoca della RT inviata in precedenza (vedi paragrafo 4.4.4).

Come indicato dal modello esposto in Figura 9 a pagina 36, la Revoca della RT si esplica nell’invio di una richiesta di revoca (RR) da parte del PSP, contenente i riferimenti della RT oggetto della revoca e nella risposta da parte dell’Ente Creditore contenente l’esito della revoca (ER).

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.

Il GdL «Pagamenti e fatturazione elettronica» ha ritenuto opportuno rinviare l’attivazione del processo di «revoca del pagamento» - qui analizzato - ad un momento successivo, condizionandone l’avviamento ad una verifica circa la casistica riscontrata in corso di effettivo utilizzo in ambiente di esercizio.

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 PSP idonee funzionalità del Nodo dei Pagamenti-SPC per gestire detta operazione utilizzando la richiesta di una revoca della RT inviata in precedenza (vedi paragrafo 4.4.5).

Come indicato dal modello esposto in Figura 10, lo «storno» del pagamento si esplica nell’invio di una richiesta di revoca (RR) da parte dell’Ente Creditore, contenente i riferimenti della RT oggetto della revoca e nella risposta da parte del PSP contenente l’esito della revoca (ER), che il PSP può accettare di eseguire utilizzando i propri processi contabili e amministrativi interni, ovvero può anche rifiutare.

Figura 10 – Modello di processo di storno di un pagamento

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.

Verifica del pagamento in attesa¶

In questa fase l’Ente Creditore può comunicare all’utilizzatore finale informazioni legate al pagamento ed al suo stato, nonché possibili variazioni dell’importo dovute ad eventi successivi all’invio dell’Avviso (ad esempio: superamento della data di scadenza del pagamento), in quanto l’importo del pagamento dovuto, stampato sull’avviso, è indicativo e riferito al momento della produzione del documento stesso.

Per comunicare al PSP tali variazioni o ulteriori informazioni legate al pagamento, utili per informare l’utilizzatore finale, l’Ente Creditore deve utilizzare le modalità indicate al § 7.4.5 della Sezione II.

Attivazione della richiesta di pagamento¶

Il Nodo dei Pagamenti-SPC non controlla la sequenza operativa delle fasi del processo descritte in precedenza: pertanto, un PSP potrebbe effettuare la richiesta di attivazione della RPT senza aver preventivamente effettuato la fase di verifica. L’utilizzo di questo approccio è deprecato e non sarà più disponibile con una successiva versione delle Specifiche attuative in quanto l’Ente Creditore potrebbe rifiutare di inviare la RPT 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 PSP avrebbe incassato dei fondi ai quali non può essere associata una Ricevuta Telematica da inviare all’Ente Creditore. A tal proposito si ricorda che, ai sensi delle Linee guida, i pagamenti effettuati attraverso il Nodo dei Pagamenti-SPC sono liberatori del debito a condizione che la Ricevuta Telematica sia congruente con le informazioni presenti sulla relativa RPT e quindi sull’archivio dei pagamenti in attesa.

Pagamento spontaneo presso i PSP¶

Nel modello di pagamento attivato presso il PSP, l’utilizzatore finale, se sprovvisto del Numero Avviso (che contiene il codice IUV), non risulta in grado di avviare il pagamento desiderato. Tale situazione rappresenta una limitazione sia per l’utilizzatore finale, sia per il sistema in generale.

Ne consegue che il modello di pagamento in esame, che costituisce il canale d’accesso ai pagamenti elettronici più vicino ed usuale per gli utenti, non sviluppa appieno le proprie possibilità di crescita e, in alcuni casi, prevede una user experience che si discosta sensibilmente da quella sperimentata dall’utilizzatore finale al momento di pagare lo stesso servizio attraverso altri canali più tradizionali.

Al fine di superare tali limitazioni è stato attivato il modello di pagamento illustrato dal Sequence diagram di Figura 13, sostanzialmente simile al processo presentato in queste pagine, con la sostituzione della iniziale richiesta di «verifica del pagamento in attesa» con la richiesta del «numero dell’avviso».

Il NodoSPC riceve la richiesta del numero di avviso dal PSP, controlla sul Catalogo dei servizi (vedi §§ 4.2.4 e 5.3.11), la congruità della richiesta e la inoltra all’Ente Creditore che, accedendo ai propri archivi, assegna alla richiesta il corretto numero avviso. Da questo momento in poi, il processo di pagamento avviene con le stesse modalità indicate al precedente § 2.2.

Figura 13 – Sequence diagram del processo di pagamento spontaneo presso il PSP

L’applicazione di tale workflow è limitata a specifici servizi caratterizzati da un insieme di dati in possesso dell’utilizzatore finale che consentono di identificare univocamente il pagamento presso l’Ente Creditore, quali, ad esempio, la targa del veicolo per il pagamento della tassa automobilistica.

Riconciliazione in modalità singola¶

Figura 15 - Riconciliazione in modalità singola

Qualora, a fronte di ogni singolo set di informazioni DatiSingoloVersamento contenuti in una richiesta di pagamento, il PSP 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 tripletta di informazioni (vedi paragrafo 5.3.2 della Sezione II):

1. identificativoUnivocoVersamento (IUV) presente sulla RT inviata all’Ente Creditore che deve coincidere con il dato presente nella causale di versamento della disposizione di accredito inviata dal PSP al PSP dell’Ente Creditore, secondo quanto definito nella Sezione I dell’Allegato A alle Linee guida;
2. identificativoUnivocoRiscossione presente nella ì-esima occorrenza della struttura dati datiSingoloPagamento facente parte della RT inviata dal PSP all’Ente Creditore, tale può coincidere con il dato presente nell’informazione Transaction Reference Number della disposizione di accredito inviata dal PSP al PSP dell’Ente Creditore;
3. singoloImportoPagato presente nella ì-esima occorrenza della struttura dati datiSingoloPagamento facente parte della RT inviata dal PSP all’Ente Creditore, tale dato deve coincidere con il dato presente nell’informazione Amount della disposizione di accredito inviata dal PSP al PSP dell’Ente Creditore.

Il dato identificativoUnivocoVersamento (codice IUV) è presente nella causale di versamento del SEPA Credit Transfer secondo lo standard indicato nella Sezione I del già citato Allegato A alle Linee guida.

Riconciliazione in modalità multipla¶

Qualora il PSP effettui un’unica disposizione 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 PSP deve inviare all’Ente Creditore stesso.

Figura 16 - Riconciliazione in modalità multipla

La riconciliazione in questo caso deve essere effettuata in due fasi: nella prima fase il dato identificativoFlusso (idFlusso in Figura 16) - presente nella causale di versamento del SEPA Credit Transfer, secondo lo standard indicato nella Sezione II dell’Allegato A alle Linee guida - deve essere abbinato con quello presente nel Flusso di rendicontazione inviato all’Ente Creditore dal PSP che ha eseguito i pagamenti secondo lo standard indicato sempre nella Sezione II dell’Allegato A alle Linee guida; 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 se sulla base della seguente tripletta di informazioni [4]:

1. identificativoUnivocoVersamento (IUV) presente sulla RT inviata all’Ente Creditore che deve coincidere con lo stesso dato presente nella struttura datiSingoliPagamenti del Flusso di rendicontazione;
2. identificativoUnivocoRiscossione presente sulla RT inviata all’Ente Creditore può coincidere con lo stesso dato presente nella struttura datiSingoliPagamenti del Flusso di rendicontazione;
3. singoloImportoPagato presente sulla RT inviata all’Ente Creditore che deve coincidere con lo stesso dato presente nella struttura datiSingoliPagamenti del Flusso di rendicontazione.

Il Nodo dei Pagamenti-SPC fornisce apposite funzioni centralizzate (vedi § 4.4.6) 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 PSP una RPT contenente più pagamenti ovvero presenti un «carrello» di RPT aventi più beneficiari, il PSP può effettuare un unico addebitò verso l’utilizzatore finale al quale il PSP può attribuire lo stesso identificativoUnivocoRiscossione: pertanto l’Ente Creditore dovrà opportunamente tenerne conto nelle proprie procedure applicative di riconciliazione.

Workflow di acquisto della marca da bollo digitale¶

Il processo descritto di seguito è un esempio di come una PA possa integrare l’acquisto della marca da bollo digitale per la presentazione di una istanza, in una propria procedura informatica. Si evidenzia che l’esempio fornito è meramente indicativo e, poiché prescinde dai vincoli e dai requisiti imposti dal sistema @e.bollo, sarà necessario che le indicazioni fornite siano valutate, nell’applicazione pratica, alla luce della normativa relativa al bollo telematico vigente al momento. Per l’approfondimento di ogni aspetto o tematica che non sia strettamente connesso all’effettuazione del pagamento, si dovrà necessariamente fare riferimento alla documentazione emessa dalla stessa Agenzia delle Entrate.

Con riferimento allo schema di Figura 17 a pagina 47, il processo di acquisto consta dei seguenti passi:

1. l’utilizzatore finale si collega al sito istituzionale dell’amministrazione presso la quale deve presentare un’istanza e compila un form on line immettendo i dati richiesti;
2. il sistema, utilizzando i dati in input, predispone l’istanza in forma di documento digitale e ne determina l’hash associato;
3. il sistema della PA presenta al cittadino una pagina di checkout, con un messaggio che evidenzia la necessità di pagare il bollo per il completamento del servizio;
4. la PA nella predisposizione della Richiesta di Pagamento Telematica da trasmettere al NodoSPC avrà cura di specificare, oltre all’importo richiesto per la marca da bollo digitale, i seguenti dati:
   1. tipo di bollo da erogare;
   2. impronta del documento da bollare;
   3. provincia di residenza del soggetto pagatore;
5. l’utilizzatore finale viene indirizzato sul WISP (vedi § 2.1.3) che gli consente di scegliere il servizio di pagamento che intende utilizzare NB: la PA deve porre attenzione alla composizione del carrello poiché in questa circostanza le opzioni disponibili saranno limitate unicamente ai servizi dei PSP rivenditori di marche da bollo digitale;
6. l’utilizzatore finale autorizza il pagamento (vedi passi 4 e 5 del workflow di cui al § 2.1.1, pagina 29);
7. il PSP, sulla base delle informazioni ricevute per mezzo della RPT, genera la marca da bollo digitale e la restituisce alla PA, per conto dell’utilizzatore finale, come allegato della Ricevuta Telematica.

Figura 17 - Sequence diagram del processo di acquisto della marca da bollo digitale

Riconciliazione delle Ricevute Telematiche¶

Nel processo di acquisto in parola la Ricevuta Telematica (RT) svolge unicamente il ruolo di vettore della marca da bollo digitale acquistata dal cittadino. In mancanza di un corrispondente flusso finanziario verso la PA, questa tipologia di Ricevute Telematiche (RT) non è soggetta a riconciliazione, limitatamente agli importi riguardanti il MBD.

Iscrizione al servizio (enrolment)¶

L’iscrizione al servizio di avvisatura push può essere effettuata dall’utilizzatore finale, sia sul sistema pagoPA, identificandosi attraverso il Sistema Pubblico di Identità Digitale (SPID), sia aderendo ad uno dei servizi messi a disposizione da parte dei Prestatori di servizi di pagamento.

Inoltre l”enrolment al servizio potrà avvenire attraverso il portale dell’Ente Creditore.

Iscrizione al servizio presso pagoPA¶

Gli utenti registrati a pagoPA riceveranno gli avvisi digitali emessi da parte di tutti gli EC

Iscrizione al servizio presso il portale di un Ente Creditore¶

L’iscrizione al servizio di avvisatura effettuata dall’utilizzatore finale sul portale di un Ente Creditore avrà efficacia esclusivamente per la ricezione di avvisi da parte di quell’Ente Creditore. L’utente potrà recuperare tali avvisi per pagare sul portale dello stesso EC.

Iscrizione al servizio presso un Prestatore di servizi di pagamento¶

L’iscrizione al servizio di avvisatura può essere effettuata dall’utilizzatore finale aderendo ad uno dei servizi messi a disposizione da parte dei Prestatori di servizi di pagamento, che possono scegliere di gestire il servizio sia in modalità push, sia in modalità pull (vedi § 2.9).

L’utilizzatore finale scarica le applicazioni predisposte dai PSP che potranno essere utilizzate su PC, smartphone, tablet. Il PSP può inviare notifiche al proprio cliente come memo del pagamento da effettuare.

L’iscrizione al servizio di avvisatura effettuata dall’utilizzatore finale presso il PSP avrà efficacia per la ricezione di avvisi da parte di tutti gli Enti Creditori aderenti al sistema pagoPA® che supportano il servizio di avvisatura in modalità push.

Il protocollo di colloquio tra NodoSPC e i PSP, previsto per la fase di enrolment presso i PSP e da utilizzare esclusivamente per la modalità di inoltro push, è descritto nei §§ 8.2.6, 8.3.7 e 9.2.7 della Sezione III.

Iscrizioni presso più Prestatori di servizi di pagamento¶

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

Revoca di iscrizione al servizio di avvisatura¶

La revoca dell’iscrizione al servizio di avvisatura deve essere richiesta al soggetto al quale è stata chiesta l’iscrizione (Ente Creditore e/o PSP) che ne stabilisce le modalità.

Inoltro degli avvisi al debitore¶

Come indicato in Figura 19, la fase di invio degli avvisi digitali a cura degli Enti Creditori avviene secondo regole diverse in funzione delle scelte effettuate dall’utente in fase di enrolment. Questa fase può essere ulteriormente suddivisa nelle tre sotto-fasi appresso indicate:

1. invio da parte dell’Ente Creditore e presa in carico degli avvisi digitali da parte del NodoSPC,
2. recapito dell’avviso digitale al debitore,
3. comunicazione dell’esito del recapito all’Ente creditore.

L’interazione tra il sistema dell’Ente Creditore ed il NodoSPC può avvenire in due modalità:

1. invio massivo di un file contenente un insieme di avvisi digitali attraverso un sistema di file transfer sicuro (SFTP);
2. invio del singolo avviso digitale via web service SOAP.

Figura 19 - Invio degli avvisi - sotto fasi del processo di avvisatura push

In entrambe i casi, il NodoSPC fornisce un feed-back all’Ente Creditore circa l’esito del recapito: nel primo caso in modalità asincrona, sempre via file transfer; nel secondo in modalità sincrona all’interno della stessa chiamata SOAP.

Invio degli avvisi in modalità File Transfer¶

L’Ente Creditore invia al Nodo dei Pagamenti-SPC un flusso informativo contenente gli avvisi digitali che intende far recapitare ai propri utenti, attraverso il sistema di file transfer sicuro messo a disposizione.

Completata la sotto fase di recapito dell’avviso digitale (vedi successivo § 2.8.2.3), nella quale la componente di avvisatura del NodoSPC provvede ad effettuare l’operazione di recapito e a registrarne l’esito, il NodoSPC predispone un flusso contenente l’esito del recapito dei singoli avvisi di pagamento effettuato nella fase precedente e lo invia all’Ente Creditore emittente l’avviso.

Invio degli avvisi in modalità Web service¶

L’Ente Creditore invia al NodoSPC il singolo avviso digitale che intende far recapitare al proprio utente attraverso un apposito Web service utilizzando il formato dati previsto dalle specifiche riportate nel § 5.4.4, segnalando all’ente eventuali difformità rispetto agli standard previsti.

Recapito dell’avviso al debitore¶

Il recapito al debitore registrato su pagoPA avviene con le modalità da questi indicate in fase di iscrizione al servizio (e-mail, sms o notifica su dispositivo mobile), pertanto l’utilizzatore finale potrebbe ricevere lo stesso avviso attraverso più canali o più PSP. Infatti, il Nodo dei Pagamenti-SPC, provvede ad inviare gli avvisi digitali (cfr. Figura 19 a pagina 49,):

1. sulla base delle informazioni inviate dall’Ente Creditore selezionando i canali sui quali inviare gli avvisi:
   1. via SMS: se sull’avviso è presente il numero di telefono dell’utilizzatore finale e lo stesso abbia scelto tale modalità;
   2. via e-mail: se sull’avviso è presente l’indirizzo fornito dell’utilizzatore finale;
2. in funzione del codice fiscale del debitore memorizzato nell’archivio delle iscrizioni al servizio di avvisatura (modalità push) effettuate presso i PSP in fase di enrolment, inviando l’avviso digitale al dispositivo mobile indicato dall’utilizzatore finale.

Nel caso di invio al dispositivo mobile che contiene un’applicazione del PSP (app), quest’ultimo deve mettere a disposizione dell’utilizzatore finale, nel rispetto delle modalità e delle condizioni con questo concordate in sede di adesione al servizio, funzioni che consentono di presentare l’avviso ed in seguito effettuare il pagamento.

Si tenga presente pertanto che uno stesso avviso potrebbe essere inviato più volte: cioè, uno per ogni app di ricezione degli avvisi attivata dall’utilizzatore finale e presente sul/sui dispositivo/i indicati al PSP.

Pagamento del dovuto¶

Per quanto riguarda la fase del pagamento del dovuto, si ricorda che l’operazione potrà essere effettuato in modalità integrata:

1. sul portale dell’Ente Creditore, qualora, sia recapitato via e-mail o sms [5] e i dati contenuti nell’avviso digitale comprendano le istruzioni che consentono di effettuare il pagamento;
2. con le modalità previste per il pagamento presso il PSP, qualora il Prestatore di servizi di pagamento dell’utilizzatore finale lo consenta.

In particolare, i PSP possono mettere a disposizioni delle app per dispositivi mobili ovvero altri servizi che consentono di ricevere i dati del dovuto e di effettuarne il pagamento contestualmente oppure conservare l’avviso per utilizzarlo in tempo successivo.

Limitazioni all’utilizzo dell’avvisatura pull¶

Al momento, il sistema non consente l’utilizzo del servizio di avvisatura in modalità pull agli Enti Creditori che si avvalgono di più di un intermediario / partner tecnologico.

Al fine di prevenire utilizzi non consoni, il NodoSPC potrà applicare apposite regole di throttling (limitazioni nell’utilizzo) nel caso in cui il codice fiscale richiesto da uno stesso canale del PSP venga interrogato più volte nell’unità di tempo. 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.

Pagamento del dovuto¶

Per quanto riguarda la fase del pagamento del dovuto, si ricorda che l’operazione potrà essere effettuato in modalità integrata con le modalità previste per il pagamento presso il PSP (vedi § 2.2), qualora il Prestatore di servizi di pagamento dell’utilizzatore finale lo consenta.

In particolare, i PSP possono mettere a disposizioni delle app per dispositivi mobili ovvero altri servizi che consentono di ricevere i dati del dovuto e di effettuarne il pagamento contestualmente oppure in tempo successivo.

Note

Gestore del Workflow Applicativo¶

È la macro-componente principale mediante la quale istanzia i modelli di pagamento di cui al capitolo 2. Ha lo scopo di coordinare l’esecuzione delle richieste di servizio, richiamando componenti di utilità (quali ad esempio, il modulo per la diagnostica, il modulo per la verifica della firma digitale, ecc.) ed interfacciare l’infrastruttura di Rete SPC tramite una specifica Porta di Dominio.

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 PSP che abilitano il pagamento sui diversi canali.

Comprende degli 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 Porta di Dominio¶

Questa componente, mantenuta per retrocompatibilità, 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 PSP. A tale scopo, espone una modalità standard verso i PSP, descritta nel capitolo 9 della Sezione III. Nel caso di peculiari modalità tecnico trasmissive richieste dai PSP, sempre che di validità generale, possono essere realizzate allo scopo specifiche interfacce software.

Qualora il PSP lo richieda, la componente permette di interfacciare il PSP attraverso un intermediario (soggetto giuridico o circuito) scelto dallo stesso PSP. Tutti gli oneri derivanti sono a carico del PSP che mantiene la titolarità del rapporto con il Nodo dei Pagamenti-SPC.

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¶

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 Nodo dei Pagamenti-SPC.

Componente Web-FESP¶

La componente «Web-FESP» permette di effettuare il pagamento reindirizzando l’utente verso una landing page messa a disposizione dal PSP.

In questo caso:

• il PSP 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 Nodo dei Pagamenti-SPC all’Ente Creditore per consentire di completare l’operazione di pagamento.

Componente WISP¶

La componente «WISP» (Wizard Interattivo di Scelta del PSP) consente all’utilizzatore finale di effettuare la scelta del PSP 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 PSP 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 funzioni di supporto per il pagatore introducendo vari accorgimenti per semplificare la user experience, anche nel caso di pagamento con dispositivi mobili. Inoltre l’utente potrà memorizzare i servizi di pagamento utilizzati, evitando di dover effettuare una nuova ricerca nelle occasioni successive.

Componente Wrapper MyBank¶

Nell’ambito del collegamento tra il Nodo dei pagamenti-SPC ed il circuito e-commerce MyBank (vedi Capitolo Errore. L’origine riferimento non è stata trovata. in Appendice 2), la componente «Wrapper MyBank» si occupa di effettuare le necessarie conversioni di tracciati e gestire il colloquio tra il Nodo dei Pagamenti-SPC 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 Nodo dei Pagamenti-SPC sono tenute ad utilizzare le specifiche di interfacciamento della componente «Wrapper MyBank».

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 (vedi rispettivamente §§ 8.7 e 8.2.6);
• ai PSP di inviare via web service al NodoSPC le richieste di iscrizione al servizio (vedi § 9.2.7 della Sezione III);
• al NodoSPC di:
  • inviare gli avvisi digitali ai PSP via web service;
  • inviare gli avvisi digitali agli utilizzatori finali tramite e-mail (protocollo SMTP);
  • notificare ai servizi di Italia Login gli avvisi digitali (predisposizione per funzionalità future);

File Transfer sicuro¶

Il Nodo dei Pagamenti-SPC 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 SOAP 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 evidenzia tutte le informazioni attinenti ad ogni singola operazione sintetizzando le registrazioni effettuate dalle singole componenti del Nodo dei Pagamenti-SPC: FESP; Web FESP; Repository, ecc.

Le principali attività svolte dalla componente riguardano:

• la raccolta delle informazioni attinenti alle operazioni svolte dalle componenti del Nodo dei Pagamenti-SPC:
• 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),
• ecc.
• esposizione di un’interfaccia di interrogazione per l’accesso alle registrazioni degli eventi che consenta:
• 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 Nodo dei Pagamenti-SPC:

• traduttore XML: struttura e assembla i messaggi XML dei servizi
• modulo firma digitale: verifica/genera firme digitali e ne gestisce/verifica i relativi certificati
• 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.

Sistema di Reporting¶

Il sistema assicura la produzione e pubblicazione di informazioni a carattere statistico, attraverso un sito all’uopo dedicato e con la gestione dei livelli di accesso secondo profili definiti.

Tabella delle controparti¶

La «Tabella delle controparti» è il documento informatico, inviato dal Nodo dei Pagamenti-SPC ad ogni prestatore di servizi di pagamento, che contiene l’elenco degli Enti Creditori aderenti al Nodo dei Pagamenti-SPC e le informazioni sull’erogazione dei servizi dell’Ente Creditore stesso, compresa l’indicazione relativa alla disponibilità del pagamento attivato presso il PSP (cosiddetto «Modello 3»).

La «Tabella delle controparti» contiene inoltre l’elenco dei codici IBAN di accredito che gli Enti Creditori sono tenuti a comunicare al Nodo dei Pagamenti-SPC (vedi successivo § 4.2.3).

La «Tabella delle controparti» viene aggiornata e pubblicata con cadenza giornaliera.

Catalogo Dati Informativi¶

Ai fini della trasparenza delle operazioni, il Nodo dei Pagamenti-SPC censisce per i PSP i dati sulle condizioni di pagamento (costi massimi del servizio, pagine web con descrizione dei servizi, ecc.) in un catalogo alimentato dai PSP stessi mediante il tramite tecnico del Canale.

Funzionalità di interrogazione del catalogo sono esposte dal Nodo dei Pagamenti-SPC verso gli Enti Creditori, che le possono utilizzare per le opportune comunicazioni agli utilizzatori finali.

Il Catalogo dei Dati Informativi viene aggiornato e pubblicato con cadenza giornaliera.

Tabella dei c/c di accredito¶

Al fine di garantire la sicurezza delle transazioni processate, il Nodo dei Pagamenti-SPC verifica che i codici IBAN presenti nelle Richieste di pagamento telematico (RPT) siano congruenti con quelli memorizzati in un apposito archivio sulla base delle informazioni fornite dagli Enti Creditori.

A tale scopo questi ultimi sono tenuti ad inviare al Nodo dei Pagamenti-SPC l’elenco dei codici IBAN sui quali effettuare l’accredito delle somme dovute.

Catalogo dei servizi¶

Il Catalogo dei Servizi è il repository che contiene l’elenco dei servizi generalizzati, attivati dagli Enti Creditori, relativo al processo di pagamento attivato presso i PSP in modalità spontanea (vedi § 2.2.3).

Il Catalogo dei Servizi viene aggiornato e pubblicato con cadenza giornaliera.

Richiesta di Pagamento Telematico¶

Il Servizio RPT apre il contesto del pagamento telematico. È costituito dalle operazioni di ricezione delle RPT dagli Enti Creditori aderenti, di verifica diagnostica, di tracciatura temporale e di inoltro al PSP di riferimento secondo le indicazioni fornite dall’utilizzatore finale ovvero secondo regole predefinite di instradamento.

Il Servizio prevede due tipologie di interazione:

• Ente Creditore Aderente verso Nodo dei Pagamenti-SPC, per la ricezione e il trattamento delle RPT inviate dagli Enti Creditori aderenti
• Nodo dei Pagamenti-SPC verso il PSP, per la spedizione delle RPT ai PSP e il trattamento dell’esito di accettazione delle RPT.

I flussi di ingresso RPT sono sottoposti a controlli di conformità agli Standard di Servizio e sono accettati se trasmessi da Enti Creditori e diretti a PSP appartenenti al Dominio.

Pagamenti multi beneficiario o multipagatore¶

Il processo di pagamento presso l’Ente Creditore consente di gestire anche pagamenti di diversi pagatori destinati a molteplici beneficiari (Enti Creditori) a fronte di un’unica transazione di addebito nei confronti dell’utilizzatore finale attraverso l’invio al Nodo dei Pagamenti-SPC di un insieme di RPT [1]; tale insieme viene denominato «carrello di RPT» e può essere veicolato nel sistema a condizione che tutti gli Enti Creditori mittenti presenti nel «carrello RPT» si servano dello stesso intermediario tecnologico.

Ricevuta Telematica¶

Il Servizio RT chiude il contesto di pagamento telematico ed è complementare al Servizio RPT. È costituito dalle operazioni di ricezione delle RT dai PSP, verifica diagnostica, tracciatura temporale e inoltro all’Ente Creditore aderente di riferimento secondo le indicazioni memorizzate nella RPT di riferimento che ne determinano l’instradamento.

Il Servizio prevede due tipologie di interazione:

• PSP aderente verso Nodo dei Pagamenti-SPC, per la ricezione ed il trattamento delle RT inviate;
• Nodo dei Pagamenti-SPC verso l’Ente Creditore aderente, per la spedizione delle RT agli Enti Creditori aderenti e seguente trattamento dell’esito di accettazione delle RT. Il contesto di pagamento è considerato concluso dopo l’accettazione finale della RT da parte dell’Ente Creditore aderente che ha generato la RPT.

I flussi RT di ricezione:

• sono sottoposti a controlli di conformità agli Standard di Servizio e sono accettati se trasmessi da PSP appartenenti al Dominio e riferiti a RPT in corso di trattamento presso il Nodo dei Pagamenti-SPC.

Revoca della Ricevuta Telematica¶

Come visto nel § 2.1.4 la Revoca della RT si esplica nell’invio di una richiesta di revoca (RR) da parte del PSP, contenente i riferimenti della RT oggetto della revoca, al quale corrisponde la valutazione dell’Ente Creditore e la restituzione al PSP dell’esito di revoca (ER) che conclude il processo di revoca.

Il Servizio del Nodo dei Pagamenti-SPC prevede quattro tipologie di interazione tra:

• Il PSP aderente verso Nodo dei Pagamenti-SPC - invio del documento XML Richiesta Revoca - RR con gli estremi della RT che si intende revocare;
• il Nodo dei Pagamenti-SPC verso l’Ente Creditore aderente - inoltro della RR e registrazione nel giornale eventi delle tracce dell’operazione. Il Nodo considera conclusa l’operazione di richiesta revoca dopo la consegna della RR all’Ente Creditore;
• l’Ente Creditore aderente verso il Nodo dei Pagamenti-SPC - invio dell’XML Esito Revoca - ER con l’indicazione di accettazione o rifiuto della richiesta di revoca connessa alla RT di riferimento;
• il Nodo dei Pagamenti-SPC verso il PSP - inoltro della ER e registrazione nel giornale eventi delle tracce dell’operazione. Il Nodo considera conclusa l’operazione di esito revoca dopo la consegna della ER al PSP;

*Come indicato al §* *2.1.4 le funzioni di Revoca della Ricevuta Telematica sono definite, ma non implementate sull’infrastruttura del NodoSPC.*

Storno di un pagamento¶

Come visto nel § 2.1.5 lo storno di un pagamento si esplica nell’invio di una richiesta di revoca (RR) da parte dell’Ente Creditore, contenente i riferimenti della RT oggetto dello storno, al quale corrisponde la valutazione del PSP e la restituzione all’Ente Creditore dell’esito di revoca (ER) che conclude il processo di storno.

Il Servizio del Nodo dei Pagamenti-SPC prevede quattro tipologie di interazione tra:

• l’Ente Creditore aderente verso Nodo dei Pagamenti-SPC - invio del documento XML Richiesta Revoca - RR con gli estremi della RT che si intende revocare;
• il Nodo dei Pagamenti-SPC verso Il PSP aderente - inoltro della RR e registrazione nel giornale eventi delle tracce dell’operazione. Il Nodo considera conclusa l’operazione di richiesta revoca dopo la consegna della RR al PSP;
• il PSP verso il Nodo dei Pagamenti-SPC - invio dell’XML Esito Revoca - ER con l’indicazione di accettazione o rifiuto della richiesta di revoca connessa alla RT di riferimento;
• il Nodo dei Pagamenti-SPC verso l’Ente Creditore - inoltro della ER e registrazione nel giornale eventi delle tracce dell’operazione. Il Nodo considera conclusa l’operazione di esito revoca dopo la consegna della ER all’Ente Creditore.

I flussi RR e ER sono sottoposti a controlli di conformità agli Standard di Servizio e sono accettati se trasmessi da Enti Creditori appartenenti al Dominio.

Rendicontazione per gli Enti Creditori¶

Il Servizio «Rendicontazione» mette a disposizione degli Enti Creditori un flusso, generato da ogni PSP (si confronti il § 2.6), che riporta le informazioni necessarie per consentire all’Ente Creditore di procedere alla riconciliazione tra le RT ricevute e gli importi trasferiti dal PSP del debitore al PSP dell’Ente Creditore.

Il Nodo dei Pagamenti-SPC mette a disposizione dell’Ente Creditore e del PSP gli strumenti per lo scambio di tali flussi (vedi anche §§ 8.2.5 e 9.2.6).

Il periodo temporale durante il quale saranno disponibili le informazioni relative a tali flussi non sarà inferiore a quindici e non superiore a trenta giorni lavorativi.

Chiusura operazioni pendenti¶

Con riferimento al modello di pagamento ad esecuzione differita (cfr. § 2.1.2), ma applicabile a tutti i processi di pagamento previsti, è possibile che una Richiesta di pagamento Telematica (RPT) non abbia ricevuto la corrispondente Ricevuta Telematica nel periodo durante il quale il Nodo dei Pagamenti-SPC rende disponibili le RPT in attesa del relativo esito (si veda il paragrafo 12.3.1 «Periodo di ritenzione delle RPT senza esito» della Sezione IV).

Al termine di detto periodo il Nodo dei Pagamenti-SPC genera in via automatica una RT avente esito del pagamento non determinato e la invia all’Ente Creditore che ha generato la RPT, nello stesso tempo interagisce con il PSP interessato per richiedere la cancellazione della RPT dall’archivio per decorrenza dei termini (vedi anche §§ 9.1.7 e 9.2.9 nella Sezione III).

Modalità Unica d’Interazione - MUI¶

In relazione ai diversi modelli di processo sopra descritti, il Servizio MUI del Nodo dei Pagamenti-SPC svolge la funzione di normalizzazione del colloquio tra Ente Creditore aderente e PSP, svincolando i criteri specifici d’interazione rispetto ad ogni PSP e rendendo questa differenze trasparenti all’Ente Creditore.

In particolare, MUI normalizza i flussi operativi per realizzare il processo di pagamento attuato presso il Portale di Pagamento del PSP appositamente predisposto dal PSP stesso (cfr. anche §2.2).

Rendicontazione per l’Agenzia delle Entrate¶

Nell’ambito della gestione dell’acquisto della marca da bollo digitale, una specifica funzione del Nodo dei Pagamenti-SPC provvederà periodicamente ad inviare all’Agenzia delle entrate, per conto di tutti gli Enti Creditori accreditati sul Nodo dei Pagamenti-SPC, il flusso di rendicontazione previsto al punto 5.4 del Provvedimento del Direttore dell’Agenzia delle Entrate del 19 settembre 2014.

Sincronizzazione con la componente di gestione SFTP¶

Il Nodo dei Pagamenti-SPC mette a disposizione degli Enti Creditori e dei PSP la possibilità di completare la ricezione e l’invio di flussi massivi di informazioni, che oggi avviene attraverso modalità SOAP sincrona (ad esempio: flussi di rendicontazione, totali di traffico, ecc.), in modalità file transfer sicuro (SFTP).

*La funzione è al momento attiva solo per la ricezione dei flussi di rendicontazione (vedi §* *5.3.5) da parte degli Enti Creditori.*

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 ed RT) transitate attraverso il Nodo dei Pagamenti-SPC e di stretta pertinenza del singolo richiedente.

Il Nodo dei Pagamenti-SPC mette a disposizione dell’Ente Creditore e del PSP gli strumenti per la ricezione di tali flussi (vedi §§ 8.2.5 e 9.2.11).

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.

Tavolo Operativo e gestione delle anomalie (Incident)¶

Il Servizio rende disponibile un Tavolo operativo di primo livello, il quale:

• costituisce il punto unico di contatto per ogni soggetto – Enti Creditori e PSP aderenti;
• recepisce le richieste provenienti da Enti Creditori e PSP aderenti, ovvero rileva le segnalazioni di incidente riscontrate o supposte - proveniente dai citati soggetti utenti del Servizio, dal proprio sistema di monitoraggio o dal proprio personale aziendale;
• registra e classifica le richieste/segnalazioni mediante Trouble Ticketing e dà inizio, per ognuna di queste, a tutte le attività necessarie all’identificazione della soluzione.

Qualora il primo livello operativo non sia in grado di fornire una soluzione adeguata alle necessità, la richiesta è assegnata alle strutture di supporto di secondo livello per la presa in carico della richiesta medesima, l’individuazione del problema e la sua eventuale risoluzione.

A seguito dell’analisi effettuata dal secondo livello, qualora emergesse un problema nel software applicativo, è aperto un Change Order al terzo livello di supporto per l’opportuno intervento correttivo.

Per l’accesso ai servizi del tavolo operativo si faccia riferimento al sito dell’Agenzia.

Monitoring e controllo¶

Il Servizio prevede la disponibilità di un sistema di tracciamento degli eventi e di strumenti per controllo avanzamento/stati a disposizione dei Tavoli Operativi di Enti Creditori e PSP aderenti.

È previsto un sistema di controllo focalizzato 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 del sistema di controllo, ogni componente del Servizio, per ogni singolo evento rilevante dal punto di vista applicativo, effettua una scrittura che ne tenga traccia nel registro degli eventi. L’insieme di tali registrazioni costituisce il «Giornale degli Eventi», il quale riporta gli estremi degli eventi verificatisi così come indicato negli Standard di Servizio.

Reporting¶

Il Servizio rende disponibile la consultazione, l’analisi e l’esportazione di:

• dati e statistiche di tipo Amministrativo;
• dati da Giornale degli Eventi;
• statistiche sui flussi scambiati nell’ambito del Dominio, nel rispetto delle regole di riservatezza e competenza delle registrazioni.