Iris Proxy - Swagger UILoading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In questa sezione viene descritto in dettaglio il json del pagamento e la definizione dettagliata dei campi
Le API fornite nella documentazione dell'intermediario vengono generalmente testate in prima battuta via Postman/Insomnia nel caso di chiamate REST o via SoapUI nel caso di chiamate SOAP
A seguito dei test delle chiamate, si procede con l'implementazione del microservizio. Per testarlo localmente fare riferimento al seguente docker-compose.yml
Se si sta facendo il deploy di un nuovo microservizio per la prima volta o si sta aggiungendo una nuova API o una nuova pagina a una interfaccia esistente, è necessario aggiungere alcuni controlli di qualità minima prima del rilascio.
Test flusso standard
Inserire la configurazione del tenant
Inserire la configurazione del servizio
Inserire un esempio di pagamento in stato CREATION_PENDING nel topic payments e verificare che venga correttamente creato il debito
Chiamare l'API /offline-payment/{id} e verificare che venga scaricato correttamente l'avviso di pagamento cartaceo
Chiamare l'API /online-payment/{id} e verificare che si venga rediretti al portale di pagamento
Una volta arrivati in fondo al pagamento online, verificare che premendo il bottone "Torna alla Home" venga chiamata correttamente l'API /landing/{id}
Chiamare l'API /update/{id} e verificare che venga correttamente controllato lo stato del pagamento ed eventualmente aggiornato e prodotto un evento sul topic payments
Chiamare l'API /receipt/{id} e verificare che, a pagamento avvenuto, venga scaricata correttamente la ricevuta telematica
Inserire un esempio di pagamento in stato PAYMENT_PENDING che è già stato processato precedentemente dal proxy e verificare che venga ignorato
Inserire un esempio di pagamento in stato PAYMENT_PENDING che non è già stato processato precedentemente dal proxy e per cui esiste una configurazione sullo storage, e verificare che venga salvato correttamente sullo storage (caso importazione dovuti)
Test flusso di errore
Modificare la configurazione del servizio in modo che sia errata (mettendo ad esempio credenziali errate)
Inserire un esempio di pagamento in stato CREATION_PENDING nel topic payments e verificare che, a seguito del fallimento, venga prodotto un evento in stato CREATION_FAILED nel topic payments
I pagamenti sono testabili sul nostro ambiente di qa: https://servizi.comune-qa.bugliano.pi.it/.
Si potrà accedere come utente SPID utilizzando l'utente AGID TEST DEMO.
Si potrà accedere come admin per eventualmente modificare il servizio di test e la relativa configurazione di pagamento
Si potrà accedere come operatore per testare pagamenti posticipati, i quali richiedono la presa in carico della pratica e l'approvazione di quest'ultima affinchè l'utente possa procedere con il pagamento.
La piattaforma consente la creazione di servizi contenenti pagamenti. I pagamenti possono essere in forma di bolli, che non richiedono una integrazione con un sistema esterno (il cittadino registra soltanto i numeri di marche da bollo che ha acquistato in precedenza), o in forma di pagamento PagoPA.
I pagamenti PagoPA vengono creati e aggiornati mediante l'integrazione con uno degli intermediari di pagamento di PagoPA.
L’area personale di OpenCity Italia è progettata per integrarsi con vari intermediari di pagamento utilizzati da Comuni ed enti pubblici. Questa sezione descrive i requisiti tecnici necessari per sviluppare e implementare l'integrazione tra la piattaforma e l'intermediario di pagamento PagoPA.
Le interazioni avvengono in seguito ad alcune azioni da parte dei cittadini e degli operatori:
Invio di una pratica da parte del cittadino
Approvazione di una pratica da parte di un operatore nel caso di un pagamento posticipato
Importazione di dovuti da parte dell'operatore mediante API file csv
Pagamento di un dovuto da parte del cittadino a seguito dell'importazione di quest'ultimo
Per sviluppare l'integrazione con l'intermediario di pagamento PagoPA, sono richiesti i seguenti elementi:
Documentazione Tecnica: Manuali, guide e riferimenti API.
Endpoint/Ambiente di Test: URL degli endpoint e accesso a un ambiente di test per effettuare chiamate API.
Modalità di Verifica dello Stato del Pagamento: Specifiche delle modalità di verifica dello stato del pagamento, tramite polling o notifica.
Per integrare OpenCity Italia Area Personale con l’intermediario di PagoPA, sono necessari i seguenti parametri minimi:
Parametri per la creazione di un pagamento
Parametri per la creazione di una Marca da Bollo Digitale
Restituzione del numero IUV e/o del numero avviso in fase di creazione del pagamento
Parametri per scaricare l’avviso di pagamento cartaceo
Parametri per scaricare la ricevuta telematica una volta effettuato il pagamento
API per il download degli importi dovuti (se disponibile)
L’intermediario di pagamento deve fornire documentazione dettagliata delle API, comprensiva di:
Endpoint
Metodi supportati (GET, POST, etc.)
Parametri richiesti e facoltativi
Formato dei dati (JSON, XML)
Esempi di richieste e risposte
Per garantire le comunicazioni fra la piattaforma e l’intermediario di pagamento, è necessario sbloccare gli IP delle chiamate entranti verso gli endpoint dell’intermediario di pagamento. Gli IP di OpenCity da sbloccare sono:
93.41.234.251/32
78.47.94.152/32
54.220.150.231/32
63.33.155.248/32
37.186.144.203/32
Per risolvere eventuali complicazioni, errori o bug durante l'integrazione, è fondamentale avere un contatto tecnico dedicato. Si prega di fornire i seguenti dettagli del contatto tecnico:
Nome
Telefono
Disponibilità (orari di lavoro)
NOTA 1: per gli sviluppatori python è stata definita una libreria a cui fare riferimento per la validazione del nuovo evento, è consultabile qui.
NOTA 2: per gli sviluppatori python, il repository da cui prendere spunto per applicare le modifiche riportate in questa sezione e in quelle successive è consultabile qui.
Con la versione 2.0 aggiornata del pagamento sono stati aggiunti nuovi campi che arricchiscono la descrizione del pagamento, in particolare i campi sono:
type: serve a distinguere tra un pagamento ordinario e una marca da bollo digitale, può avere PAGOPA o STAMP come valori
receiver: definisce il beneficiario del pagamento, non è un campo obbligatorio ma può essere utilizzato nel caso di pagamenti con beneficiario differente dall'ente su cui viene creato il pagamento. Se viene valorizzato è obbligatorio valorizzare i campi receiver.tax_identification_number e receiver.name
due_type: indica la categorizzazione del dovuto sull'intermediario di pagamento, e viene valorizzato dalla configurazione del pagamento
pagopa_category: indica la categorizzazione del dovuto su pagoPA, e viene valorizzato dalla configurazione del pagamento
document: è un campo che serve a descrivere il documento su cui viene apposta la marca da bollo digitale, se viene valorizzato è obbligatorio valorizzare il campo document.hash .
split: con la versione 2.0 dell'evento, questo campo, che viene alimentato dal bilancio contenuto nella configurazione del pagamento, avrà un tipo ben definito, composto da
split.code: indica l'identificativo della voce di bilancio
split.amount: indica l'importo della voce di bilancio
split.meta: oggetto contenente il resto dei campi presenti nella voce di bilancio
links.confirm: è un campo che serve a contenere l'API per forzare il completamento di un pagamento, per il momento tutti i proxy mancano di questa API, ma il campo è stato aggiunto per utilizzi futuri.
links.cancel: è un campo che serve a contenere l'API per forzare l'annullamento di un pagamento.
debtor: in aggiunta al payer è stato aggiunto un campo equivalente debtor, e serve a distinguere tra il debitore e il pagatore di un pagamento, ad esempio è possibile che un cittadino paghi per conto di terzi e in questo caso e debitore e pagatore sono distinti. Per ora non viene valorizzato né utilizzato.
Punti aperti
Determinazione delle URL di ritorno: Come si gestiscono le URL di ritorno? È possibile utilizzare l'indirizzo del proxy per gestire i redirect?
Gestione dell'happy path del pagamento: Come gestire il percorso ideale del pagamento e cosa accade se l'utente chiude la pagina di pagamento e poi ritorna?
Compilazione e invio pratica: L'utente compila la pratica per il servizio e invia la richiesta al Core.
Verifica pagamenti: Il Core verifica se, nella fase attuale della pratica, è necessario effettuare dei pagamenti (es. pagamento anticipato o posticipato).
Creazione pagamenti: Il Core invia i dettagli al servizio di pagamento, che restituisce gli identificativi dei pagamenti creati. Questo passaggio è fondamentale, poiché il Core deve salvare i dettagli dei pagamenti all'interno della pratica, assicurandosi che siano coerenti con il flusso (anticipato o posticipato).
Restituzione della pratica: Una volta ottenuti gli ID dei pagamenti, il Core restituisce all'utente l'intera pratica aggiornata con gli identificativi.
Gestione degli errori nella creazione dei pagamenti:
Cosa accade se la creazione di un pagamento fallisce?
Il personale dell'ufficio preposto dovrebbe essere notificato in caso di fallimento.
Stato "Creation Pending": Quando un pagamento viene creato, si ottiene comunque un ID associato al pagamento, ma questo potrebbe essere in stato di "creation pending".
Politiche di retry: Si potrebbe considerare l'implementazione di politiche di retry, ma è necessario consultare il Product Manager (PM) per decidere la miglior esperienza utente (UX).
Ipotesi: Al secondo o terzo tentativo di retry (o dopo un timeout di 10 secondi), potremmo mostrare un messaggio d'errore all'utente, suggerendo di riprovare o di avvisare l'assistenza (es. con un link "Clicca qui e avvisa"). Questo sarebbe un errore a livello ERROR.
Errore di configurazione: Se si verifica un errore di configurazione errata, è possibile fare affidamento sui messaggi restituiti dall'intermediario. In questo caso, si può evitare il retry e notificare direttamente il responsabile (es. Lorello). Questo tipo di errore potrebbe essere classificato come FATAL.
Il sequence diagram sopra riportato rappresenta il flusso di creazione e gestione dei pagamenti in un'applicazione, con particolare attenzione al retry in caso di fallimento e alla gestione dello stato del pagamento. Il flusso si svolge come segue:
Inizio del processo: L'utente invia la pratica e il Core richiama il Payment Dispatcher API per creare il pagamento. Se la creazione ha successo, si procede, altrimenti si ritenta fino a 3 volte.
Attesa di aggiornamenti dal Read Model: Quando la creazione del pagamento va a buon fine, il Core si mette in attesa di aggiornamenti dal Read Model.
Retry gestito dal Retry Orchestrator: Se il Read Model restituisce lo stato CREATION_FAILED, il Core delega il processo di retry al Retry Orchestrator, che gestisce i retry tramite Kafka. Il Retry Orchestrator tenterà di risolvere il problema creando il pagamento sull'intermediario esterno.
Risultati del Retry Orchestrator:
Se il retry riesce, il Retry Orchestrator segnalerà il successo al Core, che mostrerà all'utente lo stato PAYMENT_PENDING per procedere con il pagamento.
Se i retry falliscono, l'utente riceverà un alert di errore.
Conclusione: L'utente vedrà le informazioni di pagamento in caso di successo o un messaggio d'errore in caso di fallimento, dopo aver superato il numero massimo di tentativi.
Gestione di pagamenti parziali: Se due pagamenti vanno a buon fine e uno fallisce, come dovrebbe comportarsi il frontend? Attualmente, il processo di checkout potrebbe risultare incompleto.
Invio degli ID di pagamento: Durante il checkout, il sistema riceve tutti gli ID dei pagamenti che devono essere completati in un’unica operazione.
Il sequence diagram sopra riportato rappresenta il flusso di creazione e gestione dei pagamenti posticipati in fase approvazione della pratica da parte dell'operatore. Il flusso si svolge come segue:
Creazione delle configurazioni: L'utente modifica e invia le configurazioni, che vengono temporaneamente salvate tramite il Payment Proxy. Se fallisce, l'errore viene mostrato all'utente.
Creazione del pagamento tramite Payment Dispatcher: Il Core invia la richiesta di creazione pagamento al Payment Dispatcher API. Se fallisce, viene avviato un retry per un massimo di 3 tentativi. Se dopo 3 tentativi non riesce, viene mostrato un errore all'utente.
Attesa di aggiornamenti dal Read Model: Quando la creazione del pagamento va a buon fine, il Core si mette in attesa di aggiornamenti dal Read Model, che monitora lo stato del pagamento.
Stato CREATION_FAILED e Retry Orchestrator:
Se il Read Model restituisce lo stato CREATION_FAILED, il Core delega il retry al Retry Orchestrator, che gestisce i retry attraverso i topic di Kafka.
Se il Retry Orchestrator completa con successo la creazione, il Read Model aggiorna lo stato del pagamento, e l'utente può procedere con il pagamento (PAYMENT_PENDING).
Se anche il Retry Orchestrator fallisce dopo vari tentativi, viene restituito un errore al Core e un alert viene mostrato all'utente.
Output finale: Se il pagamento va a buon fine (PAYMENT_PENDING), l'utente riceve le informazioni per procedere con il pagamento. In caso di errore persistente, viene mostrato un alert.
Panoramica dei ciclo di funzionamento dei pagamenti di Opencity Italia - Area Personale.
Un pagamento nasce da una interazione con il cittadino: il cittadino presenta una pratica per la quale l'Ente richiede un pagamento.
Il cuore dell'integrazione con un intermediario di pagamento è un microservizio apposito che dialoga con l'intermediario da un lato, implementando le chiamate specifiche in protocollo ReST o SOAP, e con il core della piattaforma dall'altro lato, mediante la lettura e la scrittura su un topic di Kafka.
In questo momento i pagamenti hanno una relazione 1 a 1 con le pratiche, di conseguenza ci sono due servizi che fanno da intermediari tra le pratiche e i pagamenti, ovvero il payment dispatcher e il payment updater.
È l’interfaccia dalla quale l’utente usufruisce di un servizio digitale, inserendo i dati di una pratica attraverso un modulo: se il servizio prevede un pagamento, i dati di questo sono presenti nella descrizione JSON della pratica e saranno utilizzati dal dispatcher per creare il pagamento.
È il microservizio che, a partire dall'evento di una pratica nel topic applications, crea l'evento del pagamento nel topic payments.
È il microservizio che sostituirà il Payment Dispatcher, esso, anziche leggere l'evento di una pratica dal topic applications, esporrà un API che, quando chiamata, crea l'evento del pagamento nel topic payments. Questo permette di avere una soluzione unica per gestire tutti i flussi di pagamento della piattaforma, quindi sia pagamenti creati a partire dalle pratiche, che i pagamenti importati tramite csv o API esterne.
Il microservizio legge gli eventi dal topic payments e contestualmente aggiorna lo stato della pratica cambiando lo stato da Payment pending a Inviata.
E' il microservizio che gestisce la comunicazione e l’aggiornamento della posizione debitoria con l'Intermediario di pagamento di riferimento. Esso gestisce inoltre il salvataggio delle configurazioni tramite le quali può interagire con l'intermediario di pagamento di riferimento. Queste configurazioni sono inserite dall'operatore mediante l'interfaccia del Core, il quale comunica con il payment proxy mediante delle apposite API che quest'ultimo serve.
E' un microservizio che ascolta dal topic payments e crea un database interrogabile con SQL contenente tutti i pagamenti in stati non definitivi.
E' il microservizio che monitora lo stato dei pagamenti: periodicamente legge su KSQL l'elenco dei pagamenti aperti e invia per ognuno di questi una chiamata alla "update.url" specificata nel pagamento stesso: questa url è una url del proxy stesso che consente al proxy di interrogare l'Intermediario per avere lo stato aggiornato del pagamento.
Questo microservizio si occupa di centralizzare il pagamento online dei dovuti in un'unica API, ovvero quella del checkout di pagoPA, in questo modo si astrae dall'intermediario con cui ci si deve integrare facilitando quindi lo sviluppo dell'integrazione e omogeneizzando l'esperienza di pagamento del cittadino, che diventa quindi indipendente dall'intermediario tramite qui andrà a pagare.
La configurazione dei pagamenti avviene interrogando delle API apposite fornite dal proxy di riferimento. Quest'ultimo fornisce inoltre un form come json schema sviluppato con form.io mediante il quale l'utente inserisce tali configurazioni.
Per creare un form utilizzare il seguente builder:
Descrizione dettagliata di tutti i passaggi che portano alla creazione e alla chiusura di un pagamento a partire da una pratica.
Essendo il sistema in questione costruito su un'architettura a eventi, è fondamentale che il payment proxy controlli la versione dell'evento Payment (campo event_version) prima di processarlo e dichiari con quale versione dell'evento quest'ultimo è compatibile. L'evento qui descritto ha versione 2.0.
L'utente compila e invia la pratica, la quale viene inserita come evento nel topic applications
Un esempio di evento è il seguente, si faccia particolare attenzione al blocco payment_data:
Il payment dispatcher legge l'evento della pratica dal topic applications, e dopo aver controllato mediante query su KSQLDB che il pagamento per tale pratica non sia già stato creato, estrae da esso i dati del pagamento, successivamente li riversa in un nuovo evento di tipo Payment e lo inserisce nel topic payments in stato CREATION_PENDING, indicando come chiave dell'evento il valore del campo service_id. Da qui in poi solo il proxy si occuperà di scrivere sul topic payments.
Il proxy legge dal topic payments e, se ha una configurazione attiva per quel pagamento (quindi se l'evento letto ha un tenant_id e un service_id per cui ha una configurazione salvata nello storage del proxy), crea una posizione debitoria sull'Intermediario di riferimento.
È possibile che la configurazione relativa al pagamento letto dal topic payments abbia configurato al suo interno una marca da bollo digitale. In tal caso, sarà necessario, per ogni marca da bollo digitale, inserire come minimo le seguenti informazioni all'interno del payload da inviare all'intermediario di pagamento con cui ci si sta integrando (in base a poi all'intermediario potrebbero essere necessari altri campi):
Il taglio della marca da bollo o l'importo inserito nella configurazione (per ora l'unico importo supportato è quello da 16 €)
La provincia di residenza del pagatore, la quale si trova nel campo payer.country_subdivision dell'evento payment
L'hash del documento informatico o della segnatura di protocollo cui è associata la marca da bollo digitale (per semplicità il documento in questione sarà il json dell'evento letto dal topic payments)
Il valore del campo reason letto dall'evento nel topic payments o, in assenza di questo, la causale della marca da bollo inserita nella configurazione
Successivamente, sarà necessario:
Valorizzare il campo payment.amount l'importo della marca da bollo inserita in configurazione
Valorizzare il campo payment.due_type con il tipo di dovuto inserito nella configurazione
Valorizzare il campo payment.pagopa_category con il valore della tassonomia di pagoPA contenuta nella configurazione (se presente)
Valorizzare il campo payment.document.hash contenente l'hash del documento informatico o della segnatura di protocollo cui è associata la marca da bollo digitale
ATTENZIONE: questa struttura sarà presente solo sugli eventi payment con event_version valorizzato a 2.0 , sarà necessario dunque controllare la versione dell'evento prima di processarlo
In alcuni casi è possibile che il pagamento che il proxy deve processare presenti un bilancio fisso, ovvero un bilancio i cui importi per ogni voce sono già predeterminati a priori in fase di configurazione del servizio. In tal caso il campo split, quando letto dal proxy per la prima volta, si presenterà come un array vuoto [], il proxy dunque:
Leggerà il campo service_id e reperirà nel mediante esso la configurazione del servizio dentro il quale ci sono le informazioni del bilancio.
Utilizzerà le informazioni ricavate per popolare il payload di creazione della posizione debitoria sull'intermediario di riferimento e per arricchire l'evento appena letto con i dati del bilancio.
Nel proxy è configurato per il servizio A il seguente bilancio
Il bilancio da utilizzare per arricchire il campo split del pagamento sarà:
In alcuni casi è possibile che il pagamento che il proxy deve processare presenti un bilancio variabile, ovvero un bilancio i cui importi per ogni voce vengono determinati dinamicamente a seconda del cittadino. In tal caso il campo split , quando letto dal proxy per la prima volta, si presenterà con un payload così strutturato
oppure così nel caso in cui il cittadino sia esentato dal pagamento di una certa voce del bilancio
dove il campo code indica un identificativo interno della voce di bilancio determinato in fase di configurazione del servizio, e il campo amount indica l'importo per ogni voce di bilancio. Nel caso in cui il valore di amount sia null significa che quella riga deve essere eliminata in fase di creazione del pagamento sul gateway. Il proxy dunque:
Leggerà il campo service_id e reperirà mediante esso la configurazione del servizio dentro il quale ci sono le informazioni del bilancio.
Per ogni voce di bilancio ricavata dalla configurazione del servizio verrà sostituito l'importo con quello letto nel campo split del pagamento
Utilizzerà le informazioni ricavate per popolare il payload di creazione della posizione debitoria sull'intermediario di riferimento e per arricchire l'evento appena letto con i dati del bilancio.
Nel proxy è configurato per il servizio A il seguente bilancio
Nel messaggio del topic payments il campo split è valorizzato a
Il bilancio da utilizzare per arricchire il campo split del pagamento sarà:
Nel proxy è configurato per il servizio a il seguente bilancio
Nel messaggio del topic payments il campo split è valorizzato a
Il bilancio da utilizzare per arricchire il campo split del pagamento sarà:
In caso di risposta positiva:
Il pagamento viene passato in stato PAYMENT_PENDING modificando il campo status,
Vengono compilate le informazioni del bilancio nel campo split (se presenti),
Viene compilata l'url per pagare online (links.online_payment_begin.url), la quale è data dalla concatenazione della variabile d'ambiente EXTERNAL_API_URL alla stringa /online-payment/{payment_id}
Viene compilata l'url di ritorno dal pagamento (links.online_payment_landing.url), la quale è data dalla concatenazione della variabile d'ambiente EXTERNAL_API_URL alla stringa /landing/{payment_id}
Viene compilata l'url per pagare offline (links.offline_payment.url), la quale è è data dalla concatenazione della variabile d'ambiente EXTERNAL_API_URL alla stringa /offline-payment/{payment_id}
Viene compilata l'url della ricevuta di pagamento (links.receipt.url), la quale è data dalla concatenazione della variabile d'ambiente EXTERNAL_API_URL alla stringa /receipt/{payment_id}
Viene compilata l'url per richiedere l'aggiornamento del pagamento (links.update.url), la quale è data dalla concatenazione della variabile d'ambiente INTERNAL_API_URL alla stringa /update/{payment_id}
Nota: a differenza dell'altre url, questa viene valorizzata utilizzando una variabile d'ambiente separata in quanto deve essere possibile chiamarla pubblicamente, questo perchè è compito del solo payments-poller richiedere periodicamente l'aggiornamento del pagamento.
Viene compilata l'url per forzare l'annullamento di un pagamento (links.cancel.url), la quale è data dalla concatenazione della variabile d'ambiente EXTERNAL_API_URL alla stringa /payments/{payment_id} . Viene inoltre compilato il metodo con cui chiamare la url (links.cancel.method) con il valore PATCH.
Viene segnato il timestamp di aggiornamento dell'evento di pagamento (updated_at)
Viene infine salvato il pagamento sullo storage e scritto il corrispondente evento aggiornato sul topic payments, indicando come chiave dell'evento il valore del campo service_id.
In caso di risposta negativa, il pagamento viene passato in stato CREATION_FAILED, viene salvato il pagamento sullo storage e viene scritto l'evento aggiornato sul topic payments
Nel core intanto, la UI del cittadino monitora lo stato del pagamento interrogando una tabella su KSQLDB creata a partire dal topic payments, e se in stato PAYMENT_PENDING, vengono mostrate all'utente le opzioni per pagare
Verra richiamata l'url {EXTERNAL_API_URL}/online-payment/{payment_id} servita dal proxy
Il proxy richiederà all'intermediario di pagamento il link per pagare
Sarà segnato il timestamp di apertura del link (links.online_payment_begin.last_opened_at)
Sarà segnato il timestamp di aggiornamento dell'evento (updated_at)
Il pagamento verrà salvato sullo storage
L'evento aggiornato verrà scritto sul topic payments, indicando come chiave dell'evento il valore del campo service_id
Verrà restituito il link ritornato allo step 2 mediante il quale l'utente verrà rediretto al portale dell'intermediario
Contemporaneamente, essendo che si passa per il proxy, verrà segnato il timestamp in cui l'utente ha aperto il link di ritorno (links.online_payment_landing.last_opened_at)
Il pagamento verrà portato in stato PAYMENT_STARTED
Sarà segnato il timestamp di aggiornamento dell'evento (updated_at)
Il pagamento verrà salvato sullo storage
L'evento aggiornato verrà scritto sul topic payments, indicando come chiave dell'evento il valore del campo service_id.
Verra richiamata l'url {EXTERNAL_API_URL}/offline-payment/{payment_id} servita dal proxy
Il proxy richiederà all'intermediario di pagamento il pdf dell'avviso di pagamento
Sarà segnato il timestamp di apertura del link (links.offline_payment.last_opened_at)
Sarà segnato il timestamp di aggiornamento dell'evento (updated_at)
Il pagamento verrà salvato sullo storage
L'evento aggiornato verrà scritto sul topic payments, indicando come chiave dell'evento il valore del campo service_id
Verrà eseguito il download del pdf ritornato allo step 1
È possibile che l'operatore abbia necessità di annullare un pagamento mediante l'opzione di registrazione del pagamento, ciò può accadere ad esempio se il cittadino, dopo aver creato il pagamento, decide di non concluderlo, e di pagare invece mediante altri canali creando un nuovo pagamento diverso da quello presente sulla piattaforma. Per evitare quindi di lasciare il pagamento pendente per un tempo indefinito, e per permettere l'avanzamento della pratica all'interno della quale è stato creato tale pagamento, sarà possibile annullare quest'ultimo.
Gli step sono i seguenti:
Verra richiamata l'url PATCH {EXTERNAL_API_URL}/payments/{payment_id} servita dal proxy con payload {"status": "CANCELED"}
Il proxy, dopo aver letto il pagamento dallo storage, segnerà il campo status a CANCELED
Sarà segnato il timestamp di apertura del link (links.offline_payment.last_opened_at)
Sarà segnato il timestamp di aggiornamento dell'evento (updated_at)
Il pagamento verrà salvato sullo storage
L'evento aggiornato verrà scritto sul topic payments, indicando come chiave dell'evento il valore del campo service_id
In alcuni casi è possibile che i pagamenti non siano generati a partire dall'area personale, ma siano invece importati da una fonte esterna. In questo caso gli eventi relativi a tali pagamenti saranno inseriti nel topic payments già in status PAYMENT_PENDING e conterranno al loro interno tutte le informazioni che il proxy normalmente inserisce quando fa passare un pagamento generato dall'area personale dallo status CREATION_PENDING allo status PAYMENT_PENDING.
In tal caso tuttavia, questi pagamenti non saranno presenti sullo storage del proxy, dal momento che questa è un'operazione che normalmente farebbe il proxy. Di conseguenza, nel momento in cui dovesse venir letto un evento in stato PAYMENT_PENDING, ci fosse una configurazione attiva per quest'ultimo (ciò si determina controllando che ci sia sullo storage una configurazione con tenant_id e service_id equivalenti a quelli contenuti nel pagamento) ma non esistesse sullo storage, bisogna semplicemente salvare il pagamento sullo storage.
Nel core intanto, questo tipo di dovuti saranno mostrati nella sezione "Pagamenti" insieme a tutti i pagamenti (importati e non) generati dal cittadino, i dati qui presenti sono estratti mediante interrogazione di una tabella su KSQLDB creata a partire dal topic payments.
Cliccando su "Vedi dettaglio" si andrà sul dettaglio dello specifico pagamento dove saranno mostrate le opzioni per pagare (online, offline)
Il payments poller nel frattempo:
Il proxy a sua volta recupera dallo storage il pagamento, interroga l'intermediario di riferimento per verificare lo stato del pagamento, e in caso lo aggiorna in stato COMPLETE o PAYMENT_STARTED (questa casistica può verificarsi nel caso in cui l'utente paghi ma poi chiuda il browser anziche cliccare sul bottone contenente la landing url)
Se il pagamento viene portato in stato COMPLETE , si dovrà salvare, se presente come informazione ritornata dall'intemediario di riferimento, il timestamp di avvenuto pagamento (payment.paid_at), e l'id della transazione (payment.transaction_id)
Il proxy segna il timestamp in cui è stato aperto il link di aggiornamento (links.update.last_opened_at)
Il proxy segna il timestamp di aggiornamento del pagamento (updated_at)
Il proxy salva il pagamento sullo storage e lo scrive sul topic payments, indicando come chiave dell'evento il valore del campo service_id.
Nota 1: più passa il tempo, più è probabile che il pagamento non venga eseguito dall'utente, di conseguenza ad ogni chiamata del poller verso il proxy, viene incrementato l'intervallo di tempo tra una chiamata e l'altra, ciò viene fatto in base al campo links.update.next_check_at.
Nota 2: non tutti i proxy aggiornano i pagamenti mediante update, alcuni vengono aggiornati predisponendo un'apposita API che l'intermediario di pagamento PagoPA chiama inviando la notifica di completamento del pagamento. Questa viene quindi elaborata dal proxy il quale aggiorna il pagamento portandolo in stato COMPLETE, segna il timestamp di aggiornamento del pagamento (updated_at), lo salva sullo storage e lo scrive sul topic payments, indicando come chiave dell'evento il valore del campo service_id .
Il payment updater monitora lo stato dei pagamenti leggendo dal topic payments, e contestualmente aggiorna lo stato della pratica, se il pagamento è in statoPAYMENT_STARTED, aggiorna lo stato della pratica a "In attesa dell'esito di pagamento", se invece il pagamento è in stato COMPLETE, aggiorna lo stato della pratica a "Accettata" se il pagamento è posticipato, o Inviata se il pagamento è immediato.
Gli stati per i quali passa un pagamento durante il suo ciclo di vita sono riassunti nella seguente tabella
Tutti i proxy devono:
Validare gli eventi in input e output
Integrazione con sentry
Healthcheck
Esporre metriche di monitoraggio in formato prometheus
L'admin, dall'interfaccia di configurazione dei pagamenti della Stanza del Cittadino compila la configurazione mediante una form, il cui json schema è servito dall'API /tenants/schema
Lo schema della form sopra riportata è il seguente
Premendo poi il bottone Salva, viene eseguita una POST /tenants servita dal proxy, con payload
Per modificare una configurazione esistente, il proxy serve l'API PUT /tenants/{tenant_id} e PATCH /tenants/{tenant_id}
Per eliminare una configurazione esistente, il proxy serve l'API DELETE /tenants/{tenant_id} . In questo caso l'eliminazione è una soft-delete, ovvero la configurazione viene semplicemente disattivata settando il parametro active a false ed eliminando la configurazione dalla memoria ma non dallo storage.
L'admin, dall'interfaccia di configurazione dei pagamenti per un servizio compila la configurazione mediante una form, il cui json schema è servito dall'API /services/schema
Lo schema della form soprariportata è il seguente
Premendo poi il bottone Salva, viene eseguita una POST /services servita dal proxy, con payload
Per modificare una configurazione esistente, il proxy serve l'API PUT /services/{service_id} e PATCH /services/{service_id}
Per eliminare una configurazione esistente, il proxy serve l'API DELETE /services/{service_id} . In questo caso l'eliminazione è una soft-delete, ovvero la configurazione viene semplicemente disattivata settando il parametro active a false.
Le configurazioni di tenant e servizi vengono salvate con la seguente alberatura
root
|____tenant_id_1
| |____tenant.json
| |____service_id_1.json
| |____service_id_2.json
| |____.....
| |____service_id_n.json
|____tenant_id_2
| |____tenant.json
| |____service_id_1.json
| |____service_id_2.json
| |____.....
| |____service_id_n.json
|____tenant_id_n
|____tenant.json
|____service_id_1.json
|____service_id_2.json
|____.....
|____service_id_n.json
Dettaglio degli stati che attraversa un pagamento nel suo ciclo di vita
| STATO PAGAMENTO | DESCRIZIONE | NOTE |
|---|
Con la versione 2 delle API di configurazione sono stati introdotti dei campi da introdurre obbligatoriamente in ogni integrazione.
I campi da introdurre obbligatoriamente a livello di configurazione del tenant sono:
id: identificativo univoco del tenant
name: nome del tenant
tax_identification_number: codice fiscale dell'ente
| Campo | Tipo | Obbligatorio | Validazione |
|---|
I campi da introdurre obbligatoriamente a livello di configurazione del pagamento sono:
payment_type: tipo di pagamento, può assumere i valori pagopa o stamp, serve a distinguere tra un pagamento ordinario (es. TARI) e una marca da bollo digitale. Questa distinzione è necessaria in quanto in alcuni intermediare i metodi di creazione di un pagamento di una marca da bollo digitale differiscono da quelli di creazione di un pagamento ordinario.
remote_collection.id: identificativo della collezione di provenienza della configurazione di pagamento.
remote_collection.type: tipo di collezione di provenienza della configurazione di pagamento, può assumere valori quali application, service o altro.
amount: importo del pagamento configurato.
reason: causale del pagamento configurato
expire_at: data di scadenza del pagamento
receiver.tax_identification_number: codice fiscale del beneficiario del pagamento, da usare in caso di pagamenti multibeneficiario
receiver.name: nome del beneficiario del pagamento, da usare in caso di pagamenti multibeneficiario
collection_data: tassonomia di pagoPA dei pagamenti
L'admin, dall'interfaccia di configurazione dei pagamenti della Stanza del Cittadino compila la configurazione mediante una form, il cui json schema è servito dall'API /tenants/schema
Lo schema della form sopra riportata è il seguente
Premendo poi il bottone Salva, viene eseguita una POST /tenants servita dal proxy, con payload
Per modificare una configurazione esistente, il proxy serve l'API PUT /tenants/{tenant_id} e PATCH /tenants/{tenant_id}
Per eliminare una configurazione esistente, il proxy serve l'API DELETE /tenants/{tenant_id} . In questo caso l'eliminazione è una soft-delete, ovvero la configurazione viene semplicemente disattivata settando il parametro active a false ed eliminando la configurazione dalla memoria ma non dallo storage.
L'admin, dall'interfaccia di configurazione dei pagamenti per un servizio compila la configurazione mediante una form, il cui json schema è servito dall'API /configs/schema
Lo schema della form soprariportata è il seguente
Premendo poi il bottone Salva, viene eseguita una POST /configs servita dal proxy, con payload
Per ottenere una lista di configurazioni di pagamento (fino a un massimo di 5), il proxy serve l'API GET /configs?config_id=config_id1&config_id=config_id2
Per modificare una configurazione esistente, il proxy serve l'API PUT /configs/{config_id} e PATCH /configs/{config_id}
Per eliminare una configurazione esistente, il proxy serve l'API DELETE /configs/{config_id} . In questo caso l'eliminazione è una soft-delete, ovvero la configurazione viene semplicemente disattivata settando il parametro active a false.
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|---|---|---|
Al termine della procedura di pagamento, l'utente verrà fatto ritornare sul dettaglio della pratica mediante l'url di landing specificata in fase di creazione della posizione debitoria (links.online_payment_landing.url) allo , a questa url andrà aggiunto in query string un parametro payment da valorizzare con OK o KO a seconda dell'esito del pagamento
Interroga KSQLDB per ottenere lo stato dei pagamenti, e se questi sono in stato PAYMENT_PENDING o PAYMENT_STARTED, eseguirà una chiamata http all'url {INTERNAL_API_URL}/update/{payment_id} servita dal proxy (quella di aggiornamento menzionata allo )
| STATO PAGAMENTO | DESCRIZIONE | NOTE |
|---|
| Campo | Tipo | Obbligatorio | Validazione |
|---|
id
UUID
user_id
UUID
type
string(50)
Ogni proxy deve implementare un tipo di pagamento. Se per esempio, il proxy in questione gestisce pagamenti pagopa allora il campo va validato verificando che esso sia valorizzato a PAGOPA. In caso contrario si scarta l'evento e si emette un log di errore.
tenant_id
UUID
service_id
UUID
created_at
Datetime
ISO8601
updated_at
Datetime
ISO8601
status
Enum
Valori permessi: CREATION_PENDING CREATION_FAILED PAYMENT_PENDING PAYMENT_STARTED PAYMENT_CONFIRMED PAYMENT_FAILED NOTIFICATION_PENDING
COMPLETE EXPIRED
reason
string(140)
Causale del pagamento. Non può eccedere i 140 caratteri.
remote_id
UUID
payment
PaymentData
links
Links
payer
Payer
event_id
UUID
event_version
string(10)
L'attuale versione dell'evento deve essere "1.0". Ogni proxy deve validare la versione dell'evento in modo da sapere se processarlo o meno.
event_created_at
Datetime
ISO8601
app_id
string(100)
Valorizzarlo nel formato <nome-proxy>:<versione-proxy>
Es.
iris-payment-proxy:1.3.0
transaction_id
string(255)
Fornito dall'intermediario di pagamento. La lunghezza dunque può essere variabile
paid_at
Datetime
ISO8601
expire_at
Datetime
ISO8601 E' già valorizzato a priori, quindi non viene gestito dal proxy
amount
float
E' già valorizzato a priori, quindi non viene gestito dal proxy
currency
string(3)
ISO4217
notice_code
string(50)
iud
string(50)
iuv
string(50)
split
jsonArray
online_payment_begin
UrlData
online_payment_landing
UrlData
offline_payment
UrlData
receipt
UrlData
notify
List[Notify]
update
Update
url
string
last_opened_at
Datetime
ISO8601
method
Enum
Valori permessi: GET POST
url
string
method
Enum
Valori permessi: GET POST
sent_at
Datetime
ISO8601
url
string
last_check_at
Datetime
ISO8601
next_check_at
Datetime
ISO8601
method
Enum
Valori permessi: GET POST
type
Enum
Valori permessi: human legal
tax_identification_number
string(255)
name
string(255)
family_name
string(255)
street_name
string(255)
building_number
string(255)
postal_code
string(255)
town_name
string(255)
country_subdivision
string(2)
ISO 3166-2
country
string(2)
ISO 3166-1 alpha-2
email
string(255)
id
UUID
user_id
UUID
type
string(50)
Ogni proxy deve implementare un tipo di pagamento. Se per esempio, il proxy in questione gestisce pagamenti pagopa allora il campo va validato verificando che esso sia valorizzato a PAGOPA. In caso contrario si scarta l'evento e si emette un log di errore.
tenant_id
UUID
service_id
UUID
created_at
Datetime
ISO8601
updated_at
Datetime
ISO8601
status
Enum
Valori permessi: CREATION_PENDING CREATION_FAILED PAYMENT_PENDING PAYMENT_STARTED PAYMENT_CONFIRMED PAYMENT_FAILED NOTIFICATION_PENDING
COMPLETE EXPIRED
reason
string(140)
Causale del pagamento. Non può eccedere i 140 caratteri.
remote_id
UUID
payment
PaymentData
links
Links
payer
Payer
Soggetto Versante
debtor
Debtor
Soggetto Pagatore
event_id
UUID
event_version
string(10)
L'attuale versione dell'evento deve essere "1.0". Ogni proxy deve validare la versione dell'evento in modo da sapere se processarlo o meno.
event_created_at
Datetime
ISO8601
app_id
string(100)
Valorizzarlo nel formato <nome-proxy>:<versione-proxy>
Es.
iris-payment-proxy:1.3.0
type
Enum
Valori permessi:
PAGOPA nel caso in cui si tratto di un dovuto standard
STAMP nel caso in cui si tratta di un dovuto di tipo marca da bollo digitale
transaction_id
string(255)
Fornito dall'intermediario di pagamento. La lunghezza dunque può essere variabile
paid_at
Datetime
ISO8601
expire_at
Datetime
ISO8601 E' già valorizzato a priori, quindi non viene gestito dal proxy
amount
float
E' già valorizzato a priori, quindi non viene gestito dal proxy
reason
string(140)
Causale del pagamento. Non può eccedere i 140 caratteri.
currency
string(3)
ISO4217
notice_code
string(50)
iud
string(50)
iuv
string(50)
receiver
Receiver
Destinatario o beneficiario del versamento/dovuto
due_type
string(256)
Tipo di dovuto secondo la classificazione dell'intermediario di riferiemento
pagopa_category
string(12)
Tipo di dovuto secondo la tassonomia ufficiale di pagoPA
document
Document
Contiene le informazioni riguardanti il documento informatico o la segnatura di protocollo cui è associata la marca da bollo digitale
split
List[PaymentDataSplit]
tax_identification_number
string(255)
name
string(255)
iban
string(34)
ISO 13616 (obbligatorio solo dal secondo beneficiario in poi)
street_name
string(255)
building_number
string(255)
postal_code
string(255)
town_name
string(255)
country_subdivision
string(2)
ISO 3166-2
country
string(2)
ISO 3166-1 alpha-2
id
UUID
Identificativo del documento
ref
string
Url per scaricare il documento
hash
string
Hash digest del documento informatico
code
string(50)
amount
float
meta
json
online_payment_begin
UrlData
online_payment_landing
UrlData
offline_payment
UrlData
receipt
UrlData
notify
List[Notify]
update
Update
confirm
UrlData
cancel
UrlData
url
string
last_opened_at
Datetime
ISO8601
method
Enum
Valori permessi:
GET
POST
PUT
PATCH
DELETE
url
string
method
Enum
Valori permessi: GET POST
sent_at
Datetime
ISO8601
url
string
last_check_at
Datetime
ISO8601
next_check_at
Datetime
ISO8601
method
Enum
Valori permessi: GET POST
type
Enum
Valori permessi: human legal
tax_identification_number
string(255)
name
string(255)
family_name
string(255)
street_name
string(255)
building_number
string(255)
postal_code
string(255)
town_name
string(255)
country_subdivision
string(2)
ISO 3166-2
country
string(2)
ISO 3166-1 alpha-2
email
string(255)
type
Enum
Valori permessi: human legal
tax_identification_number
string(255)
name
string(255)
family_name
string(255)
street_name
string(255)
building_number
string(255)
postal_code
string(255)
town_name
string(255)
country_subdivision
string(2)
ISO 3166-2
country
string(2)
ISO 3166-1 alpha-2
email
string(255)
| pagamento in attesa di essere creato sul provider di riferimento |
| pagamento di cui è fallita la creazione sul provider di riferimento |
| pagamento creato sul provider di riferimento e in attesa di essere eseguito dall'utente |
| procedura di pagamento iniziata dall'utente |
| pagamento completato a seguito di conferma dal provider di riferimento |
| pagamento fallito a causa di scadenza del termine ultimo entro cui doveva essere eseguito | nei proxy sviluppati questo stato non è quasi mai stato utilizzato |
| pagamento annullato forzatamente da un operatore |
| UUID | Identificativo univoco |
| String | Non vuoto, massimo 255 caratteri |
| String | Codice fiscale valido |
| Enum | Valori: |
| UUID | Identificativo univoco |
| String | Valori: application, service, altro |
| float | Maggiore di 0 |
| String | Non vuoto, massimo 255 caratteri |
| DateTime | Data futura valida |
| String | Codice fiscale valido |
| String | Non vuoto, massimo 255 caratteri |
| String | Tassonomia pagoPA valida |
Molti aspetti implementativi dipendono più dalla normativa che da nostre scelte progettuali, in questa pagina si evidenziano gli uni e le altre.
Sono requisiti che dipendono da nostre scelte implementative, possono cambiare man mano che evolviamo la piattaforma, per supportare nuovi casi d'uso (pagamento dei dovuti) oppure perché ci accorgiamo che abbiamo commesso qualche errore nella progettazione.
Gestione di pagamenti spontanei
Gestione di pagamenti con bilancio
Gestione della notifica dello stato del pagamento da parte dell'IdP - se disponibile - o del polling se non è disponibile la notifica
Se è implementato il polling, questo deve avvenire con un back-off esponenziale che assicuri alcuni check nel giro di pochi minuti e poi si diradi fino a un massimo di un check al giorno fino alla scadenza del pagamento o 1 anno se la scadenza è inferiore.
Gestione delle configurazioni a livello di Tenant e di Servizio
Avere una specifica in formato OpenAPI v3
Rispettare la Linee Guida di interoperabilità: in particolare per quanto riguarda
il formato dei dati (4.2)
raccomandazioni sul naming (4.3) optando per la scelta di snake_case per i nomi degli attributi
logging (4.4)
risultare valido nel validatore ufficiale OA3
Sappiamo che in molti topic ci sono diversi eventi mal formati, per vari errori e assenza di uno schema registry, quindi è necessario validare gli eventi in input e opzionalmente in output (lo fanno le nostre prime implementazioni in python, ma è un requisito?)
Ci aspettiamo che se di dovesse aggiornare il formato dell'evento nel topic payments gestiremo eventi anche in parallelo con versioni distinte, quindi ogni proxy deve Interpretare solo gli eventi che riportano il formato più recente dell'evento nel topic payments: event_version: 2.0
Integrarsi con sentry per la gestione degli errori
Esporre metriche di monitoraggio in formato prometheus, in particolare:
counter sul numero di pagamenti creati
counter sul numero di errori durante il processamento di pagamenti, differenziando gli errori interni (errori di formato dati in ingresso o validazione) da errori esterni (errori di dialogo con l'IdP)
latenza delle chiamate fatte all'IdP
Di seguito la tabella contenente le specifiche di ogni metrica
Inoltre il servizio deve rispettare gli standard della piattaforma in particolare per quanto riguarda la gestione dello storage: non possiamo avere vendor-lockin sulle tecnologie, quindi dobbiamo essere compatibili con file-system posix tradizionale, NFS share e almeno i due cloud-storage più diffusi S3 e Azure Blob.
EFIL: http://gitlab.com/opencontent/stanza-del-cittadino/efil-payment-proxy
IRIS: http://gitlab.com/opencontent/stanza-del-cittadino/iris-payment-proxy
MYPAY: http://gitlab.com/opencontent/stanza-del-cittadino/mypay-payment-proxy
PMPAY: http://gitlab.com/opencontent/stanza-del-cittadino/pmpay-payment-proxy
Questi proxy condividono alcune scelte implementative grazie a un apposito python-sdk sviluppato in parallelo ai proxy stessi:
le configurazioni sono salvate su disco locale o s3 secondo un albero ben definito tenant->servizio
i singoli pagamenti vengono salvati su storage fino a che il pagamento è pendente, così da poter fare il polling in autonomia.
| pagamento in attesa di essere creato sull'IdP |
| pagamento di cui è fallita la creazione sull'IdP |
| pagamento creato sull'IdP e in attesa di essere eseguito dall'utente |
| procedura di pagamento iniziata dall'utente |
| pagamento completato a seguito di conferma dalI'dP |
| pagamento fallito a causa di scadenza del termine ultimo entro cui doveva essere eseguito | nei proxy sviluppati questo stato non è quasi mai stato utilizzato |
| pagamento annullato |
Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
Successful Response
Successful Response
Successful Response
Successful Response
Lista id delle configurazioni di pagamento
Successful Response
Successful Response
Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
Successful Response
| Metrica | Labels | Descrizione |
|---|---|---|
oc_payment_validation_errors_total
cluster, env, app_name
la metrica deve misurare gli errori di validazione sull'evento letto (es. l'importo è una stringa invece che un float)
oc_api_requests_total
cluster, env, method, app_name, status_code
la metrica deve monitorare le chiamate http indicandone lo status code
oc_payment_success_events_total
cluster, env, app_name
la metrica deve misurare solo gli eventi per cui il proxy ha una configurazione e che stati processati con successo
oc_payment_failed_events_total
cluster, env, app_name
la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing per qualsiasi motivo (escluso il caso in cui non esiste una configurazione per esso)
oc_payment_provider_errors_total
cluster, env, app_name
la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing a causa di un errore sul provider
oc_payment_internal_errors_total
cluster, env, app_name
la metrica deve misurare gli eventi di pagamento validi di cui però è fallito il processing per errori interni al codice
oc_payment_provider_latency_bucket
cluster, env, app_name
istogramma che mostra la distribuzione di latenza delle risposte del provider
Successful Response
Successful Response
Successful Response
Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
"5f99646d-769e-4d73-ba28-cffd30a77e74"Successful Response
"5f99646d-769e-4d73-ba28-cffd30a77e74"Successful Response
"5f99646d-769e-4d73-ba28-cffd30a77e74"Successful Response
"5f99646d-769e-4d73-ba28-cffd30a77e74"Successful Response
"5f99646d-769e-4d73-ba28-cffd30a77e74"Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
"b212c4b4-db26-4404-8c7c-47dab99dd2e6"Successful Response
Successful Response
Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
"23d57b65-5eb9-4f0a-a507-fbcf3057b248"Successful Response
