> Continue procesverbetering > Betalingsverwerkingingng > Fiserv > Datatemplate

Uw betalingsverwerking datatemplate

Name: Betalingsverwerkingingng Process Mining Data Template
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

← Terug naar Verbetergids

Attributen Betalingsverwerkingingng (19) Activiteiten Betalingsverwerkingingng (13) Extractiegidsen (1)

Uw betalingsverwerking datatemplate

Deze template biedt een gestructureerd raamwerk om je te helpen uw Fiserv data te mappen naar een formaat dat geschikt is voor process mining en analyse. Het schetst de essentiële attributen en activiteiten die nodig zijn om helder inzicht te krijgen in je verrekenings- en reconciliatiecycli. Door deze handleiding te volgen, kunt u een betrouwbare event log creëren die inefficiënties en compliancerisico's binnen je financiële operaties benadrukt.

Aanbevolen attributen voor betalingsanalyse
Belangrijke stappen in het proces om te monitoren
Technische handvaten voor Fiserv data-extractie

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Attributen Betalingsverwerkingingng

Deze aanbevolen velden bieden de benodigde context voor uw event log ter ondersteuning van een grondige analyse van uw gehele betalingslevenscyclus.

5 Verplicht 9 Aanbevolen 5 Optioneel

	Naam	Beschrijving
	Activiteitsnaam ActivityName	Het specifieke gebeurtenis of de statuswijziging die plaatsvond in het betalingsproces.
Beschrijving Dit attribuut beschrijft de uitgevoerde stap, zoals 'Betalingsaanvraag aangemaakt' of 'Betaling verrekend'. Het definieert de stappen in de proceskaart en is belangrijk voor het begrijpen van de volgorde van bewerkingen. Door de afzonderlijke activiteiten te analyseren, kunnen organisaties de workflow visualiseren, overgeslagen stappen vinden en niet-conforme paden detecteren waar verplichte validaties of goedkeuringen werden omzeild. Waarom het belangrijk is Definieert de gebeurtenissen die de procestijdlijn vormen. Waar te verkrijgen Transactiehistorie log of audit tabellen voor statuswijzigingen. Voorbeelden Betalingsaanvraag aangemaaktBetaling geautoriseerdBetalingsfout geïdentificeerdBetaling afgewikkeldBetaling geannuleerd
	Payment Transaction ID PaymentTransactionId	De unieke ID voor de specifieke betalingsinstructie of transactiecase.
Beschrijving Dit attribuut dient als de centrale sleutel voor het koppelen van alle activiteiten binnen één betalingslevenscyclus. Het stelt analysesten in staat het traject te volgen van de initiële aanvraag via validatie, goedkeuring en uiteindelijke verrekening of annulering. In Fiserv-omgevingen is dit doorgaans de primary key in de transactiehistorietabellen. Het is belangrijk voor het reconstrueren van de processtroom en om ervoor te zorgen dat losgekoppelde gebeurtenissen (zoals verrekening die dagen na autorisatie plaatsvindt) correct worden gekoppeld aan hetzelfde bedrijfsobject. Waarom het belangrijk is Het is de fundamentele Case-ID die nodig is om gebeurtenissen te groeperen in procesinstanties. Waar te verkrijgen Raadpleeg de Fiserv-documentatie voor Transactie- of Betalingsheadertabellen. Voorbeelden TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Tijdstempel EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Beschrijving Dit attribuut registreert het precieze moment waarop een gebeurtenis plaatsvond. Dit vormt de basis voor alle temporele analyse, inclusief cyclustijden, doorlooptijden en knelpuntidentificatie. In dashboards drijft deze data de berekening van de duur tussen stappen aan, zoals de tijd van 'Betalingsaanvraag aangemaakt' tot 'Betaling geautoriseerd'. Tijdstempels met hoge precisie zijn noodzakelijk om gebeurtenissen die snel achter elkaar plaatsvinden nauwkeurig te ordenen. Waarom het belangrijk is Verplicht om gebeurtenissen te ordenen en de duur van de procesprestaties te berekenen. Waar te verkrijgen Auditlogs of tijdstempelkolommen voor transactie-updates. Voorbeelden 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Bronsysteem SourceSystem	De naam van het systeem waar de data vandaan komt.
Beschrijving Identificeert de specifieke Fiserv-module of extern systeem dat de gebeurtenis heeft gegenereerd. Dit is bijzonder nuttig in complexe landschappen waar betalingen kunnen ontstaan in een front-end kanaal en afgewikkeld worden in een back-end core banking systeem. Het stelt analysesten in staat om de procesweergave te filteren op systeem van herkomst, waardoor analyse kan worden gericht op specifieke technische omgevingen of integratiepunten. Waarom het belangrijk is Biedt technische context en data lineage. Waar te verkrijgen Hardcoded tijdens extractie of systeemmetadata. Voorbeelden Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Tijdstip van extractie LastDataUpdate	De timestamp van de laatste extractie of verversing van het record.
Beschrijving Geeft de relevantie aan van de data die wordt gebruikt voor analyse. Dit is belangrijk om te bepalen of de dashboards real-time operaties of historische snapshots weergeven. Het helpt gebruikers de getoonde meetwaarden te vertrouwen, waardoor wordt gewaarborgd dat zij geen beslissingen nemen op basis van verouderde data, vooral bij het monitoren van cutoff compliance of actieve knelpunten. Waarom het belangrijk is Zorgt voor relevantie van de data en betrouwbaarheid. Waar te verkrijgen Systeemtijd op het moment van ETL-uitvoering. Voorbeelden 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Begunstigde Rekeningnummer PayeeAccountNumber	Het rekeningnummer waarop fondsen worden bijgeschreven.
Beschrijving Identificeert de bestemmingsrekening. Net als de betalersrekening is dit belangrijk voor de weergave van dubbele betalingsdetectie. Het zorgt ervoor dat de analyse correct specifieke begunstigde-relaties target. Bij cutoff compliance monitoring kan het kennen van de begunstigde helpen strategische leveranciers of kritieke afwikkelingen die niet mogen mislukken te prioriteren. Waarom het belangrijk is Essentieel voor duplicaatdetectie en begunstigdeanalyse. Waar te verkrijgen Transactiedetails, Kolom Creditrekening of Begunstigde. Voorbeelden 555000111222333444BEN-882-11
	Betaalbedrag PaymentAmount	De financiële waarde van de betalingstransactie.
Beschrijving Dit attribuut vertegenwoordigt de financiële waarde die geassocieerd is met de betaling. Het is een primaire dimensie voor het segmenteren van analyse, waardoor gebruikers onderscheid kunnen maken tussen strategische betalingen met hoogwaardige en routinetransacties met lage waarde. Het is belangrijk voor de Dupliceren Payment Detection View, waar identieke bedragen gepaard met betaler/ontvanger details potentiële fouten markeren. Het ondersteunt ook goedkeuringsautoriteitsanalyse, aangezien hogere bedragen vaak verschillende workflow-paden activeren. Waarom het belangrijk is Belangrijk voor financiële risicoanalyse en duplicaatdetectie. Waar te verkrijgen Transactie header tabel, Kolom Bedrag. Voorbeelden 150.0025000.5010.991000000.00
	Betaler Rekeningnummer PayerAccountNumber	Het rekeningnummer waarvan gelden worden gedebiteerd.
Beschrijving Identificeert de bronrekening voor de betaling. Dit is een belangrijk onderdeel van de weergave voor dubbele betalingsdetectie. In combinatie met begunstigde, bedrag en tijd vormt het de unieke vingerafdruk die wordt gebruikt om onbedoelde dubbele betalingen te detecteren. Het maakt ook analyse van het betalingsvolume per oorspronkelijke rekening mogelijk om de meest actieve interne portfolio's te vinden. Waarom het belangrijk is Essentieel voor duplicaatdetectie en fraudeanalyse. Waar te verkrijgen Transactiedetails, Kolom Debetrekening. Voorbeelden 123456789987654321ACC-001-992
	Foutcode ErrorCode	De specifieke code die wordt gegenereerd wanneer een betaling de validatie faalt.
Beschrijving Vastlegging van de technische of zakelijke foutcode die hoort bij 'Payment Error Identified' activiteiten. Dit attribuut is de basis van de Validation Error en Rework Tracker. Door frequenties van specifieke foutcodes te aggregeren, kan de organisatie systemische data-kwaliteitsproblemen (bijv. 'Ongeldig routeringsnummer') opsporen en gerichte oplossingen implementeren voor validatielogica of gebruikerstraining. Waarom het belangrijk is Identificeert de hoofdoorzaken van rework. Waar te verkrijgen Foutlogs of transactiestatusdetails. Voorbeelden E-101INV_ACCNSF_ERRAUTH_FAIL
	Is STP IsStraightThroughProcessing	Vlag die aangeeft of de betaling geen handmatige tussenkomst vereiste.
Beschrijving Een berekend booleaans attribuut dat waar is als de case geen 'Payment Error Identified', 'Payment Error Opgelost' of handmatige 'Payment Approved' stappen bevat (afhankelijk van de definitie). Dit helpt bij de KPI voor het Straight Through Processing (STP) percentage. Het maakt binaire segmentatie van het proces mogelijk: puur geautomatiseerde flows versus flows die menselijke tussenkomst vereisen, wat een duidelijk beeld geeft van het automatiseringspotentieel. Waarom het belangrijk is Kernmetriek voor procesefficiëntie en automatiseringssucces. Waar te verkrijgen Berekend tijdens data-transformatie. Voorbeelden truefalse
	Payment Method PaymentMethod	Het mechanisme dat gebruikt wordt om de betaling uit te voeren (bijv. Wire, ACH).
Beschrijving Classificeert de transactie op basis van het verwerkingskanaal (processing rail). Dit attribuut is onmisbaar voor de Autorisation Cycle Time Analysis, aangezien verschillende methoden aanzienlijk uiteenlopende standaard operationele procedures en service level agreements hebben. Het analyseren van procesvarianten per betaalmethode helpt te isoleren of vertragingen systemisch zijn voor een specifiek kanaal (zoals internationale overboekingen) of algemeen voor de organisatie. Waarom het belangrijk is Segmenteert processtromen op basis van de gebruikte infrastructuur. Waar te verkrijgen Kolom transactietype of instrumentcode. Voorbeelden WireACHChequeRTPInterne Overdracht
	Processende Gebruiker ProcessingUser	De gebruikers-id of systeemagent die verantwoordelijk is voor de activiteit.
Beschrijving Identificeert wie de specifieke actie heeft uitgevoerd, of het nu een menselijke goedkeurder of een systeemautomatiseringsbot is. Deze data voedt de dashboards voor Error Resolution Cycle Efficiency en Approval Authority Throughput. Door gebruikers te volgen, kunnen analysesten trainingsbehoeften vinden voor personen met hoge foutpercentages of knelpunten herkennen waar specifieke goedkeurders overladen worden met aanvragen. Waarom het belangrijk is Maakt bron-analyse en knelpuntidentificatie mogelijk. Waar te verkrijgen Auditlogs, gebruikers-id kolom. Voorbeelden jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Uiterste betaaldatum PaymentDueDate	De datum waarop de betaling verwerkt moet zijn.
Beschrijving De doeldatum voor de voltooiing van de betaling. Dit wordt gebruikt in de Processing Cutoff Compliance Monitor om transacties te markeren die het risico lopen te laat te zijn. Het vergelijken van de 'Payment Settled' timestamp met dit attribuut maakt de berekening van on-time leveringsmeetwaarden mogelijk en helpt de organisatie het vertrouwen met ontvangers te behouden. Waarom het belangrijk is Referentiepunt voor het meten van de naleving van SLA's. Waar te verkrijgen Details van betalingsinstructie. Voorbeelden 2023-11-012023-11-15
	Valutacode CurrencyCode	De ISO-valutacode voor het betalingsbedrag.
Beschrijving Specificeert de valuta waarin de betaling is gedenomineerd (bijv. USD, EUR). Dit attribuut is belangrijk voor het Valuta and Method Volume Trends dashboard, waardoor de organisatie de blootstellingng aan verschillende buitenlandse valuta kan monitoren. Het wordt ook gebruikt om bedragen te normaliseren voor wereldwijde rapportage en om ervoor te zorgen dat dubbele controles transacties met dezelfde numerieke waarde maar verschillende valuta niet ten onrechte als duplicaten markeren. Waarom het belangrijk is Noodzakelijk voor analyse van multi-valuta verwerking. Waar te verkrijgen Transactie header tabel, Kolom Valuta. Voorbeelden USDEURGBPCADJPY
	Bedrijfseenheid BusinessUnit	De afdeling of divisie die de betaling heeft geïnitieerd.
Beschrijving Categoriseert de betaling per organisatie-eenheid die verantwoordelijk is voor de uitgave. Dit helpt bij het toewijzen van kosten en het begrijpen welke delen van de organisatie de meeste handmatige rework of fouten genereren. Het ondersteunt de Payment Path Compliance Audit door ervoor te zorgen dat verschillende eenheden voldoen aan hun specifieke wettelijke of interne controlevereisten. Waarom het belangrijk is Biedt organisatorische context voor prestaties. Waar te verkrijgen Kosten center mapping of afdelingscode. Voorbeelden Retail BankingZakelijke KredietverleningVermogensbeheerOperationele taken
	Begunstigde Bank BeneficiaryBank	De naam of identificatie van de ontvangende bank.
Beschrijving Identificeert de financiële instelling die de betaling ontvangt. Dit is nuttig voor het analyseren van afwikkelingsvertragingen, aangezien specifieke ontvangende banken verschillende verwerkingssnelheden of integratieproblemen kunnen hebben. Het voegt een andere dimensie toe aan het Settlement to Reconciliation Gap dashboard, en benadrukt of vertragingen extern (bankspecifiek) of intern zijn. Waarom het belangrijk is Externe afhankelijkheidsanalyse. Waar te verkrijgen Transactiedetails, Kolom Bank ID of Naam. Voorbeelden ChaseBank of AmericaWells FargoCitibank
	Goedkeuringsniveau ApprovalLevel	Het hiërarchisch niveau dat vereist of gebruikt wordt voor het autoriseren van de betaling.
Beschrijving Geeft het anciënniteits- of autoriteitsniveau aan dat is gekoppeld aan de activiteit 'Payment Approved'. Dit wordt gebruikt in het Approval Authority Throughput dashboard om te analyseren of goedkeurders op hoger niveau knelpunten worden. Inzicht in de verdeling van betalingen over niveaus (bijv. Niveau 1 versus Niveau 3) helpt bij het optimaliseren van beleid voor bevoegdheidsdelegatie. Waarom het belangrijk is Segmenteert goedkeuringsknelpunten per hiërarchie. Waar te verkrijgen Gebruikersrol of goedkeuringsworkflowtabellen. Voorbeelden Niveau 1ManagerDirecteurCFO
	Is Cutoff Gemist IsCutoffMissed	Vlag die aangeeft of de betaling na de dagelijkse bankafsluiting is verzonden.
Beschrijving Een berekende booleaanse waarde die de 'Payment Instruction Sent' tijd vergelijkt met de dagelijkse cutoff-tijd voor de specifieke valuta/methode. Dit ondersteunt de KPI voor de naleving van cutoff-tijden. Het vinden van gemiste cutoff-tijden helpt bij het onderzoeken van de hoofdoorzaken van vertragingen, of deze nu voortkomen uit late initiatie of trage interne verwerking. Waarom het belangrijk is Belangrijk voor operationele compliance en liquiditeitsbeheer. Waar te verkrijgen Berekend door EventTimestamp te vergelijken met de Cutoff Reference tabel. Voorbeelden truefalse
	Is herstelwerk IsRework	Vlag die aangeeft of deze specifieke activiteit deel uitmaakt van een herstelcyclus.
Beschrijving Een booleaanse vlag die activiteiten markeert die plaatsvinden nadat een fout is geïdentificeerd maar voordat deze is opgelost, of herhaalde activiteiten. Dit ondersteunt de KPI voor het percentage rework bij betalingsvalidatie. Het stelt analysesten in staat om de proceskaart te filteren om alleen het 'happy path' te tonen, of omgekeerd, om zich volledig te richten op het 'herstelwerk path' om faalmodi te begrijpen. Waarom het belangrijk is Isoleert werk dat waarde toevoegt van correctiewerk. Waar te verkrijgen Berekend op basis van proceslussen. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Activiteiten Betalingsverwerkingingng

Leg deze essentiële processtappen en mijlpalen vast in uw event log om nauwkeurige bekijkking en optimalisatie van uw betalingsworkflows mogelijk te maken.

5 Aanbevolen 8 Optioneel

	Activiteit	Beschrijving
	Betaalopdracht Verzonden	De verzending van het betalingsbestand (bijv. ACH batch, Wire message) naar het externe netwerk of clearinghuis. Dit is een kritiek overdrachtspunt.
Waarom het belangrijk is Belangrijk voor de 'Processing Cutoff Compliance Monitor'. Zorgt ervoor dat de organisatie de dagelijkse bankafsluitingen haalt. Waar te verkrijgen Logs van batchverwerking of tijdstempels voor bestandsgeneratie. Vaak gelogd als 'Batch Created' of 'File Transmitted'. Vastleggen Vastgelegd wanneer batchbestand is gegenereerd Gebeurtenistype explicit
	Betaling afgestemd	De interne afstemming van de transactie met bankafschriften of verrekeningsbestanden. Dit sluit de cyclus voor boekhouding.
Waarom het belangrijk is Verplicht voor 'Verrekening naar Reconciliatiekloof'. Zorgt ervoor dat financiële boeken nauwkeurig worden afgesloten. Waar te verkrijgen De reconciliatiemodule registreert waar de status wijzigt naar 'Afgestemd' of 'Gereconcilieerd'. Vastleggen Vastgelegd wanneer reconciliatiematch plaatsvindt Gebeurtenistype explicit
	Betaling afgewikkeld	De fondsstroom is voltooid en geboekt in het grootboek. Dit markeert de financiële voltooiing van de transactie vanuit het perspectief van de bank.
Waarom het belangrijk is Het primaire eindpunt voor 'Straight Through Processing Rate'. Geeft aan dat het geld daadwerkelijk is verplaatst. Waar te verkrijgen Transactiestatus 'Geboekt' of de aanwezigheid van een 'Boekingsdatum' timestamp in het grootboek. Vastleggen Vastgelegd wanneer GL-boeking plaatsvindt Gebeurtenistype explicit
	Betaling goedgekeurd	Een handmatige of geautomatiseerde beslissing om de betaling te laten doorgaan op basis van autoriteitslimieten. Dit wordt vastgelegd wanneer een geautoriseerde gebruiker of systeemregel de goedkeuringsvlag bijwerkt.
Waarom het belangrijk is Sleutel voor de 'Authorization Cycle Time Analysis'. Vertragingen hier duiden op knelpunten in de menselijke goedkeuringsketen. Waar te verkrijgen Auditlogs die een gebruikersactie tonen die de status verandert van 'Wacht op goedkeuring' naar 'Goedgekeurd'. Vastleggen Vastgelegd wanneer goedkeuringsactie is ondernomen Gebeurtenistype explicit
	Betalingsaanvraag aangemaakt	De initiële invoer van de betalingsinstructie in het Fiserv-systeem. Dit wordt expliciet gelogd wanneer een gebruiker of extern systeem een transactie initieert via API of interface.
Waarom het belangrijk is Markeert het begin van de procestijdlijn. Essentieel voor het berekenen van de totale doorlooptijd en het vinden van knelpunten bij de intake. Waar te verkrijgen Timestamp van aanmaak transactiehistorietabel. Zoek naar de vroegste record met de specifieke Payment Transaction ID. Vastleggen Vastgelegd wanneer transacpakketecord is ingevoegd Gebeurtenistype explicit
	`Betaling` bevestigd	Ontvangst van een positieve bevestiging (ACK) van het externe netwerk of de gateway. Dit bevestigt dat de instructie correct is ontvangen door de volgende entiteit.
Waarom het belangrijk is Valideert dat de 'Instructie Verzonden' succesvol was. Hiaten hier duiden op netwerkconnectiviteit of externe formaatproblemen. Waar te verkrijgen Logs van inkomende bestandsverwerking of API-responscodes die ontvangst bevestigen. Vastleggen Vastgelegd wanneer ACK is ontvangen Gebeurtenistype explicit
	Betaling geannuleerd	De beëindiging van een betalingsstroom vóór verrekening, geïnitieerd door een gebruiker of systeemregel. Dit stopt alle verdere verwerking.
Waarom het belangrijk is Identificeert verspilling en verlaten werk. Hoge annuleringspercentages na goedkeuring duiden op procesinefficiënties. Waar te verkrijgen Statuswijziging naar 'Geannuleerd', 'Ongeldig', of 'Gestopt'. Vastleggen Vastgelegd wanneer status verandert naar Geannuleerd Gebeurtenistype explicit
	Betaling geautoriseerd	De definitieve interne bevestiging dat fondsen beschikbaar zijn en de transactie is vrijgegeven voor uitvoering. Dit kan gelijktijdig met goedkeuring plaatsvinden of als een aparte systeemcontrole.
Waarom het belangrijk is Differentieert tussen managementgoedkeuring en autorisatie op systeemniveau. Belangrijk voor het 'Approval Authority Throughput' dashboard. Waar te verkrijgen Statuswijziging die 'Geautoriseerd' of 'Klaar om te boeken' aangeeft. Vastleggen Vergelijk het statusveld voor/na Gebeurtenistype inferred
	Betaling ingepland	Treedt op wanneer een betaling is goedgekeurd, maar wordt vastgehouden voor een toekomstige ingangsdatum. Het systeem zet de transactie in de wachtrij totdat het verwerkingsvenster opent.
Waarom het belangrijk is Verklaart stilstand in het proces. Onderscheidt tussen een vertraging veroorzaakt door een knelpunt en een bewuste wachttijd voor de vervaldatum. Waar te verkrijgen Vergelijking van 'Entry Date' versus 'Effective Date'. Als de Effective Date in de toekomst ligt, is deze status actief. Vastleggen Afleiden uit het vergelijken van veld X met Y Gebeurtenistype calculated
	Betalingsdetails Gervalideerd	Het systeem controleert rekeningnummers, routeringsnummers en format compliance. Dit wordt doorgaans afgeleid wanneer een transactie succesvol beweegt van een ontvangen status naar een in afwachting zijnde of goedgekeurde status zonder een fout te veroorzaken.
Waarom het belangrijk is Geeft aan dat de eerste geautomatiseerde poort is gepasseerd. Falen hier staat voor data-kwaliteitsproblemen in plaats van liquiditeits- of goedkeuringsproblemen. Waar te verkrijgen Afgeleid van een statuswijziging van 'Ontvangen' naar 'In afwachting' of 'Klaar' binnen een korte tijdsspanne. Vastleggen Vergelijk het statusveld voor/na Gebeurtenistype inferred
	Betalingsfout geïdentificeerd	Vastlegging van het moment waarop een transactie wordt gemarkeerd met een faalstatus of uitzonderingscode. Dit gebeurt wanneer validapakketegels falen of externe controles een negatieve reactie geven.
Waarom het belangrijk is Belangrijk voor het 'Validation Error and Rework Tracker' dashboard. Grote volumes hier duiden op upstream data-kwaliteitsproblemen. Waar te verkrijgen Transactiestatusveld verandert naar een uitzonderingscode (bijv. 'Ongeldig', 'In afwachting', 'Fout'). Vastleggen Vastgelegd wanneer status verandert naar Fout Gebeurtenistype explicit
	Betalingsfout Opgelost	Vertegenwoordigt de correctie van een eerder foutieve transactie. Dit wordt afgeleid wanneer een transactie van een foutstatus terugkeert naar een verwerkings- of geldige status.
Waarom het belangrijk is Essentieel voor het berekenen van 'Mean Time to Resolve Payment Errors'. Het helpt de efficiëntie van het operationele team te meten. Waar te verkrijgen Afgeleid wanneer de transactiestatus update van een foutcode naar een normale verwerkingscode. Vastleggen Vergelijk het statusveld voor/na Gebeurtenistype inferred
	Betalingsmelding Verzonden	Het systeem activeert een communicatie (e-mail/SMS) naar de betaler of ontvanger ter bevestiging van de transactie. Dit verhoogt de klanttransparantie.
Waarom het belangrijk is Ondersteunt 'Notificatiesnelheid en Responsiviteit'. Lange vertragingen na verrekening verminderen het klantvertrouwen. Waar te verkrijgen Communicatielogs of geschiedenistabellen voor klantinteracties, gekoppeld aan de Transactie-ID. Vastleggen Vastgelegd wanneer e-mail/SMS is getriggerd Gebeurtenistype explicit

Aanbevolen Optioneel

Extractiegidsen

Hoe u je data van Fiserv krijgt

Stappen

1. Verplichte Configuratie

Zorg ervoor dat u toegang heeft tot het Fiserv Commerce Hub developer portal. U moet een API Key en API Secret (soms aangeduid als Client ID en Client Secret) genereren met machtigingen om toegang te krijgen tot de Transaction Inquiry of Search API. Controleer of uw IP-adres is gewhitelisted in de Fiserv-omgeving als IP-beperkingen zijn ingeschakeld.

2. Omgevingsinstelling

Installeer Python 3.8 of hoger op uw extractieserver of lokale machine. U heeft de requests en pandas libraries nodig. U kunt deze installeren via pip: pip install requests pandas. Creëer een werkmap voor uw script en outputbestanden.

3. Scriptconfiguratie

Download het meegeleverde Python-script naar uw werkmap. Open het script en werk de configuratiesectie bovenaan bij. U moet uw specifieke API_KEY, API_SECRET en de BASE_URL opgeven (gebruik de sandbox URL voor testen en de productie URL voor de uiteindelijke run). Pas de START_DATE en END_DATE aan om het gewenste process mining window te dekken.

4. Implementatie van Authenticatie Logica

Het script bevat een helper class om Fiserv's specifieke het inloggenvereisten af te handelen, wat doorgaans het genereren van een HMAC signature omvat met behulp van uw API Secret, de timestamp en de request payload. Wijzig de signature generation logic niet, tenzij uw specifieke Fiserv-implementatie een andere standaard gebruikt (bijv. OAuth2 bearer tokens).

5. Inzicht in de Parseringslogica

Het script bevraagt de API voor transacties. De API retourneert doorgaans een snapshot van het transactieobject met diverse tijdstempels (bijv. submission time, authorization time, settlement time). Het script parset dit enkele JSON object en unpivot het naar meerdere rijen (gebeurtenissen) voor de event log. Een enkel JSON record met een submission timestamp en een settlement timestamp zal bijvoorbeeld ten minste twee afzonderlijke rijen in uw CSV genereren.

6. Paginering Afhandelen

Het script implementeert een lus om paginering af te handelen. Fiserv API's beperken het aantal records per respons (vaak 50 of 100). Het script vraagt automatisch de volgende pagina op totdat alle transacties in de date range zijn opgehaald. Zorg ervoor dat uw internetverbinding stabiel is, aangezien dit tijd kan kosten voor grote datasets.

7. Uitvoering

Voer het script uit via de command line: python fiserv_extraction.py. De console zal de voortgang afdrukken, met het aantal verwerkte pagina's en opgehaalde transacties. Let op eventuele HTTP 401 (Unauthorized) of 429 (Rate Limit) fouten.

8. Outputverificatie

Nadat het script is voltooid, controleert u de map op een bestand met de naam fiserv_gebeurtenis_log.csv. Open dit bestand en verifieer dat de ActiviteitNaam kolom een mix bevat van de 13 vereiste activiteiten en dat het EventTimestamp veld correct is geformatteerd.

9. Nabehandeling (Optioneel)

Als u specifieke tijdzone-aanpassingen nodig heeft (bijv. het converteren van UTC naar lokale tijd), kunt u de pandas transformation section in het script aanpassen of dit binnen ProcessMind afhandelen na upload.

10. Uploaden naar ProcessMind

Importeer het CSV-bestand in ProcessMind. Wijs PaymentTransactionId toe aan Case-ID, ActiviteitNaam aan Activiteit, en EventTimestamp aan Timestamp. Zorg ervoor dat numerieke kolommen zoals PaymentBedrag zijn toegewezen als attributen.

Configuratie

API Credentials: Verplicht een API Key en Secret/Shared Secret. Zorg ervoor dat deze leestoegang hebben tot Transaction Reporting endpoints.
Base URL: Instellen op https://api.commerce.fiserv.com voor productie of de specifieke cert/sandbox URL die tijdens onboarding is verstrekt.
Date Range: Aanbevolen extractieperiode is 30 tot 90 dagen vanwege de omvang van de API-payloads. Voor historische uploads, draai het script in maandelijkse delen.
Page Size: Geconfigureerd op 100 records per aanroep om geheugengebruik en netwerkoverhead in evenwicht te houden.
Timezone: De API retourneert tijdstempels in UTC. Het script behoudt deze standaard om consistentie in alle regio's te zorgen.
Retry Logic: Inclusief basis herstelmechanisme voor intermitterende netwerktime-outs (HTTP 500/502/503).

a Voorbeeldquery 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()

Uw betalingsverwerking datatemplate

Uw betalingsverwerking datatemplate

Attributen Betalingsverwerkingingng

Activiteiten Betalingsverwerkingingng

Extractiegidsen

Fiserv Commerce Hub API Python Script

Stappen

1. Verplichte Configuratie

2. Omgevingsinstelling

3. Scriptconfiguratie

4. Implementatie van Authenticatie Logica

5. Inzicht in de Parseringslogica

6. Paginering Afhandelen

7. Uitvoering

8. Outputverificatie

9. Nabehandeling (Optioneel)

10. Uploaden naar ProcessMind

Configuratie

a Voorbeeldquery python

Klaar om te starten?

Optimaliseer Betalingsverwerkingingng en Bereik Vandaag 98% STP

Uw betalingsverwerking datatemplate

Uw betalingsverwerking datatemplate

Attributen Betalingsverwerkingingng

Activiteiten Betalingsverwerkingingng

Extractiegidsen

Fiserv Commerce Hub API Python Script

Stappen

1. Verplichte Configuratie

2. Omgevingsinstelling

3. Scriptconfiguratie

4. Implementatie van Authenticatie Logica

5. Inzicht in de Parseringslogica

6. Paginering Afhandelen

7. Uitvoering

8. Outputverificatie

9. Nabehandeling (Optioneel)

10. Uploaden naar ProcessMind

Configuratie

a Voorbeeldquery python

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Optimaliseer Betalingsverwerkingingng en Bereik Vandaag 98% STP