PAGAMENTI TELEMATICI DELLA GIUSTIZIA - Portale Servizi ...

MINISTERO DELLA GIUSTIZIA – D.G.S.I.A. 

SISTEMI INFORMATIVI AUTOMATIZZATI PER LA GIUSTIZIA CIVILE E PROCESSO TELEMATICO 

PAGAMENTI TELEMATICI DELLA GIUSTIZIA 

SPECIFICHE – VERSIONE 5.2 

STATO:VERIFICATO


SISTEMI INFORMATIVI AUTOMATIZZATI PER IL PROCESSO TELEMATICO 

[Pagina Vuota] 

PAGAMENTI TELEMATICI DELLA GIUSTIZIA–SPECIFICHE– VERSIONE: 5.2 –STATO:VERIFICATO PAGINA 2 DI 43



SOMMARIO 

PREMESSA......................................................................................................................................................................8 

IL PAGAMENTO TELEMATICO DELLE SPESE DI GIUSTIZIA.........................................................................8 

ARCHITETTURA LOGICO FUNZIONALE DEL PAGAMENTO DELLE SPESE DI GIUSTIZIA .................10 

IL PROCESSO DI PAGAMENTO DELLE SPESE DI GIUSTIZIA .......................................................................12 

REQUISITI PRINCIPALI DEL PROCESSO DI PAGAMENTO..................................................................................................12 

Sicurezza.................................................................................................................................................................13 

Autenticazione tra i soggetti ...................................................................................................................................13 

Profilazione Automatica .........................................................................................................................................13 

Scelta della modalità di pagamento........................................................................................................................14 

Certezza del pagamento..........................................................................................................................................14 

Univocità del pagamento........................................................................................................................................14 

Rimborso del pagamento ........................................................................................................................................14 

Uniformità ..............................................................................................................................................................14 

REGOLE DI COLLOQUIO PER IL PROCESSO DI PAGAMENTO ............................................................................................15 

Oggetti scambiati....................................................................................................................................................15 

Repository Ricevute Telematiche (RRT) .................................................................................................................16 

Identificativo univoco di erogazione del servizio (CRS).........................................................................................16 

Processo di interazione nel Pagamento Telematico ...............................................................................................17 

ALLEGATO “A” – FLUSSI PROCEDURALI DEL PCT INTEGRATI CON IL PROCESSO DI 

PAGAMENTO ...............................................................................................................................................................21 

RILASCIO DI COPIE SEMPLICI O AUTENTICHE................................................................................................................21 

ISCRIZIONE A RUOLO ....................................................................................................................................................22 

ALLEGATO “B” – FLUSSI PROCEDURALI NELLA GESTIONE NON INTEGRATA DEI PAGAMENTI 

TELEMATICI................................................................................................................................................................24 

RILASCIO DI COPIE SEMPLICI O AUTENTICHE ................................................................................................................24 

ISCRIZIONE A RUOLO ....................................................................................................................................................25 

ALLEGATO “C” - PROTOCOLLO SULLE REGOLE TECNICHE E LO STANDARD PER L’EMISSIONE 

DEI DOCUMENTI INFORMATICI ...........................................................................................................................27 

PREMESSA....................................................................................................................................................................27 

FORMATO DEI MESSAGGI..............................................................................................................................................27 

SOGGETTI.....................................................................................................................................................................27 

ELENCO DEI DATI .........................................................................................................................................................28 

Richiesta di Pagamento Telematico (RPT) ............................................................................................................28 

Ricevuta Telematica (RT).......................................................................................................................................30 

NOTE ESPLICATIVE SULLE MODIFICHE ALLE INFORMAZIONI SCAMBIATE......................................................................33 

Versioning...............................................................................................................................................................33 

Dominio ..................................................................................................................................................................33 

Dati versamento......................................................................................................................................................33 

FORMATO DEI MESSAGGI..............................................................................................................................................33 

Richiesta Pagamento Telematico (RPT) ................................................................................................................34 

Ricevuta Telematica (RT).......................................................................................................................................37 

ALLEGATO “D” - STRUTTURA DELL’ELEMENTO “IDENTIFICATIVO UNIVOCO VERSAMENTO” ......41 

CONTESTO GENERALE ..................................................................................................................................................41 

LO STANDARD ISO 11649:2009 ...................................................................................................................................41 

CALCOLO DEI CHECK DIGITS DEL CREDITOR REFERENCE .............................................................................................42 

ALGORITMO DI CALCOLO ISO/IEC 7064 .....................................................................................................................42 

COMPOSIZIONE DEL CRS NEI PAGAMENTI DELLA GIUSTIZIA ........................................................................................43 

CALCOLO DEI CHECK DIGITS DEL CRS NEI PAGAMENTI DELLA GIUSTIZIA....................................................................43 




MODIFICHE APPORTATE 

dalla versione 2.3 

modificato il requisito Univocità del pagamento 

modificato il paragrafo Oggetti scambiati 

inserito il paragrafo Emissione e Gestione dell’identificativo univoco di erogazione del 

servizio 

modificato il paragrafo Rilascio di copie semplici 

modificato il paragrafo Iscrizione a ruolo 

modifica ad Allegato B 


modifica denominazione Quietanza Telematica ridenominata in Ricevuta Telematica 

modificato il requisito Certezza del pagamento 

inserito il requisito Rimborso del pagamento 

inserito il paragrafo Identificativo univoco di erogazione del servizio 

modificato il paragrafo Processo di interazione con il Front-End SP nell’ambito del PCT 

modificato il paragrafo Rilascio di copie semplici 


modifica ad Allegato B: 

• Inserito paragrafo Soggetti 

• Modificato paragrafo Elenco dei dati (RPT e RT) 

• Modificato paragrafo Allegato tecnico sul formato dei messaggi 

(RPT e RT) 


eliminato Refusi vari e Nota (3) di pagina 11, Nota (6) di pagina 13 

modificato il paragrafo Regole di colloquio per il processo di pagamento 

Inserita precisazione su PdA/Portale 

modificato il paragrafo Emissione e gestione dell’Identificativo univoco di erogazione del 

servizio 

Nota (1) e Nota (2) di pagina 9 riportate direttamente nel testo 

modificato il paragrafo Flussi Procedurali del PCT integrati con il processo di pagamento 

Nota (4) di pagina 11 e Nota (7) di pagina 13 unificate e riportate 

direttamente nel testo 


Nota (5) di pagina 13 riportata direttamente nel testo 

modifica ad Allegato B: 

• Modificato paragrafo Elenco dei dati (RPT e RT) con 

inserimento del numero civico su tutti gli indirizzi 


(RPT e RT) con: 

correzione refusi, 

inserimento civicoXxxxx su tutti gli indirizzi, 

inserimento precisazioni. 





modificato il paragrafo Sicurezza 

Inserita precisazione su interconnessione tra rete pubblica e rete 

interbancaria. 

modificato il paragrafo Oggetti Scambiati 

modificato il paragrafo Emissione e gestione dell’Identificativo univoco di erogazione del 

servizio 

modificato il paragrafo Rilascio Copie Semplici 

modificato il paragrafo Iscrizione a Ruolo 

eliminato Allegato A 

modificato Allegato B diventa allegato A 

modificato ex Allegato B: 

Inserita la possibilità di effettuare, a fronte di un unico Identificativo 

Univoco di Versamento, il pagamento di fino a 5 importi diversi, anche 

su conti di tesoreria diversi: 

• Modificato paragrafo Elenco dei dati (RPT e RT) con i nuovi 

dati 


(RPT e RT) con: 

correzione refusi, 

inserimento dei nuovi dati 

modifica ad obbligatorietà di alcune informazioni. 


eliminato il paragrafo Scenario 

inserito il paragrafo Premessa 

inserito il capitolo Il pagamento delle spese di Giustizia 

Alla luce delle nuove impostazioni riportate nel paragrafo si traccia il 

rinnovato schema del processo 

modificato il capitolo Architettura logico funzionale del sistema (precisazioni) e rinominato 

in Architettura logico funzionale pagamento delle spese di Giustizia 

eliminato il paragrafo Integrazione 

Il requisito è stato posizionato nell’allegato A in quanto peculiare del 

procedimento amministrativo in ambito PCT 

modificato il paragrafo Sicurezza (precisazioni) 

modificato il paragrafo Autenticazione tra i soggetti (precisazioni) 

modificato il paragrafo Profilazione automatica (precisazioni) 

modificato il paragrafo Univocità del pagamento (precisazioni) 

modificato il paragrafo Oggetti scambiati (precisazioni) 

inserito il paragrafo Firma digitale degli oggetti scambiati (a precisazione) 

inserito il paragrafo Versamenti multipli (a precisazione) 

inserito il paragrafo Repository Ricevute Telematiche ( RRT) 

modificato il paragrafo Identificativo univoco di erogazione del servizio (CRS) 

eliminato il paragrafo Emissione e gestione dell’Identificativo univoco di erogazione del 

servizio 




inserito il paragrafo Emissione del CRS 

sostituisce con precisazioni parte dell’eliminato paragrafo “Emissione 

e gestione dell’Identificativo univoco di erogazione del servizio” 

inserito il paragrafo Controllo e annullamento del CRS 

sostituisce con precisazioni parte dell’eliminato paragrafo “Emissione 

e gestione dell’Identificativo univoco di erogazione del servizio” 

eliminato il paragrafo Processo di interazione con il Front-End SP nell’ambito del PCT 

inserito il paragrafo Processo di interazione nel Pagamento Telematico 

rivisitazione dell’intero processo alla luce della nuova impostazione e 

dell’introduzione del sottosistema Repository Ricevute Telematiche 

(RRT) 

inserito il paragrafo Il middleware FESP (a precisazione) 

eliminato il capitolo Flussi procedurali del PCT integrati con il processo di pagamento 

diventa “Allegato A” con modifiche 

modificato allegato Allegato “A” diventa Allegato “C” 

• elemento identificativoUnivocoVersamento modificato nella 

specifica del “contenuto”; 

• elemento causaleVersamento modificato nella specifica del 

“contenuto”; 

• elemento datiSpecificiRiscossione diventa obbligatorio, inseriti 

valori da utilizzare; 

• eliminazione refusi; 

• allineamento con element name della XSD. 

inserito allegato Allegato “A” – Flussi procedurali del PCT integrati con il processo di 

pagamento 

rivisitazione dei flussi di erogazione dei servizi alla luce della nuova 

impostazione e dell’introduzione del sottosistema Repository Ricevute 

Telematiche ( RRT) 

inserito allegato Allegato “B” – Pagamenti telematici non integrati 

descrizione dei flussi di erogazione dei servizi alla luce della nuova 

impostazione e dell’introduzione del sottosistema Repository Ricevute 

Telematiche ( RRT) 

inserito allegato Allegato “D” - Struttura dell’elemento “Identificativo Univoco 

Versamento” 


modificato paragrafo Oggetti scambiati 

Inserite precisazioni su firma degli aggetti RPT ed RT. 

modificato allegato 

Versamenti multipli, ammessa la possibilità di pagamento parziale. 

Allegato “C” 

Elenco dei dati: 

• Inserite precisazioni sulla firma degli oggetti RPT ed RT. 

Formato dei messaggi 

• struttura soggettoVersante resa facoltativa (oggetti RPT ed 

RT); 

• struttura soggettoPagatore resa obbligatoria (oggetti RPT ed 

RT); 

• Oggetto RPT: 





modificato allegato 

elemento identificativoDominio modificato il valore delle 

colonna UNIFI e semantica del contenuto; 

elemento identificativoStazioneRichiedente modificato il 

valore della colonna UNIFI; 

• Oggetto RT: 

elemento codiceEsitoPagamento modificato contenuto con 

inserimento di pagamento parziale (codice 2); 

eliminato elemento esitoPagamento; 

struttura datiSingoloPagamento modificata semantica del 

contenuto con riferimento a obbligatorietà; 

elemento singoloImportoVersato modificato contenuto 

inserito elemento esitoSingoloPagamento nella struttura 

datiSingoloPagamento; 

elemento datiSpecificiRiscossione modificata 

obbligatorietà. 

Allegato “C” 

Elenco dei dati: 

vedi modifiche a “Formato dei messaggi” 

Inserito il nuovo paragrafo “Note esplicative sulle modifiche alle 

informazioni scambiate” 

Formato dei messaggi 

• inserita la nuova informazione versioneOggetto (oggetti RPT ed 

RT); 

• la struttura Dominio è stata inserita anche nell’oggetto RT; 

• Oggetto RT: 

struttura datiVersamento: eliminato l’elemento 

dataVersamento; 

struttura datiSingoloPagamento: inserito il nuovo elemento 

dataEsitoSingoloVersamento che assume il significato di 

data di versamento o di rifiuto dell’ordine di pagamento. 


PREMESSA 



Nell’ambito della collaborazione tra il Ministero della giustizia ed il CNIPA (ora DigitPA), nella 

primavera del 2009 è stato avviato un tavolo di lavoro congiunto con la Direzione Generale Sistemi 

Informativi Automatizzati al fine di definire una procedura che consenta ai privati di effettuare, in 

maniera telematica, i pagamenti relativi alle spese di giustizia relative al Processo Civile 

Telematico utilizzando gli strumenti messi a disposizione dalla normativa vigente, in particolare 

con riferimento al decreto MEF 9 ottobre 2006, n° 293 “Regolamento recante norme per 

l'introduzione di nuove modalità di versamento presso le tesorerie statali”. 

Tale collaborazione ha prodotto, attraverso un percorso di approfondimento e affinamento, un 

documento di specifiche che ha consentito l’avvio della sperimentazione dei pagamenti telematici 

in ambito PCT presso alcuni tribunali ‘pilota’ già a partire da maggio 2010 (versione 4.0 del 

presente documento). 

La pubblicazione del Decreto Legge 29 dicembre 2009, n. 193 - convertito con la legge 22 febbraio 

2010, n. 24 – che con il comma 9 dell’articolo 4 ha innovato le modalità per il pagamento di tutte 

spese di giustizia 1 e la ridefinizione dell’art.5 operata nel nuovo CAD, pubblicato sulla G.U. del 

30/12/2010, che traccia le linee guida del processo di pagamento, confermano la fondatezza delle 

attività di sperimentazione avviate. 

Dette normative definiscono le modalità per il pagamento telematico astraendolo dal contesto 

specifico, pertanto le redazioni del presente documento di specifiche, a iniziare dalla versione 5.0, 

tratteranno il pagamento di tutte le spese di giustizia in termini generalizzati, per poi riferirsi a 

specifici ambiti di applicazione. 

IL PAGAMENTO TELEMATICO DELLE SPESE DI GIUSTIZIA 

L’obiettivo del presente documento è quello di individuare i flussi e le modalità operative utilizzate 

dal Ministero della Giustizia al fine di garantire l’erogazione del servizio a fronte di un pagamento 

eseguito per via telematica, indipendentemente dal livello e dal tipo di informatizzazione 

dell’ufficio erogante. A tale scopo saranno pertanto presi in considerazione sia uffici che operano 

in maniera “tradizionale”, che strutture presso cui sono già attivi flussi telematici di scambio dati 

(Processo Telematico). 

Il pagamento, il cui schema generale di flusso è descritto in Figura 1, avviene in modalità 

telematica attraverso il Punto di Accesso o il Portale dei Servizi Telematici del Ministero, come 

meglio descritto nei successivi capitoli. 

Nel passo 1 “autenticazione e accesso al servizio” il Portale del Ministero ovvero il Punto di 

Accesso autentica in maniera “forte” il soggetto pagatore, tipicamente un avvocato. Una volta 

1 “Per consentire il pagamento, da parte dei privati, con sistemi telematici di pagamento ovvero con carte di debito, di 

credito o prepagate o con altri mezzi di pagamento con moneta elettronica disponibili nei circuiti bancario e postale, 

del contributo unificato, del diritto di copia, del diritto di certificato, delle spettanze degli ufficiali giudiziari relative 

ad attività di notificazione ed esecuzione, delle somme per il recupero del patrocinio a spese dello Stato, delle spese 

processuali, delle spese di mantenimento, delle pene pecuniarie, delle sanzioni amministrative pecuniarie e delle 

sanzioni pecuniarie il Ministero della giustizia si avvale, ((senza nuovi o maggiori oneri)) a carico del bilancio dello 

Stato, di intermediari abilitati che, ricevuto il versamento delle somme, ne effettuano il riversamento alla Tesoreria 

dello Stato, registrando in apposito sistema informatico a disposizione dell'amministrazione i pagamenti eseguiti e la 

relativa causale, la corrispondenza di ciascun pagamento, i capitoli e gli articoli d'entrata. (…omissis …)” 




verificata l’identità dell’utente il Portale del Ministero/Punto di accesso permette al soggetto 

pagatore di inserire i dati per effettuare la richiesta di pagamento. 

Nel passo 2 “rilascio codice univoco” il Portale del Ministero ovvero il Punto di Accesso, una volta 

ottenute dal soggetto pagatore le informazioni inerenti il pagamento, richiede in via automatica la 

generazione di un codice univoco al Ministero della Giustizia (Servizi Telematici), codice che, 

sempre in via automatica, viene inserito nella richiesta di pagamento che sarà inviata ai fornitori di 

servizi di pagamento. 

Nel passo 3 “esecuzione del pagamento”, la richiesta di pagamento viene trasmessa sempre in via 

automatica dal Portale del Ministero/Punto di accesso al fornitore di servizi di pagamento che 

provvede ad eseguire la disposizione attraverso, al momento, i seguenti strumenti di pagamento: 

a. bonifico bancario a favore della tesoreria competente (cfr. citato DM 9/10/2006, n° 296); 

b. conto corrente postale dedicato intestato alla tesoreria dello Stato. 

Il fornitore di servizi di pagamento, eseguita l’operazione, provvede a restituire al Portale del 

Ministero ovvero al Punto di Accesso la ricevuta del versamento delle somme richieste. 

Nel passo 4 “Registrazione ricevute”, una volta ottenuta la Ricevuta relativa al pagamento 

richiesto, contenente anche il codice univoco generato in precedenza, il Portale del Ministero 

ovvero il Punto di Accesso provvede, in via automatica, a registrare la ricevuta, che attesta 

l’univocità del pagamento, su di un apposito archivio gestito dal Ministero della Giustizia (Servizi 

Telematici). 

Nel passo 5 “Invio ricevute” il Portale del Ministero ovvero il Punto di accesso provvede a 

restituire al soggetto pagatore la ricevuta che attesta l’avvenuto pagamento. La ricevuta restituita 

automaticamente è un documento informatico (in forma di file xml) contenente tutte le 

informazioni inerenti il pagamento. 

Figura 1 - Schema generale del pagamento delle spese di giustizia 

Nel successivo passo 6 “Richiesta servizio e comunicazione pagamento” il soggetto pagatore, al 

fine di ottenere il servizio richiesto per il quale ha già eseguito il pagamento (cfr. passi da 1 a 5), 

comunica l’avvenuto pagamento al competente ufficio erogatore. 




Nel passo 7 “verifica pagamento e annullamento ricevuta”, l’ufficio erogatore procede alla verifica 

del pagamento (attraverso l’accesso all’archivio delle Ricevute) ed all’annullamento della ricevuta 

(per evitarne il riutilizzo). 

Nel passo 8 “erogazione del servizio” l’ufficio competente procede all’erogazione del servizio. 

Dal punto di vista funzionale, il processo può essere suddiviso logicamente in due fasi: 

• la prima fase (passi da 1 a 5) riguarda più specificatamente il processo di pagamento e verrà 

trattato dettagliatamente nel capitolo “Il processo di pagamento delle spese di Giustizia”; 

• la seconda fase (passi 6, 7 e 8) riguarda le modalità con le quali viene erogato il servizio e 

dipende quindi dallo stato di automazione del servizio in questione (l’ufficio giudiziario si 

avvale di procedure automatizzate e flussi telematici o fornisce il servizio in modo 

tradizionale). Si possono pertanto distinguere le seguenti possibili configurazioni di 

modalità di erogazione del servizio: 

1. Erogazione del servizio in via completamente telematica (Uffici automatizzati): il 

servizio erogato è informatizzato attraverso una procedura, che acquisisce in via 

automatica ed elaborabile la Ricevuta in formato xml e provvede a erogare il servizio 

all’utente (es. Processo Telematico); 

2. Erogazione del servizio in via informatica ma non integrata al pagamento (Uffici 

automatizzati ma senza gestione informatizzata della ricevuta): la Ricevuta è inviata per 

via telematica all’utente richiedente il servizio il quale può presentarla in via cartacea o 

in via telematica, all’ufficio competente per l’erogazione del servizio. L’Ufficio 

competente provvede, attraverso un interrogazione sull’archivio delle ricevute, ad 

eseguire le attività di controllo e annullamento della Ricevuta e, successivamente, a 

fornire il servizio, anche in via telematica; 

3. Erogazione del servizio in via tradizionale: L’utente, una volta eseguito il pagamento, 

può procedere a farsi rilasciare dal Portale del Ministero ovvero Punto di Accesso la 

Ricevuta in un formato stampabile e leggibile da un operatore umano. L’ufficio 

competente provvede quindi, attraverso un interrogazione sull’archivio delle ricevute, 

ad eseguire le attività di controllo di univocità e annullamento della Ricevuta che gli è 

stata presentata e successivamente ad erogare il servizio nelle modalità tradizionali. 

Nell’allegato “A” del presente documento sono descritti i flussi procedurali nell’ambito del 

Processo Civile Telematico (configurazione 1), nell’allegato “B” sono istanziate le procedure 

riguardanti quegli uffici che non gestiscono in modo automatizzato gli oggetti scambiati 

nell’ambito del processo di pagamento (configurazione 2 e 3). 

Il flusso procedurale descritto nel presente documento è applicabile a tutti i servizi erogati dal 

Ministero della Giustizia: a titolo di esempio, si cita il pagamento per diritti di copia, dei diritti di 

cancelleria, del contributo unificato, ecc. 

ARCHITETTURA LOGICO FUNZIONALE DEL PAGAMENTO DELLE SPESE 

DI GIUSTIZIA 

Secondo quanto raffigurato nella Figura 2, in cui è rappresentata l’architettura del sistema, le 

modalità individuate per effettuare i pagamenti delle spettanze dovute sono sostanzialmente due. 

La principale prevede che il soggetto abilitato (tipicamente un avvocato) possa utilizzare il Portale 

dei Servizi Telematici del Ministero, in corso di progettazione e presumibilmente attivo a partire 




dal primo semestre 2011, per accedere ai servizi di pagamento attraverso l’interconnessione tra la 

rete SPC ed il sistema dei pagamenti. 

La modalità alternativa si esplica attraverso un collegamento diretto tra il Punto di Acceso (PdA) e 

l’infrastruttura che si pone come Front-End verso gli l’erogatori dei servizi di pagamento. 

Figura 2 – Architettura logico funzionale 

Come indicato nello schema di Figura 2, di seguito sono evidenziate le componenti che 

interagiscono tra di loro per fornire il servizio di pagamento telematico: 

• Punto di Acceso (PdA): definisce la struttura tecnico-organizzativa che fornisce la 

connessione ai servizi erogati nell’ambito del PCT, ovvero servizi a valore aggiunto (es. 

pagamento telematico). I Punti di Accesso sono autorizzati dal Ministero. Ai fini della 

presente iniziativa, il PdA effettua l’autenticazione degli utenti ed è collegato con il Front- 

End SP, instaurando pertanto un rapporto diretto tra l’utente esterno e il sistema dei 

pagamenti. Il pagamento delle somme di cui in premessa non è infatti un servizio offerto dal 

sistema giustizia; 

• Portale dei Servizi Telematici del Ministero: struttura gestita dal Ministero della Giustizia 

che può essere logicamente suddivisa in due sottosistemi: 

il primo (Portale) eroga i servizi nei confronti dei privati, in parte funzionalmente 

equivalenti a quelli forniti da un PdA; le interazioni con il sistema dei pagamenti 

avvengono attraverso la rete SPC; 




il secondo (Servizi Telematici) consente la gestione di alcuni oggetti prodotti nel 

processo di pagamento attraverso appositi servizi (web services) allo scopo messi a 

disposizione (vedi capitolo successivo); 

• Soggetto abilitato: persona fisica che, attraverso opportune procedure, viene riconosciuta 

dal PdA o dal Portale ed abilitata ad usufruire dei servizi da questi erogati, compreso il 

pagamento delle spese di giustizia; 

• Sistema Pubblico di Connettività (SPC): “l’insieme di infrastrutture tecnologiche e di 

regole tecniche per lo sviluppo, la condivisione, l’integrazione e la diffusione del 

patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare 

l’interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e 

dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la 

salvaguardia e l’autonomia del patrimonio informativo di ciascuna pubblica 

amministrazione" (art.73, comma 2 del CAD); 

• Sistema dei Pagamenti (SP): infrastruttura del sistema finanziario costituta dall’insieme di 

tutti gli strumenti con i quali possono essere acquistati beni e servizi nell’economia, nonché 

dalle attività e dagli intermediari che consentono l’effettivo trasferimento di tali strumenti 

da un operatore ad un altro (fonte: Banca d’Italia); 

• Prestatore dei servizi di Pagamento (Psp): gli istituti di credito, Poste Italiane o altri 

soggetti abilitati che, ai sensi della normativa vigente e nell’ambito del Sistema dei 

Pagamenti, mettono a disposizione degli utenti gli strumenti atti ad effettuare il pagamento 

richiesto; 

• Front-End con il Sistema dei Pagamenti (FESP): componente infrastrutturale 

(middleware) atto a facilitare lo scambio di informazioni tra i soggetti attraverso la 

condivisione dei protocolli di colloquio (sia applicativi, che di trasporto), l’erogazione di 

eventuali servizi aggiuntivi, tra cui la firma digitale dei documenti scambiati. Tale 

componente può essere specifico per ognuno dei diversi soggetti Prestatori di Servizio, 

oppure a fattor comune tra più Prestatori di Servizio. 

• Nodo PA 2 : infrastruttura condivisa all’interno del SPC che, oltre a svolgere le funzioni 

previste per il FESP, costituisce il nodo che colloquia con i prestatori dei servizi di 

pagamento (Psp) e fornisce le funzioni di Certification Authority (CA) quale terza parte 

fidata (trusted third party) abilitata a rilasciare certificati digitali. 

IL PROCESSO DI PAGAMENTO DELLE SPESE DI GIUSTIZIA 

In questo capitolo saranno analizzati i requisiti e le regole di colloquio individuate per gestire il 

processo di pagamento. 

REQUISITI PRINCIPALI DEL PROCESSO DI PAGAMENTO 

I requisiti di seguito esposti esplicitano le necessità utente associate al processo di pagamento dei 

spettanze previste dalla normativa, operazione da effettuare in via telematica, con lo scopo di 

ricevere la ricevuta attestante il versamento sempre attraverso lo stesso canale telematico. 

2 In altri contesti denominato “HUB dei Pagamenti” ovvero “Nodo degli Incassi” 


SICUREZZA 



Le interazioni tra le varie componenti sopra descritte avvengono attraverso un canale sicuro. 

Nel caso in cui l’interazione avvenga tramite la rete SPC, il requisito è garantito dalla natura 

‘riservata’ della rete; in questo caso l’utilizzo della rete SPC può essere diretto qualora il prestatore 

di servizi sia Poste Italiane, già attestata su SPC, mentre nel caso di un istituto di credito, il flusso 

può utilizzare l’infrastruttura che connette il sistema pubblico con la rete degli istituti bancari 

(interconnessione tra reti “sicure”). 

Nel caso in cui si utilizzi una connessione diretta tra il PdA e il Front-End del sistema dei 

pagamenti (FESP), il requisito è ottenuto attraverso l’adozione di protocolli sicuri che realizzano 

una Virtual Private Network sul livello di trasporto internet. 

In tutti i casi, il colloquio tra le macchine avviene attraverso l’utilizzo di certificati “server” 

rilasciati da Certification Authorities qualificate. 

AUTENTICAZIONE TRA I SOGGETTI 

L’autenticazione dell’utente avvocato avviene al momento della connessione al PdA (a carico del 

fornitore di servizi PdA o del Ministero della Giustizia nel caso in cui l’accesso avvenga tramite 

Portale) ed è del tipo CNS-like, assicurando quindi una “autenticazione a più fattori” (o strong 

authentication). 

Il presente requisito consiste nella “concessione di fiducia” (trust) da parte del Front-End SP 

(FESP) circa l’autenticazione del soggetto abilitato (tipicamente un avvocato) operata dal PdA 

(ovvero dal Portale). 

Il circuito di trust è evidenziato nello schema di Figura 3, dove il colloquio tra FESP e Psp è basato 

su un’autenticazione reciproca tra macchine. 

Per il completamento del processo di pagamento da parte del prestatore del servizio (Psp), questi 

può richiedere al soggetto abilitato di autenticarsi sul proprio sistema attraverso l’immissione delle 

credenziali allo scopo rilasciate per l’utilizzo di detto servizio. 

Figura 3 - Autenticazione tra i soggetti del processo di pagamento e circuito di trust 

PROFILAZIONE AUTOMATICA 

Il processo deve permettere di trasferire in modo automatico il profilo utente sul Front-End SP 

(FESP), una volta riconosciuti ed autenticati gli utenti stessi da parte del PdA/Portale (generalità 

dell’avvocato - con tutti gli attributi a lui associati in quanto cliente del servizio di pagamento – 

abilitazione al servizio, circuiti di pagamento disponibili, ecc). 




Una sola volta, alla prima richiesta di accesso ai servizi di pagamento, il FESP potrebbe richiedere 

all’utente una serie di ulteriori informazioni necessarie a completarne il profilo. 

SCELTA DELLA MODALITÀ DI PAGAMENTO 

Il processo deve consentire all’avvocato la possibilità di scegliere tra le diverse modalità di 

pagamento che lo stesso ha a disposizione in funzione del suo profilo (strumenti diversi associati ad 

uno stesso prestatore di servizio o strumenti associati a una molteplicità di prestatori di servizio. Es. 

bollettino, bonifico da uno o più conti aperti nei confronti di banche differenti) . 

CERTEZZA DEL PAGAMENTO 

La ricevuta telematica restituita all’avvocato a fronte del pagamento effettuato in via telematica 

deve costituire garanzia del trasferimento dell’importo versato sul conto corrente intestato alla 

Tesoreria dello Stato. 

I versamenti in Tesoreria previsti dalla normativa vigente possono essere effettuati in modalità 

telematica tramite bollettino postale o bonifico. 

Nel caso del bollettino postale la certezza del pagamento è immediata in quanto costituisce 

pagamento in c.d. “pro soluto” per il beneficiario. 

Nel caso di bonifico (bancario o postale), in base al DM MEF del 9 ottobre 2006 n.293 

“Regolamento recante norme per l'introduzione di nuove modalità di versamento presso le tesorerie 

statali”, la ricevuta può essere rilasciata (ed è liberatoria) dal momento in cui l’importo è addebitato 

sul conto dello stesso. 

In tal caso il prestatore di servizi di pagamento dovrà garantire, attraverso apposita convenzione / 

clausole contrattuali con il richiedente, l’adozione di procedure che permettano l’addebito 

immediato della somma sul conto del loro cliente (senza che questo modifichi le modalità di 

trasferimento della somma sul conto della Tesoreria dello Stato). 

UNIVOCITÀ DEL PAGAMENTO 

Il processo deve conferire certezza circa l’univocità del pagamento rispetto al servizio richiesto a 

Giustizia; in altre parole, non deve essere possibile riutilizzare la stessa ricevuta a fronte di 

richieste di servizio diverse. 

Nel presente documento vengono disciplinati tre ‘oggetti’, Richiesta Pagamento Telematico, 

Ricevuta Telematica, e un identificativo univoco di erogazione servizio che permettono al sistema 

di cancelleria di verificare che la Ricevuta Telematica non sia stata già utilizzata (vedi capitolo 

“Regole di colloquio per il processo di pagamento”) 

RIMBORSO DEL PAGAMENTO 

Nel caso di somme erroneamente versate, si può procedere alla richiesta di rimborso secondo le 

modalità tradizionali previste dalla legge. Nel caso di versamento tramite bonifico, il diritto al 

rimborso è disciplinato e previsto dal Decreto del 9/10/2006 “Regolamento recante norme per 

l’introduzione di nuove modalità di versamento presso le tesorerie statali” (art. 4). 

UNIFORMITÀ 

Le regole di interazione con i Prestatori di servizi di Pagamento, più avanti dettagliate, devono 

poter valere per ogni fattispecie di pagamento, quindi sia nel caso di servizi automatici (es. rilascio 

on-line di copie elettroniche di atti informatici) sia nel caso in cui per l’erogazione del servizio sia 

necessario l’intervento di un Cancelliere (es. iscrizione a ruolo di un procedimento civile). 




REGOLE DI COLLOQUIO PER IL PROCESSO DI PAGAMENTO 

L’interazione tra la postazione dell’avvocato che richiede di effettuare un pagamento ed il 

Prestatore dei Servizi di Pagamento avviene attraverso lo scambio di oggetti contenenti le 

informazioni necessarie a garantire i requisiti sopra indicati. 

Ai fini di questa interazione, l’avvocato potrà utilizzare il Punto di Acceso (PdA) ovvero il Portale 

del Ministero della Giustizia, a seconda delle modalità prescelte dall’avvocato stesso; nel prosieguo 

del documento indicheremo il punto di attivazione dell’interazione con PdA/Portale. 

OGGETTI SCAMBIATI 

Gli oggetti scambiati tra il soggetto abilitato ed il prestatore di servizi di pagamento sono costituiti 

da file xml le cui principali informazioni sono riportate in 

Allegato “C” - Protocollo sulle regole tecniche e lo standard per l’emissione dei documenti 

informatici. 

La Richiesta pagamento telematico (RPT) è costituita da una struttura standardizzata che: 

a) definisce gli elementi necessari a caratterizzare i pagamenti comuni a tutte le PA, in 

particolare qualifica il versamento con un identificativo univoco versamento; 

b) contiene i dati identificativi, variabili a seconda dell’operazione per cui è richiesto il 

pagamento; 

c) contiene una parte riservata (Dati Specifici Riscossione) per inserire informazioni 

elaborabili automaticamente dai sistemi della PA che eroga il servizio; 

d) può essere firmata digitalmente, ovvero con firma elettronica qualificata, o meno dal 

soggetto pagatore, a seconda degli accordi intercorsi con il Prestatore di Servizi di 

Pagamento (Psp) o con il gestore della componente architetturale FESP. 

La Ricevuta Telematica (RT), restituita al richiedente a fronte di una RPT, è costituita da una 

struttura standardizzata che: 

a) definisce gli elementi necessari a qualificare il pagamento, tra cui un identificativo 

univoco del pagamento; 

b) trasferisce inalterate le stesse informazioni ricevute in ingresso (RPT) relative alla parte 

riservata (Dati Specifici Riscossione) a disposizione della PA; 

c) è firmata digitalmente ovvero con firma elettronica qualificata dal soggetto che effettua la 

riscossione (Psp) o da un componente del sistema (FESP) in grado di attestare l’avvenuto 

pagamento sulla base degli esiti forniti dal Psp e nel rispetto del requisito “Certezza del 

Pagamento”. 

Firma digitale degli oggetti scambiati 

La necessità di firmare digitalmente il documento Ricevuta Telematica è motivata dal requisito di 

certezza del pagamento connesso all’integrità e non ripudiabilità del documento stesso. 

Allo scopo di consentire la firma digitale del documento Ricevuta Telematica, tra le funzioni messe 

a disposizione dal Nodo PA sarà istituita un’apposita Certification Authority che, a tal fine, 

provvederà ad emettere certificati digitali intestati agli operatori attivi nel circuito, aventi come 

estensione Key usage impostata a nonRepudiation; tale Certification Authority potrebbe emettere 

anche certificati server necessari alla mutua autenticazione degli operatori del circuito, di cui al 

requisito “Sicurezza”. 




In via transitoria, con l’obiettivo di semplificare la fase di sperimentazione del sistema proposto, il 

documento Ricevuta Telematica potrà essere firmato dal PdA o dal FESP con certificati generati 

internamente, in quanto il requisito essenziale è quello della integrità della RT. 

Versamenti multipli 

Nell’ambito dei servizi offerti dal Ministero possono essere richiesti versamenti multipli a fronte di 

un'unica operazione, come, ad esempio, l’iscrizione a ruolo di un procedimento per il quale è 

dovuto il contestuale versamento del corrispettivo relativo al contributo unificato ed alle spese di 

notifica (art.30 D.P.R. 30 maggio 2002, n.115). 

Allo scopo di gestire questa fattispecie, l’oggetto RPT (Richiesta pagamento telematico) è 

strutturato per contenere i dati relativi a più versamenti (sino ad un massimo di 5). Pertanto, 

nell’esempio sopra menzionato di iscrizione a ruolo di un procedimento, un versamento sarà 

destinato al contributo unificato, mentre l’altro verrà utilizzato per il pagamento delle spese di 

notifica. 

A fronte di un oggetto RPT strutturato come sopra, il FESP deve emettere comunque un unico 

oggetto RT (Ricevuta Telematica) che attesti il versamento di tutte le somme richieste. 

REPOSITORY RICEVUTE TELEMATICHE (RRT) 

Nell’ambito del dominio Giustizia sarà configurato un sottosistema centralizzato per la gestione di 

tutte le Ricevute Telematiche prodotte nel processo di pagamento delle spese di giustizia, 

sottosistema denominato RRT (Repository Ricevute Telematiche). 

Tale repository, in cui saranno memorizzate le ricevute derivanti da un pagamento telematico, sarà 

accessibile, a tutte le applicazioni e/o sistemi interessati operanti nel dominio Giustizia e ai PdA, 

attraverso appositi servizi (web services allo scopo messi a disposizione) per: 

a. inserimento dell’oggetto RT nel repository RRT; 

b. esibizione dell’oggetto RT a richiesta del soggetto abilitato (versante, Cancelliere); 

c. annullamento dell’entità identificativo univoco di erogazione servizio (CRS, vedi apposito 

paragrafo più avanti), a seguito di una richiesta automatica delle applicazioni ovvero da 

parte di transazioni attivate dalle cancellerie. 

La verifica della firma dell’oggetto RT, necessaria per attestarne l’integrità, è un controllo che 

viene eseguito al momento del deposito della RT nel repository e al momento dell’esibizione a 

richiesta del soggetto esterno. 

IDENTIFICATIVO UNIVOCO DI EROGAZIONE DEL SERVIZIO (CRS) 

Al fine di qualificare in maniera univoca il versamento, viene definito l’entità identificativo 

univoco di erogazione servizio (CRS) che individua univocamente una richiesta di erogazione 

servizio da parte dei sistemi informatici della Giustizia ed è associato all’elemento 

identificativoUnivocoVersamento, sia nella Richiesta Pagamento Telematico (RPT), che nella 

Ricevuta Telematica (RT). 

Il CRS emesso a fronte di una richiesta di pagamento deve essere comunicato all’utente e 

costituisce l’elemento attraverso il quale lo stesso può eseguire eventuali controlli e verifiche 

relativi all’erogazione del servizio ed al pagamento. 

La politica di emissione e di gestione (controllo e annullamento) del CRS da parte dei sistemi 

informatici della Giustizia garantisce il requisito di Univocità del pagamento. 




Emissione del CRS 

Il CRS è generato dalla componente Servizi Telematici, su richiesta del PdA/Portale e rilasciato 

attraverso un servizio sincrono (chiamata web-service) esposto dallo stesso componente. 

La configurazione del CRS utilizzato per il pagamento delle spese di giustizia assume il formato 

specificato nel par. “Composizione del CRS nei pagamenti della giustizia” all’interno dell’Allegato 

“D” - Struttura dell’elemento “Identificativo Univoco Versamento”. 

Il CRS viene inserito nella struttura RPT (elemento identificativoUnivocoVersamento) e ritorna 

inalterato al PdA/Portale all’interno della RT. 

Controllo e annullamento del CRS 

Nella fase di gestione della RT, la funzionalità di controllo del pagamento preleva il CRS (presente 

nell’elemento identificativoUnivocoVersamento) e verifica che: 

• il codice sia stato generato per un servizio che quel sistema può erogare (in funzione del 

per la definizione del quale si rimanda al citato paragrafo 

“Composizione del CRS nei pagamenti della giustizia”); 

• il formato del CRS sia corretto (verifica delle cifre di controllo contenute nel CRS per la 

definizione del quale si rimanda a citato paragrafo “Composizione del CRS nei pagamenti 

della giustizia”) 

• il CRS non sia stato già utilizzato tramite un’altra Ricevuta Telematica; tale controllo è 

gestito per mezzo di un database delle CRS già ricevute tramite RT per il quale 

l’inserimento di un nuovo CRS nel database equivale all’annullamento dello stesso CRS 3 . 

La funzionalità di controllo e annullamento del CRS può essere implementata in modalità 

centralizzata nell’ambito del repository RRT e invocata dai sistemi erogatori del servizio tramite 

web service oppure essere implementata in modalità ‘distribuita’ nell’ambito dei singoli sistemi 

erogatori del servizio. Le informazioni contenute nel CRS rendono efficaci e sicure entrambe le 

modalità di implementazione della fase di controllo e annullamento del CRS. 

PROCESSO DI INTERAZIONE NEL PAGAMENTO TELEMATICO 

Il processo di interazione nell’ambito del pagamento telematico è schematizzato in Figura 4, dove 

RPT.xml ed RT.xml individuano, rispettivamente, la richiesta e la ricevuta di pagamento. 

I passi previsti per detto processo sono pertanto i seguenti: 

1. Scelta del canale di pagamento e richiesta di accesso al servizio: il PdA/Portale consente 

all’utente di scegliere il canale di pagamento (messa a disposizione di più FESP: CBI, 

Poste, altro), quindi: 

a. richiede la generazione del CRS alla componente Servizi Telematici; 

b. inserisce il CRS così ottenuto nell’informazione identificativoUnivocoVersamento 

della RPT; 

c. invia la richiesta di pagamento (RPT) al FESP prescelto; 

3 In fase di implementazione ed allo scopo di distribuire le elaborazioni tra le varie componenti del sistema, si potrebbe 

optare per una soluzione in cui il controllo e l’annullamento dei CRS venga effettuato direttamente da ogni singolo 

Sistema Gestore che implementerà solo la lista dei CRS a lui destinati (in funzione del ). 




2. Riconoscimento del pagatore e scelta delle modalità di pagamento: il FESP riconosce il 

pagatore sulla base delle informazioni contenute nella RPT (“trust” al PdA/Portale) e 

consente all’utente, se previsto dai protocolli di interazione tra PdA e FESP, di scegliere le 

modalità di pagamento a lui riservate (con eventuale re-indirizzamento, se previsto dai 

protocolli di interazione tra PdA e FESP); 

3. Richiesta di esecuzione pagamento: il FESP elabora, predispone, invia, ovvero inoltra, la 

richiesta di pagamento (che può essere costituita dalla stessa RPT) 4 al Psp secondo i 

requisiti da quest’ultimo richiesti; 

4. Esecuzione del pagamento: il Psp elabora la richiesta, esegue il pagamento e predispone 

l’esito (che può essere costituito anche dalla Ricevuta Telematica RT) 4 e lo invia al FESP. 

5. Rilascio della ricevuta: il FESP riceve dal Psp l’esito del pagamento (risposta alla 

richiesta), predispone ed invia, ovvero inoltra, al PdA (ovvero al Portale) la RT . Qualora il 

FESP provveda a predisporre la RT, avente le caratteristiche riportate al punto precedente, 

sarà cura di quest’ultimo firmare digitalmente il documento; 

6. Inoltro Ricevuta e suo inserimento nel repository RRT: Il PdA (ovvero il Portale) riceve 

la RT dal FESP e: 

a. se l’esito del pagamento è positivo, provvede a inserire la stessa nel repository RRT 

(Repository Ricevute Telematiche) attraverso un apposito servizio (web service) 

esposto dalla componente Servizi Telematici; qualora l’inserimento non andasse a 

buon fine sarà cura del PdA/Portale esperire tutte le azioni necessarie al corretto 

completamento dell’attività; 

b. in ogni caso, provvede a inoltrare ovvero mettere a disposizione dell’utente la RT 

stessa, per quietanza e per gli usi consentiti dalle procedure della Giustizia. 

4 Qualora lo prevedano gli accordi intervenuti con il FESP. 




7. Figura 4 - Flusso del processo di pagamento telematico 

Il processo di erogazione del servizio è on-line e può essere sincrono o asincrono come meglio 

specificato nei successivi paragrafi. 

Il middleware FESP 

Nella descrizione del processo si evidenzia la presenza di un componente di middleware (FESP 

ovvero Front-End SP) che implementa le logiche di elaborazione della richiesta di pagamento 

(scelta modalità di pagamento, impacchettamento e invio richiesta di pagamento, spacchettamento 

e ricezione della ricevuta, firma digitale, ecc.) che potrebbero non essere implementate nei sistemi 

offerti dai prestatori di servizi (Psp). 

Dal punto di vista della loro collocazione nell’infrastruttura tecnologica, le funzioni espletate dal 

componente FESP, potrebbero essere: 

• integrate nel PdA (ovvero nel Portale); 

• integrate nel sistema offerto dal prestatore di servizi di pagamento (Psp); 

• messe a disposizione da una parte terza, per conto di più prestatori di servizi di pagamento; 

• condivise (anche da più di un’amministrazione) essendo messe a fattor comune nell’ambito 

dell’infrastruttura di sistema della pubblica amministrazione (Nodo PA all’interno di SPC). 

Le modalità tecniche di interazione (definizione del client e del server) tra il FESP e il 

PdA/Portale, sono definite da specifici accordi tra le parti (“Protocollo di colloquio” pubblicato a 

cura del FESP), nel rispetto delle regole indicate nel presente capitolo, in particolare con 

riferimento allo schema di Figura 4, dove le interazioni (frecce) in “giallo chiaro” indicano 

azioni/attività non obbligatorie e che quindi possono non essere presenti nel citato “Protocollo di 

colloquio”. 




Il processo descritto nel paragrafo precedente può essere sincrono ovvero asincrono relativamente 

ai livelli servizio erogati dal FESP, con riferimento al “Protocollo di colloquio” ed in particolare 

alle interazioni di cui ai punti 4 (Esecuzione del pagamento) e 5 (Rilascio della ricevuta). 

Il “Protocollo di colloquio” con il PdA/Portale, può prevedere l’effettuazione di più pagamenti a 

fronte di un unico accesso telematico alle funzioni messe a disposizioni dal FESP; in tal a caso sarà 

inviato un file RT.xml differente per ognuno dei pagamenti richiesti. 

È della massima importanza che il FESP garantisca che la Ricevuta Telematica (RT) sia “ben 

formata” soprattutto nel caso di processi automatizzati, come nel caso del PCT, per evitare che, in 

fase di validazione del file xml, la RT stessa sia rifiutata dal sistema di gestione dei registri di 

cancelleria. 




ALLEGATO “A” – FLUSSI PROCEDURALI DEL PCT INTEGRATI CON IL 

PROCESSO DI PAGAMENTO 

Vengono di seguito riportate a titolo esemplificativo le istanze delle due procedure utilizzate 

nell’ambito del Processo Civile Telematico (Rilascio di copie semplici e Iscrizione a ruolo) che 

utilizzano e integrano il processo di pagamento, così come descritto nei capitoli precedenti. 

Ai requirements del processo di pagamento già illustrati, si aggiunge, nelle interazioni relative al 

PCT, l’ulteriore requisito Integrazione che prevede che le applicazioni client, operative presso gli 

studi degli avvocati piuttosto che presso i punti di accesso, debbono essere in grado di integrare le 

procedure di pagamento telematico offerte dai prestatori di servizi di pagamento, rendendo 

all’utente un servizio unico e (appunto) integrato. 

RILASCIO DI COPIE SEMPLICI O AUTENTICHE 

La richiesta ed il rilascio delle copie avviene tendenzialmente on-line. 

Figura 5 - Flusso relativo al rilascio di copie semplici 

Il servizio di gestione del pagamento è schematizzato nella Figura 5 dove RPT.xml ed RT.xml 

individuano, rispettivamente, la richiesta e la ricevuta di pagamento: 

1) l’utente accede al Punto di Accesso (ovvero al Portale) con autenticazione forte; 




2) l’utente accede in consultazione al procedimento per i quali è autorizzato ed individua i 

documenti (o le singole pagine) di cui richiedere copia. Attraverso il PdA/Portale l’utente 

inoltra la richiesta di copia al servizio di Richiesta & Gestione Copie, accessibile, che: 

a. calcola l’importo da corrispondere, in modo automatico o per mezzo dell’intervento del 

Cancelliere 5 

b. associa alla richiesta un identificatore univoco (idRichiestaCopie); 

3) l’utente tramite PdA/Portale attiva il processo di interazione con i sistemi di pagamento 

descritto in precedenza ed invia la richiesta di pagamento RPT al FESP; 

4) il Front-End-SP (FESP) elabora il file xml e, al termine dell’operazione di pagamento, 

restituisce la Ricevuta Telematica (RT) firmata digitalmente; 

5) il PdA/Portale riceve la RT e, se l’esito del pagamento è positivo, provvede a inserire la stessa 

nel repository RRT attraverso un apposito servizio (web service) esposto dalla componente 

Servizi Telematici; in ogni caso il PdA/Portale inoltra ovvero mette a disposizione dell’utente 

l’esito del pagamento; 

6) il sistema di Gestione & Richiesta Copie mette a disposizione una apposita interfaccia utente 

che consente all’utilizzatore di perfezionare la richiesta della copia associando la RT, fornita 

dal PdA/Portale, all’identificatore univoco della richiesta (idRichiestaCopie) di cui al punto 

2)b; 

7) il servizio di Gestione & Richiesta Copie provvede all’annullamento del CRS, attraverso un 

apposito servizio (web service) esposto dalla componente Servizi Telematici, e rilascia 

all’utente la copia richiesta, automaticamente o attraverso l’intervento del cancelliere. La copia 

è inviata via PEC o, nei casi di presenza di dati sensibili, sarà fornita all’utente l’indicazione 

per scaricare direttamente la copia. 

Il servizio può essere sincrono ovvero asincrono, a seconda dei livelli di servizio erogati dai vari 

FESP e a seconda del tipo di copia richiesta. 

Nella Figura 5 non sono state indicate, per semplicità di rappresentazione, le interazioni tra FESP e 

Psp, nonché quelle tra soggetto abilitato e FESP, tra soggetto abilitato e Psp e tra Pda/Portale e 

FESP che nel flusso del processo di pagamento di Figura 4 sono indicati come eventuali e 

peculiari, in funzione degli accordi tra le varie controparti. 

ISCRIZIONE A RUOLO 

Il pagamento del contributo unificato (e della marca da bollo di 8 €, tuttora prevista) avviene in un 

momento antecedente rispetto all’iscrizione a ruolo vera e propria; quest’ultima viene effettuata dal 

Cancelliere, previo accertamento dell’avvenuto pagamento. 

Il servizio di gestione del pagamento è schematizzato in Figura 6, dove RPT.xml ed RT.xml 

individuano, rispettivamente, la richiesta e la ricevuta di pagamento: 

1) l’avvocato predispone l’atto introduttivo con il suo redattore o software di studio ed accede al 

punto di accesso (o al Portale) con autenticazione forte; 

5 Tale richiesta di copia, per poter essere elaborata dal sistema o, nei casi previsti, dal cancelliere dovrà essere 

completata con la RT 




2) l’utente tramite PdA/Portale attiva il processo di interazione con i sistemi di pagamento 








5) se l’esito del pagamento è positivo, l’avvocato inserisce la Ricevuta Telematica (RT) all’interno 

della busta e la spedisce via PEC, secondo le modalità stabilite; 

6) il Sistema Gestore elabora la busta contenente anche la Ricevuta Telematica (RT) (e mostra i 

risultati al Cancelliere, che effettua il controllo sull’importo e procede all’iscrizione a ruolo 

annullando contestualmente il CRS, attraverso un apposito servizio (web service) esposto dalla 

componente Servizi Telematici. 

La richiesta di iscrizione a ruolo avviene con modalità asincrona in quanto eseguita tramite Posta 

elettronica certificata (PEC). 

Figura 6 - Flusso relativo all'iscrizione a ruolo 

Anche in Figura 6 non sono state indicate, per semplicità di rappresentazione, le interazioni tra 

FESP e Psp, nonché quelle tra soggetto abilitato e FESP, tra soggetto abilitato e Psp e tra 

Pda/Portale e FESP che nel flusso del processo di pagamento di Figura 4 sono indicati come 

eventuali e peculiari, in funzione degli accordi tra le varie controparti. 




ALLEGATO “B” – FLUSSI PROCEDURALI NELLA GESTIONE NON 

INTEGRATA DEI PAGAMENTI TELEMATICI 

Sulla base di quanto analizzato nei capitoli precedenti risulta evidente che il pagamento del 

corrispettivo dovuto e la relativa richiesta di erogazione del servizio rappresentano per l’utente 

momenti logicamente distinti, pertanto in questo capitolo saranno descritte le interazioni relative ai 

pagamenti eseguiti dagli utenti in via telematica laddove l’Ufficio giudiziario non sia in grado di 

gestire l’intero ciclo attraverso lo stesso canale. 

In particolare si fa riferimento allo schema di Figura 1 ed ai casi nei quali tra l’Ufficio Giudiziario 

e l’utente non sia attivo alcun flusso telematico (cfr configurazione 3 a pagina 10) ovvero tali 

funzionalità siano parzialmente attivate, cioè l’Ufficio giudiziario sia in grado di gestire flussi 

telematici, ma non abbia la gestione informatizzata della ricevuta (cfr configurazione 2 a 10). 

In tali ipotesi, un processo che utilizzi il CRS emesso dalla componente Servizi Telematici, 

associato in maniera univoca al pagamento, nonché l’esistenza del repository RRT supporta 

l’utilizzo della Ricevuta Telematica (RT). 

Infatti l’utente potrà procedere al pagamento telematico grazie al servizio offerto da un PdA ovvero 

dal Portale e successivamente presentare l’attestazione del pagamento presso l’Ufficio giudiziario 

che potrà verificare l’attendibilità dello stesso e l’effettivo versamento delle somme collegandosi al 

repository RRT per mezzo del riferimento univoco rappresentato dal CRS. 

RILASCIO DI COPIE SEMPLICI O AUTENTICHE 

Nella Figura 7 è riportato lo schema di interazione del pagamento telematico per il servizio di 

“Rilascio di copie semplici o autentiche” nel quale l’Ufficio giudiziario è in grado di gestire flussi 

telematici, ma non possiede la capacità di gestire informaticamente la ricevuta (cfr configurazione 

2 a pagina 10): 

1) l’utente accede al Punto di Accesso (ovvero al Portale) con autenticazione forte; 

2) l’utente accede in consultazione al procedimento per i quali è autorizzato ed individua i 

documenti (o le singole pagine) di cui richiedere copia. Inoltra la richiesta di copia al servizio 

di Richiesta & Gestione Copie, accessibile attraverso il PdA/Portale, che calcola l’importo da 

corrispondere, in modo automatico o per mezzo dell’intervento del Cancelliere; 

3) l’utente, tramite PdA/Portale, attiva il processo di interazione con i sistemi di pagamento 








6) l’utente, dopo aver ricevuto la RT si reca presso l’Ufficio giudiziario portando con se la copia 

cartacea della RT stessa (stampata da PdA/Portale) o anche solo il riferimento al CRS 

(comunicatogli dal PdA/Portale); 




7) il Cancelliere si collega al repository RRT per visualizzare la ricevuta di pagamento ed 

eseguire il controllo della firma, annullare il CRS nel momento in cui eroga il servizio e 

stampare una copia della ricevuta telematica in formato leggibile. 

Rispetto all’analogo flusso dello schema di Figura 5, le variazioni riguardano i passi dal 6 in poi. 

Nella Figura 7 non sono state indicate, per semplicità di rappresentazione, le interazioni tra FESP e 

Psp, nonché quelle tra soggetto abilitato e FESP, tra soggetto abilitato e Psp e tra Pda/Portale e 

FESP che nel flusso del processo di pagamento di Figura 4 sono indicati come eventuali e 

peculiari, in funzione degli accordi tra le varie controparti. 

Figura 7 - Flusso relativo al rilascio di copie semplici (non integrato) 

Con riferimento al punto 7, deve essere definita una procedura tecnico-organizzativa che consenta, 

con le cautele necessarie ed in casi eccezionali, di rimuovere eventuali errori di annullamento del 

CRS. 

Il servizio di pagamento può essere sincrono ovvero asincrono relativamente all’interazione di cui 

al punto 4, a seconda dei livelli di servizio erogati dai vari FESP. 

ISCRIZIONE A RUOLO 

Nella Figura 8 è riportato lo schema di interazione del pagamento telematico per il servizio di 

“Iscrizione a ruolo” nel quale l’Ufficio giudiziario non è grado di gestire interazioni telematiche 

con gli utenti (cfr configurazione 3 a pagina 10): 

1) l’utente accede al PdA/Portale con autenticazione forte e attiva il descritto processo di 

interazione con i sistemi di pagamento inviando la richiesta di pagamento RPT al FESP; 










4) l’utente, se l’esito del pagamento è positivo, stampa la copia cartacea della RT messa a 

disposizione dal PdA/Portale o anche solo il riferimento al CRS (comunicatogli dal 

PdA/Portale) e si reca presso l’Ufficio giudiziario; 

5) il Cancelliere si collega al repository RRT per visualizzare la ricevuta di pagamento ed 

eseguire il controllo della firma, annullare il CRS nel momento in cui eroga il servizio 

(iscrizione a ruolo) e stampare una copia della ricevuta telematica in formato leggibile. 

Figura 8 - Flusso relativo all'iscrizione a ruolo (non integrato) 

Con riferimento al punto 5, deve essere definita una procedura tecnico-organizzativa che consenta, 

con le cautele necessarie ed in casi eccezionali, di rimuovere eventuali errori di annullamento del 

CRS. 

Il servizio di pagamento può essere sincrono ovvero asincrono relativamente all’interazione di cui 

al punto 2, a seconda dei livelli di servizio erogati dai vari FESP. 




ALLEGATO “C” - PROTOCOLLO SULLE REGOLE TECNICHE E LO 

STANDARD PER L’EMISSIONE DEI DOCUMENTI INFORMATICI 

PREMESSA 

Oggetto del presente allegato sono i documenti informatici che costituiscono la rappresentazione 

informatica delle informazioni che dovranno essere scambiati nell’ambito di processi di pagamento 

on-line di somme versate favore di un ente pubblico. 

Per le sigle adottate e le convenzioni utilizzate si rimanda al documento “Pagamenti telematici 

della Giustizia – specifiche versione 5.0”. 

Le informazioni scambiate nel processo di pagamento telematico sono: 

- la Richiesta Pagamento Telematico (RPT) 

- la Ricevuta Telematica (RT). 

FORMATO DEI MESSAGGI 

I formati adottati devono possedere almeno i seguenti requisiti: 

- consentire, nei diversi ambiti di applicazione e per le diverse tipologie di trattazione, 

l'archiviazione, la leggibilità, l'interoperabilità e l’interscambio dei messaggi ; 

- la non alterabilità dei messaggi durante le fasi di accesso; 

- la possibilità di effettuare operazioni di ricerca tramite indici di classificazione o di 

archiviazione; 

- l'immutabilità del contenuto e della sua struttura. A tale fine i messaggi non devono 

contenere macroistruzioni o codice eseguibile, tali da attivare funzionalità che possano 

modificarne nel tempo la struttura o il contenuto. 

Al fine di garantire il rispetto del requisito di interoperabilità, si prevede una rappresentazione in 

formato xml. 

Dovranno essere definite strutture che ne consentano la validazione sia presso la PA che presso il 

Psp, relativamente alle fasi di generazione e di verifica formale dei messaggi. 

Le strutture rappresentano lo standard minimo a cui le PA e i Psp/FESP devono attenersi; il 

rigoroso rispetto dello standard minimo è indispensabile per garantire l’interoperabilità. 

Per la visualizzazione dei messaggi, devono essere adottate soluzioni che presentino le 

informazioni in modo fedele alla struttura. 

SOGGETTI 

Sono di seguito elencati i soggetti coinvolti nel processo di pagamento: 

a. Soggetto Versante: rappresenta l’entità (Persona Fisica o Giuridica) debitore di somme nei 

confronti della Pubblica Amministrazione; 

b. Soggetto Pagatore: rappresenta l’entità (Persona Fisica o Giuridica) che effettua il 

pagamento delle somme dovute; può coincidere con il Soggetto Versante; 




c. Ente Beneficiario: rappresenta la Pubblica Amministrazione creditrice, a qualsiasi titolo, di 

somme dovute dal Soggetto Versante; 

d. Istituto Attestante: rappresenta il Prestatore di Servizi di Pagamento (Psp) che effettua il 

pagamento richiesto e ne attesta la regolarità. 

ELENCO DEI DATI 

Sono di seguito elencati gli elementi che consentono la rappresentazione informatica dei messaggi. 

Le PA e i Psp che intendono scambiare ulteriori informazioni riguardanti la gestione dei processi o 

altre esigenze amministrative possono inserire ulteriori dati nei messaggi. 

RICHIESTA DI PAGAMENTO TELEMATICO (RPT) 

È il documento informatico predisposto dal soggetto Pagatore per richiedere all’Istituto Pagatore 

un pagamento a favore di un ente pubblico. 

Versione Oggetto 

Dominio 

Identificativo Dominio 

Identificativo Stazione Richiedente 

Identificativo Messaggio Richiesta 

Data Ora Messaggio Richiesta 

Soggetto Versante 

Identificativo Univoco Versante 

Tipo Identificativo Univoco 

Codice Identificativo Univoco 

Anagrafica Versante 

Indirizzo Versante 

Numero Civico Versante 

CAP Versante 

Località Versante 

Provincia Versante 

Nazione Versante 

e-mail Versante 

Soggetto Pagatore 

Identificativo Univoco Pagatore 



Anagrafica Pagatore 

Indirizzo Pagatore 




CAP Pagatore 

Numero Civico Pagatore 

Località Pagatore 

Provincia Pagatore 

Nazione Pagatore 

e-mail Pagatore 

Ente Beneficiario 

Identificativo Univoco Beneficiario 



Denominazione Beneficiario 

Codice Unità Operativa 

Denominazione Unità Operativa 

Indirizzo Ente Beneficiario 

Numero Civico Ente Beneficiario 

CAP Ente Beneficiario 

Località Ente Beneficiario 

Provincia Ente Beneficiario 

Nazione Ente Beneficiario 

Dati Versamento 

Data Esecuzione Pagamento 

Importo Totale da Versare 

Tipo Versamento 

Identificativo Univoco Versamento 

IBAN addebito 

BIC addebito 

Dati del Singolo Versamento 

Importo del Singolo Versamento 

IBAN accredito 

BIC accredito 

Credenziali Pagatore 

Causale Versamento 

Dati Specifici Riscossione 

Il documento può essere firmato digitalmente, ovvero con firma elettronica qualificata, o meno 

dal soggetto pagatore, a seconda degli accordi intercorsi con il Prestatore di Servizi di 




Pagamento (Psp) o con il gestore della componente architetturale FESP. 

RICEVUTA TELEMATICA (RT) 

È il documento informatico rilasciato a cura dell’organizzazione che effettua l’operazione di 

pagamento su mandato di un soggetto (Pagatore) in nome e per conto del soggetto Versante 

debitore di somme nei confronti di enti pubblici. 

Versione Oggetto 

Dominio 

Identificativo Dominio 

Identificativo Stazione Richiedente 

Identificativo Messaggio Ricevuta 

Data Ora Messaggio Ricevuta 

Riferimento Messaggio Richiesta 

Riferimento Data Messaggio 

Istituto Attestante 

Identificativo Univoco Attestante 



Denominazione Attestante 

Codice Unità Operativa Attestante 

Denominazione Unità Operativa Attestante 

Indirizzo Unità Operativa Attestante 

Numero Civico Unità Operativa Attestante 

CAP Unità Operativa Attestante 

Località Unità Operativa Attestante 

Provincia Unità Operativa Attestante 

Nazione Unità Operativa Attestante 

Ente Beneficiario 

Identificativo Univoco Beneficiario 



Denominazione Beneficiario 

Codice Unità Operativa 

Denominazione Unità Operativa 

Indirizzo Ente Beneficiario 

Numero Civico Ente Beneficiario 




CAP Ente Beneficiario 

Località Ente Beneficiario 

Provincia Ente Beneficiario 

Nazione Ente Beneficiario 

Soggetto Versante 

Identificativo Fiscale Versante 



Anagrafica Versante 

Indirizzo Versante 

Numero Civico Versante 

CAP Versante 

Località Versante 

Provincia Versante 

e-mail Versante 

Soggetto Pagatore 

Identificativo Univoco Pagatore 



Anagrafica Pagatore 

Indirizzo Pagatore 

Numero Civico Pagatore 

CAP Pagatore 

Località Pagatore 

Provincia Pagatore 

Nazione Pagatore 

e-mail Pagatore 

Dati Versamento (sino a 5 occorrenze) 

Codice Esito Pagamento 

Importo Totale Versato 

Identificativo Univoco Versamento 

Dati del Singolo Pagamento 

Singolo Importo Versato 

Esito Singolo Pagamento 

Data Esito Singolo Versamento 




Identificativo Univoco Riscossione 

Causale Versamento 

Dati Specifici Riscossione 

Il documento deve essere firmato digitalmente ovvero con firma elettronica qualificata dal 

Prestatore del Servizio (Psp) che rilascia il documento di attestazione pagamento o da un 

componente architetturale del sistema (FESP) in grado di attestare l’esito dei versamenti eseguiti 

dal soggetto che effettua la riscossione (Psp). 




NOTE ESPLICATIVE SULLE MODIFICHE ALLE INFORMAZIONI SCAMBIATE 

L’avvio della sperimentazione ed i conseguenti affinamenti di carattere applicativo, che tuttavia 

non modificano l’architettura del sistema ed i processi di interazione tra le varie componenti, 

hanno reso necessario introdurre, a partire dalla versione 5.1, alcuni non sostanziali cambiamenti 

nella composizione delle informazioni scambiate. 

VERSIONING 

Al fine di gestire in modo automatico, soprattutto per ciò che riguarda la gestione nel tempo 

dell’oggetto Ricevuta Telematica, la concomitanza di versioni relative agli oggetti scambiati, si è 

ritenuto opportuno inserire, sia nella Richiesta di Pagamento Telematica che nella Ricevuta 

Telematica, l’informazione Versione Oggetto che deve contenere la versione della RPT e RT 

utilizzate nel processo di interazione. 

L’informazione ha carattere descrittivo e non rappresenta un elemento che possa condizionare il 

rifiuto dell’ordine di pagamento. 

DOMINIO 

Stante l’architettura del sistema, che è articolata su varie tratte interconnesse, è stato necessario 

riordinare le informazioni contenute nella struttura Dominio allo scopo di poter meglio attribuire 

alle giuste provenienze le informazioni scambiate. Pertanto la struttura Dominio è stata riportata 

anche nella Ricevuta Telematica dove, nelle versioni precedenti, non era presente. 

Altra importante specificazione è stata quella relativa al dato Identificativo Dominio che, al posto 

di un generico valore (es.: PCT nelle versioni precedenti) dovrà riportare il codice fiscale della 

struttura che invia la richiesta di pagamento: nella fattispecie delle spese di giustizia potrà 

contenere il codice fiscale dell’amministrazione, ovvero quello del Punto di Accesso; in tale ottica 

la semantica del dato Identificativo Stazione Richiedente assume il valore di codice interno al 

richiedente, che lo può configurare come meglio crede. 

DATI VERSAMENTO 

Lo scopo di queste modifiche riguarda una migliore definizione delle informazioni relative ad ogni 

singolo pagamento, oltre alla possibilità di gestire meglio esiti di pagamento diversi a fronte di 

unica richiesta di erogazione servizio. 

In particolare sono stati inseriti all’interno delle occorrenze previste per la struttura Dati del 

Singolo Pagamento le informazioni, prima gestite a livello generale, quali la descrizione dell’esito 

(Esito Singolo Pagamento) ed alla data di esecuzione o di rifiuto del pagamento (Data Esito 

Singolo Versamento), che risulta ora obbligatoria. 

FORMATO DEI MESSAGGI 

Le colonne Genere, O / F, Len e UNIFI hanno i seguenti significati: 

colonna Genere 

s struttura che può contenere altre strutture o dati, 

an dato alfanumerico, 




n dato numerico. 

colonna O / F 

o dato sempre obbligatorio, 

f dato facoltativo. 

L’eventuale obbligatorietà di tali informazioni è legata alla natura dell’ente, alle 

specifiche esigenze e caratteristiche dell’operazione ovvero ad accordi tra utilizzatore 

(nella fattispecie PdA) e prestatore di servizi (Psp / FESP). 

colonna Len indica la lunghezza massima del dato nel formato min..max; nel caso si tratti di 

una lunghezza fissa comparirà solo il dato len, nel caso di lunghezze fisse in 

alternativa la notazione sarà len1 | len2. 

colonna UNIFI indica la corrispondenza del Dato con gli schemi ISO 20022 - UNIversal 

Financial Industry message (UNIFI). 

RICHIESTA PAGAMENTO TELEMATICO (RPT) 

Dato Genere 

O 

/ 

F 

Len UNIFI Contenuto 

versioneOggetto an o 1..16 VersionNumber Versione che identifica l’oggetto scambiato. 

Dominio s o Initiating Party Aggregazione “dominio” che riporta le 

informazioni che consentono di individuare 

univocamente l’ambito di applicazione della 

richiesta. 

identificativoDominio an o 1..35 Tax Identification 

Number 

Campo alfanumerico contenente il codice fiscale 

della struttura che invia la richiesta di pagamento. 

identificativoStazioneRichiedente an f 1..35 Name Identifica la stazione richiedente il pagamento 

secondo una codifica nota al mittente. 

identificativoMessaggioRichiesta an o 1..35 Message 

Identification 

Identificativo legato alla trasmissione della 

richiesta di pagamento. 

Deve essere univoco nell’ambito della stessa data 

riferita all’elemento 

dataOraMessaggioRichiesta. 

dataOraMessaggioRichiesta an o 19 Creation Date Time Indica la data e l’ora di generazione del messaggio 

di richiesta di pagamento secondo il formato ISO 

8601 

[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss] 

SoggettoVersante s f Ultimate Debtor Aggregazione “versante” che riporta le 

informazioni concernenti il soggetto titolare del 

versamento nei confronti della PA. 

Se coincide con il soggetto Pagatore deve essere 

omesso. 

identificativoUnivocoVersante s f Aggregazione che riporta le informazioni 

concernenti l’identificazione fiscale del versante. 

tipoIdentificativoUnivoco an f 1 Campo alfanumerico che indica la natura del 

versante; può assumere i seguenti valori: 

• ‘F’ Persona fisica 

• ‘G’ Persona Giuridica. 

codiceIdentificativoUnivoco an o 1..35 Tax Identification 

Number 

Campo alfanumerico che può contenere il codice 

fiscale o, in alternativa, la partita IVA del soggetto 

versante. 




Dato Genere 

O 

/ 

F 


anagraficaVersante an o 1..70 Name Indica il nominativo o la ragione sociale del 

versante. 

indirizzoVersante an f 1..70 StreetName Indica l’indirizzo del versante. 

civicoVersante an f 1..16 BuildingNumber Indica il numero civico del versante. 

capVersante an f 1..16 PostalCode Indica il CAP del versante. 

localitaVersante an f 1..35 TownName Indica la località del versante. 

provinciaVersante an f 1..35 Country 

SubDivision 

Indica la provincia del versante. 

nazioneVersante an f 2 Country Indica il codice nazione del versante secondo lo 

standard ISO 3166. 

e-mailVersante an f 1..256 Remittance 

Location Electronic 

Address 

Indirizzo di posta elettronica del versante. 

soggettoPagatore s o Debtor Aggregazione “soggetto pagatore” che riporta le 

informazioni concernenti il soggetto che effettua il 

pagamento. 

identificativoUnivocoPagatore s o Aggregazione che riporta le informazioni 

concernenti l’identificazione fiscale del pagatore. 


pagatore, può assumere i seguenti valori: 

• ‘F’ Identificativo fiscale Persona fisica 

• ‘G’ Identificativo fiscale Persona 

Giuridica. 


Number 

Campo alfanumerico che può contenere il codice 

fiscale o, in alternativa, la partita IVA del pagatore. 

anagraficaPagatore an o 1..70 Name Indica il nominativo o la ragione sociale del 

pagatore 

indirizzoPagatore an f 1..70 StreetName Indica l’indirizzo del pagatore 

civicoPagatore an f 1..16 BuildingNumber Indica il numero civico del pagatore. 

capPagatore an f 1..16 PostalCode Indica il CAP del pagatore 

localitaPagatore an f 1..35 TownName Indica la località del pagatore. 

provinciaPagatore an f 1..35 CountrySubDivision Indica la provincia del pagatore 

nazionePagatore an f 2 Country Indica il codice nazione del pagatore secondo lo 

standard ISO 3166. 

e-mailPagatore an f 1..256 Remittance 

Location Electronic 

Address 

Indirizzo di posta elettronica del pagatore 

enteBeneficiario s o Creditor Aggregazione “ente beneficiario” costituita dai 

seguenti elementi: 

identificativoUnivocoBeneficiario s o Aggregazione che riporta le informazioni 

concernenti l’identificazione fiscale dell’ente 

beneficiario. 


pagatore; se presente deve assumere il valore ‘G’, 

Identificativo fiscale Persona Giuridica. 


Number 

Campo alfanumerico contenente il codice fiscale 

dell’amministrazione destinataria del pagamento. 

denominazioneBeneficiario an o 1..70 Name Contiene la denominazione della PA 




Dato Genere 

O 

/ 

F 


codiceUnitOperBeneficiario an f 1..35 Indica il codice dell’unità operativa destinataria 

denomUnitOperBeneficiario an f 1..70 Contiene la denominazione dell’unità operativa 

destinataria. 

indirizzoBeneficiario an f 1..70 StreetName Indica l’indirizzo dell’ente beneficiario. 

Può coincidere con quello dell’unità operativa 

destinataria 

civicoBeneficiario an f 1..16 BuildingNumber Indica il numero civico dell’ente beneficiario. 


destinataria. 

capBeneficiario an f 1..16 PostalCode Indica il CAP dell’ente beneficiario. 


destinataria 

localitaBeneficiario an f 1..35 TownName Indica la località dell’ente beneficiario. 


destinataria 

provinciaBeneficiario an f 1..35 Country 

SubDivision 

Indica la provincia dell’ente beneficiario. 


destinataria 

nazioneBeneficiario an f 2 Country Indica il codice nazione dell’ente beneficiario 

secondo lo standard ISO 3166. 

datiVersamento s o Aggregazione “dati del versamento” costituita dai 

seguenti elementi: 

dataEsecuzionePagamento an o 10 Requested 

Execution Date 

Indica la data in cui si richiede che venga effettuato 

il pagamento secondo il formato ISO 8601 

[YYYY]-[MM]-[DD] 

importoTotaleDaVersare an o 3..12 Amount Campo numerico (due cifre per la parte decimale, il 

separatore dei centesimi è il punto “.”), indicante 

l’importo relativo alla somma da versare. 

Deve essere diverso da “0.00”. 

Deve uguale alla somma delle varie occorrenze (da 

1 a 5) del dato importoSingoloVersamento presente 

nella struttura DatiSingoloVersamento. 

tipoVersamento an f 1.35 Forma tecnica di versamento delle somme dovute 

presso la Tesoreria Statale. Può assumere i seguenti 

valori 6 : 

• BBT = Bonifico Bancario di Tesoreria, 

• BP = Bollettino Postale. 

identificativoUnivocoVersamento an o 1..35 Creditor Reference Riferimento univoco assegnato al versamento 

dall’ente beneficiario, utilizzato ai fini specifici 

della rendicontazione e riconciliazione eseguita sui 

conti di tesoreria. 

Si faccia riferimento all’Allegato “D” - Struttura 

dell’elemento “Identificativo Univoco Versamento” 

a pagina 41 

ibanAddebito an o 1..35 Debtor. Account 

IBAN 

Identifica l’International Bank Account Number del 

conto da addebitare riferito al soggetto pagatore, 

definito secondo lo standard ISO 13616. 

bicAddebito an f 8 | 11 Debtor Agent.BIC Bank Identifier Code della banca ordinante, 

definito secondo lo standard ISO 9362. 7 

6 In futuro potranno essere utilizzate altre forme di pagamento telematiche che verranno messe a disposizione, quali, ad 

esempio, F23 e F24 telematici,, Addebiti diretti, ecc. 

7 Il dato è riportato per completezza in quanto l’informazione è richiesta solo se il trasferimento di fondi riguarda conti 

residenti in nazioni diverse dall’Italia. 




Dato Genere 

O 

/ 

F 


datiSingoloVersamento s o Aggregazione “dati dei singoli versamenti”, da un 

minimo di uno ad un massimo di 5 occorrenze di 

versamento, facenti capo ad un unico 

identificativoUnivocoVersamento. 

importoSingoloVersamento an o 3..12 Amount Campo numerico (due cifre per la parte decimale, il 

separatore dei centesimi è il punto “.”), indicante 

l’importo relativo alla somma da versare relativa al 

singolo versamento. 

Deve essere diverso da “0.00”. 

ibanAccredito an o 1..35 Creditor Account 

IBAN 

Identifica l’International Bank Account Number,, 

definito secondo lo standard ISO 13616, del conto 

da accreditare presso la Banca Tesoriera, nella 

fattispecie la Tesoreria Statale presso la Banca 

d’Italia. 

bicAccredito an f 8 | 11 Creditor Agent BIC Bank Identifier Code definito secondo lo standard 

ISO 9362 (vedi nota 7). 

credenzialiPagatore an f 1..35 Eventuali credenziali richieste dal Prestatore di 

servizi di Pagamento necessarie per completare 

l’operazione (ad esempio: un codice bilaterale 

utilizzabile una sola volta). 

causaleVersamento an o 1..140 Unstructured 

Remittance 

Information 

datiSpecificiRiscossione an o 1..140 Additional 

Remittance 

Information 

RICEVUTA TELEMATICA (RT) 

Dato Genere 

O 

/ 

F 

Rappresenta la descrizione estesa della causale del 

versamento da riempire a cura del soggetto 

versante/pagatore 

Il dato deve essere riportato invariato nel 

documento di attestazione pagamento rilasciato dal 

PsP/FESP. 

Rappresenta l’indicazione dell’imputazione della 

specifica entrata ed è così articolato: 

”/” 

Per la fattispecie delle spese di giustizia assume i 

seguenti valori: 

• 0/3321.00 per Contributo unificato 

• 0/2101.01 per Diritti di cancelleria 

• 0/2413.12 per Diritti di Copia 


versioneOggetto an o 1..16 VersionNumber Riporta la stessa informazione presente 

nel dato “versioneOggetto” della 

Richiesta di Pagamento Telematico (RPT) 

Dominio s o Initiating Party Riporta le stesse informazioni presenti nel 

blocco “Dominio” della Richiesta di 

Pagamento Telematico (RPT) 

identificativoMessaggioRicevuta an o 1..35 Message 


dataOraMessaggioRicevuta an o 19 Creation Date 

Time 

Identificativo legato alla trasmissione della 

ricevuta telematica. 

Deve essere univoco nell’ambito della 

stessa data riferita all’elemento 

dataMessaggioRicevuta. 

Indica la data e ora del messaggio di 

ricevuta, secondo il formato ISO 8601 

[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss] 




Dato Genere 

riferimentoMessaggioRichiesta an o 1..35 Original Message 


riferimentoDataRichiesta an o 10 Original Creation 

Date Time 

O 

/ 

F 


Con riferimento al messaggio di Ricevuta 

Telematica (RT) l’elemento contiene il 

dato identificativoMessaggioRichiesta 

legato alla trasmissione della Richiesta di 

Pagamento Telematico (RPT). 

Indica la data secondo il formato ISO 8601 

[YYYY]-[MM]-[DD] cui si riferisce la 

generazione del dato 

riferimentoMessaggioRichiesta. 

istitutoAttestante s o Debtor Agent Aggregazione relativa al soggetto 

Prestatore dei servizi di Pagamento che 

emette il documento di attestazione 

dell’avvenuto versamento. 

identificativoUnivocoAttestante s o Financial Institution 


tipoIdentificativoUnivoco an f 1 

codiceIdentificativoUnivoco an o 1..35 BIC | 

Proprietary | 

Tax Identification 

Number 

Aggregazione che riporta le informazioni 

concernenti l’identificazione fiscale 

dell’Istituto attestante il pagamento. 

Campo alfanumerico che descrive la 

codifica utilizzata per individuare l’Istituto 

attestante il pagamento; se presente può 

assumere i seguenti valori: 

• ‘G’ persona giuridica 

• ‘A’ Codice ABI 

• ‘B’ Codice BIC secondo lo 

standard ISO 9362 

Campo alfanumerico che può contenere il 

codice fiscale o la partita IVA, o il codice 

ABI o il codice BIC del prestatore di 

servizi di pagamento attestante. 

denominazioneAttestante an o 1..70 Name Contiene la denominazione del prestatore 

di servizi di pagamento 

codiceUnitOperAttestante an f 1..35 Indica il codice dell’unità operativa che 

rilascia la ricevuta. 

denomUnitOperAttestante an f 1..70 Indica la denominazione dell’unità 

operativa attestante. 

indirizzoAttestante an f 1..70 StreetName Indica l’indirizzo dell’attestante. 

Può coincidere con quello dell’unità 

operativa che rilascia la ricevuta. 

civicoAttestante an f 1..16 BuildingNumber Indica il numero civico dell’attestante. 



capAttestante an f 1..16 PostalCode Indica il CAP dell’attestante. 



localitaAttestante an f 1..35 TownName Indica la località dell’attestante. 



provinciaAttestante an f 1..35 Country 

SubDivision 

Indica la provincia dell’attestante. 



nazioneAttestante an f 2 Country Indica il codice nazione dell’attestante 

secondo lo standard ISO 3166. 






Dato Genere 

O 

/ 

F 


enteBeneficiario s o Creditor Riporta le stesse informazioni presenti nel 

blocco “enteBeneficiario” della Richiesta 

di Pagamento Telematico (RPT) cui si 

riferisce il messaggio di Ricevuta 

Telematica. 

soggettoVersante s f Ultimate Debtor Riporta le stesse informazioni presenti nel 

blocco “soggettoVersante” della Richiesta 

di Pagamento Telematico (RPT) cui si 

riferisce il messaggio di Ricevuta 

Telematica. 

soggettoPagatore s o Debtor Riporta le stesse informazioni presenti 

nel blocco “soggettoPagatore” della 

Richiesta di Pagamento Telematico 

(RPT) cui si riferisce il messaggio di 

Ricevuta Telematica. 

datiVersamento s o Aggregazione “dati del versamento” 

costituita dai seguenti elementi: 

codiceEsitoPagamento n o 1 Campo numerico indicante l’esito del 

pagamento. Può assumere i seguenti 

valori: 

0 Pagamento eseguito 

1 Pagamento non eseguito 

2 Pagamento parzialmente eseguito 

importoTotaleVersato an o 3..12 Amount Campo numerico (due cifre per la parte 

decimale, il separatore dei centesimi è il 

punto “.”), indicante l’importo relativo al 

totale delle somme versate. 

Deve essere uguale alla somma delle varie 

occorrenze (da 1 a 5) dell’informazione 

singoloImportoVersato presente nella 

struttura DatiSingoloPagamento. 

Se il versamento non è stato effettuato 

l’importo deve essere impostato a 0.00. 

identificativoUnivocoVersamento an o 1..35 Creditor Reference Il dato deve essere riportato invariato, a 

cura del Psp/FESP, così come presente 

nella Richiesta di Pagamento Telematico 



datiSingoloPagamento s f Aggregazione “dati dei singoli pagamenti”, 

da un minimo di uno ad un massimo di 5 

occorrenze di versamento, facenti capo ad 

un unico 

identificativoUnivocoVersamento. 

Obbligatorio nel caso che l’elemento 

codiceEsitoPagamento sia 0 o 2 

singoloImportoVersato an o 3..12 Amount Campo numerico (due cifre per la parte 

decimale, il separatore dei centesimi è il 

punto “.”), indicante l’importo relativo alla 

somma versata. Se il singolo versamento 

non è stato effettuato l’importo deve essere 

impostato a 0.00. 

esitoSingoloPagamento an f 1..35 Status Reason 

Proprietary 

Contiene la descrizione in formato testo 

dell’esito del singolo pagamento. 

Obbligatorio nel caso che l’elemento 

singoloImportoVersato sia 0.00 

dataEsitoSingoloVersamento an o 10 Acceptance Date Indica la data di esecuzione o di rifiuto del 

pagamento, nel formato ISO 8601 

[YYYY]-[MM]-[DD]. 

identificativoUnivocoRiscossione an o 1..35 Transaction Riferimento univoco dell’operazione 




Dato Genere 

causaleVersamento an o 1..140 Unstructured 

Remittance 

Information 

datiSpecificiRiscossione an o 1..140 Additional 

Remittance 

Information 

O 

/ 

F 


Reference Number assegnato al versamento dal Prestatore dei 

servizi di Pagamento. Può coincidere con il 

CRO ovvero TRN nel caso di Bonifico 

Bancario o con il CODELINE nel caso di 

bollettino postale. 

Il dato deve essere riportato invariato, a 

cura del Psp/FESP, così come presente 

nella Richiesta di Pagamento Telematico 



Il dato, se presente, deve essere riportato 

invariato, a cura del Psp/FESP, così come 

presente nella Richiesta di Pagamento 

Telematico (RPT) cui si riferisce il 

messaggio di Ricevuta Telematica. 




ALLEGATO “D” - STRUTTURA DELL’ELEMENTO “IDENTIFICATIVO 

UNIVOCO VERSAMENTO” 

CONTESTO GENERALE 

Al fine di qualificare in maniera univoca il versamento, nella struttura dei dati (cfr “Allegato “C” - 

Protocollo sulle regole tecniche e lo standard per l’emissione dei documenti informatici”), è stato 

definito l’elemento “Identificativo Univoco Versamento” che viene generato a cura dell’ente 

erogante i servizi per il quale è richiesto il pagamento. 

Tale informazione è presente nei documenti informatici di Richiesta Pagamento Telematico (RPT) 

e Ricevuta Telematica (RT). 

Secondo gli schemi ISO 20022 - UNIversal Financial Industry message (UNIFI), ai quali si 

riconducono le informazioni presenti nei documenti informatici sopra citati, il dato è identificato 

come “Creditor Reference” e presenta una lunghezza massima di 35 caratteri. 

Le amministrazioni utilizzatrici sono libere di strutturare secondo le proprie esigenze la 

composizione di tale identificativo, tenendo in debito conto il limite sopra indicato (35 caratteri); 

tuttavia si raccomanda fortemente di adottare la strutturazione denominata “Structured Creditor 

Reference” che viene utilizzata nei pagamenti a livello europeo (cfr. SEPA Credit Transfert 

Rulebook a partire dalla versione 3.2) e comporta notevoli vantaggi in termini di riconciliazione per 

l’ente creditore 8 . 

Nel rispetto dei citati schemi SEPA, il formato da adottare per lo “Structured Creditor Reference” è 

lo standard ISO 11649:2009. 

LO STANDARD ISO 11649:2009 

Secondo lo standard ISO 11649:2009 il Creditor Reference è un costrutto alfanumerico 9 lungo al 

massimo 25 caratteri, così composto: 

< identifier > < check digits > < reference > 

All’inizio della struttura è posizionata la costante “RF” (identifier), di seguito sono presenti due 

numeri (check digits), mentre la parte rimanente (reference) può essere lunga sino ad un massimo 

di 21 caratteri, il cui contenuto può essere strutturato senza alcuna restrizione nell’ambito del 

dominio alfanumerico.. 

La componente check digits ha lo scopo di verificare che la componente reference sia stata 

correttamente impostata e viene calcolata secondo l’algoritmo ISO/IEC 7064. 

Per una informativa più esaustiva possono essere consultati anche i seguiti link: 

http://www.iso.org/iso/catalogue_detail.htm?csnumber=50649 

http://www.jknc.eu 

8 Si veda ad esempio il “RF Creditor reference” al seguente indirizzo 

https://www.ebaportal.eu/_Download/Research%20and%20Analysis/2010/rf_creditor_reference.pdf 

9 L'insieme delle lettere dell'alfabeto latino e dei numeri arabi. Appartengono a quest'insieme le lettere minuscole dalla 

a alla z, le maiuscole dalla A alla Z e i numeri da 0 a 9 




CALCOLO DEI CHECK DIGITS DEL CREDITOR REFERENCE 

Carattere Valore ASCII Carattere Valore ASCII Carattere Valore ASCII Carattere Valore ASCII 

0 0 48 G 16 71 W 32 87 m 22 109 

1 1 49 H 17 72 X 33 88 n 23 110 

2 2 50 I 18 73 Y 34 89 o 24 111 

3 3 51 J 19 74 Z 35 90 p 25 112 

4 4 52 K 20 75 a 10 97 q 26 113 

5 5 53 L 21 76 b 11 98 r 27 114 

6 6 54 M 22 77 c 12 99 s 28 115 

7 7 55 N 23 78 d 13 100 t 29 116 

8 8 56 O 24 79 e 14 101 u 30 117 

9 9 57 P 25 80 f 15 102 v 31 118 

A 10 65 Q 26 81 g 16 103 w 32 119 

B 11 66 R 27 82 h 17 104 x 33 120 

C 12 67 S 28 83 i 18 105 y 34 121 

D 13 68 T 29 84 j 19 106 z 35 122 

E 14 69 U 30 85 k 20 107 

F 15 70 V 31 86 l 21 108 

Tabella 1 - Valori per la conversione dei caratteri 

Tutti valori della stringa di caratteri reference sono convertiti sequenzialmente, uno ad uno, in 

numeri applicando il valore presente nell’omonima colonna con riferimento a quello presente nella 

colonna “carattere” della Tabella 1. 

Ad esempio, il carattere avente la lettera minuscola “w” viene convertito con il valore 32, mentre il 

carattere numero 9 viene, pertanto la stringa w9 viene convertita nella stringa numerica 329. 

Una volta convertito tutto il dato reference si aggiunge alla stringa numerica così ottenuta il valore 

2715 (conversione di RF) ed il valore fisso 00; alla stringa risultante si applica l’algoritmo di 

calcolo ISO/IEC 7064 (vedi paragrafo successivo). 

Continuando l’esempio precedente, la stringa derivante sarà pertanto 329271500. 

Di conseguenza, applicando l’algoritmo di calcolo sopra indicato alla stringa w9, il risultato del 

calcolo del check digit è 45. 

Il Creditor Reference risultante è quindi RF45w9. 

ALGORITMO DI CALCOLO ISO/IEC 7064 

L’algoritmo di calcolo è lo stesso usato per il determinare i check digits del codice IBAN per 

quanto riguarda gli identificativi strutturati dei conti correnti bancari. 

L’algoritmo per il calcolo dei check digits che si applica alla stringa numerica risultante dal 

processo di conversione è il seguente: 

1. Calcolare il resto della divisione per 97 (modulo 97) di detto numero, 

2. Sottrarre il risultato ottenuto da 98; 

3. Se tale valore è maggiore di 10, il dato check digits è il valore ottenuto al punto 2, altrimenti 

anteporre uno zero (esempio: se il risultato è 4, il valore del check digits è 04). 




COMPOSIZIONE DEL CRS NEI PAGAMENTI DELLA GIUSTIZIA 

Al fine di gestire al meglio le necessità delle applicazioni del dominio Giustizia, il dato 

identificativoUnivocoVersamento utilizzato per definire il Codice di erogazione del servizio (CRS) 

per il pagamento delle spese di giustizia è strutturato secondo il seguente formato: 

dove 

 

costituisce il codice numerico di controllo (2 posizioni) ed è calcolato con 

l’algoritmo indicato nel successivo paragrafo “Calcolo dei check digits del CRS nei pagamenti 

della giustizia”.Errore. L'autoriferimento non è valido per un segnalibro. 

mentre 

è rappresentato da 33 posizioni alfanumeriche così strutturate: 

, dove 

la sezione (4 caratteri alfanumerici) assicura flessibilità nella 

emissione del CRS in quanto, limitatamente alla fase di sperimentazione del servizio, la 

generazione del CRS potrebbe essere ‘delegata’ dall’Amministrazione ai singoli PdA. 

la sezione (4 caratteri alfanumerici) rappresenta il sistema a cui è 

destinata la ricevuta e garantisce una maggiore duttilità applicativa nella gestione della RT da 

parte dei sistemi del dominio Giustizia (funzionalità di controllo del pagamento), 

la sezione (25 caratteri alfanumerici) contiene un codice ‘non 

ambiguo’ all’interno del dominio entro il quale viene generato. 

CALCOLO DEI CHECK DIGITS DEL CRS NEI PAGAMENTI DELLA GIUSTIZIA 

Analogamente a quanto indicato nel paragrafo relativo al “Calcolo dei check digits del Creditor 

reference”, tutti valori del dato identificatore univoco sono convertiti sequenzialmente, uno ad 

uno, in numeri applicando il valore presente nell’omonima colonna facendo riferimento a quello 

presente nella colonna carattere della Tabella 1. 

Ad esempio, la stringa 123ABCD viene convertita nella stringa numerica 12310111213. 

Alla stringa risultante si applica l’algoritmo di calcolo ISO/IEC 7064; di conseguenza, 

nell’esempio sopra riportato, il risultato del calcolo dei check digits è 96. 

Il valore del CRS risultante è quindi 96123ABCD.

PAGAMENTI TELEMATICI DELLA GIUSTIZIA - Portale Servizi ...

Create successful ePaper yourself

Delete template?

Save as template?