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