> Amélioration continue des processus > Traitement des paiements > Fiserv > Modèle de données

Votre modèle de données pour le traitement des paiements

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

Fiserv

Votre modèle de données pour le traitement des paiements

← Retour au guide d’amélioration

Attributs du traitement des paiements (19) Activités du traitement des paiements (13) Guides d’extraction (1)

Votre modèle de données pour le traitement des paiements

Ce modèle fournit un cadre structuré pour vous aider à associer vos données Fiserv à un format adapté au Process Mining et à l’analyse. Il présente les attributs et les activités essentiels pour obtenir une visibilité claire sur vos cycles de règlement et de rapprochement. En suivant ce guide, vous pouvez créer un journal d’événements fiable qui met en évidence les inefficacités et les risques de conformité de vos opérations financières.

Attributs recommandés pour l’analyse des paiements
Principales étapes du processus à surveiller
Recommandations techniques pour l’extraction des données Fiserv

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du traitement des paiements

Ces champs de données recommandés fournissent le contexte nécessaire à votre journal d’événements pour analyser de manière complète l’ensemble du cycle de vie de vos paiements.

5 Obligatoire 9 Recommandé 5 Facultatif

	Nom	Description
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité s’est produite.
Description Cet attribut enregistre le moment précis où un événement a eu lieu. Il constitue la base de toutes les analyses temporelles, notamment les temps de cycle, les délais et l’identification des goulots d’étranglement. Dans les Dashboards, ces données servent à calculer la durée entre les étapes, par exemple le délai entre « Payment Request Created » et « Payment Authorized ». Des horodatages précis sont nécessaires pour ordonner correctement les événements qui se produisent à quelques instants d’intervalle. Pourquoi c’est important Requis pour ordonner les événements et calculer les durées de performance du processus. Où les obtenir Journaux d’audit ou colonnes d’horodatage des mises à jour de transaction. Exemples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Identifiant de transaction du paiement PaymentTransactionId	Identifiant unique de l’instruction de paiement ou du dossier de transaction concerné.
Description Cet attribut sert de clé centrale pour relier toutes les activités d’un même cycle de vie de paiement. Il permet aux analystes de suivre le parcours depuis la demande initiale jusqu’à la validation, l’approbation, puis le règlement final ou l’annulation. Dans les environnements Fiserv, il s’agit généralement de la clé primaire des tables d’historique des transactions. Elle est indispensable pour reconstituer le flux du processus et associer correctement des événements disjoints, comme un règlement intervenant plusieurs jours après l’autorisation, au même objet métier. Pourquoi c’est important Il s’agit du Case ID fondamental requis pour regrouper les événements en instances de processus. Où les obtenir Consultez la documentation Fiserv pour identifier les tables Transaction ou Payment Header. Exemples TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Nom de l’activité ActivityName	Événement ou changement de statut précis survenu dans le processus de paiement.
Description Cet attribut décrit l’étape exécutée, comme « Payment Request Created » ou « Payment Settled ». Il définit les nœuds de la carte du processus et est essentiel pour comprendre l’enchaînement des opérations. L’analyse des activités distinctes permet aux organisations de visualiser le flux de travail, d’identifier les étapes ignorées et de détecter les parcours non conformes où des validations ou approbations obligatoires ont été contournées. Pourquoi c’est important Définit les événements qui composent la chronologie du processus. Où les obtenir Journal d’historique des transactions ou tables d’audit des changements de statut. Exemples Demande de paiement crééePaiement autoriséErreur de paiement identifiéePaiement régléPaiement annulé
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière extraction ou actualisation de l’enregistrement.
Description Indique l’actualité des données utilisées pour l’analyse. Cela est essentiel pour déterminer si les Dashboards reflètent les opérations en temps réel ou des instantanés historiques. Cet attribut aide les utilisateurs à se fier aux indicateurs affichés et à éviter de prendre des décisions sur la base de données obsolètes, notamment lors du suivi du respect des heures limites ou des goulots d’étranglement actifs. Pourquoi c’est important Garantit l’actualité et la fiabilité des données. Où les obtenir Heure système au moment de l’exécution de l’ETL. Exemples 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Système source SourceSystem	Nom du système à l’origine des données.
Description Identifie le module Fiserv ou le système externe précis ayant généré l’événement. Cela est particulièrement utile dans les environnements complexes où les paiements peuvent être initiés dans un canal frontal, puis réglés dans un système bancaire central en arrière-plan. Les analystes peuvent ainsi filtrer la vue du processus par système d’origine et cibler l’analyse sur des environnements techniques ou des points d’intégration précis. Pourquoi c’est important Fournit le contexte technique et la traçabilité des données. Où les obtenir Renseigné en dur lors de l’extraction ou issu des métadonnées du système. Exemples Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Code d’erreur ErrorCode	Code précis généré lorsqu’un paiement échoue à la validation.
Description Enregistre le code d’erreur technique ou métier associé aux activités « Payment Error Identified ». Cet attribut constitue le fondement du Validation Error and Rework Tracker. En regroupant la fréquence des codes d’erreur spécifiques, l’organisation peut identifier les problèmes systémiques de qualité des données, par exemple « Invalid Routing Number », et mettre en place des corrections ciblées dans la logique de validation ou la formation des utilisateurs. Pourquoi c’est important Identifie les causes profondes des reprises. Où les obtenir Journaux d’erreurs ou détails du statut des transactions. Exemples E-101INV_ACCNSF_ERRAUTH_FAIL
	Code devise CurrencyCode	Code ISO de la devise du montant du paiement.
Description Précise la devise dans laquelle le paiement est libellé, par exemple USD ou EUR. Cet attribut est essentiel pour le Dashboard Currency and Method Volume Trends, qui permet à l’organisation de suivre son exposition aux différentes devises étrangères. Il sert également à normaliser les montants pour les rapports internationaux et à éviter que les contrôles de doublons ne signalent à tort des transactions ayant la même valeur numérique, mais libellées dans des devises différentes. Pourquoi c’est important Nécessaire pour l’analyse des traitements multidevises. Où les obtenir Table d’en-tête des transactions, colonne Currency. Exemples USDEURGBPCADJPY
	Date d’échéance du paiement PaymentDueDate	Date à laquelle le paiement doit avoir été traité.
Description Date cible d’achèvement du paiement. Elle est utilisée dans le Processing Cutoff Compliance Monitor pour signaler les transactions susceptibles d’être en retard. La comparaison de l’horodatage « Payment Settled » avec cet attribut permet de calculer les indicateurs de respect des délais et aide l’organisation à préserver la confiance des bénéficiaires. Pourquoi c’est important Point de référence pour mesurer le respect des SLA. Où les obtenir Détails de l’instruction de paiement. Exemples 2023-11-012023-11-15
	Est STP IsStraightThroughProcessing	Indicateur précisant si le paiement n’a nécessité aucune intervention manuelle.
Description Attribut booléen calculé, vrai lorsque le dossier ne contient aucune étape « Payment Error Identified », « Payment Error Resolved » ou « Payment Approved » manuelle, selon la définition retenue. Il alimente directement le KPI Straight Through Processing Rate. Il permet de segmenter le processus entre les flux entièrement automatisés et ceux nécessitant une intervention humaine, afin d’obtenir une vision claire du potentiel d’automatisation. Pourquoi c’est important Indicateur essentiel de l’efficacité du processus et de la réussite de l’automatisation. Où les obtenir Calculé lors de la transformation des données. Exemples truefalse
	Mode de paiement PaymentMethod	Mécanisme utilisé pour exécuter le paiement, par exemple Wire ou ACH.
Description Classe la transaction selon son canal de traitement. Cet attribut est fondamental pour l’analyse du temps de cycle d’autorisation, car les différents modes de paiement suivent des procédures opérationnelles et des accords de niveau de service très différents. L’analyse des variantes de processus par mode de paiement permet de déterminer si les retards sont propres à un canal, comme les virements internationaux, ou s’ils concernent l’organisation dans son ensemble. Pourquoi c’est important Segmente les flux de processus selon l’infrastructure utilisée. Où les obtenir Colonne du type de transaction ou du code de l’instrument. Exemples Virement bancaireACHChèqueRTPVirement interne
	Montant du paiement PaymentAmount	Valeur monétaire de la transaction de paiement.
Description Cet attribut représente la valeur financière associée au paiement. Il constitue une dimension principale pour segmenter l’analyse et permet de distinguer les paiements stratégiques de montant élevé des transactions courantes de faible montant. Il est essentiel pour la vue « Duplicate Payment Detection View », où des montants identiques associés aux informations du payeur et du bénéficiaire signalent des erreurs potentielles. Il sert également à analyser les autorités d’approbation, car les montants élevés déclenchent souvent des parcours de flux de travail différents. Pourquoi c’est important Essentiel pour l’analyse des risques financiers et la détection des doublons. Où les obtenir Table d’en-tête des transactions, colonne Amount. Exemples 150.0025000.5010.991000000.00
	Numéro de compte du bénéficiaire PayeeAccountNumber	Numéro du compte sur lequel les fonds sont crédités.
Description Identifie le compte destinataire. Comme le compte du payeur, cet attribut est essentiel pour la vue Duplicate Payment Detection. Il garantit que l’analyse cible correctement les relations avec les bénéficiaires concernés. Dans le suivi du respect des heures limites, l’identification du bénéficiaire peut aider à prioriser les fournisseurs stratégiques ou les règlements importants qui ne doivent pas échouer. Pourquoi c’est important Essentiel pour la détection des doublons et l’analyse des bénéficiaires. Où les obtenir Détails de la transaction, colonne Credit Account ou Beneficiary. Exemples 555000111222333444BEN-882-11
	Numéro de compte du payeur PayerAccountNumber	Numéro du compte sur lequel les fonds sont débités.
Description Identifie le compte à l’origine du paiement. Il s’agit d’un élément clé de la vue Duplicate Payment Detection. Associé au bénéficiaire, au montant et à l’heure, il forme l’empreinte unique utilisée pour détecter les doubles paiements accidentels. Il permet également d’analyser le volume des paiements par compte d’origine afin d’identifier les portefeuilles internes les plus actifs. Pourquoi c’est important Essentiel pour la détection des doublons et l’analyse de la fraude. Où les obtenir Détails de la transaction, colonne Debit Account. Exemples 123456789987654321ACC-001-992
	Utilisateur de traitement ProcessingUser	Identifiant de l’utilisateur ou de l’agent système responsable de l’activité.
Description Identifie la personne ou le système ayant exécuté l’action, qu’il s’agisse d’un approbateur humain ou d’un robot d’automatisation. Ces données alimentent les Dashboards Error Resolution Cycle Efficiency et Approval Authority Throughput. Le suivi des utilisateurs permet aux analystes d’identifier les besoins de formation des personnes présentant un taux d’erreur élevé et de repérer les goulots d’étranglement lorsque certains approbateurs sont surchargés de demandes. Pourquoi c’est important Permet d’analyser les ressources et d’identifier les goulots d’étranglement. Où les obtenir Journaux d’audit, colonne User ID. Exemples jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Banque du bénéficiaire BeneficiaryBank	Nom ou identifiant de la banque destinataire.
Description Identifie l’établissement financier qui reçoit le paiement. Cet attribut est utile pour analyser les retards de règlement, car certaines banques destinataires peuvent présenter des délais de traitement ou des problèmes d’intégration différents. Il ajoute une dimension au Dashboard Settlement to Reconciliation Gap et permet de déterminer si les retards sont externes, liés à une banque donnée, ou internes. Pourquoi c’est important Analyse des dépendances externes. Où les obtenir Détails de la transaction, colonne Bank ID ou Name. Exemples ChaseBank of AmericaWells FargoCitibank
	Est une reprise IsRework	Indicateur précisant si cette activité fait partie d’une boucle de reprise.
Description Indicateur booléen qui marque les activités survenant après l’identification d’une erreur, mais avant sa résolution, ainsi que les activités répétées. Il alimente le KPI Payment Validation Rework Rate. Les analystes peuvent ainsi filtrer la cartographie du processus pour n’afficher que le « happy path » ou, au contraire, se concentrer entièrement sur le « rework path » afin de comprendre les modes de défaillance. Pourquoi c’est important Distingue le travail créateur de valeur du travail de correction. Où les obtenir Calculé à partir des boucles du processus. Exemples truefalse
	Heure limite dépassée IsCutoffMissed	Indicateur précisant si le paiement a été envoyé après l’heure limite bancaire quotidienne.
Description Valeur booléenne calculée qui compare l’heure de « Payment Instruction Sent » à l’heure limite quotidienne correspondant à la devise et au mode de paiement. Elle alimente le KPI Cutoff Adherence Rate. L’identification des heures limites manquées aide à rechercher les causes profondes des retards, qu’ils résultent d’une initiation tardive ou d’un traitement interne trop lent. Pourquoi c’est important Essentiel pour la conformité opérationnelle et la gestion des liquidités. Où les obtenir Calculé en comparant EventTimestamp avec la table Cutoff Reference. Exemples truefalse
	Niveau d’approbation ApprovalLevel	Niveau hiérarchique requis ou utilisé pour autoriser le paiement.
Description Indique le niveau de séniorité ou d’autorité associé à l’activité « Payment Approved ». Il est utilisé dans le Dashboard Approval Authority Throughput pour déterminer si les approbateurs de niveau supérieur deviennent des goulots d’étranglement. La compréhension de la répartition des paiements entre les différents niveaux, par exemple Level 1 et Level 3, aide à optimiser les règles de délégation des pouvoirs. Pourquoi c’est important Segmente les goulots d’étranglement liés aux approbations selon la hiérarchie. Où les obtenir Tables des rôles utilisateurs ou des flux de travail d’approbation. Exemples Niveau 1ResponsableDirecteurCFO
	Unité opérationnelle BusinessUnit	Service ou division à l’origine du paiement.
Description Classe le paiement selon l’unité organisationnelle responsable de la dépense. Cela aide à répartir les coûts et à comprendre quelles parties de l’organisation génèrent le plus de reprises manuelles ou d’erreurs. Cet attribut contribue à l’audit de conformité du parcours de paiement en vérifiant que les différentes unités respectent leurs exigences réglementaires ou leurs contrôles internes spécifiques. Pourquoi c’est important Fournit le contexte organisationnel nécessaire à l’analyse de la performance. Où les obtenir Correspondance du centre de coûts ou code du service. Exemples Banque de détailCrédit commercialGestion de patrimoineOpérations

Obligatoire Recommandé Facultatif

Activités du traitement des paiements

Consignez ces étapes et jalons essentiels du processus dans votre journal d’événements afin de permettre une découverte précise et l’optimisation de vos flux de paiement.

5 Recommandé 8 Facultatif

	Activité	Description
	Demande de paiement créée	Il s’agit de l’enregistrement initial de l’instruction de paiement dans le système Fiserv. Cet événement est explicitement journalisé lorsqu’un utilisateur ou un système externe lance une transaction via une API ou une interface.
Pourquoi c’est important Marque le début de la chronologie du processus. Cet élément est essentiel pour calculer le temps de cycle total et identifier les goulots d’étranglement à l’entrée. Où les obtenir Horodatage de création de la table d’historique des transactions. Recherchez le premier enregistrement associé au Payment Transaction ID concerné. Collecte Journalisé lors de l’insertion de l’enregistrement de transaction Type d’événement explicit
	Instruction de paiement envoyée	Transmission du fichier de paiement, par exemple un lot ACH ou un message Wire, au réseau externe ou à la chambre de compensation. Il s’agit d’un point de transfert essentiel.
Pourquoi c’est important Essentiel pour le « Processing Cutoff Compliance Monitor ». Garantit que l’organisation respecte les heures limites bancaires quotidiennes. Où les obtenir Journaux de traitement des lots ou horodatages de génération des fichiers. Souvent consignés sous « Batch Created » ou « File Transmitted ». Collecte Consigné lors de la génération du fichier de lot Type d’événement explicit
	Paiement approuvé	Décision manuelle ou automatisée autorisant la poursuite du paiement selon les limites de délégation. Cet événement est enregistré lorsqu’un utilisateur habilité ou une règle système met à jour l’indicateur d’approbation.
Pourquoi c’est important Essentiel pour l’« Authorization Cycle Time Analysis ». Les retards à cette étape indiquent des goulots d’étranglement dans la chaîne d’approbation humaine. Où les obtenir Journaux d’audit montrant l’action d’un utilisateur qui fait passer l’état de « Pending Approval » à « Approved ». Collecte Journalisé lors de l’exécution de l’action d’approbation Type d’événement explicit
	Paiement rapproché	Rapprochement interne de la transaction avec les relevés bancaires ou les fichiers de règlement. Cette étape clôt le cycle comptable.
Pourquoi c’est important Requis pour le « Settlement to Reconciliation Gap ». Garantit une clôture exacte des comptes financiers. Où les obtenir Journaux du module de rapprochement, lorsque le statut passe à « Matched » ou « Reconciled ». Collecte Consigné lors du rapprochement de la transaction Type d’événement explicit
	Paiement réglé	Le transfert des fonds est finalisé et comptabilisé dans le grand livre. Cela marque l’achèvement financier de la transaction du point de vue de la banque.
Pourquoi c’est important Point final principal du « Straight Through Processing Rate ». Indique que les fonds ont effectivement été transférés. Où les obtenir Statut de transaction « Posted » ou présence d’un horodatage « Post Date » dans le grand livre. Collecte Consigné lors de la comptabilisation dans le grand livre Type d’événement explicit
	Détails du paiement validés	Le système vérifie les numéros de compte, les numéros d’acheminement bancaire et la conformité du format. Cet événement est généralement déduit lorsqu’une transaction passe correctement de l’état reçu à l’état en attente ou approuvé, sans déclencher d’erreur.
Pourquoi c’est important Indique que le premier contrôle automatisé a été franchi. Un échec à cette étape révèle un problème de qualité des données, et non un problème de liquidité ou d’approbation. Où les obtenir Déduit d’un changement d’état de « Received » à « Pending » ou « Ready » dans un délai court. Collecte Comparer le champ d’état avant et après Type d’événement inferred
	Erreur de paiement identifiée	Enregistre le moment où une transaction est signalée par un état d’échec ou un code d’exception. Cela se produit lorsque les règles de validation échouent ou que des contrôles externes renvoient une réponse négative.
Pourquoi c’est important Essentiel pour le Dashboard « Validation Error and Rework Tracker ». Des volumes élevés à cette étape indiquent des problèmes de qualité des données en amont. Où les obtenir Le champ d’état de la transaction prend la valeur d’un code d’exception, par exemple « Invalid », « Hold » ou « Error ». Collecte Journalisé lorsque l’état passe à Error Type d’événement explicit
	Erreur de paiement résolue	Représente la correction d’une transaction précédemment en erreur. Cet événement est déduit lorsqu’une transaction passe d’un état d’erreur à un état de traitement ou de validité.
Pourquoi c’est important Essentiel pour calculer le « Mean Time to Resolve Payment Errors ». Cet indicateur aide à mesurer l’efficacité de l’équipe opérationnelle. Où les obtenir Déduit lorsque l’état de la transaction passe d’un code d’erreur à un code de traitement normal. Collecte Comparer le champ d’état avant et après Type d’événement inferred
	Notification de paiement envoyée	Le système déclenche une communication, par e-mail ou SMS, destinée au payeur ou au bénéficiaire pour confirmer la transaction. Cela améliore la transparence pour les clients.
Pourquoi c’est important Alimente le « Notification Speed and Responsiveness ». De longs délais après le règlement réduisent la confiance des clients. Où les obtenir Journaux de communication ou tables d’historique des interactions clients associés à l’identifiant de transaction. Collecte Consigné lors du déclenchement de l’e-mail ou du SMS Type d’événement explicit
	Paiement annulé	Arrêt d’un flux de paiement avant le règlement, déclenché par un utilisateur ou une règle système. Cela interrompt tout traitement ultérieur.
Pourquoi c’est important Identifie le gaspillage et le travail abandonné. Un taux élevé d’annulation après approbation peut révéler des inefficacités dans le processus. Où les obtenir Changement de statut vers « Cancelled », « Void » ou « Stopped ». Collecte Consigné lorsque le statut passe à « Cancelled » Type d’événement explicit
	Paiement autorisé	Confirmation interne finale indiquant que les fonds sont disponibles et que la transaction peut être exécutée. Cette étape peut avoir lieu simultanément à l’approbation ou lors d’un contrôle système distinct.
Pourquoi c’est important Distingue l’approbation managériale de l’autorisation au niveau du système. Important pour le Dashboard « Approval Authority Throughput ». Où les obtenir Changement de statut indiquant « Authorized » ou « Ready to Post ». Collecte Comparer le champ d’état avant et après Type d’événement inferred
	Paiement confirmé	Réception d’un accusé de réception positif (ACK) du réseau externe ou de la passerelle. Cela confirme que l’instruction a été reçue correctement par l’entité suivante.
Pourquoi c’est important Valide que l’« Instruction Sent » a abouti. Les écarts à ce stade indiquent des problèmes de connectivité réseau ou de format externe. Où les obtenir Journaux de traitement des fichiers entrants ou codes de réponse de l’API confirmant la réception. Collecte Consigné lors de la réception de l’ACK Type d’événement explicit
	Paiement planifié	Se produit lorsqu’un paiement est approuvé, mais conservé jusqu’à une date d’effet ultérieure. Le système place la transaction en file d’attente jusqu’à l’ouverture de la fenêtre de traitement.
Pourquoi c’est important Explique le temps d’inactivité dans le processus. Distingue un délai causé par un goulot d’étranglement d’une attente volontaire jusqu’à la date d’échéance. Où les obtenir Comparaison entre « Entry Date » et « Effective Date ». Si « Effective Date » est ultérieure, cet état est actif. Collecte Dérivé de la comparaison du champ X avec le champ Y Type d’événement calculated

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Fiserv

Étapes

1. Configuration préalable

Vérifiez que vous avez accès au portail développeur Fiserv Commerce Hub. Vous devrez générer une clé API et un secret API, parfois appelés Client ID et Client Secret, avec les autorisations nécessaires pour accéder à l’API Transaction Inquiry ou Search. Si des restrictions d’adresse IP sont activées, vérifiez que votre adresse IP figure dans la liste blanche de l’environnement Fiserv.

2. Configuration de l’environnement

Installez Python 3.8 ou une version ultérieure sur votre serveur d’extraction ou votre machine locale. Vous aurez besoin des bibliothèques requests et pandas. Vous pouvez les installer avec pip : pip install requests pandas. Créez un répertoire de travail pour le script et les fichiers de sortie.

3. Configuration du script

Téléchargez le script Python fourni dans votre répertoire de travail. Ouvrez-le et mettez à jour la section de configuration située en haut du fichier. Renseignez vos valeurs API_KEY, API_SECRET et BASE_URL, en utilisant l’URL sandbox pour les tests et l’URL de production pour l’exécution finale. Ajustez START_DATE et END_DATE afin de couvrir la période de Process Mining souhaitée.

4. Mise en œuvre de l’authentification

Le script comprend une classe auxiliaire qui gère les exigences d’authentification propres à Fiserv. Celles-ci consistent généralement à générer une signature HMAC à partir de votre secret API, de l’horodatage et du contenu de la requête. Ne modifiez pas la logique de génération de la signature, sauf si votre implémentation Fiserv utilise une autre norme, par exemple des jetons bearer OAuth2.

5. Comprendre la logique d’analyse

Le script interroge l’API pour récupérer les transactions. L’API renvoie généralement un instantané de l’objet transaction contenant plusieurs horodatages, par exemple l’heure de soumission, d’autorisation et de règlement. Le script analyse cet objet JSON unique et le convertit en plusieurs lignes, correspondant aux événements de l’Event Log. Ainsi, un enregistrement JSON contenant un horodatage de soumission et un horodatage de règlement génère au moins deux lignes distinctes dans votre fichier CSV.

6. Gestion de la pagination

Le script utilise une boucle pour gérer la pagination. Les API Fiserv limitent le nombre d’enregistrements par réponse, souvent à 50 ou 100. Le script demande automatiquement la page suivante jusqu’à la récupération de toutes les transactions de la période. Vérifiez la stabilité de votre connexion Internet, car l’opération peut prendre du temps pour les volumes importants.

7. Exécution

Exécutez le script en ligne de commande : python fiserv_extraction.py. La console affiche la progression, notamment le nombre de pages traitées et de transactions récupérées. Surveillez les erreurs HTTP 401 (Unauthorized) ou 429 (Rate Limit).

8. Vérification du résultat

Une fois le script terminé, recherchez le fichier fiserv_event_log.csv dans le répertoire. Ouvrez-le et vérifiez que la colonne ActivityName contient un ensemble des 13 activités requises et que le champ EventTimestamp est correctement formaté.

9. Post-traitement facultatif

Si vous devez ajuster le fuseau horaire, par exemple convertir l’UTC en heure locale, vous pouvez modifier la section de transformation pandas du script ou effectuer cette opération dans ProcessMind après l’importation.

10. Chargement dans ProcessMind

Importez le fichier CSV dans ProcessMind. Associez PaymentTransactionId à Case ID, ActivityName à Activity et EventTimestamp à Timestamp. Vérifiez que les colonnes numériques, telles que PaymentAmount, sont associées comme Attributs.

Configuration

Identifiants API : nécessite une clé API et un secret, ou secret partagé. Vérifiez qu’ils disposent d’un accès en lecture aux points de terminaison de reporting des transactions.
URL de base : définissez https://api.commerce.fiserv.com pour la production ou l’URL spécifique de certification ou sandbox fournie lors de l’intégration.
Période : une fenêtre d’extraction de 30 à 90 jours est recommandée en raison de la taille des réponses de l’API. Pour les chargements historiques, exécutez le script par tranches mensuelles.
Taille des pages : configurée à 100 enregistrements par appel afin d’équilibrer l’utilisation de la mémoire et la charge réseau.
Fuseau horaire : l’API renvoie les horodatages en UTC. Le script conserve cette norme afin d’assurer la cohérence entre les régions.
Logique de nouvelle tentative : un mécanisme de nouvelle tentative élémentaire est inclus pour les délais d’attente réseau intermittents, notamment les erreurs HTTP 500, 502 et 503.

a Exemple de requête 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()

Prêt à commencer ?

Commencez à optimiser vos flux de travail financiers en appliquant ce modèle à votre environnement Fiserv. Notre approche guidée vous garantit de disposer des bonnes données pour obtenir des améliorations concrètes de votre trésorerie et de votre conformité opérationnelle.

Retour au guide d’amélioration Télécharger le modèle

Optimisez le traitement des paiements et atteignez 98 % de STP dès aujourd’hui

Supprimez les retards de rapprochement et maîtrisez vos flux de travail Fiserv.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données pour le traitement des paiements

Votre modèle de données pour le traitement des paiements

Attributs du traitement des paiements

Activités du traitement des paiements

Guides d’extraction

Script Python de l’API Fiserv Commerce Hub

Étapes

1. Configuration préalable

2. Configuration de l’environnement

3. Configuration du script

4. Mise en œuvre de l’authentification

5. Comprendre la logique d’analyse

6. Gestion de la pagination

7. Exécution

8. Vérification du résultat

9. Post-traitement facultatif

10. Chargement dans ProcessMind

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez le traitement des paiements et atteignez 98 % de STP dès aujourd’hui

Nous attachons de l’importance à votre confidentialité