> 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: Modèle de données de Process Mining pour Traitement des paiements
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 propose un cadre structuré pour 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 comprendre clairement les cycles de règlement et de rapprochement. Suivez ce guide pour créer un journal d’événements 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 à suivre
Conseils techniques pour extraire les données Fiserv

Vous découvrez les journaux d’événements ? Découvrez comment créer 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 apportent au journal d’événements le contexte nécessaire à l’analyse complète 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é a eu lieu.
Description Cet attribut consigne le moment précis où un événement s’est produit. Il sert de base à toutes les analyses temporelles, notamment le calcul des temps de cycle et des délais, ainsi que l’identification des goulots d’étranglement. Dans les Dashboards, ces données permettent de calculer la durée entre les étapes, par exemple le temps écoulé entre « Demande de paiement créée » et « Paiement autorisé ». Des horodatages précis sont nécessaires pour ordonner correctement les événements qui se succèdent rapidement. Pourquoi est-ce important ? Nécessaire pour ordonner les événements et calculer les durées de performance du processus. Où trouver ces données 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
	ID de transaction de paiement PaymentTransactionId	Identifiant unique de l’instruction de paiement ou du cas de transaction concerné.
Description Cet attribut sert de clé centrale pour relier toutes les activités d’un même cycle de paiement. Il permet aux analystes de suivre le parcours depuis la demande initiale jusqu’à la validation, l’approbation et 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. Cet identifiant est indispensable pour reconstituer le flux du processus et associer correctement au même objet métier des événements qui semblent disjoints, par exemple un règlement intervenant plusieurs jours après l’autorisation. Pourquoi est-ce important ? Il s’agit de l’ID de cas fondamental nécessaire pour regrouper les événements en instances de processus. Où trouver ces données Consultez la documentation Fiserv sur 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 réalisée, par exemple « Demande de paiement créée » ou « Paiement réglé ». Il définit les nœuds de la cartographie du processus et permet de comprendre l’ordre des opérations. En analysant les différentes activités, les organisations peuvent visualiser le flux de travail, repérer les étapes ignorées et détecter les parcours non conformes où des validations ou approbations obligatoires ont été contournées. Pourquoi est-ce important ? Définit les événements qui composent la chronologie du processus. Où trouver ces données Journal d’historique des transactions ou tables d’audit des changements de statut. Exemples Demande de paiement crééePaiement autoriséErreur de paiement détecté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 la fraîcheur des données utilisées pour l’analyse. Cet attribut permet de déterminer si les Dashboards reflètent les opérations en temps réel ou un état historique. Il aide les utilisateurs à se fier aux métriques affichées et à éviter de prendre des décisions à partir de données obsolètes, notamment lors du suivi du respect des heures limites ou des goulots d’étranglement en cours. Pourquoi est-ce important ? Garantit l’actualité et la fiabilité des données. Où trouver ces données 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 d’origine des données.
Description Identifie le module Fiserv ou le système externe qui a généré l’événement. Cet attribut est particulièrement utile dans les environnements complexes où les paiements peuvent être initiés par un canal frontal, puis réglés dans un système bancaire central en arrière-plan. Il permet aux analystes de filtrer la vue du processus selon le système d’origine et de cibler l’analyse sur des environnements techniques ou des points d’intégration précis. Pourquoi est-ce important ? Fournit le contexte technique et la traçabilité des données. Où trouver ces données Valeur codée en dur lors de l’extraction ou issue des métadonnées du système. Exemples Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Code d’erreur ErrorCode	Code généré lorsqu’un paiement échoue à la validation.
Description Enregistre le code d’erreur technique ou métier associé aux activités « Erreur de paiement identifiée ». Cet attribut constitue la base du suivi des erreurs de validation et des reprises. En regroupant les occurrences de chaque code d’erreur, l’organisation peut repérer les problèmes systémiques de qualité des données, comme un numéro d’acheminement non valide, et apporter des corrections ciblées à la logique de validation ou à la formation des utilisateurs. Pourquoi est-ce important ? Permet d’identifier les causes profondes des reprises. Où trouver ces données Journaux d’erreurs ou détails du statut de la transaction. Exemples E-101INV_ACCNSF_ERRAUTH_FAIL
	Code de devise CurrencyCode	Code ISO de la devise du paiement.
Description Précise la devise dans laquelle le paiement est libellé (par exemple, USD ou EUR). Cet attribut est essentiel au Dashboard des tendances de volume par devise et mode de paiement, 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 le contrôle des doublons ne signale à tort des transactions de même montant numérique, mais libellées dans des devises différentes. Pourquoi est-ce important ? Nécessaire à l’analyse des traitements multidevises. Où trouver ces données Table d’en-tête des transactions, colonne Currency. Exemples USDEURGBPCADJPY
	Date d’échéance du paiement PaymentDueDate	Date limite à laquelle le paiement doit être traité.
Description Date cible à laquelle le paiement doit être effectué. Elle sert au suivi du respect des heures limites de traitement pour signaler les transactions susceptibles d’être en retard. La comparaison de l’horodatage « Paiement réglé » 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 est-ce important ? Point de référence pour mesurer le respect des SLA. Où trouver ces données Détails de l’instruction de paiement. Exemples 2023-11-012023-11-15
	Mode de paiement PaymentMethod	Moyen utilisé pour effectuer le paiement (par exemple, virement Wire ou ACH).
Description Classe la transaction selon le réseau de traitement utilisé. Cet attribut est fondamental pour l’analyse du temps de cycle d’autorisation, car les modes de paiement ont des procédures opérationnelles standard et des accords de niveau de service très différents. L’analyse des variantes du 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’ensemble de l’organisation. Pourquoi est-ce important ? Segmente les flux de processus selon l’infrastructure utilisée. Où trouver ces données Colonne du type de transaction ou du code d’instrument. Exemples Virement WireACHChèqueRTPVirement interne
	Montant du paiement PaymentAmount	Valeur monétaire de la transaction de paiement.
Description Cet attribut représente la valeur financière du paiement. Il constitue une dimension essentielle pour segmenter l’analyse et distinguer les paiements stratégiques de montant élevé des transactions courantes de faible montant. Il est indispensable à la vue de détection des paiements en double, où des montants identiques associés aux informations du payeur et du bénéficiaire peuvent signaler des erreurs potentielles. Il contribue aussi à l’analyse des pouvoirs d’approbation, car les montants élevés suivent souvent des flux de travail différents. Pourquoi est-ce important ? Indispensable à l’analyse des risques financiers et à la détection des doublons. Où trouver ces données 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 crédité.
Description Identifie le compte destinataire. Comme le compte du payeur, cet attribut est essentiel à la vue de détection des paiements en double. Il permet de cibler correctement les relations avec les bénéficiaires concernés. Pour le suivi du respect des heures limites, connaître le bénéficiaire aide à donner la priorité aux fournisseurs stratégiques ou aux règlements importants qui ne doivent pas échouer. Pourquoi est-ce important ? Indispensable à la détection des doublons et à l’analyse des bénéficiaires. Où trouver ces données 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 débité.
Description Identifie le compte à l’origine du paiement. Cet attribut est essentiel à la vue de détection des paiements en double. Associé au bénéficiaire, au montant et à l’heure, il forme une empreinte unique qui permet de repérer les doubles paiements accidentels. Il permet également d’analyser le volume des paiements par compte d’origine et d’identifier les portefeuilles internes les plus actifs. Pourquoi est-ce important ? Indispensable à la détection des doublons et à l’analyse des fraudes. Où trouver ces données Détails de la transaction, colonne Debit Account. Exemples 123456789987654321ACC-001-992
	Traitement direct IsStraightThroughProcessing	Indique si le paiement a été traité sans intervention manuelle.
Description Attribut booléen calculé, vrai si le cas ne comporte aucune étape « Erreur de paiement identifiée », « Erreur de paiement résolue » ou « Paiement approuvé » manuellement, selon la définition retenue. Il contribue directement à l’indicateur de taux de traitement direct. Il permet de segmenter le processus en deux catégories : les flux entièrement automatisés et ceux qui nécessitent une intervention humaine. L’organisation peut ainsi évaluer clairement le potentiel d’automatisation. Pourquoi est-ce important ? Métrique clé de l’efficacité du processus et de la réussite de l’automatisation. Où trouver ces données Calculé lors de la transformation des données. Exemples truefalse
	Utilisateur chargé du traitement ProcessingUser	ID de l’utilisateur ou de l’agent système responsable de l’activité.
Description Identifie la personne ou le système à l’origine de l’action, qu’il s’agisse d’un approbateur ou d’un robot d’automatisation. Ces données alimentent les Dashboards d’efficacité de résolution des erreurs et de débit des autorisations d’approbation. Le suivi des utilisateurs permet aux analystes de repérer les besoins de formation des personnes qui commettent souvent des erreurs, ou les goulots d’étranglement dus à une surcharge de demandes pour certains approbateurs. Pourquoi est-ce important ? Permet d’analyser les ressources et de repérer les goulots d’étranglement. Où trouver ces données 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 les banques destinataires peuvent avoir des délais de traitement ou des problèmes d’intégration différents. Il ajoute une dimension au Dashboard du délai entre le règlement et le rapprochement et permet de déterminer si les retards sont externes, propres à une banque, ou internes. Pourquoi est-ce important ? Analyse des dépendances externes. Où trouver ces données Détails de la transaction, colonne Bank ID ou Name. Exemples ChaseBank of AmericaWells FargoCitibank
	Heure limite dépassée IsCutoffMissed	Indique si le paiement a été envoyé après l’heure limite quotidienne de la banque.
Description Valeur booléenne calculée en comparant l’heure d’envoi de l’« Instruction de paiement » à l’heure limite quotidienne correspondant à la devise et au mode de paiement. Cet attribut contribue à l’indicateur de respect des heures limites. Le repérage des heures limites manquées aide à rechercher les causes profondes des retards, qu’ils soient dus à une initiation tardive ou à un traitement interne trop lent. Pourquoi est-ce important ? Indispensable à la conformité opérationnelle et à la gestion des liquidités. Où trouver ces données Calculé en comparant EventTimestamp à la table Cutoff Reference. Exemples truefalse
	Niveau d’approbation ApprovalLevel	Niveau hiérarchique requis ou utilisé pour autoriser le paiement.
Description Indique le niveau d’ancienneté ou d’autorité associé à l’activité « Paiement approuvé ». Le Dashboard de débit des autorisations d’approbation s’appuie sur cet attribut pour déterminer si les approbateurs de niveau supérieur deviennent des goulots d’étranglement. La répartition des paiements par niveau, par exemple entre le niveau 1 et le niveau 3, aide à optimiser les règles de délégation des pouvoirs. Pourquoi est-ce important ? Segmente les goulots d’étranglement liés aux approbations selon la hiérarchie. Où trouver ces données Rôle de l’utilisateur ou tables de flux de travail des approbations. Exemples Niveau 1ResponsableDirecteurCFO
	Reprise IsRework	Indique si cette activité précise fait partie d’une boucle de reprise.
Description Indicateur booléen qui marque les activités réalisées après la détection d’une erreur et avant sa résolution, ainsi que les activités répétées. Il contribue à l’indicateur de taux de reprise lors de la validation des paiements. Les analystes peuvent filtrer la cartographie du processus pour n’afficher que le parcours nominal ou, au contraire, se concentrer sur le parcours de reprise afin de comprendre les causes des échecs. Pourquoi est-ce important ? Distingue le travail créateur de valeur des corrections. Où trouver ces données Calculé à partir des boucles du processus. Exemples truefalse
	Unité opérationnelle BusinessUnit	Service ou division à l’origine du paiement.
Description Classe le paiement selon l’unité organisationnelle responsable de la dépense. Cet attribut aide à répartir les coûts et à déterminer quelles parties de l’organisation génèrent le plus de reprises manuelles ou d’erreurs. Il contribue à l’audit de conformité du parcours de paiement en vérifiant que chaque unité respecte ses exigences réglementaires ou ses contrôles internes. Pourquoi est-ce important ? Fournit un contexte organisationnel pour l’analyse des performances. Où trouver ces données Association au centre de coûts ou code du service. Exemples Services bancaires aux particuliersFinancement commercialGestion de patrimoineOpérations

Obligatoire Recommandé Facultatif

Activités du traitement des paiements

Consignez ces étapes et jalons essentiels dans votre journal d’événements pour reconstituer avec précision les flux de traitement des paiements et repérer les possibilités d’optimisation.

5 Recommandé 8 Facultatif

	Activité	Description
	Demande de paiement créée	Saisie initiale de l’instruction de paiement dans le système Fiserv. Cet événement est enregistré lorsqu’un utilisateur ou un système externe lance une transaction par API ou depuis une interface.
Pourquoi est-ce important ? Marque le début du processus. Cet événement est essentiel pour calculer le temps de cycle total et repérer les goulots d’étranglement à la réception des demandes. Où trouver ces données Horodatage de création de l’enregistrement dans la table d’historique des transactions. Recherchez l’enregistrement le plus ancien associé à l’identifiant de transaction de paiement concerné. Données à recueillir Enregistré 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, lot ACH ou message Wire) au réseau externe ou à la chambre de compensation. Il s’agit d’un point de transfert important.
Pourquoi est-ce important ? Indispensable au « Suivi du respect des heures limites de traitement ». Permet de vérifier que l’organisation respecte les heures limites bancaires quotidiennes. Où trouver ces données Journaux de traitement par lots ou horodatages de génération des fichiers. Souvent consignés sous les libellés « Lot créé » ou « Fichier transmis ». Données à recueillir 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 le 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 est-ce important ? Indispensable à l’« Analyse du temps de cycle d’autorisation ». Les retards à cette étape signalent des goulots d’étranglement dans le circuit d’approbation. Où trouver ces données Journaux d’audit montrant qu’une action utilisateur a fait passer le statut de « En attente d’approbation » à « Approuvé ». Données à recueillir Enregistré lorsque l’approbation est accordée 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 est-ce important ? Nécessaire au « Délai entre le règlement et le rapprochement ». Permet de clôturer les comptes avec exactitude. Où trouver ces données Journaux du module de rapprochement où le statut passe à « Correspondance trouvée » ou « Rapproché ». Données à recueillir Consigné lors de la correspondance de rapprochement Type d’événement explicit
	Paiement réglé	Le transfert des fonds est finalisé et comptabilisé dans le grand livre. Du point de vue de la banque, cette étape marque la fin financière de la transaction.
Pourquoi est-ce important ? Point final principal pour le « Taux de traitement direct ». Indique que les fonds ont effectivement été transférés. Où trouver ces données Statut de transaction « Comptabilisé » ou présence d’un horodatage de « Date de comptabilisation » dans le grand livre. Données à recueillir 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 et la conformité du format. Cette étape est généralement déduite lorsqu’une transaction passe du statut reçu au statut en attente ou approuvé sans générer d’erreur.
Pourquoi est-ce important ? Indique que le premier contrôle automatisé a été franchi. Un échec à cette étape signale un problème de qualité des données, plutôt qu’un problème de liquidités ou d’approbation. Où trouver ces données Déduit d’un changement de statut de « Reçu » à « En attente » ou « Prêt » dans un court délai. Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Erreur de paiement détectée	Enregistre le moment où une transaction reçoit un statut d’échec ou un code d’exception. Cela se produit lorsque les règles de validation ne sont pas respectées ou qu’un contrôle externe renvoie une réponse négative.
Pourquoi est-ce important ? Indispensable au tableau de bord « Suivi des erreurs de validation et des reprises ». Un volume élevé à cette étape signale des problèmes de qualité des données en amont. Où trouver ces données Le champ de statut de la transaction prend un code d’exception, par exemple « Invalide », « En attente » ou « Erreur ». Données à recueillir Enregistré lorsque le statut passe à « Erreur » Type d’événement explicit
	Erreur de paiement résolue	Correspond à la correction d’une transaction précédemment en erreur. Cet événement est déduit lorsque le statut de la transaction passe d’un état d’erreur à un état de traitement normal ou valide.
Pourquoi est-ce important ? Indispensable au calcul du « délai moyen de résolution des erreurs de paiement ». Il permet de mesurer l’efficacité de l’équipe opérationnelle. Où trouver ces données Déduit lorsque le statut de la transaction passe d’un code d’erreur à un code de traitement normal. Données à recueillir Comparez le champ de statut avant et après Type d’événement inferred
	Notification de paiement envoyée	Le système envoie un message (e-mail/SMS) au payeur ou au bénéficiaire pour confirmer la transaction. Cette notification améliore la transparence pour le client.
Pourquoi est-ce important ? Contribue à la « Rapidité et réactivité des notifications ». Un délai important après le règlement peut entamer la confiance des clients. Où trouver ces données Journaux de communication ou tables d’historique des interactions avec les clients, associés à l’ID de transaction. Données à recueillir Consigné lors de l’envoi de l’e-mail/SMS Type d’événement explicit
	Paiement annulé	Arrêt du flux de paiement avant le règlement, à l’initiative d’un utilisateur ou d’une règle système. Tout traitement ultérieur est interrompu.
Pourquoi est-ce important ? Permet de repérer le travail inutile et les opérations abandonnées. Un taux élevé d’annulations après approbation peut révéler des inefficacités dans le processus. Où trouver ces données Changement de statut vers « Annulé », « Invalidé » ou « Arrêté ». Données à recueillir Consigné lorsque le statut passe à « Annulé » Type d’événement explicit
	Paiement autorisé	Confirmation interne finale que les fonds sont disponibles et que la transaction peut être exécutée. Cette étape peut avoir lieu en même temps que l’approbation ou faire l’objet d’un contrôle système distinct.
Pourquoi est-ce important ? Distingue l’approbation managériale de l’autorisation au niveau du système. Important pour le Dashboard « Débit des autorisations d’approbation ». Où trouver ces données Changement de statut indiquant « Autorisé » ou « Prêt à comptabiliser ». Données à recueillir Comparez le champ de statut 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. Il confirme que l’entité suivante a bien reçu l’instruction.
Pourquoi est-ce important ? Permet de vérifier que l’« Instruction envoyée » a bien été transmise. Les écarts à cette étape peuvent signaler des problèmes de connectivité réseau ou de format externe. Où trouver ces données Journaux de traitement des fichiers entrants ou codes de réponse de l’API confirmant la réception. Données à recueillir Consigné à la réception de l’ACK Type d’événement explicit
	Paiement planifié	Cette étape intervient lorsqu’un paiement est approuvé, mais conservé en attente jusqu’à une date d’effet ultérieure. Le système met la transaction en file d’attente jusqu’à l’ouverture de la fenêtre de traitement.
Pourquoi est-ce important ? Permet d’expliquer les temps d’inactivité dans le processus. Distingue un retard dû à un goulot d’étranglement d’une attente volontaire jusqu’à la date d’échéance. Où trouver ces données Comparaison entre la « Date de saisie » et la « Date d’effet ». Si la date d’effet est ultérieure, cet état est actif. Données à recueillir À déduire en comparant le champ X au 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. Générez une clé API et un secret API (parfois appelés Client ID et Client Secret) disposant des autorisations nécessaires pour accéder à l’API Transaction Inquiry ou Search. Si les restrictions par adresse IP sont activées, vérifiez que votre adresse IP figure dans la liste d’autorisation de l’environnement Fiserv.

2. Préparation de l’environnement

Installez Python 3.8 ou une version ultérieure sur le serveur d’extraction ou votre ordinateur. Vous aurez besoin des bibliothèques requests et pandas, que vous pouvez 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 modifiez la section de configuration située en haut. Renseignez les valeurs propres à votre environnement pour API_KEY, API_SECRET et BASE_URL (utilisez l’URL de test pour les essais et l’URL de production pour l’exécution finale). Ajustez START_DATE et END_DATE à la période de Process Mining souhaitée.

4. Mise en place 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 signature, sauf si votre implémentation Fiserv utilise une autre norme, comme les jetons OAuth2 bearer.

5. Comprendre l’analyse des données

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

6. Gérer 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 les pages suivantes jusqu’à récupérer toutes les transactions de la période. Vérifiez la stabilité de votre connexion Internet, car l’opération peut prendre du temps avec de grands volumes de données.

7. Exécution

Lancez le script depuis la ligne de commande : python fiserv_extraction.py. La console affiche l’avancement, le nombre de pages traitées et le nombre de transactions récupérées. Surveillez les erreurs HTTP 401 (non autorisé) et 429 (limite de requêtes atteinte).

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. Traitement après extraction (facultatif)

Si vous devez ajuster les fuseaux horaires, 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. Importer dans ProcessMind

Importez le fichier CSV dans ProcessMind. Associez PaymentTransactionId à l’ID de cas, ActivityName à l’Activité et EventTimestamp à l’Horodatage. Veillez à associer les colonnes numériques, comme PaymentAmount, à des attributs.

Configuration

Identifiants API : une clé API et un secret ou secret partagé sont nécessaires. Vérifiez qu’ils disposent d’un accès en lecture aux points de terminaison de rapports de transactions.
URL de base : utilisez https://api.commerce.fiserv.com en production ou l’URL de certification ou de test fournie lors de l’intégration.
Période : une période d’extraction de 30 à 90 jours est recommandée en raison du volume des réponses de l’API. Pour les chargements historiques, exécutez le script par périodes mensuelles.
Taille des pages : configurée à 100 enregistrements par appel pour équilibrer l’utilisation de la mémoire et la charge réseau.
Fuseau horaire : l’API renvoie les horodatages en UTC. Le script conserve ce format pour assurer la cohérence entre les régions.
Nouvelle tentative : un mécanisme de nouvelle tentative simple est prévu en cas d’interruption temporaire du réseau (HTTP 500/502/503).

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 financiers en appliquant ce modèle à votre environnement Fiserv. Notre démarche guidée vous aide à réunir les données nécessaires pour améliorer concrètement votre trésorerie et 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

Réduisez les retards de rapprochement et maîtrisez vos flux de travail Fiserv.

Démarrez 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 pour l’API Fiserv Commerce Hub

Étapes

1. Configuration préalable

2. Préparation de l’environnement

3. Configuration du script

4. Mise en place de l’authentification

5. Comprendre l’analyse des données

6. Gérer la pagination

7. Exécution

8. Vérification du résultat

9. Traitement après extraction (facultatif)

10. Importer dans ProcessMind

Configuration

Exemple de requête python

Prêt à commencer ?

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

Prêt à commencer ?