Polo Regionale dei Pagamenti Disciplinare Tecnico. Versione 2.1

Transcript

1 Polo Regionale dei Pagamenti Disciplinare Tecnico Versione 2.1

2 Sommario SOMMARIO INTRODUZIONE Premessa Scopo Abbreviazioni COSA È PREVISTO DALLE DISPOSIZIONI NAZIONALI Scadenze Come funziona il sistema nazionale dei pagamenti PA Intermediari tecnologici Il formato dell IUV (vigente) SERVIZI DISPONIBILI ALLE PA I servizi di Portale di NRP I servizi applicativi di NRP Scenari di pagamento NRP e gli scenari di riconciliazione dei pagamenti IL PORTALE DI BACK-OFFICE DI NRP Accesso a RPT Accesso a RT Lista PSP: attivazione Lista PSP: accesso Flussi di rendicontazione: attivazione Flussi di rendicontazione: accesso Flussi di quadratura: attivazione Flussi di quadratura: accesso Accesso al giornale degli eventi

3 4.10. Accesso a dati generali statistici sull attività di NRP Configurazione servizi Caricamento massivo pratiche Gestione pratiche in attesa Storno di una RT IL PORTALE DI FRONT-OFFICE DI NRP Pagamenti in attesa Pagamenti spontanei I miei pagamenti Link ai servizi di pagamento I SERVIZI APPLICATIVI DI NRP Pagamento immediato (un solo pagamento senza marca da bollo) Pagamento immediato (fino a 5 pagamenti con o senza marca da bollo) Pagamento diretto (un solo pagamento senza marca da bollo) Avviso di pagamento IL SISTEMA DI TEST DI NRP I LIVELLI DI SERVIZIO ALLEGATO 1: FORMATO FILE DI SCAMBIO DATI PER MODELLO Nome dei file Principi generali del file CSV Carattere di Escape Struttura del tracciato dati

4 1. INTRODUZIONE 1.1. Premessa La normativa vigente prevede l obbligo per ciascuna Pubblica Amministrazione di gestire i pagamenti elettronici (riscossioni) in formato elettronico secondo le regole e le Linee Guida predisposte dall Agenzia per l Italia Digitale (AgID) con i relativi allegati tecnici pubblicate sul sito: Scopo Lo scopo del presente documento è quello di descrivere i componenti sviluppati da Regione Liguria e messi a disposizione degli Enti Liguri per la gestione dei pagamenti elettronici dei quali sono beneficiari Abbreviazioni IUV Identificativo Univoco di Versamento NRP Nodo Regionale Pagamenti API Application Programming Interface PSP Prestatore Servizi di Pagamento IUV Identificativo Univoco di Versamento FE Front End PAP Porta Applicativa Pagamenti (AgID) RPT Richiesta di Pagamento Telematica REST REpresentational State Transfer RT Ricevuta Telematica (di pagamento) WISP Wizard Scelta PSP (AgID) 2. COSA È PREVISTO DALLE DISPOSIZIONI NAZIONALI 2.1. Scadenze Ai sensi dell articolo 5, comma 1 del CAD, le pubbliche amministrazioni e i gestori di pubblici servizi devono adeguare entro il primo giugno 2013 le proprie procedure informatiche e gli strumenti software al fine di consentire l effettuazione dei pagamenti elettronici. Si precisa che la procedura di adesione al sistema nazionale dei pagamenti costituisce di per sé il rispetto dell articolo 5 del CAD, a condizione che la pubblica amministrazione in sede di adesione alla piattaforma nazionale definisca un piano di attivazione che individui in dettaglio le attività da compiere e i tempi di realizzazione, da terminare entro il 31 dicembre Per quanto riguarda l attivazione dei servizi il termine ultimo è il 31/12/2016. Ferma restando la facoltà di adesione alla piattaforma nazionale, i gestori di pubblici servizi possono ricevere pagamenti informatici a mezzo bonifico e/o bollettino di conto corrente postale senza l uso della piattaforma di cui sopra. Di converso, le pubbliche amministrazioni possono ricevere pagamenti informatici a mezzo bonifico e/o bollettino di conto corrente postale senza l uso della piattaforma nazionale solo in via transitoria, entro e non oltre il 31 dicembre 2015 e a condizione che abbiano già espletato la procedura di adesione. 4

5 2.2. Come funziona il sistema nazionale dei pagamenti PA Quanto segue è un estratto dalle Linee Guida AgID: vengono riportati gli elementi principali funzionali alla lettura delle sezioni successive di presente documento. Nell ambito delle relazioni tra utilizzatori finali (cittadino, professionista, impresa) e pubbliche amministrazioni l effettuazione di pagamenti è sempre riconducibile a un processo amministrativo che si articola in fasi ben definite, funzionali al suo corretto completamento. Tali fasi possono essere ricondotte in un Ciclo di vita del pagamento, a qualunque titolo gli importi siano dovuti: tassa, imposta, oblazione, ticket per prestazioni, etc. Le fasi possono essere schematizzate come segue: a) nascita della necessità del pagamento (da parte dell ente o del privato); b) generazione delle informazioni necessarie per dar corso al pagamento; c) pagamento; d) regolamento e riversamento degli importi; e) riconciliazione del pagamento; f) emissione della quietanza da parte dell'ente creditore ed eventuale erogazione del servizio. Tenuto presente che le fasi sopra riportate possono avere un ordine diverso da quello su indicato e che tale ordine può variare a seconda dello scenario e della tipologia di servizio al quale si riferisce il pagamento, le Linee guida AgID contengono le indicazioni circa le modalità attraverso le quali automatizzare e de-materializzare le varie fasi del Ciclo di vita del pagamento e contengono inoltre le informazioni essenziali per la loro attuazione. Gli enti creditori mettono a disposizione dell utilizzatore finale (pagatore o soggetto versante) sui propri siti web e sugli avvisi di pagamento le seguenti informazioni minime: a) Denominazione dell ente creditore; b) Identificativo dell obbligato (il pagatore); c) Importo del pagamento dovuto; d) Identificativo univoco di versamento e causale del versamento; e) Identificativo del conto di pagamento sul quale versare le somme dovute (IBAN o conto corrente postale); f) Scadenza (se prevista). Nel momento in cui i dati vengono resi disponibili all utilizzatore finale, gli stessi devono essere memorizzati in un apposito archivio - che costituisce evidenza informatica dei pagamenti attesi - al fine di facilitare la fase di riconciliazione. Gli enti creditori possono ampliare i dati resi disponibili in coerenza con le proprie soluzioni organizzative. Al fine di consentire le attività di riconciliazione del pagamento da parte degli enti creditori e quelle di riversamento a cura dei prestatori di servizi di pagamento, ciascun ente creditore attribuisce ad ogni operazione di incasso un codice identificativo denominato Identificativo Univoco di Versamento (IUV) che non può essere associato nel tempo ad alcun altro incasso emesso dal medesimo ente creditore. Gli enti creditori possono demandare a un soggetto terzo, in tutto o in parte, la generazione dell Identificativo Univoco di Versamento, curando che ne sia mantenuta l univocità nel tempo. Per i versamenti al bilancio dello Stato o ai conti aperti presso la Banca d Italia nell ambito del servizio di tesoreria dello Stato di cui al decreto del Ministro dell'economia e delle finanze 9 ottobre 2006, n. 293 ( Regolamento recante norme per l'introduzione di nuove modalità di versamento presso le tesorerie statali ), l indicazione del codice IUV si affianca alle disposizioni fornite dalla Circolare della Ragioneria Generale dello Stato n. 20 dell 8 maggio 2007, con particolare riferimento agli elementi da indicare obbligatoriamente nel campo causale del versamento. In aderenza all autonomia organizzativa degli enti il quadro normativo enuclea le operazioni di pagamento per le quali la verifica del buon fine dello stesso debba essere contestuale all'erogazione del servizio per semplicità Pagamenti contestuali all erogazione del servizio dagli altri, che pertanto saranno individuati come Pagamenti non contestuali all erogazione del servizio. I primi sono i pagamenti, effettuati dall utilizzatore finale attraverso i siti web degli enti creditori (portale PA), concomitanti alla erogazione del servizio richiesto ovvero integrati in un procedimento amministrativo che prevede la de-materializzazione dell attestazione del pagamento. Per secondi ci si riferisce ai pagamenti per i quali non è richiesta, sul sito web dell ente creditore, un operatività di tipo interattivo con l utilizzatore finale; tali pagamenti sono eventualmente supportati da un avviso di pagamento analogico e possono quindi essere perfezionati in tempi successivi valendosi dei canali offerti dai prestatori di servizi di pagamento PSP quali, per esempio, banche, ecc. Nel seguito del documento i primi saranno denominati pagamenti da portale PA mentre i secondi pagamenti da PSP. 5

6 L Agenzia per l Italia Digitale, ai sensi del vigente quadro normativo, mette a disposizione delle pubbliche amministrazioni, attraverso il Sistema Pubblico di Connettività, una piattaforma tecnologica per assicurare l interconnessione e l interoperabilità tra queste ultime e i prestatori di servizi di pagamento, denominata nel seguito Nodo dei Pagamenti-SPC. L utilizzo della piattaforma è obbligatorio per le pubbliche amministrazioni L infrastruttura messa a disposizione dall Agenzia per l Italia Digitale consente agli enti creditori di gestire tutte le soluzioni organizzative adottate per far effettuare i pagamenti dovuti attraverso il Nodo dei Pagamenti-SPC - gestire in modo interattivo tutti i pagamenti, nonché consentire all utilizzatore finale di operare direttamente sui canali offerti dai prestatori di servizi di pagamento, rendendo possibile agli enti creditori lo snellimento dei processi di riscossione, il miglioramento della qualità dei servizi erogati e il risparmio sui costi di processo. L esecuzione dei pagamenti si perfeziona attraverso lo scambio di oggetti informatici denominati Richiesta di pagamento telematico e Ricevuta telematica, tra il Nodo dei Pagamenti-SPC e le piattaforme dei prestatori di servizi di pagamento aderenti che colloquiano tra di loro in modalità cooperativa. Le Ricevute telematiche costituiscono prova dell avvenuto addebito del pagatore o del soggetto versante e devono essere conservate, a cura degli enti creditori, con le modalità indicate nelle disposizioni sulla conservazione dei documenti informatici. L adesione dei prestatori di servizi di pagamento al Nodo dei Pagamenti-SPC consente a questi ultimi di rilasciare al pagatore una ricevuta, telematica o cartacea, con potere liberatorio. Per un approfondimento sulle modalità tecniche e organizzative per l utilizzo della piattaforma tecnologica si rimanda all Allegato B delle Linee Guida AgID. Schema architetturale sistema nazionale (da Linee Guida AgID) 6

7 2.3. Intermediari tecnologici Le Pubbliche Amministrazioni possono offrire il servizio e accedere al Nodo dei Pagamenti-SPC anche attraverso un intermediario pubblico o privato (quali per esempio: regione, consorzio di enti pubblici o altro) che gestisce per suo conto i servizi di front-office offerti all utilizzatore finale, nonché tutte le funzionalità di interconnessione al Nodo dei Pagamenti-SPC. I PSP possono anche essi utilizzare degli intermediari per connettersi al Nodo dei Pagamenti-SPC ovvero per offrire i propri servizi di pagamento; tali soggetti possono essere rappresentati da altri prestatori di servizi di pagamento ovvero da circuiti o consorzi costituiti in ambito finanziario. Rimangono comunque inalterate le responsabilità di ente creditore e PSP nei confronti delle controparti e in particolare degli utilizzatori finali Il formato dell IUV (vigente) Per il formato dell IUV si rimanda alle specifiche vigenti pubblicate da AgiD. In particolare, sul sito di Agid ( nella sezione relativa a PagoPA) sono pubblicati i documenti SPECIFICHE ATTUATIVE DEL NODO DEI PAGAMENTI-SPC, Utilizzo del codice IUV per Enti plurintermediati. Il nodo Regionale dei Pagamenti è allineato a queste specifiche. 3. SERVIZI DISPONIBILI ALLE PA Regione Liguria mette a disposizione delle PA liguri: la Porta di Dominio (PdD) configurata per il corretto colloquio con il Nodo dei Pagamenti-SPC; il Nodo Regionale dei Pagamenti (NRP) integrato con la PA. Il sistema Nodo Regionale dei Pagamenti (NRP): si configura come intermediario tecnologico per le PA liguri; si propone di semplificare il dialogo con il Nodo dei Pagamenti-SPC (il nodo nazionale) manlevando, per esempio, le PA da tutte le attività legate alle Porte di Dominio mette a disposizione delle PA liguri un ambiente operativo dedicato: questo ambiente utilizza, in riuso, le funzioni di un applicativo sviluppato dall AgID (PAP Porta Applicativa dei Pagamenti) e include anche un repository dei pagamenti; tale ambiente dedicato offre: o una serie di servizi applicativi disponibili mediante WS REST; o una serie di servizi applicativi realizzati da un bridge NRP richiamabile via URL; o un portale di back-office grazie al quale è possibile inserire nuove pratiche, controllare lo stato di quelle già inserite e visualizzare gli incassi effettuati; o un portale di front-office a disposizione dei cittadini per effettuare pagamenti; su richiesta, genera lo IUV per conto della PA garantendone, quindi, l unicità anche in presenza di più servizi distinti (della PA stessa) che utilizzano il sistema; offre uno spazio di archiviazione sul quale ciascuna PA può caricare le pratiche da pagare; offre disponibilità del servizio nei confronti del Nodo dei Pagamenti-SPC manlevando quindi la PA dal mantenere disponibilità di servizio sui propri sistemi informativi: nella configurazione più semplice, la PA ha infatti solo l onere di registrare l informazione del debito su NRP (e di andarne a leggere l esito). 7

8 NRP espone servizi e dialoga principalmente con: Sistemi titolari di pratica: (nel seguito sistema PA ) sistema al quale è delegata la gestione di pratiche oggetto di pagamento. Esempi sono rappresentati dal sistema del bollo auto, dal CUP, dal sistema informativo di una PA; Portali di pagamento: (nel seguito portale PA ) portali istituzionali che consentono al cittadino di effettuare un pagamento (es. Ticket Web, Bollo Auto, Certificazioni, ecc.); Nodo Nazionale dei Pagamenti: il Nodo dei Pagamenti-SPC di AGID; Operatori PA (bilancio, assistenza e manutenzione, ecc.); La PA può interagire con NRP attraverso: Bridge NRP: interazione applicativa tra Portale PA e sistema NRP; Portale di Back-office: interazione attraverso operatore PA e NRP; Portali di pagamento Sistemi titolari di pratica Operatore PA NRP Nodo nazionale dei pagamenti Il cittadino può pagare: Utilizzando il Portale PA, se presente; Utilizzando il Portale di front-office di NRP; Utilizzando i PSP. 8

9 3.1. I servizi di Portale di NRP Portale di Back-office Il Portale di Back office è funzionale a operatori che fanno parte della PA intermediata o che sono amministratori centrali di NRP. Consente l accesso a informazioni di reportistica e di rendicontazione e offre servizi di gestione di NRP. Le funzioni principali sono: Operazioni caricamento pratica (singola o massiva); Operazioni di rendicontazione, controllo e storno; Il Portale è fruibile attraverso protocollo https e a valle di una verifica positiva da parte del sistema di identificazione regionale (IAM). Ciascun operatore PA può avere accesso solamente alle transazioni afferenti alla propria PA, alle funzioni per le quali è stato profilato ed ai dati dei servizi per i quali è stato abilitato. Portale di Front-office Il Portale di Front-office consente al cittadino di effettuare il pagamento di pratiche: pratiche con Avviso pratiche senza Avviso Per quanto riguarda le pratiche con Avviso, cioè quelle che la PA ha precedentemente caricato su NRP, il cittadino si collega al Portale di Front-office, sceglie la PA beneficiaria e inserisce il codice IUV in suo possesso. Il Portale NRP procede al pagamento e rilascia l attestato di pagamento al cittadino. La RT, come per gli altri casi, rimane disponibile su NRP per la PA che potrà, quindi, consegnare la ricevuta di pagamento al cittadino. Per quanto riguarda le pratiche senza Avviso, il Portale di Front-office consente al cittadino di effettuare un pagamento spontaneo per tipologie di pratiche che la PA ha precedentemente configurato su NRP (es., bollettini spontanei, refezione scolastica, palestre, ecc.). Il cittadino si collega al Portale di Front-office, sceglie la PA beneficiaria e sceglie il tipo di pratica che desidera pagare, integra il pagamento con gli estremi del pagatore, l importo dovuto e la causale. A questo punto può decidere se effettuare il pagamento on line oppure pagare in seguito presso un PSP abilitato. Il Portale di Front-office può anche essere configurato per rimandare il cittadino a servizi specifici di pagamento on-line gestiti direttamente da portali della PA dove il cittadino può effettuare il pagamento (link a portali PA). Per Regione Liguria esempi possono essere rimandi ai servizi di pagamento ticket, pagamento bollo auto, ecc. 9

10 3.2. I servizi applicativi di NRP I servizi applicativi di NRP sono utilizzabili dai programmatori degli enti per creare specifici servizi applicativi di pagamento e/o per integrare le funzioni di pagamento nei sistemi verticali esistenti. NPR rende disponibili i seguenti servizi: Pagamento immediato singolo Questo servizio, trattato in dettaglio nella Sezione 6, prevede un interazione con il sistema di pagamento attraverso URL, modalità utilizzata da parte di molti verticali in esercizio da prima dell avvento di PagoPA. Le funzioni sono progettate per supportare il Portale PA per un solo singolo pagamento immediato e sono progettate per comportare adattamenti minimi ai sistemi verticali già in essere prima di PagoPA. Pagamento immediato multiplo Questo servizio è consigliato quando il sistema verticale deve effettuare, per un solo ente beneficiario, fino a un massimo di 5 pagamenti contemporanei in modalità immediata (pagamento on line). Il sistema è predisposto anche per gestire in questa modalità l acquisto di marca da bollo digitale 1. Pagamento diretto Questo servizio è consigliato quando il sistema verticale deve effettuare, per un solo ente beneficiario, in modalità diretta ovvero quando si consegna al soggetto pagatore un avviso di pagamento e questi si reca presso un PSP per il suo pagamento. Le attuali specifiche di AgiD prevedono per questo modello di pagamento un solo pagamento per volta (senza marca da bollo). Come meglio dettagliato nella Sezione 6, qualora una PA avesse specifiche necessità di operare applicativamente in maniera specifica anche su aspetti parziali (quali, per esempio, la rendicontazione) saranno valutate le modalità che meglio rispondono alle esigenze anche attraverso l esposizione di specifici Web Services Scenari di pagamento Le funzioni esposte da NRP consentono alla PA di progettare e realizzare i propri servizi di pagamento attraverso differenti modalità. Di seguito sono mostrati alcuni esempi che illustrano i casi d uso più comuni. 1 N.B. al momento della redazione del documento su PagoPA nazionale non è ancora disponibile questa funzionalità: è necessario, quindi, verificarne l effettiva attivazione sul Nodo Nazionale. 10

11 In tutti questi casi verranno usati i seguenti termini: Cittadino: soggetto (cittadino o impresa) che deve effettuare un pagamento alla PA Sistema PA: sistema informativo della PA dedicato a tematiche specifiche (es., CUP, Pronto Soccorso, Bollo Auto, multe, ecc.) e dotato di un proprio sottosistema pagamenti Portale PA: portale della PA collegato a un proprio sottosistema pagamenti Sottosistema pagamenti: sottosistema della PA in grado di interagire con NRP per quanto concerne l aspetto dei pagamenti. Operatore PA: soggetto della PA profilato sul sistema regionale che opera all interno del portale di back-office di NRP. Caso d uso 1a: pagamento immediato da portale PA In questo caso il cittadino si collega con il proprio Internet browser al portale PA e mediante il sottosistema pagamenti - inserisce tutte le informazioni relative al proprio debito (utili alla predisposizione della RPT). Inseriti i dati procede immediatamente al pagamento on line (modello 1 di PagoPA: pagamento immediato). I passi logici sono i seguenti: 1. il cittadino si collega al portale della PA e ricerca il proprio debito; 2. il portale PA acquisisce dal cittadino il PSP prescelto (direttamente od attraverso il sistema WISP di AgID); 3. Il sottosistema pagamenti: a. richiede un IUV a NRP (attraverso la funzione paprestgeneraiuv) b. completa la RPT con lo IUV e i dati identificativi del PSP prescelto dal cittadino c. procede con un pagamento immediato, attraverso la funzione paprestinviarpt d. ridirige il browser del cittadino sull URL del PSP (ricevuta da NRP in risposta a paprestinviarpt) per l autorizzazione al pagamento 4. il cittadino: a. introduce l autorizzazione al pagamento (sul sito del PSP) 5. Il PSP una volta recuperato l incasso ridirige il browser del cittadino verso il portale PA e invia la RT a NRP 6. Il portale PA, a questo punto, può recuperare la RT interrogando NRP (attraverso la funzione paprestchiedirt) e, se il pagamento è andato a buon fine (RT positiva) consegnare la ricevuta al cittadino. 11

12 Questo caso d uso, per una sua parte, è assimilabile a quello del pagamento immediato della PAP e, per semplicità di lettura, riassunto in Appendice C. Caso d uso 2: debito inserito da PA e pagato da PSP (scenario di pagamento diretto) In questo caso il cittadino paga presso una struttura PSP un debito generato all interno della PA e di cui è posto a conoscenza tramite un Avviso di Pagamento. Il debito viene generato dal sistema PA mediante il proprio sottosistema pagamenti. I passi logici sono i seguenti: 1. La PA inserisce i dati del debito mediante il proprio sottosistema pagamenti (o da Portale di Backoffice): a. richiede un IUV a NRP; b. inserisce il debito (con IUV) su NRP; c. produce l Avviso di Pagamento che riporta lo IUV associato al debito, consegnandolo (es. via , posta tradizionale) al cittadino; 2. il cittadino: a. si reca presso una struttura PSP e mostra l Avviso di Pagamento (che contiene il C.F. della PA e l IUV della pratica); 3. il PSP: a. interroga il NRP utilizzando C.F. PA e IUV contenuti nell Avviso di Pagamento; b. in caso di risposta positiva: i. consente la finalizzazione del pagamento ii. produce un attestato di pagamento (con l IUV) per il cittadino e contestualmente 12

13 iii. invia la RT a NRP, ove rimarrà a disposizione della PA c. in caso negativo, la transazione verrà negata 4. Il sistema PA, una volta recuperata la RT da NRP, potrà consegnare se il caso la ricevuta al cittadino. Il passo 1. (caricamento del debito su NRP da parte della PA) può essere fatto sia attraverso chiamata a metodo WS Rest esposto da NRP (paprestcaricapagamentodiretto) da parte del sottosistema PA oppure attraverso il Portale di Back-office di NRP (caricamento singolo o massivo di debiti). Di seguito, lo schema nel primo caso (WR Rest) in cui la PA chiede anche un IUV a NRP. Questo caso d uso, per una sua parte, è assimilabile a quello del pagamento diretto attivato presso strutture PSP della PAP e, per semplicità di lettura, riassunto in Appendice D NRP e gli scenari di riconciliazione dei pagamenti Come specificato nelle Linee Guida di AgID (Allegato B), e qui riassunto per semplicità di lettura, una volta terminata la fase di pagamento da parte del PSP, la PA beneficiaria provvede a riconciliare le Ricevute Telematiche (RT) con le informazioni fornite dalla propria Banca Tesoriera. Il PSP che riceve l ordine dal proprio cliente o che esegue l incasso per conto del ente creditore può regolare contabilmente l operazione in modalità singola o in modalità cumulativa, il che comporta per la PA beneficiaria due diverse modalità di riconciliazione. Qualora, a fronte del singolo versamento, il PSP effettui una singola disposizione di pagamento nei confronti della Banca Tesoriera della PA beneficiaria per regolare contabilmente l operazione (ad esempio: l utilizzo della forma tecnica bonifico di tesoreria ), si parla di riconciliazione in modalità singola. Qualora il PSP effettui un unica disposizione di pagamento nei confronti della Banca Tesoriera dell ente creditore per regolare contabilmente i pagamenti relativi agli esiti contenuti in una o più Ricevute 13

14 Telematiche, si parla di rendicontazione in modalità multipla che viene effettuata dall ente creditore sulla base dei dati forniti dal proprio istituto tesoriere e di quelli contenuti nel flusso di rendicontazione generato dal PSP che viene messo a disposizione della PA beneficiaria attraverso NRP. La riconciliazione in questo caso deve essere effettuata in due fasi: nella prima fase il dato identificativoflusso - presente nella causale di versamento del SEPA Credit Transfer, secondo lo standard indicato nella Sezione II dell Allegato A alle Linee guida - deve essere abbinato con quello presente nel Flusso di rendicontazione inviato dal PSP e disponibile su NRP. Nella fase di riconciliazione sono quindi presenti tre elementi: 1. RT: la ricevuta telematica che viene resa disponibile immediatamente alla PA dopo l avvenuto incasso da parte del PSP; 2. il bonifico della somma incassata dal PSP nei confronti della banca della PA beneficiaria (tesoriere) che avviene entro il giorno successivo a quello in cui è avvenuto l incasso; 3. il flusso di rendicontazione che viene predisposto dal PSP (e fatto pervenire a NRP) entro due giorni successivi a quello in cui è avvenuto l incasso. Di seguito uno schema dei vari elementi della rendicontazione (il dialogo tra PSP e NRP avviene sempre attraverso il Nodo Nazionale): Primo caso: riconciliazione dei pagamenti in modalità singola Il cittadino effettua un pagamento per una PA (indifferentemente, da portale PA o da PSP). Il PSP predispone immediatamente la RT che viene inviata a NRP che, a sua volta, la rende disponibile alla PA (funzione paprestchiedirt). Entro il giorno successivo la PA riceve un bonifico con l importo della RT: nella causale di 14

15 versamento del SEPA Credit Transfer è riportato l IUV del pagamento effettuato e, quindi, la PA può recuperare i dettagli del pagamento attraverso la lettura (su NRP) della corrispondente RT. Secondo caso: riconciliazione dei pagamenti in modalità multipla Vengono effettuati più pagamenti per una stessa PA (indifferentemente, da portale PA o da PSP) presso un PSP. Al verificarsi di ciascun pagamento, il PSP predispone immediatamente la RT che viene inviata a NRP che, a sua volta, la rende disponibile alla PA (funzione paprestchiedirt). Entro il giorno successivo la PA beneficiaria riceve un bonifico cumulativo dal PSP relativo a più incassi, (e quindi a più RT) che, nella causale di versamento del SEPA Credit Transfer, riporta il dato identificativoflusso. Entro due giorni successivi all incasso la PA può recuperare su NRP le informazioni (IUV, importo) di tutte le RT coinvolte nel bonifico cumulativo corrispondente al dato identificativoflusso (funzione paprestchiediflussorendicontazione). Le informazioni di dettaglio delle singole RT potranno sempre essere recuperate con la funzione paprestchiedirt. 4. IL PORTALE DI BACK-OFFICE DI NRP Il Portale di Back office è progettato per essere di supporto a operatori che afferiscono alla PA intermediata o al sistema centrale NRP (Regione Liguria). Il Portale è fruibile attraverso protocollo https e a valle di una verifica positiva da parte del sistema di identificazione regionale (IAM). Ciascun operatore PA può avere accesso solamente alle transazioni afferenti alla propria PA, alle funzioni per le quali è stato profilato e ai dati dei servizi per i quali è stato abilitato. I profili di accesso previsti sono di seguito elencati unitamente alle sezioni da loro accessibili (il dettaglio delle sezioni è riportato nelle sezioni successive). Servizi del Portale di Back office referente contabilità (operatore PA) referente di (singolo) servizio (operatore PA) assistenza tecnica (operatore PA o RL) amministratore NRP (operatore RL) 1. Accesso a RPT X X X 2. Accesso a RT X X X 3. Lista PSP: attivazione X X X 4. Lista PSP: accesso X X X 5. Flussi di rendicontazione: attivazione X X X 6. Flussi di rendicontazione: accesso X X X 7. Flussi di quadratura: attivazione X 8. Flussi di quadratura: accesso X 9. Accesso al giornale degli eventi X 10. Dati generali statistici X X X 11. Configurazione servizi X 12. Caricamento massivo pratiche X X X 13. Gestione pratiche in attesa X X X 14. Storno di RT X X X 15

16 I profili previsti sono i seguenti: il referente contabilità è l operatore del Settore Bilancio (o Amministrazione) della PA che gestisce gli aspetti contabili (es., rendicontazione, storno) di tutti i servizi di pagamento per i quali la PA è intermediata da NRP. Questo profilo ha, quindi, accesso alle informazioni di tutti i servizi della PA attestati su NRP; il referente di servizio è l operatore afferente alla PA che gestisce un particolare servizio attestato su NRP e che, quindi, può avere necessità di accedere alle informazioni di quel servizio. Questo profilo ha accesso al solo servizio (ai soli servizi) della PA attestato su NRP di cui è referente; il referente di assistenza tecnica è un operatore che può essere afferente alla PA (es., assistenza di primo livello) o a Regione Liguria (es., assistenza di II livello) e che ha lo scopo di intervenire nel caso di problemi o malfunzionamenti. Questo profilo ha accesso a tutti i servizi della PA attestati su NRP; l amministratore NRP è l operatore amministratore dell intero sistema NRP e ha accesso a tutte le informazioni di tutti i servizi (di pagamento) di tutte le PA attestate su NRP. Ha, tra gli altri, il compito di effettuare tutte le configurazioni sul sistema. Di seguito una descrizione più dettagliata dei servizi del Portale Accesso a RPT Il report di accesso a RPT mostra un elenco di tutte le RPT che soddisfano una serie di criteri di ricerca. I criteri sono i seguenti: PAP dell Ente: una Servizio: uno o tutti Stato: uno o tutti Soggetto pagatore: uno o tutti IUV: uno o tutti Data da: data di inizio intervallo scelta da calendario Data a: data di fine intervallo scelta da calendario L elenco delle RPT riporta in lista una sintesi dei dati principali della RPT. A partire dalla singola riga, è prevista la possibilità di accedere a una pagina con tutti i dettagli della RPT. Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Accesso a RT Il report di accesso a RT mostra un elenco di tutte le RT che soddisfano una serie di criteri di ricerca. I criteri sono i seguenti: PAP dell Ente: una Servizio: uno o tutti Esito pagamento: uno o tutti Soggetto pagatore: uno o tutti IUV: uno o tutti Data da: data di inizio intervallo scelta da calendario Data a: data di fine intervallo scelta da calendario 16

17 L elenco delle RT riporta in lista una sintesi dei dati principali della RT ed il link al sevizio di presentazione e scarico della Ricevuta Telematica. A partire dalla singola riga, è prevista la possibilità di accedere a una pagina con tutti i dettagli della RT. Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Lista PSP: attivazione Il servizio consente di scaricare dal Nodo nazionale la lista aggiornata dei PSP. Questa stessa funzione è schedulata automaticamente ogni giorno al momento della prima richiesta di pagamento Lista PSP: accesso L utente seleziona: PAP dell Ente: una Banca: una o tutte Tipo versamento: uno o tutti Il report restituisce la lista dei PSP che corrispondono ai criteri selezionati. Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Flussi di rendicontazione: attivazione Il servizio consente di ricevere dal Nodo nazionale i flussi di rendicontazione e di elaborali su NRP. L elaborazione verifica la corretta corrispondenza tra gli IUV presenti nel flusso e quanto risulta all interno della PAP Flussi di rendicontazione: accesso L utente seleziona: PAP dell Ente: una Data da: data di inizio intervallo scelta da calendario Data a: data di fine intervallo scelta da calendario Il report restituisce la lista dei flussi di rendicontazione presenti. Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Flussi di quadratura: attivazione Il servizio consente di ricevere dal Nodo nazionale i flussi di quadratura e di elaborali su NRP Flussi di quadratura: accesso L utente seleziona: PAP dell Ente: una 17

18 Data da: data di inizio intervallo scelta da calendario Data a: data di fine intervallo scelta da calendario Il report restituisce la lista dei flussi di quadratura presenti. Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Accesso al giornale degli eventi L utente seleziona: PAP dell Ente: una Data da: data di inizio intervallo scelta da calendario Data a: data di fine intervallo scelta da calendario Esito pagamento: uno o tutti IUV: uno o tutti Il report restituisce il contenuto del giornale degli eventi con le informazioni relative ai log. Per la sua natura la funzione è abilitata agli operatori di assistenza. Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Accesso a dati generali statistici sull attività di NRP L utente seleziona: PAP dell Ente: una Data da: data di inizio intervallo scelta da calendario Data a: data di fine intervallo scelta da calendario Il report restituisce le statistiche della PAP per l intervallo di tempo selezionato riportando: Numero annuo complessivo di transazioni di pagamento (con esito positivo ed esito negativo); Numero annuo per servizio di transazioni di pagamento annuali (con esito positivo ed esito negativo). Il sistema consente la restituzione dei dati selezionati in Excel, CSV e/o PDF Configurazione servizi Consente all amministratore NRP di definire i servizi che la PA desidera rendere disponibili per: Pagare avvisi di pagamento (prodotti e distribuiti dalla PA) Effettuare pagamenti spontanei Nel primo caso viene configurato per la PA il modello di pagamento diretto (modello 3); nel secondo caso viene configurata una serie di tipologie di debiti che la PA presenta a portale per il pagamento e che possono essere pagati come pagamento spontaneo sia con un pagamento immediato da portale (modello 1), sia con pagamento diretto (modello 3) attraverso la creazione, da portale, di un avviso di pagamento. Il pagamento spontaneo si caratterizza dal fatto che chi paga inserisce tutte le informazioni relative al pagamento (importo compreso). 18

19 Si definiscono quindi: i servizi pubblicati e la loro tipologia ( con avviso o spontaneo ) gli enti beneficiari del servizio (normalmente è l ente richiedente la configurazione, ma potrebbe anche essere un altro ente afferente a NRP) tutti gli elementi indispensabili per contestualizzare il pagamento. A titolo di esempio riportiamo l IBAN di accredito, il tipi di versamento possibili associati al servizio, circuito MyBank, PSP poste. Ogni configurazione è definita negozio e a questo è associato un codice che dovrà essere utilizzato dai servizi verticali che colloquiano con NRP. Nel caso degli avvisi di pagamento con caricamento massivo tramite file, il negozio dovrà essere indicato in ogni pratica da caricare su NRP Caricamento massivo pratiche Questo sevizio permette di: eseguire da portale di back-office l upload di file.zip (uno per volta) contenenti ognuno un elenco di debiti da gestire su NRP visualizzare, sul portale di back-office, la lista dei flussi caricati con il loro rispettivo stato ( in elaborazione, caricato, rigettato, pubblicato ) per i flussi in stato rigettato, verificare, consultando il log della elaborazione, gli errori riscontrati durante il caricamento (ad esempio: codice negozio non presente per l ente, flusso con IUV presente a fronte di configurazione con IUV generato da NRP) annullare un flusso appena caricato (l operazione di annullamento è disponibile solamente se un flusso è in stato caricato ) abilitare la pubblicazione e il pagamento di tutti i debiti contenuti nei flussi caricati. Non sono previsti caricamenti parziali di file: un solo errore prevede il rigetto di tutto il file. Il processo di caricamento: 1. pone lo stato del flusso in in elaborazione ; 2. per ogni debito verifica la completezza dei dati che caratterizzano il debito: se ci sono errori pone lo stato in rigettato e ritorna rendendo disponibili gli errori riscontrati. Altrimenti 3. per ogni debito: a. genera l IUV; b. predispone e inserisce la RPT su PAP (pagamento diretto) 4. pone lo stato del flusso in caricato 5. in caso di errore pone il flusso in stato rigettato Il formato del file per il caricamento massivo di pratiche è descritto in ALLEGATO 1: Formato file di scambio dati per modello 3, capitolo 9 del presente documento a pag Gestione pratiche in attesa Questa funzione consente a un operatore di: accedere alla lista delle pratiche in attesa caricare un nuovo debito (pratica) 19

20 Ogni pratica non ancora pagata può essere eliminata: l eventuale operazione di modifica dovrà quindi essere eseguita mediante le due operazioni di eliminazione e di inserimento. Per il caricamento ex novo di una pratica il servizio: 1. presenta una maschera con la quale riceve in input i dati della RPT; 2. verifica la completezza dei dati inputati; 3. genera un IUV; 4. predispone e inserisce l RPT parziale (senza PSP) su PAP (attraverso la funzione PAP di caricamento del pagamento diretto, modello 3) Storno di una RT Lo storno è un operazione attraverso la quale la PA può procedere all annullamento (storno) di un pagamento effettuato a proprio favore. Il servizio consente all operatore di ente di individuare il pagamento da stornare secondo alcuni parametri di ricerca (IUV, soggetto pagatore, intervallo temporale). La funzione è soggetta alle regole dello storno previste da AgiD e dai singoli PSP. Esso si esplica nell invio di una richiesta di revoca (RR) da parte dell Ente Creditore, contenente i riferimenti della RT oggetto della revoca e nella risposta da parte del PSP contenente l esito della revoca (ER), che il PSP può accettare di eseguire utilizzando i propri processi contabili e amministrativi interni, ovvero può anche rifiutare. ATTENZIONE: lo storno è applicabile sono nei confronti dei PSP che sono abilitati allo stesso. 5. IL PORTALE DI FRONT-OFFICE DI NRP 5.1. Pagamenti in attesa Questa sezione del portale consente di pagare in modalità immediata da portale NRP un pagamento diretto o di recuperarne i dati relativi all avviso di pagamento. L accesso alla sezione Pagamenti in attesa può avvenire in modalità libera o autenticata (con credenziale SPID). Nel caso di accesso autenticato viene resa disponibile la posizione debitoria (ovviamente, per le sole pratiche presenti su NRP). Nel caso di accesso libero, la modalità di fruizione è la seguente: 1. selezione della PA 2. digitazione dell IUV e del codice fiscale 3. pagamento immediato del debito o stampa dell avviso di pagamento (dati utili per il pagamento). Nel caso di accesso autenticato (SPID), la modalità di fruizione è la seguente: 20

21 1. selezione della pratica da un elenco delle proprie pratiche in attesa di pagamento 2. pagamento immediato del debito o stampa dell avviso di pagamento (dati utili per il pagamento). N.B. l avviso di pagamento viene, di norma, consegnato dalla PA al cittadino in un formato predisposto dalla PA stessa: in questa sezione del portale si recuperano quindi solo i dati utili al pagamento da PSP e non, necessariamente, una copia dell avviso Pagamenti spontanei Questa sezione, ad accesso non autenticato, consente di: selezionare l ente per il quale si deve effettuare il pagamento scegliere la macro tipologia di pagamento (tra quelli configurati per la PA attraverso il servizio di back office descritto in precedenza) completare i dati relativi al pagamento (estremi del pagatore, importo, causale) effettuare: o il pagamento immediato (modello 1) della pratica, oppure o stampare i dati dell avviso di pagamento I miei pagamenti Questa sezione accessibile solo con autenticazione (SPID) presenta l elenco di tutti i pagamenti effettuati attraverso NRP. Viene utilizzato il codice fiscale per presentare sia i pagamenti effettuati a nome dell utente (soggetto pagatore) che quelli effettuati per conto di altri (soggetto versante). Da ogni pagamento si accede alla corrispondente ricevuta telematica 5.4. Link ai servizi di pagamento Su richiesta della PA possono essere riportati in questa sezione link a indirizzi web (URL) di servizi di pagamento della PA stessa. 6. I SERVIZI APPLICATIVI DI NRP Di seguito vengono elencati i servizi applicativi di interazione con il sistema NRP. In versioni precedenti del disciplinare era esplicitamente esposta una serie di Web Services ognuno dei quali dedicato a un azione specifica e atomica nel contesto di tutto il processo del pagamento. L esperienza maturata con l integrazione dei primi applicativi, e la considerazione che anche il sistema nazionale impone frequenti evoluzioni e aggiornamenti, ha reso più opportuno esporre alle PA funzioni applicative in grado di gestire i principali processi completi di pagamento, ottenendo in questo modo una maggiore semplicità e stabilità di integrazione. Tali macro-processi sono i seguenti: 1. pagamento immediato di un pagamento singolo (senza marca da bollo) 2. pagamento immediato un pagamento multiplo con singolo IUV (eventualmente con marca da bollo) 3. pagamento diretto di un pagamento singolo 4. richiesta di avviso di pagamento 21

22 La parte descrittiva dei singoli Web Services atomici in questa versione non è, quindi, più presente. Qualora, tuttavia, una PA avesse specifiche necessità di operare applicativamente in maniera più atomica (anche su aspetti parziali del processo quali, per esempio, la rendicontazione) saranno valutate le modalità che meglio rispondono alle esigenze anche attraverso l esposizione di specifici Web Services. Di seguito un elenco dei principali WS che, previo accordo e con il supporto tecnico di Regione Liguria, possono essere utilizzati: Descrizione Funzione WS REST Lista PSP paprestchiedilistapsp Richiesta IUV paprestgeneraiuv (vedi Sez. 6.1, 6.2 e 6.3) Caricamento di un debito vedi Sez. 6.3 Annullamento di un debito vedi Sez. 6.3 Richiesta di pagamento immediato vedi Sez. 6.1 e 6.2 Pagamento diretto: attivazione RPT in attesa svolta in automatico da NRP Richiesta storico RPT paprestchiedistoricorpt Pagamento diretto: richiesta stato RPT in attesa paprestnodochiedistatorpt Verifica RPT pendenti tra NRP e Nodo nazionale paprestnodochiedilistapendentirpt Richiesta RT paprestchiedirt Richiesta storico RT paprestchiedistoricort Richiesta elenco flussi rendicontazione paprestchiedielencoflussirendicontazione Richiesta singolo flusso rendicontazione paprestchiediflussorendicontazione Elabora flusso di rendicontazione paprestelaboraflussirendicontazione 6.1. Pagamento immediato (un solo pagamento senza marca da bollo) Il servizio è raggiungibile dalle applicazioni dell ente richiamando una pagina HTML e indicando i seguenti parametri con metodo post (consigliato) o metodo get. Tramite questa interfaccia, è possibile avviare la modalità di pagamento immediato per uno solo pagamento destinato a un unico beneficiario. Non è possibile, attraverso questa interfaccia, ad esempio, effettuare più pagamenti contemporanei per un beneficiario (RPT con più di un pagamento fino a un massimo di 5), ne pagare per più beneficiari (carrello di RPT), ne pagare una marca da bollo. Parametro Descrizione Formato Obbligatorio codtrans identificativo del pagamento da 2 a 30 caratteri obbligatorio (univoco per ogni pagamento) alfanumerici (escluso # ) importo Importo in centesimi di euro obbligatorio (es., > 2573) divisa Divisa 3 caratteri (EUR) obbligatorio alias Valore fisso comunicato da Regione url_back url in caso di annullamento vedi dopo obbligatorio url url a cui inviare i parametri di obbligatorio risposta con il risultato della transazione urlpost url (post) a cui inviare i parametri di risposta con il risultato della transazione mac Message Code Authentication max 40 caratteri obbligatorio 22

23 Parametro Descrizione Formato Obbligatorio mail indirizzo del pagatore Da 1 a 150 caratteri obbligatorio languageid codice linguaggio sempre il valore ITA nome Nome del pagatore max 140 caratteri cognome Cognome del pagatore max 140 caratteri identificativofiscalepagatore Identificativo fiscale del max 34 caratteri pagatore (CF o PIVA) anagraficapagatore Anagrafica del pagatore max 140 caratteri tipopagatore Natura giuridica del pagatore F (persona fisica) G (persona giuridica) max 1 carattere Il parametro url_back indica un indirizzo che verrà richiamato alla pressione del tasto annulla a cui verranno accodati i seguenti parametri: Variabile Valore importo importo da autorizzare divisa EUR codtrans codice identificativo del pagamento assegnato dal gestore del negozio esito ANNULLO o ERRORE Se tale parametro non viene valorizzato, alla pressione del tasto annulla, non verrà effettuata nessuna operazione. (facoltativo) Il parametro iuv, se presente deve contenere un IUV valido (campo PA=1 e codice controllo corretto). Se assente, l IUV verrà generato da NRP (campo PA=0). L esito della richiesta di pagamento, viene comunicato dal PSP attraverso il Nodo Nazionale prima e NRP dopo al Portale PA e reindirizzando l acquirente all URL applicativo, al quale vengono inviati, in modalità GET, i seguenti parametri: Parametro Descrizione Formato e Valore alias identificatore PA AN max 30 caratteri codtrans Codice transazione Da 2 a 30 caratteri importo importo in centesimi di euro (es., > 2573) codaut Codice autorizzazione Da 2 a 6 caratteri mac Message Code Authentication brand tcontab esito esito transazione 2 caratteri ( OK o KO ) divisa Divisa 3 caratteri ( EUR ) data data della transazione yyyymmdd orario orario della transazione hhmmsss 23

24 Parametro Descrizione Formato e Valore indirizzo del Da 1 a 150 caratteri pagatore cognome cognome del pagatore Da 1 a 30 caratteri nome nome del pagatore Da 1 a 30 caratteri IUV identificativo univoco del pagamento di PagoPA uidriscossione identificativo univoco del pagamento per il PSP ParametriAggiuntivi Eventuali parametri aggiuntivi Nello scambio di informazioni tra Portale PA e servizio è obbligatorio aggiungere la fase di autenticazione reciproca compiuta accodando a ogni messaggio un MAC (Message Code Authentication) calcolato sui dati della transazione. L adozione di un MAC è obbligatoria in quanto consente di verificare, sia a Regione Liguria, sia al Portale PA, che non siano stati manipolati i dati inviati attraverso URL. La RPT riporterà la causale di default del servizio concordata con gli amministratori di NRP in fase di configurazione Pagamento immediato (fino a 5 pagamenti con o senza marca da bollo) Tipi di dato RichiestaPagamentoMultiploImmediato presenta i seguenti membri, con la stessa semantica del caso di PAGAMENTO IMMEDIATO (SINGOLO): String alias String urlpost String urlback String urlok String String tipopagatore String anagraficapagatore String identificativofiscalepagatore String codtrans String mac Inoltre, per quanto riguarda la lista dei dati dei singoli pagamenti, questa può contenere da 1 a 5 elementi relativi ai singoli pagamenti da effettuare, ognuno dei quali può essere o no relativo ad una marca da bollo digitale: List<DatiSingoloPagamento> listadatisingolopagamento DatiSingoloPagamento presenta i seguenti membri: String importo 24

25 BigDecimal commissionecaricopa String ibanbeneficiario String divisa String hashdocumentobollodigitale String provinciaresidenza String causale (*) Anche in questo caso, cosi come nel caso del PAGAMENTO IMMEDIATO, l importo deve essere specificato in centesimi di Euro. Nota bene che nel caso di pagamento di marca da bollo digitale, l ibanbeneficiario non deve essere valorizzato, mentre lo saranno l hashdocumentobollodigitale e la provinciaresidenza. Nella fattispecie devono rispettivamente contenere i dati relativi al valore hash in base SHA256 del documento su cui si desidera applicare la marca da bollo e la sigla della provincia di residenza del pagatore. In caso contrario, l ibanbeneficiario è obbligatorio mentre non devono essere valorizzati i dati relativi al bollo, hashdocumentobollodigitale e provinciaresidenza. (*) La causale è una stinga opzionale di 90 caratteri. Se non valorizzata la RPT e l avviso di pagamento riporteranno la causale di default del servizio concordata con gli amministratori di NRP in fase di configurazione. Metodi esposti Vengono esposti due metodi, inviarichiesta e annullarichiesta, per effettuare rispettivamente l invio e l annullo della richiesta. Entrambi i metodi sono esposti da una servlet sotto forma di dopost e sono raggiungibili, rispettivamente, agli indirizzi host/portale/rest/pagamentomultiplo/inviarichiesta host/portale/rest/pagamentomultiplo/annullarichiesta Per es. Metodo inviarichiesta Parametri: RichiestaPagamentoMultiploImmediato Tipo di ritorno: Una stringa contenente il valore dell iuv in formato Json (es: {"iuv":" "}) Il servizio crea l RPT per il nodo nazionale dei pagamenti e persiste sul data base del Bridge, un record riassuntivo dei totali dei pagamenti da effettuare, ponendolo nello stato IN_ATTESA. 25

26 Lo stato IN_ATTESA è il corrispondente dello stato IN_ATTESA_DI_PSP della PAP e garantisce che l RPT non venga ulteriormente processata fino a che non verrà posta nello stato INVIATA (IN_ATTESA_DI_RT sulla PAP). Metodo annullarichiesta Parametri: String, una stringa contenente l iuv della richiesta da annullare Tipo di ritorno: Una stringa contenente il valore 0/1 a seconda se è fallita o è andata a buon fine l'operazione di annullo, in formato Json (es: {"result":"1"}) Il servizio modifica lo stato della richiesta relativa all iuv in input, ponendola rispettivamente nello stato ANNULLATA sul database del Bridge e ponendone la pratica relativa nello stato PAGAMENTO_MULTIPLO_ANNULLATO sul database della PAP. Modalità operative In modo esattamente analogo a quanto accade per il pagamento immediato singolo, l applicazione X dell ente individua: 1. Il pagatore a. tipo [F/G fisico/giuridico], b. codice [Codice Fiscale / partita IVA], c. anagrafica [denominazione (nome e cognome o ragione sociale)] 2. Gli estremi del pagamento e l ENTE beneficiario (ovvero il NEGOZIO) 3. Gli URL per OK, BACK, POST e richiama la servlet con l operazione inviarichiesta, mettendo perciò la richiesta multipla sulla PAP e sul database del Bridge in stato di attesa (rispettivamente, IN_ATTESA_DI_PSP e IN_ATTESA). A seguito del corretto funzionamento del servizio inviarichiesta e al ritorno dell iuv, l'applicazione richiama una pagina HTML, che a sua volta effettua l attivazione dell RPT relativo all iuv ricevuto nella request HTTP. Una volta attivato, l RPT è pronto per essere pagato dall utente, cui viene presentata la lista dei PSP (tramite richiesta alla PAP). L utente sceglie il PSP e il processo prosegue come se fosse il pagamento di una RPT con singolo pagamento Pagamento diretto (un solo pagamento senza marca da bollo) Tipi di dato RichiestaPagamentoDiretto presenta i seguenti membri: String alias 26