> Miglioramento continuo dei processi > Elaborazione dei pagamenti > Fiserv > Template dei dati

Il Suo template dei dati per l’elaborazione dei pagamenti

Name: Template di dati per il Process Mining di Elaborazione dei pagamenti
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

Il Suo template dei dati per l’elaborazione dei pagamenti

← Torna alla guida al miglioramento

Attributi dell’elaborazione dei pagamenti (19) Attività di elaborazione dei pagamenti (13) Guide all’estrazione (1)

Il Suo template dei dati per l’elaborazione dei pagamenti

Questo template offre una struttura per associare i dati Fiserv a un formato adatto al Process Mining e all’analisi. Descrive gli attributi e le attività essenziali per ottenere una visione chiara dei cicli di regolamento e riconciliazione. Seguendo questa guida, potrà creare un Event Log completo che evidenzia inefficienze e rischi di conformità nelle operazioni finanziarie.

Attributi consigliati per l’analisi dei pagamenti
Principali tappe del processo da monitorare
Indicazioni tecniche per estrarre i dati Fiserv

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il template

Attributi dell’elaborazione dei pagamenti

Questi campi dati consigliati forniscono il contesto necessario affinché l’Event Log consenta un’analisi completa dell’intero ciclo di vita dei pagamenti.

5 Obbligatorio 9 Consigliato 5 Facoltativo

	Nome	Descrizione
	ID della transazione di pagamento PaymentTransactionId	Identificativo univoco della specifica istruzione di pagamento o del caso di transazione.
Descrizione Questo attributo funge da chiave centrale per collegare tutte le attività svolte nell’ambito del ciclo di vita di un singolo pagamento. Consente agli analisti di ricostruire il percorso dalla richiesta iniziale fino alla convalida, all’approvazione e al regolamento finale o all’annullamento. Negli ambienti Fiserv, in genere corrisponde alla chiave primaria delle tabelle della cronologia delle transazioni. È essenziale per ricostruire il flusso del processo e associare correttamente allo stesso oggetto aziendale eventi separati nel tempo, come un regolamento che avviene giorni dopo l’autorizzazione. Perché è importante È l’ID del caso fondamentale necessario per raggruppare gli eventi in istanze di processo. Dove reperirli Consultare la documentazione Fiserv relativa alle tabelle Transaction o Payment Header. Esempi TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Nome dell’attività ActivityName	Evento specifico o cambio di stato verificatosi nel processo di pagamento.
Descrizione Questo attributo descrive il passaggio eseguito, ad esempio «Richiesta di pagamento creata» o «Pagamento regolato». Definisce i nodi nella mappa del processo ed è fondamentale per comprendere la sequenza delle operazioni. Analizzando le singole attività, le organizzazioni possono visualizzare il flusso di lavoro, individuare i passaggi ignorati e rilevare percorsi non conformi in cui sono state aggirate convalide o approvazioni obbligatorie. Perché è importante Definisce gli eventi che compongono la cronologia del processo. Dove reperirli Registro della cronologia delle transazioni o tabelle di audit dei cambi di stato. Esempi Richiesta di pagamento creataPagamento autorizzatoErrore di pagamento individuatoPagamento regolatoPagamento annullato
	Timestamp dell’evento EventTimestamp	Data e ora esatte in cui si è verificata l’attività.
Descrizione Questo attributo registra il momento preciso in cui si è verificato un evento. È alla base di tutte le analisi temporali, compresi i tempi di ciclo, i tempi di attraversamento e l’individuazione dei colli di bottiglia. Nelle Dashboard, questi dati consentono di calcolare la durata tra i passaggi, ad esempio il tempo che intercorre tra «Richiesta di pagamento creata» e «Pagamento autorizzato». Timestamp precisi sono necessari per ordinare correttamente gli eventi che si verificano a breve distanza l’uno dall’altro. Perché è importante Necessario per ordinare gli eventi e calcolare la durata delle prestazioni del processo. Dove reperirli Registri di audit o colonne con i timestamp degli aggiornamenti delle transazioni. Esempi 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Sistema di origine SourceSystem	Nome del sistema da cui provengono i dati.
Descrizione Identifica il modulo Fiserv specifico o il sistema esterno che ha generato l’evento. È particolarmente utile nelle architetture complesse, in cui i pagamenti possono essere avviati da un canale front-end e regolati in un sistema bancario centrale back-end. Consente agli analisti di filtrare la vista del processo in base al sistema di origine, così da concentrare l’analisi su specifici ambienti tecnici o punti di integrazione. Perché è importante Fornisce il contesto tecnico e la tracciabilità dei dati. Dove reperirli Valore codificato durante l’estrazione o metadati di sistema. Esempi Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp dell’ultima estrazione o aggiornamento del record.
Descrizione Indica quanto sono aggiornati i dati utilizzati per l’analisi. È fondamentale per stabilire se le Dashboard riflettono le operazioni in tempo reale o una fotografia storica. Aiuta gli utenti a fidarsi delle metriche visualizzate e a evitare decisioni basate su dati obsoleti, soprattutto quando monitorano il rispetto degli orari limite o i colli di bottiglia attivi. Perché è importante Garantisce l’aggiornamento e l’affidabilità dei dati. Dove reperirli Ora di sistema al momento dell’esecuzione dell’ETL. Esempi 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Codice di errore ErrorCode	Codice specifico generato quando un pagamento non supera la convalida.
Descrizione Registra il codice di errore tecnico o aziendale associato alle attività «Errore di pagamento identificato». Questo attributo è alla base del monitoraggio degli errori di convalida e delle rilavorazioni. Aggregando la frequenza dei singoli codici di errore, l’organizzazione può individuare problemi sistemici nella qualità dei dati, ad esempio un «Numero di routing non valido», e intervenire in modo mirato sulla logica di convalida o sulla formazione degli utenti. Perché è importante Individua le cause profonde delle rilavorazioni. Dove reperirli Registri degli errori o dettagli dello stato della transazione. Esempi E-101INV_ACCNSF_ERRAUTH_FAIL
	Codice valuta CurrencyCode	Codice ISO della valuta dell’importo del pagamento.
Descrizione Specifica la valuta in cui è espresso il pagamento, ad esempio USD o EUR. Questo attributo è essenziale per la Dashboard sull’andamento dei volumi per valuta e metodo, che consente all’organizzazione di monitorare l’esposizione ai diversi cambi valutari. Viene inoltre utilizzato per normalizzare gli importi nei report globali e per evitare che i controlli sui duplicati segnalino erroneamente transazioni con lo stesso valore numerico ma in valute diverse. Perché è importante Necessario per analizzare l’elaborazione in più valute. Dove reperirli Tabella di intestazione della transazione, colonna Currency. Esempi USDEURGBPCADJPY
	Data di scadenza del pagamento PaymentDueDate	Data entro la quale il pagamento deve essere elaborato.
Descrizione Data prevista per il completamento del pagamento. Viene utilizzata nel monitoraggio della conformità agli orari limite di elaborazione per segnalare le transazioni che rischiano di essere in ritardo. Confrontando il timestamp di «Pagamento regolato» con questo attributo, è possibile calcolare le metriche di puntualità e aiutare l’organizzazione a mantenere la fiducia dei beneficiari. Perché è importante Riferimento per misurare il rispetto degli SLA. Dove reperirli Dettagli dell’istruzione di pagamento. Esempi 2023-11-012023-11-15
	È STP IsStraightThroughProcessing	Indicatore che segnala se il pagamento è stato elaborato senza intervento manuale.
Descrizione Attributo booleano calcolato, impostato su vero se il caso non include passaggi «Errore di pagamento identificato», «Errore di pagamento risolto» o «Pagamento approvato» manualmente, a seconda della definizione adottata. Supporta direttamente il KPI del tasso di elaborazione senza intervento manuale. Consente di segmentare il processo in due categorie: flussi interamente automatizzati e flussi che richiedono l’intervento umano, offrendo una visione chiara del potenziale di automazione. Perché è importante Metrica fondamentale per l’efficienza del processo e i risultati dell’automazione. Dove reperirli Calcolato durante la trasformazione dei dati. Esempi truefalse
	Importo del pagamento PaymentAmount	Valore monetario della transazione di pagamento.
Descrizione Questo attributo rappresenta il valore finanziario associato al pagamento. È una dimensione fondamentale per segmentare l’analisi e distinguere i pagamenti strategici di importo elevato dalle transazioni ordinarie di importo ridotto. È essenziale per la vista di rilevamento dei pagamenti duplicati, in cui importi identici associati ai dati del pagatore e del beneficiario possono segnalare potenziali errori. Supporta inoltre l’analisi dell’autorità di approvazione, poiché gli importi più elevati spesso seguono flussi di lavoro diversi. Perché è importante Fondamentale per l’analisi del rischio finanziario e il rilevamento dei duplicati. Dove reperirli Tabella di intestazione della transazione, colonna Amount. Esempi 150.0025000.5010.991000000.00
	Metodo di pagamento PaymentMethod	Modalità utilizzata per eseguire il pagamento, ad esempio Wire o ACH.
Descrizione Classifica la transazione in base al circuito di elaborazione utilizzato. Questo attributo è fondamentale per l’analisi del tempo di ciclo dell’autorizzazione, poiché i diversi metodi seguono procedure operative standard e accordi sui livelli di servizio molto diversi. L’analisi delle varianti di processo per metodo di pagamento aiuta a capire se i ritardi sono circoscritti a un canale specifico, come i bonifici internazionali, o se riguardano l’intera organizzazione. Perché è importante Segmenta i flussi di processo in base all’infrastruttura utilizzata. Dove reperirli Colonna del tipo di transazione o del codice dello strumento. Esempi BonificoACHAssegnoRTPTrasferimento interno
	Numero di conto del beneficiario PayeeAccountNumber	Numero del conto su cui vengono accreditati i fondi.
Descrizione Identifica il conto di destinazione. Come il conto del pagatore, è fondamentale per la vista di rilevamento dei pagamenti duplicati e consente di indirizzare correttamente l’analisi verso specifici rapporti con i beneficiari. Nel monitoraggio del rispetto degli orari limite, conoscere il beneficiario può aiutare a dare priorità ai fornitori strategici o ai regolamenti critici che non devono subire ritardi. Perché è importante Essenziale per individuare i duplicati e analizzare i beneficiari. Dove reperirli Dettagli della transazione, colonna Credit Account o Beneficiary. Esempi 555000111222333444BEN-882-11
	Numero di conto del pagatore PayerAccountNumber	Numero del conto da cui vengono addebitati i fondi.
Descrizione Identifica il conto di origine del pagamento. È un elemento chiave della vista di rilevamento dei pagamenti duplicati. Insieme al beneficiario, all’importo e all’ora, forma l’impronta univoca utilizzata per individuare i doppi pagamenti accidentali. Consente inoltre di analizzare il volume dei pagamenti per conto di origine e individuare i portafogli interni più attivi. Perché è importante Essenziale per individuare i duplicati e analizzare le frodi. Dove reperirli Dettagli della transazione, colonna Debit Account. Esempi 123456789987654321ACC-001-992
	Utente che elabora ProcessingUser	ID utente o agente di sistema responsabile dell’attività.
Descrizione Identifica chi ha eseguito l’azione specifica, che si tratti di un approvatore o di un bot di automazione del sistema. Questi dati alimentano le Dashboard sull’efficienza del ciclo di risoluzione degli errori e sul throughput dell’autorità di approvazione. Tracciando gli utenti, gli analisti possono individuare esigenze di formazione per chi registra un numero elevato di errori o rilevare colli di bottiglia dovuti a un carico eccessivo di richieste per specifici approvatori. Perché è importante Consente di analizzare le risorse e individuare i colli di bottiglia. Dove reperirli Registri di audit, colonna User ID. Esempi jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Banca beneficiaria BeneficiaryBank	Nome o identificativo della banca ricevente.
Descrizione Identifica l’istituto finanziario che riceve il pagamento. È utile per analizzare i ritardi nel regolamento, poiché le banche riceventi possono avere tempi di elaborazione o problemi di integrazione diversi. Aggiunge un’ulteriore dimensione alla Dashboard sul divario tra regolamento e riconciliazione, evidenziando se i ritardi dipendono da fattori esterni, specifici della banca, o interni. Perché è importante Analisi delle dipendenze esterne. Dove reperirli Dettagli della transazione, colonna Bank ID o Name. Esempi ChaseBank of AmericaWells FargoCitibank
	È una rilavorazione IsRework	Indicatore che segnala se questa specifica attività fa parte di un ciclo di rilavorazione.
Descrizione Indicatore booleano che contrassegna le attività svolte dopo l’identificazione di un errore e prima della sua risoluzione, oppure le attività ripetute. Supporta il KPI del tasso di rilavorazione nella convalida dei pagamenti. Consente agli analisti di filtrare la mappa del processo per visualizzare solo il percorso ottimale oppure, al contrario, concentrarsi sul percorso di rilavorazione per comprendere le modalità di errore. Perché è importante Distingue il lavoro che crea valore da quello dedicato alle correzioni. Dove reperirli Calcolato in base ai cicli del processo. Esempi truefalse
	Livello di approvazione ApprovalLevel	Livello gerarchico richiesto o utilizzato per autorizzare il pagamento.
Descrizione Indica il livello di anzianità o autorità associato all’attività «Pagamento approvato». Viene utilizzato nella Dashboard sul throughput dell’autorità di approvazione per verificare se gli approvatori di livello superiore stanno diventando colli di bottiglia. Comprendere come si distribuiscono i pagamenti tra i diversi livelli, ad esempio Livello 1 e Livello 3, aiuta a ottimizzare le politiche di delega dell’autorità. Perché è importante Segmenta i colli di bottiglia nell’approvazione in base alla gerarchia. Dove reperirli Tabelle dei ruoli utente o dei flussi di lavoro di approvazione. Esempi Livello 1ResponsabileDirettoreCFO
	Orario limite non rispettato IsCutoffMissed	Indicatore che segnala se il pagamento è stato inviato dopo l’orario limite giornaliero della banca.
Descrizione Valore booleano calcolato confrontando l’ora di «Istruzione di pagamento inviata» con l’orario limite giornaliero previsto per la valuta e il metodo specifici. Supporta il KPI del tasso di rispetto degli orari limite. Individuare gli orari limite non rispettati aiuta a risalire alle cause profonde dei ritardi, che possono dipendere da un avvio tardivo o da un’elaborazione interna lenta. Perché è importante Fondamentale per la conformità operativa e la gestione della liquidità. Dove reperirli Calcolato confrontando EventTimestamp con la tabella di riferimento degli orari limite. Esempi truefalse
	Unità aziendale BusinessUnit	Dipartimento o divisione che ha avviato il pagamento.
Descrizione Classifica il pagamento in base all’unità organizzativa responsabile della spesa. Aiuta ad allocare i costi e a capire quali aree dell’organizzazione generano più rilavorazioni manuali o errori. Supporta l’audit di conformità del percorso di pagamento, verificando che le diverse unità rispettino i requisiti normativi o di controllo interno a cui sono soggette. Perché è importante Fornisce il contesto organizzativo necessario per analizzare le prestazioni. Dove reperirli Mappatura dei centri di costo o codice del dipartimento. Esempi Servizi bancari al dettaglioFinanziamenti alle impreseGestione patrimonialeOperazioni

Obbligatorio Consigliato Facoltativo

Attività di elaborazione dei pagamenti

Registri nell’Event Log questi passaggi e queste tappe essenziali del processo per individuare e ottimizzare con precisione i flussi di lavoro dei pagamenti.

5 Consigliato 8 Facoltativo

	Attività	Descrizione
	Istruzione di pagamento inviata	Invio del file di pagamento, ad esempio un lotto ACH o un messaggio Wire, alla rete esterna o alla stanza di compensazione. È un punto di passaggio fondamentale.
Perché è importante Fondamentale per il «Monitoraggio della conformità agli orari limite di elaborazione». Garantisce che l’organizzazione rispetti gli orari limite bancari giornalieri. Dove reperirli Registri dell’elaborazione in batch o timestamp di generazione dei file. Spesso registrati come «Lotto creato» o «File trasmesso». Acquisizione Registrato al momento della generazione del file batch Tipo di evento explicit
	Pagamento approvato	Decisione manuale o automatizzata che autorizza il pagamento in base ai limiti di delega. L’evento viene registrato quando un utente autorizzato o una regola di sistema aggiorna il flag di approvazione.
Perché è importante È fondamentale per l’'analisi dei tempi di ciclo delle autorizzazioni'. I ritardi in questa fase indicano colli di bottiglia nella catena di approvazione. Dove reperirli Registri di audit che mostrano l’azione di un utente che modifica lo stato da 'Pending Approval' a 'Approved'. Acquisizione Registrato al momento dell’approvazione Tipo di evento explicit
	Pagamento regolato	Il trasferimento dei fondi viene completato e registrato nel libro mastro generale. Dal punto di vista della banca, questo segna il completamento finanziario della transazione.
Perché è importante È il principale punto di arrivo per il «Tasso di elaborazione senza intervento manuale». Indica che il denaro è stato effettivamente trasferito. Dove reperirli Stato della transazione «Registrata» o presenza di un timestamp «Data di registrazione» nel libro mastro. Acquisizione Registrato al momento della registrazione nel libro mastro generale Tipo di evento explicit
	Pagamento riconciliato	Abbinamento interno della transazione agli estratti conto bancari o ai file di regolamento. Completa il ciclo contabile.
Perché è importante Necessario per il «Divario tra regolamento e riconciliazione». Garantisce la corretta chiusura dei libri contabili. Dove reperirli Registri del modulo di riconciliazione, in cui lo stato viene aggiornato a «Abbinato» o «Riconciliato». Acquisizione Registrato al completamento dell’abbinamento di riconciliazione Tipo di evento explicit
	Richiesta di pagamento creata	Inserimento iniziale della disposizione di pagamento nel sistema Fiserv. L’evento viene registrato esplicitamente quando un utente o un sistema esterno avvia una transazione tramite API o interfaccia.
Perché è importante Segna l’inizio della cronologia del processo. È essenziale per calcolare il tempo di ciclo totale e individuare i colli di bottiglia nella fase di acquisizione. Dove reperirli Data e ora di creazione della riga nella tabella dello storico delle transazioni. Cerchi il record più vecchio associato allo specifico Payment Transaction ID. Acquisizione Registrato al momento dell’inserimento del record della transazione Tipo di evento explicit
	Dati di pagamento convalidati	Il sistema controlla i numeri di conto, i codici bancari e la conformità del formato. In genere, l’evento si deduce quando una transazione passa dallo stato ricevuto a quello in sospeso o approvato senza generare errori.
Perché è importante Indica che è stato superato il primo controllo automatizzato. Un errore in questa fase segnala problemi di qualità dei dati, non di liquidità o approvazione. Dove reperirli Dedotto da un cambiamento di stato da 'Received' a 'Pending' o 'Ready' entro un breve intervallo di tempo. Acquisizione Confrontare il campo di stato prima e dopo Tipo di evento inferred
	Errore di pagamento individuato	Registra il momento in cui una transazione viene contrassegnata con uno stato di errore o un codice di eccezione. Ciò avviene quando le regole di convalida non vengono superate o i controlli esterni restituiscono un esito negativo.
Perché è importante È fondamentale per la Dashboard 'Validation Error and Rework Tracker'. Un volume elevato di eventi in questa fase indica problemi di qualità dei dati nelle fasi precedenti. Dove reperirli Il campo dello stato della transazione cambia e assume un codice di eccezione, ad esempio 'Invalid', 'Hold' o 'Error'. Acquisizione Registrato quando lo stato cambia in Error Tipo di evento explicit
	Errore di pagamento risolto	Indica la correzione di una transazione che aveva generato un errore. L’evento si deduce quando la transazione passa da uno stato di errore a uno stato di elaborazione o valido.
Perché è importante È essenziale per calcolare il 'tempo medio di risoluzione degli errori di pagamento' e misurare l’efficienza del team operativo. Dove reperirli Dedotto quando lo stato della transazione passa da un codice di errore a un normale codice di elaborazione. Acquisizione Confrontare il campo di stato prima e dopo Tipo di evento inferred
	Notifica di pagamento inviata	Il sistema invia un messaggio (e-mail/SMS) al pagatore o al beneficiario per confermare la transazione. In questo modo, il cliente dispone di informazioni più chiare.
Perché è importante Supporta la «Rapidità e tempestività delle notifiche». Intervalli prolungati dopo il regolamento riducono la fiducia dei clienti. Dove reperirli Registri delle comunicazioni o tabelle della cronologia delle interazioni con i clienti collegate all’ID della transazione. Acquisizione Registrato all’invio dell’e-mail/SMS Tipo di evento explicit
	Pagamento annullato	Interruzione del flusso di pagamento prima del regolamento, avviata da un utente o da una regola di sistema. Blocca ogni ulteriore elaborazione.
Perché è importante Individua attività inutili e abbandonate. Un tasso elevato di annullamenti dopo l’approvazione può indicare inefficienze nel processo. Dove reperirli Cambio di stato in «Annullato», «Stornato» o «Interrotto». Acquisizione Registrato quando lo stato passa ad Annullato Tipo di evento explicit
	Pagamento autorizzato	Conferma interna finale che attesta la disponibilità dei fondi e autorizza l’esecuzione della transazione. Può avvenire contemporaneamente all’approvazione oppure come controllo di sistema separato.
Perché è importante Distingue tra approvazione manageriale e autorizzazione a livello di sistema. È importante per la Dashboard «Throughput dell’autorità di approvazione». Dove reperirli Cambio di stato che indica «Autorizzato» o «Pronto per la registrazione». Acquisizione Confrontare il campo di stato prima e dopo Tipo di evento inferred
	Pagamento confermato	Ricezione di una conferma positiva (ACK) dalla rete esterna o dal gateway. Conferma che l’istruzione è stata ricevuta correttamente dall’entità successiva.
Perché è importante Verifica che l’«Istruzione inviata» sia andata a buon fine. Eventuali lacune in questa fase indicano problemi di connettività di rete o di formato esterno. Dove reperirli Registri di elaborazione dei file in entrata o codici di risposta API che confermano la ricezione. Acquisizione Registrato alla ricezione dell’ACK Tipo di evento explicit
	Pagamento programmato	Si verifica quando un pagamento viene approvato, ma trattenuto fino a una data di valuta futura. Il sistema accoda la transazione finché non si apre la finestra di elaborazione.
Perché è importante Spiega i tempi di inattività nel processo. Distingue tra un ritardo dovuto a un collo di bottiglia e un’attesa intenzionale fino alla data di scadenza. Dove reperirli Confronto tra «Data di inserimento» e «Data di valuta». Se la data di valuta è futura, questo stato è attivo. Acquisizione Derivato dal confronto tra il campo X e il campo Y Tipo di evento calculated

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Fiserv

Passaggi

1. Configurazione preliminare

Verifichi di avere accesso al portale per sviluppatori Fiserv Commerce Hub. Dovrà generare una chiave API e un segreto API (talvolta denominati Client ID e Client Secret) con le autorizzazioni per accedere all’API Transaction Inquiry o Search. Se sono attive restrizioni IP, verifichi che il Suo indirizzo IP sia inserito nell’elenco degli indirizzi autorizzati nell’ambiente Fiserv.

2. Configurazione dell’ambiente

Installi Python 3.8 o versioni successive sul server di estrazione o sul computer locale. Le serviranno le librerie requests e pandas, installabili con pip: pip install requests pandas. Crei una cartella di lavoro per lo script e i file di output.

3. Configurazione dello script

Scarichi lo script Python fornito nella cartella di lavoro. Lo apra e aggiorni la sezione di configurazione iniziale. Inserisca i valori specifici di API_KEY, API_SECRET e BASE_URL (utilizzi l’URL sandbox per i test e quello di produzione per l’esecuzione finale). Modifichi START_DATE e END_DATE in modo da includere il periodo di Process Mining desiderato.

4. Implementazione della logica di autenticazione

Lo script include una classe di supporto per gestire i requisiti di autenticazione specifici di Fiserv, che in genere prevedono la generazione di una firma HMAC usando il segreto API, il timestamp e il contenuto della richiesta. Non modifichi la logica di generazione della firma, a meno che la Sua implementazione Fiserv non utilizzi uno standard diverso, ad esempio i token bearer OAuth2.

5. Comprensione della logica di analisi

Lo script interroga l’API per recuperare le transazioni. In genere, l’API restituisce un’istantanea dell’oggetto transazione con diversi timestamp, ad esempio l’ora di invio, di autorizzazione e di regolamento. Lo script analizza questo singolo oggetto JSON e lo suddivide in più righe (eventi) per l’Event Log. Per esempio, un singolo record JSON con un timestamp di invio e uno di regolamento genera almeno due righe distinte nel file CSV.

6. Gestione della paginazione

Lo script utilizza un ciclo per gestire la paginazione. Le API Fiserv limitano il numero di record per risposta (spesso 50 o 100). Lo script richiede automaticamente la pagina successiva finché non recupera tutte le transazioni nell’intervallo di date. Si assicuri che la connessione Internet sia stabile, poiché il recupero di grandi insiemi di dati può richiedere tempo.

7. Esecuzione

Esegua lo script dalla riga di comando: python fiserv_extraction.py. La console mostrerà l’avanzamento, indicando il numero di pagine elaborate e di transazioni recuperate. Presti attenzione agli errori HTTP 401 (Unauthorized) o 429 (Rate Limit).

8. Verifica dei risultati

Al termine dello script, controlli che nella cartella sia presente il file fiserv_event_log.csv. Lo apra e verifichi che la colonna ActivityName contenga una combinazione delle 13 attività richieste e che il campo EventTimestamp sia formattato correttamente.

9. Elaborazione successiva (facoltativa)

Se deve applicare specifiche conversioni di fuso orario, ad esempio convertire l’ora UTC in quella locale, può modificare la sezione di trasformazione pandas dello script oppure gestire la conversione in ProcessMind dopo il caricamento.

10. Caricamento in ProcessMind

Importi il file CSV in ProcessMind. Mappi PaymentTransactionId su ID caso, ActivityName su Attività e EventTimestamp su Timestamp. Verifichi che le colonne numeriche, come PaymentAmount, siano mappate come attributi.

Configurazione

Credenziali API: sono necessarie una chiave API e un segreto o segreto condiviso. Verifichi che consentano l’accesso in lettura agli endpoint di reportistica delle transazioni.
URL di base: imposti https://api.commerce.fiserv.com per l’ambiente di produzione oppure l’URL specifico per certificazione o sandbox fornito durante l’attivazione.
Intervallo di date: a causa delle dimensioni dei dati restituiti dall’API, si consiglia di estrarre dati relativi a un periodo da 30 a 90 giorni. Per i caricamenti storici, esegua lo script suddividendo i dati per mese.
Dimensione della pagina: configurata su 100 record per chiamata, per bilanciare l’uso della memoria e il carico di rete.
Fuso orario: l’API restituisce timestamp in UTC. Lo script mantiene questo standard per garantire coerenza tra le diverse aree geografiche.
Nuovi tentativi: è incluso un meccanismo di base per ripetere le richieste in caso di timeout di rete intermittenti (HTTP 500/502/503).

a Query di esempio python

import requests
import json
import time
import hmac
import hashlib
import base64
import uuid
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
API_KEY = class="hl-string">"YOUR_API_KEY"
API_SECRET = class="hl-string">"YOUR_API_SECRET"
BASE_URL = class="hl-string">"https://cert.api.fiservapps.com"  class=class="hl-string">"hl-comment"># Update to Production URL as needed
ENDPOINT = class="hl-string">"/ch/payments/v1/transaction-inquiry"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
PAGE_SIZE = 50
OUTPUT_FILE = class="hl-string">"fiserv_event_log.csv"

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># AUTHENTICATION HELPER
class=class="hl-string">"hl-comment"># ==========================================
def generate_headers(payload):
    class=class="hl-string">"hl-comment"># Fiserv Commerce Hub typically requires HMAC auth
    class=class="hl-string">"hl-comment"># This is a standard implementation pattern
    client_request_id = str(uuid.uuid4())
    timestamp = str(int(time.time() * 1000))
    
    class=class="hl-string">"hl-comment"># specific signature construction depends on Fiserv documentation version
    class=class="hl-string">"hl-comment"># standard pattern: apiKey + reqId + timestamp + payload
    raw_signature = API_KEY + client_request_id + timestamp + payload
    
    hmac_obj = hmac.new(
        API_SECRET.encode(class="hl-string">'utf-8'),
        raw_signature.encode(class="hl-string">'utf-8'),
        hashlib.sha256
    )
    message_signature = base64.b64encode(hmac_obj.digest()).decode(class="hl-string">'utf-8')
    
    return {
        class="hl-string">"Content-Type": class="hl-string">"application/json",
        class="hl-string">"Client-Request-Id": client_request_id,
        class="hl-string">"Api-Key": API_KEY,
        class="hl-string">"Timestamp": timestamp,
        class="hl-string">"Message-Signature": message_signature
    }

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># PARSING LOGIC (UNPIVOTING EVENTS)
class=class="hl-string">"hl-comment"># ==========================================
def extract_events_from_transaction(tx):
    events = []
    
    class=class="hl-string">"hl-comment"># Base Attributes
    case_id = tx.get(class="hl-string">"transactionId", class="hl-string">"")
    amount = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"total", 0.0)
    currency = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"currency", class="hl-string">"USD")
    method = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"type", class="hl-string">"Unknown")
    payer_acc = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"maskedAccountNumber", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Identifying common attributes
    base_data = {
        class="hl-string">"PaymentTransactionId": case_id,
        class="hl-string">"SourceSystem": class="hl-string">"Fiserv Commerce Hub",
        class="hl-string">"LastDataUpdate": datetime.utcnow().isoformat(),
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentMethod": method,
        class="hl-string">"PayerAccountNumber": payer_acc,
        class="hl-string">"PayeeAccountNumber": class="hl-string">"MerchantAccount", class=class="hl-string">"hl-comment"># Placeholder
        class="hl-string">"ErrorCode": tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseCode", class="hl-string">""),
        class="hl-string">"IsStraightThroughProcessing": class="hl-string">"True" class=class="hl-string">"hl-comment"># Default assumption unless error found
    }

    class=class="hl-string">"hl-comment"># Helper to append event
    def add_event(activity, timestamp_str, specific_attrs={}):
        if timestamp_str:
            row = base_data.copy()
            row.update({
                class="hl-string">"ActivityName": activity,
                class="hl-string">"EventTimestamp": timestamp_str
            })
            row.update(specific_attrs)
            events.append(row)

    class=class="hl-string">"hl-comment"># 1. Payment Request Created (Submission Time)
    submission_time = tx.get(class="hl-string">"submissionTime")
    add_event(class="hl-string">"Payment Request Created", submission_time)

    class=class="hl-string">"hl-comment"># 2. Payment Details Validated (Inferred: slightly after submission if no immediate 400 error)
    class=class="hl-string">"hl-comment"># We infer this exists if the transaction exists and has a submission time
    if submission_time:
        class=class="hl-string">"hl-comment"># Infer validation happened 1 second after submission
        val_time = (datetime.fromisoformat(submission_time.replace(class="hl-string">'Z', class="hl-string">'+00:00')) + timedelta(seconds=1)).isoformat()
        add_event(class="hl-string">"Payment Details Validated", val_time)

    class=class="hl-string">"hl-comment"># 3. Payment Error Identified / 4. Resolved
    status = tx.get(class="hl-string">"transactionStatus", class="hl-string">"")
    if status == class="hl-string">"FAILED":
        fail_time = tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseTimestamp", submission_time)
        add_event(class="hl-string">"Payment Error Identified", fail_time, {class="hl-string">"IsStraightThroughProcessing": class="hl-string">"False"})
    elif status == class="hl-string">"APPROVED" and tx.get(class="hl-string">"retryCount", 0) > 0:
        class=class="hl-string">"hl-comment"># Logic: If approved but had retries, an error was resolved
        add_event(class="hl-string">"Payment Error Resolved", submission_time) class=class="hl-string">"hl-comment"># Simplified assumption

    class=class="hl-string">"hl-comment"># 5. Payment Approved
    approval_time = tx.get(class="hl-string">"approvalTime")
    if approval_time:
        add_event(class="hl-string">"Payment Approved", approval_time)

    class=class="hl-string">"hl-comment"># 6. Payment Authorized
    auth_time = tx.get(class="hl-string">"authorizationTime")
    class=class="hl-string">"hl-comment"># If separate auth time not provided, use approval time
    if not auth_time and approval_time:
        auth_time = approval_time
    add_event(class="hl-string">"Payment Authorized", auth_time)

    class=class="hl-string">"hl-comment"># 7. Payment Scheduled (if future dated)
    req_exec_date = tx.get(class="hl-string">"requestedExecutionDate")
    if req_exec_date and req_exec_date > submission_time:
         add_event(class="hl-string">"Payment Scheduled", submission_time)

    class=class="hl-string">"hl-comment"># 8. Payment Instruction Sent
    gateway_time = tx.get(class="hl-string">"gatewayTransmitTime")
    add_event(class="hl-string">"Payment Instruction Sent", gateway_time)

    class=class="hl-string">"hl-comment"># 9. Payment Confirmed (Gateway ACK)
    gateway_ack = tx.get(class="hl-string">"gatewayAckTime")
    add_event(class="hl-string">"Payment Confirmed", gateway_ack)

    class=class="hl-string">"hl-comment"># 10. Payment Settled
    settle_time = tx.get(class="hl-string">"settlementTime") or tx.get(class="hl-string">"fundingDate")
    add_event(class="hl-string">"Payment Settled", settle_time)

    class=class="hl-string">"hl-comment"># 11. Payment Notification Sent (Inferred or specific field)
    notify_time = tx.get(class="hl-string">"customerNotificationEmailTime")
    add_event(class="hl-string">"Payment Notification Sent", notify_time)

    class=class="hl-string">"hl-comment"># 12. Payment Reconciled
    recon_time = tx.get(class="hl-string">"reconciliationDate")
    add_event(class="hl-string">"Payment Reconciled", recon_time)

    class=class="hl-string">"hl-comment"># 13. Payment Cancelled
    if status == class="hl-string">"VOIDED" or status == class="hl-string">"CANCELLED":
        void_time = tx.get(class="hl-string">"voidTime") or tx.get(class="hl-string">"lastUpdateTime")
        add_event(class="hl-string">"Payment Cancelled", void_time)

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXTRACTION LOOP
class=class="hl-string">"hl-comment"># ==========================================
def main():
    all_events = []
    page_number = 1
    has_more = True
    
    print(fclass="hl-string">"Starting extraction from {START_DATE} to {END_DATE}...")

    while has_more:
        class=class="hl-string">"hl-comment"># Construct Search Payload
        payload_dict = {
            class="hl-string">"startDate": START_DATE,
            class="hl-string">"endDate": END_DATE,
            class="hl-string">"page": page_number,
            class="hl-string">"limit": PAGE_SIZE
        }
        payload_json = json.dumps(payload_dict)
        
        headers = generate_headers(payload_json)
        full_url = BASE_URL + ENDPOINT
        
        try:
            response = requests.post(full_url, headers=headers, data=payload_json)
            
            if response.status_code == 200:
                data = response.json()
                transactions = data.get(class="hl-string">"reports", []) class=class="hl-string">"hl-comment"># Key depends on specific endpoint schema
                
                if not transactions:
                    print(fclass="hl-string">"No transactions found on page {page_number}. Finishing.")
                    has_more = False
                    break
                
                print(fclass="hl-string">"Processing page {page_number}, found {len(transactions)} transactions.")
                
                for tx in transactions:
                    events = extract_events_from_transaction(tx)
                    all_events.extend(events)
                
                class=class="hl-string">"hl-comment"># Pagination Check
                total_pages = data.get(class="hl-string">"totalPages", page_number)
                if page_number >= total_pages:
                    has_more = False
                else:
                    page_number += 1
            else:
                print(fclass="hl-string">"Error fetching data: {response.status_code} - {response.text}")
                has_more = False
                
        except Exception as e:
            print(fclass="hl-string">"Exception occurred: {str(e)}")
            has_more = False

    class=class="hl-string">"hl-comment"># ==========================================
    class=class="hl-string">"hl-comment"># EXPORT TO CSV
    class=class="hl-string">"hl-comment"># ==========================================
    if all_events:
        df = pd.DataFrame(all_events)
        class=class="hl-string">"hl-comment"># Column ordering
        cols = [
            class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 
            class="hl-string">"SourceSystem", class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentMethod",
            class="hl-string">"PayerAccountNumber", class="hl-string">"ErrorCode", class="hl-string">"IsStraightThroughProcessing"
        ]
        class=class="hl-string">"hl-comment"># Ensure columns exist even if empty
        for c in cols:
            if c not in df.columns:
                df[c] = None
                
        df = df[cols]
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">"Extraction complete. {len(df)} rows written to {OUTPUT_FILE}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    main()

È pronto a iniziare?

Inizi a ottimizzare i flussi di lavoro finanziari applicando questo template al Suo ambiente Fiserv. Il nostro approccio guidato La aiuta a individuare i dati necessari per apportare miglioramenti concreti al flusso di cassa e alla conformità operativa.

Torna alla guida al miglioramento Scarica il template

Ottimizzi l’elaborazione dei pagamenti e raggiunga oggi il 98% di STP

Riduca i ritardi di riconciliazione e gestisca al meglio i flussi di lavoro Fiserv.

Inizi la prova gratuita

Non è richiesta la carta di credito. La configurazione richiede pochi minuti.

Il Suo template dei dati per l’elaborazione dei pagamenti

Il Suo template dei dati per l’elaborazione dei pagamenti

Attributi dell’elaborazione dei pagamenti

Attività di elaborazione dei pagamenti

Guide all’estrazione

Script Python per l’API Fiserv Commerce Hub

Passaggi

1. Configurazione preliminare

2. Configurazione dell’ambiente

3. Configurazione dello script

4. Implementazione della logica di autenticazione

5. Comprensione della logica di analisi

6. Gestione della paginazione

7. Esecuzione

8. Verifica dei risultati

9. Elaborazione successiva (facoltativa)

10. Caricamento in ProcessMind

Configurazione

a Query di esempio python

È pronto a iniziare?

Ottimizzi l’elaborazione dei pagamenti e raggiunga oggi il 98% di STP

La Sua privacy è importante