> Amélioration Continue des Processusus > Traitement des facturess factures fournisseurs factures fournisseurs paiements > Fiserv > Template de données

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

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

Fiserv

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

← Retour au Guide d'amélioration

Attributs de traitement des paiements (19) Activités de traitement des paiements (13) Guides d'extraction (1)

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

Ce modèle fournit un cadre structuré pour vous aider à mapper vos données Fiserv dans un format adapté à l'exploration de processus (Process Mining) et à l'analyse. Il décrit les attributs et activités essentiels nécessaires 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é dans vos opérations financières.

Attributs recommandés pour l'analyse des paiements
Jalons clés du processus à surveiller
Guide technique pour l'extraction de données Fiserv

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de traitement des paiements

Ces champs de données recommandés fournissent le contexte nécessaire à votre journal d'événements pour prendre en charge une analyse complète de l'ensemble de votre cycle de vie des paiements.

5 Obligatoire 9 Recommandé 5 Facultatif

	Nom	Descriptionn
	Horodatage de l'événement EventTimestamp	La date et l'heure exactes de l'activité.
Descriptionn Cet attribut enregistre le moment précis où un événement a eu lieu. Il sert de base à toute analyse temporelle, y compris les temps de cycle, les délais et l'identification des points de blocage. Dans les dashboards, ces données pilotent le calcul de la durée entre les étapes, comme le temps entre la 'Demande de paiement créée' et le 'Paiement autorisé'. Des horodatages de haute précision sont nécessaires pour ordonner avec exactitude les événements qui se succèdent rapidement. Pourquoi est-ce important ? : Requis pour ordonner les événements et calculer les durées de performance du processus. Source des données : Journaux d'audit ou colonnes d'horodatage de mise à jour des transactions. Exemples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	ID de transaction de paiement PaymentTransactionId	L'identifiant unique de l'instruction de paiement ou du dossier de transaction spécifique.
Descriptionn Cet attribut sert de clé centrale pour lier toutes les activités au sein 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, et le règlement final ou l'annulation. Dans les environnements Fiserv, il s'agit généralement de la clé primaire dans les tables d'historique des transactions. Il est indispensable pour reconstituer le flux de processus et s'assurer que les événements disjoints (comme un règlement intervenant plusieurs jours après l'autorisation) sont correctement associés au même objet métier. Pourquoi est-ce important ? : C'est l'ID de cas principal requis pour regrouper les événements en instances de processus. Source des données : Consulter la documentation Fiserv pour les tables d'en-tête de transaction ou de paiement. Exemples TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Nom de l'activité ActivityName	L'événement spécifique ou le changement de statut qui s'est produit dans le processus de paiement.
Descriptionn Cet attribut décrit l'étape exécutée, telle que 'Demande de paiement créée' ou 'Paiement réglé'. Il définit les nœuds dans la cartographie des processus et est indispensable pour comprendre la séquence des opérations. En analysant les activités distinctes, les organisations peuvent visualiser le workflow, identifier les étapes ignorées et détecter les chemins non conformes où des validations ou des approbations obligatoires ont été contournées. Pourquoi est-ce important ? : Définit les événements qui constituent la chronologie du processus. Source des 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 identifiéePaiement régléPaiement annulé
	Dernière mise à jour des données LastDataUpdate	Heure de la dernière extraction ou rafraîchissement de l'enregistrement.
Descriptionn Indique la la réactualisation des données utilisées pour l'analyse. Ceci est impératif pour déterminer si les dashboards reflètent des opérations en temps réel ou des instantanés historiques. Cela aide les utilisateurs à faire confiance aux métriques affichées, garantissant qu'ils ne prennent pas de décisions basées sur des données obsolètes, en particulier lors du suivi de la conformité des délais ou des points de blocage actifs. Pourquoi est-ce important ? : Garantit l'actualité et la fiabilité des données. Source des 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	Le nom du système d'où proviennent les données.
Descriptionn Identifie le module Fiserv spécifique ou le système externe qui a généré l'événement. Ceci est particulièrement utile dans les environnements complexes où les paiements peuvent provenir d'un canal frontal et être réglés dans un système bancaire central dorsal. Il permet aux analystes de filtrer la vue du processus par système d'origine, garantissant que l'analyse peut être ciblée vers des environnements techniques ou des points d'intégration spécifiques. Pourquoi est-ce important ? : Fournit le contexte technique et la traçabilité des données. Source des données : Codé en dur lors de l'extraction ou des métadonnées système. Exemples Fiserv PremierFiserv SignatureFiserv DNAFiserv Grande entreprise Payments Platform
	Code d'erreur ErrorCode	Le code spécifique généré lorsqu'un paiement échoue à la validation.
Descriptionn Capture le code d'erreur technique ou commercial associé aux activités « Erreur de paiement identifiée ». Cet attribut est la base du Suivi des erreurs de validation et des reprises. En agrégeant les fréquences de codes d'erreur spécifiques, l'organisation peut identifier les problèmes systémiques de qualité des données (par exemple, « Numéro de routage invalide ») et mettre en œuvre des correctifs ciblés pour la logique de validation ou la formation des utilisateurs. Pourquoi est-ce important ? : Identifie les causes profondes des reprises. Source des données : Journaux d'erreurs ou détails de statut de transaction. Exemples E-101INV_ACCNSF_ERRAUTH_FAIL
	Code de devise CurrencyCode	Le code de devise ISO pour le montant du paiement.
Descriptionn Spécifie la devise dans laquelle le paiement est libellé (par exemple, USD, EUR). Cet attribut est indispensable pour le tableau de bord 'Tendances de volume par devise et méthode', permettant à l'organisation de surveiller son exposition aux différentes devises étrangères. Il est également utilisé pour normaliser les montants pour les rapports mondiaux et pour garantir que les contrôles de doublons ne signalent pas à tort des transactions de même valeur numérique mais de devises différentes. Pourquoi est-ce important ? : Nécessaire pour l'analyse du traitement multi-devises. Source des données : Table d'en-tête de transaction, colonne Devise. Exemples USDEURGBPCADJPY
	Date d'échéance du paiement PaymentDueDate	La date à laquelle le paiement doit être traité.
Descriptionn La date cible d'achèvement du paiement. Cet attribut est utilisé dans le Moniteur de Conformité aux Dates Limites de Traitement pour signaler les transactions risquant d'être en retard. La comparaison de l'horodatage 'Paiement Réglé' avec cet attribut permet de calculer les métriques de paiement à temps et aide l'organisation à maintenir la confiance avec les bénéficiaires. Pourquoi est-ce important ? : Point de référence pour mesurer le respect des SLA. Source des données : Détails de l'instruction de paiement. Exemples 2023-11-012023-11-15
	Indicateur STP IsStraightThroughProcessing	Indicateur signalant si le paiement n'a pas nécessité d'intervention manuelle.
Descriptionn Un attribut booléen calculé qui est vrai si le cas ne contient aucune étape « Erreur de paiement identifiée », « Erreur de paiement résolue » ou « Paiement approuvé » manuelle (selon la définition). Cela contribue directement au l'indicateur clé de performance du taux de traitement direct. Il permet une segmentation binaire du processus : les flux purement automatisés par rapport à ceux nécessitant une intervention humaine, facilitant une vision claire du potentiel d'automatisation. Pourquoi est-ce important ? : Métrique clé pour l'efficacité des processus et le succès de l'automatisation. Source des données : Calculé lors de la transformation des données. Exemples truefaux
	Méthode de paiement PaymentMethod	Le mécanisme utilisé pour exécuter le paiement (par exemple, virement bancaire, ACH).
Descriptionn Classifie la transaction par son canal de traitement. Cet attribut est indispensable pour l'Analyse du temps de cycle d'autorisation, car différentes méthodes ont des procédures opérationnelles standard et des accords de niveau de service très différents. L'analyse des variantes de processus par mode de paiement aide à isoler si les retards sont systémiques à un canal spécifique (comme les virements internationaux) ou généraux à l'organisation. Pourquoi est-ce important ? : Segmente les flux de processus par l'infrastructure utilisée. Source des données : Type de transaction ou colonne de code d'instrument. Exemples Virement BancaireACHChèqueRTPTransfert interne
	Montant du paiement PaymentAmount	La valeur monétaire de la transaction de paiement.
Descriptionn Cet attribut représente la valeur financière associée au paiement. C'est une dimension primaire pour segmenter l'analyse, permettant aux utilisateurs de différencier les paiements stratégiques de grande valeur des transactions de routine de faible valeur. Il est indispensable pour la vue de 'Détection des Paiements en Doublon', où des montants identiques associés aux détails du payeur/bénéficiaire signalent des erreurs potentielles. Il soutient également l'analyse de l'autorité d'approbation, car des montants plus élevés déclenchent souvent des chemins de workflow différents. Pourquoi est-ce important ? : Critique pour l'analyse des risques financiers et la détection des doublons. Source des données : Table d'en-tête de transaction, colonne Montant. Exemples 150.0025000.5010.991000000.00
	Numéro de compte du bénéficiaire PayeeAccountNumber	Le numéro de compte auquel les fonds sont crédités.
Descriptionn Identifie le compte destinataire. Comme le compte du payeur, cet élément est indispensable pour la Vue de détection des paiements en double. Il garantit que l'analyse cible correctement les relations avec des bénéficiaires spécifiques. Dans le suivi de la conformité des délais, connaître le bénéficiaire peut aider à prioriser les fournisseurs stratégiques ou les règlements critiques qui ne doivent pas échouer. Pourquoi est-ce important ? : Primordial pour la détection des doublons et l'analyse des bénéficiaires. Source des données : Détails de la transaction, colonne Compte Crédit ou Bénéficiaire. Exemples 555000111222333444BEN-882-11
	Numéro de compte du payeur PayerAccountNumber	Le numéro de compte à partir duquel les fonds sont débités.
Descriptionn Identifie le compte source du paiement. C'est un composant clé de la Vue de détection des paiements en double. Combiné avec le Bénéficiaire, le Montant et l'Heure, il forme l'empreinte unique utilisée pour détecter les doubles paiements accidentels. Il permet également l'analyse du volume de paiements par compte d'origine pour identifier les portefeuilles internes les plus actifs. Pourquoi est-ce important ? : Primordial pour la détection des doublons et l'analyse des fraudes. Source des données : Détails de la transaction, colonne Compte Débit. Exemples 123456789987654321ACC-001-992
	Utilisateur de traitement ProcessingUser	L'ID utilisateur ou l'agent système responsable de l'activité.
Descriptionn Identifie qui a effectué l'action spécifique, qu'il s'agisse d'un approbateur humain ou d'un robot d'automatisation système. Ces données alimentent les dashboards d'efficacité du cycle de résolution des erreurs et de débit de l'autorité d'approbation. En suivant les utilisateurs, les analystes peuvent identifier les besoins de formation pour les personnes ayant des taux d'erreur élevés ou reconnaître les points de blocage où des approbateurs spécifiques sont surchargés de demandes. Pourquoi est-ce important ? : Permet l'analyse des ressources et l'identification des points de blocage. Source des données : Journaux d'audit, colonne ID utilisateur. Exemples jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Banque bénéficiaire BeneficiaryBank	Le nom ou l'identifiant de la banque réceptrice.
Descriptionn Identifie l'institution financière qui reçoit le paiement. Ceci est utile pour analyser les retards de règlement, car des banques réceptrices spécifiques peuvent avoir des vitesses de traitement ou des problèmes d'intégration différents. Il ajoute une dimension supplémentaire au tableau de bord de l'écart entre le règlement et le rapprochement, en soulignant si les retards sont externes (spécifiques à la banque) ou internes. Pourquoi est-ce important ? : Analyse des dépendances externes. Source des données : Détails de la transaction, colonne ID ou Nom de la Banque. Exemples ChaseBank of AmericaWells FargoCitibank
	Délai non respecté IsCutoffMissed	Indicateur signalant si le paiement a été envoyé après le délai bancaire quotidien.
Descriptionn Un booléen calculé qui compare l'heure d'« Instruction de paiement envoyée » au délai limite quotidien pour la devise/méthode spécifique. Cela soutient l'indicateur clé de performance du taux de respect des délais. L'identification des délais non respectés aide à enquêter sur les causes profondes des retards, qu'elles proviennent d'une initiation tardive ou d'un traitement interne lent. Pourquoi est-ce important ? : Critique pour la conformité opérationnelle et la gestion de la liquidité. Source des données : Calculé en comparant EventHorodatage avec la table de référence des délais. Exemples truefaux
	Est un reprises IsRework	Indicateur signalant si cette activité spécifique fait partie d'une boucle de reprise.
Descriptionn Un indicateur booléen signalant les activités qui se produisent après l'identification d'une erreur mais avant sa résolution, ou les activités répétées. Cela soutient l'indicateur clé de performance du taux de reprise de la validation des paiements. Il permet aux analystes de filtrer la cartographie des processus pour n'afficher que le « chemin optimal » ou, inversement, de se concentrer entièrement sur le « chemin de reprise » pour comprendre les modes de défaillance. Pourquoi est-ce important ? : Isole le travail à valeur ajoutée du travail de correction. Source des données : Calculé en fonction des boucles de processus. Exemples truefaux
	Niveau d'approbation ApprovalLevel	Le niveau hiérarchique requis ou utilisé pour autoriser le paiement.
Descriptionn Indique le niveau de séniorité ou d'autorité associé à l'activité « Paiement approuvé ». Ceci est utilisé dans le tableau de bord « Débit de l'autorité d'approbation » pour analyser si les approbateurs de niveau supérieur deviennent des points de blocage. Comprendre la distribution des paiements entre les niveaux (par exemple, Niveau 1 vs Niveau 3) aide à optimiser les politiques de délégation d'autorité. Pourquoi est-ce important ? : Segmente les points de blocage d'approbation par hiérarchie. Source des données : Tables des rôles utilisateur ou des workflows d'approbation. Exemples Niveau 1ResponsableDirecteurDirecteur financier
	Unité commerciale BusinessUnit	Le département ou la division qui a initié le paiement.
Descriptionn Catégorise le paiement par l'unité organisationnelle responsable de la dépense. Cela aide à allouer les coûts et à comprendre quelles parties de l'organisation génèrent le plus de reprises manuelles ou d'erreurs. Il soutient l'audit de conformité des parcours de paiement en garantissant que les différentes unités respectent leurs exigences de contrôle réglementaires ou internes spécifiques. Pourquoi est-ce important ? : Fournit un contexte organisationnel pour la performance. Source des données : Mappage des centres de coûts ou code de département. Exemples Banque de détailPrêts commerciauxGestion de patrimoineOpérations

Obligatoire Recommandé Facultatif

Activités de traitement des paiements

Capturez ces étapes et jalons essentiels du processus dans votre journal d'événements pour permettre une découverte et une optimisation précises de vos workflows de paiement.

5 Recommandé 8 Facultatif

	Activité	Descriptionn
	Demande de paiement créée	L'enregistrement initial de l'instruction de paiement dans le système Fiserv. Ceci est explicitement journalisé lorsqu'un utilisateur ou un système externe initie une transaction via une API ou une interface.
Pourquoi est-ce important ? : Marque le début de la chronologie du processus. Primordial pour calculer le temps de cycle total et identifier les points de blocage d'admission. Source des données : Horodatage de création de la table d'historique des transactions. Recherchez l'enregistrement le plus ancien avec l'ID de transaction de paiement spécifique. Capture Comptabilisé lors de l'insertion de l'enregistrement de transaction Type d'événement explicit
	Instruction de paiement envoyée	La transmission du fichier de paiement (par exemple, lot ACH, message Wire) au réseau externe ou à la chambre de compensation. C'est un point de transfert critique.
Pourquoi est-ce important ? : Critique pour le « Moniteur de conformité des délais de traitement ». Garantit que l'organisation respecte les délais bancaires quotidiens. Source des données : Journaux de traitement par lots ou horodatages de génération de fichiers. Souvent enregistrés comme 'Lot créé' ou 'Fichier transmis'. Capture Comptabilisé lors de la génération du fichier de lot Type d'événement explicit
	Paiement approuvé	Une décision manuelle ou automatisée d'autoriser le paiement à se poursuivre en fonction des limites d'autorité. Cela est capturé lorsqu'un utilisateur autorisé ou une règle système met à jour l'indicateur d'approbation.
Pourquoi est-ce important ? : Clé pour l'« Analyse du temps de cycle d'autorisation ». Les retards ici indiquent des points de blocage dans la chaîne d'approbation humaine. Source des données : Journaux d'audit montrant une action utilisateur qui modifie le statut de 'En attente d'approbation' à 'Approuvé'. Capture Comptabilisé lorsqu'une action d'approbation est effectuée Type d'événement explicit
	Paiement rapproché	Le rapprochement interne de la transaction avec les relevés bancaires ou les fichiers de règlement. Cela clôt la boucle pour la comptabilité.
Pourquoi est-ce important ? : Requis pour le 'Délai de Règlement au Rapprochement'. Assure la clôture exacte des comptes financiers. Source des données : Journal des événements du module de rapprochement lorsque le statut passe à 'Rapproché' ou 'Compensé'. Capture Comptabilisé lorsqu'une correspondance de rapprochement se produit Type d'événement explicit
	Paiement réglé	Le mouvement des fonds est finalisé et enregistré dans le grand livre. Cela marque l'achèvement financier de la transaction du point de vue de la banque.
Pourquoi est-ce important ? : Le point final principal pour le 'Taux de Traitement Direct'. Indique que les fonds ont effectivement été transférés. Source des données : Statut de transaction 'Comptabilisée' ou présence d'un horodatage 'Date de Comptabilisation' dans le grand livre. Capture Comptabilisé lors de la publication GL Type d'événement explicit
	Détails du paiement validés	Le système vérifie les numéros de compte, les numéros de routage et la conformité au format. Cela est généralement inféré lorsqu'une transaction passe avec succès d'un statut reçu à un statut en attente ou approuvé sans déclencher d'erreur.
Pourquoi est-ce important ? : Indique que la première porte automatisée a été franchie. Un échec ici représente des problèmes de qualité des données plutôt que des problèmes de liquidité ou d'approbation. Source des données : Déduit d'un changement de statut de 'Reçu' à 'En attente' ou 'Prêt' dans un court laps de temps. Capture Comparer le champ de statut avant/après Type d'événement inferred
	Erreur de paiement identifiée	Capture le moment où une transaction est signalée avec un statut d'échec ou un code d'exception. Cela se produit lorsque les règles de validation échouent ou que les vérifications externes renvoient une réponse négative.
Pourquoi est-ce important ? : Critique pour le tableau de bord « Suivi des erreurs de validation et des reprises ». Des volumes élevés ici indiquent des problèmes de qualité des données en amont. Source des données : Le champ de statut de la transaction passe à un code d'exception (par exemple, 'Invalide', 'En attente', 'Erreur'). Capture Comptabilisé lorsque le statut passe à Erreur Type d'événement explicit
	Erreur de paiement résolue	Représente la correction d'une transaction précédemment erronée. Ceci est inféré lorsqu'une transaction passe d'un statut d'erreur à un statut de traitement ou valide.
Pourquoi est-ce important ? : Primordial pour le calcul du « Temps moyen de résolution des erreurs de paiement ». Il aide à mesurer l'efficacité de l'équipe des opérations. Source des données : Déduit lorsque le statut de la transaction passe d'un code d'erreur à un code de traitement normal. Capture Comparer le champ de statut avant/après Type d'événement inferred
	Notification de paiement envoyée	Le système déclenche une communication (e-mail/SMS) à l'émetteur ou au bénéficiaire confirmant la transaction. Cela améliore la transparence pour le client.
Pourquoi est-ce important ? : Soutient la 'Vitesse et Réactivité des Notifications'. Des délais importants après le règlement réduisent la confiance des clients. Source des données : Journaux de communication ou tables d'historique d'interaction client liés à l'ID de transaction. Capture Comptabilisé lors du déclenchement d'un e-mail/SMS Type d'événement explicit
	Paiement annulé	L'interruption d'un flux de paiement avant le règlement, initiée par un utilisateur ou une règle système. Cela arrête tout traitement ultérieur.
Pourquoi est-ce important ? : Identifie le gaspillage et le travail abandonné. Des taux d'annulation élevés après approbation suggèrent des inefficacités de processus. Source des données : Changement de statut en 'Annulé', 'Nul' ou 'Arrêté'. Capture Comptabilisé lorsque le statut passe à Annulé Type d'événement explicit
	Paiement autorisé	La confirmation interne finale que les fonds sont disponibles et que la transaction est prête à être exécutée. Cela peut se produire simultanément avec l'approbation ou comme une vérification système distincte.
Pourquoi est-ce important ? : Différencie l'approbation managériale de l'autorisation au niveau système. Important pour le tableau de bord « Débit de l'autorité d'approbation ». Source des données : Changement de statut indiquant 'Autorisé' ou 'Prêt à être Comptabilisé'. Capture Comparer le champ de statut avant/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 valablement par l'entité suivante.
Pourquoi est-ce important ? : Valide le succès de l''Instruction Envoyée'. Les écarts ici indiquent des problèmes de connectivité réseau ou de format externe. Source des données : Journaux de traitement des fichiers entrants ou codes de réponse API accusant réception. Capture Comptabilisé à la réception de l'ACK Type d'événement explicit
	Paiement planifié	Se produit lorsqu'un paiement est approuvé mais retenu pour une date d'effet future. Le système met la transaction en file d'attente jusqu'à l'ouverture de la fenêtre de traitement.
Pourquoi est-ce important ? : Explique le temps d'inactivité dans le processus. Différencie un retard causé par un goulot d'étranglement d'une attente délibérée de la date d'échéance. Source des données : Comparaison de la 'Date d'entrée' et de la 'Date d'effet'. Si la Date d'effet est future, cet état est actif. Capture Dériver en comparant le champ X à Y Type d'événement calculated

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données de Fiserv

Étapes

1. Configuration préalable

Assurez-vous d'avoir accès au portail développeur Fiserv Commerce Hub. Vous devrez générer une clé API et un secret API (parfois appelés ID client et Secret client) avec les permissions d'accéder à l'API de consultation ou de recherche de transactions. Vérifiez que votre adresse IP est autorisée dans l'environnement Fiserv si des restrictions IP sont activées.

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 via pip : pip install requests pandas. Créez un répertoire de travail pour votre script et vos fichiers de sortie.

3. Configuration du script

Téléchargez le script Python fourni dans votre répertoire de travail. Ouvrez le script et mettez à jour la section de configuration en haut. Vous devez fournir votre API_KEY, API_SECRET et BASE_URL spécifiques (utilisez l'URL du bac à sable pour les tests et l'URL de production pour l'exécution finale). Ajustez les dates START_DATE et END_DATE pour couvrir la fenêtre de process mining souhaitée.

4. Implémentation de la logique d'authentification

Le script inclut une classe d'aide pour gérer les exigences d'authentification spécifiques de Fiserv, qui impliquent généralement la génération d'une signature HMAC à l'aide de votre secret API, de l'horodatage et de la charge utile de la requête. Ne modifiez pas la logique de génération de signature, sauf si votre implémentation Fiserv spécifique utilise une norme différente (par exemple, les jetons de porteur OAuth2).

5. Compréhension de la logique d'analyse

Le script interroge l'API pour les transactions. L'API renvoie généralement un instantané de l'objet transactionnel contenant divers horodatages (par exemple, heure de soumission, heure d'autorisation, heure de règlement). Le script analyse cet objet JSON unique et le déplie en plusieurs lignes (événements) pour le journal d'événements. Par exemple, un seul enregistrement JSON avec un horodatage de soumission et un horodatage de règlement générera au moins deux lignes distinctes dans votre fichier CSV.

6. Gestion de la pagination

Le script implémente 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'à ce que toutes les transactions de la plage de dates soient récupérées. Assurez-vous que votre connexion Internet est stable, car cela peut prendre du temps pour les grands ensembles de données.

7. Exécution

Exécutez le script via la ligne de commande : python fiserv_extraction.py. La console affichera la progression, montrant le nombre de pages traitées et de transactions récupérées. Surveillez les erreurs HTTP 401 (Non autorisé) ou 429 (Limite de débit).

8. Vérification de la sortie

Une fois le script terminé, vérifiez le répertoire pour un fichier nommé fiserv_event_log.csv. Ouvrez ce fichier et vérifiez que la colonne (ActivityName) contient un mélange des 13 activités requises et que le champ EventHorodatage est correctement formaté.

9. Post-traitement (facultatif)

Si vous avez besoin d'ajustements de fuseau horaire spécifiques (par exemple, convertir l'UTC en heure locale), vous pouvez modifier la section de transformation pandas dans le script ou gérer cela dans ProcessMind après le téléchargement.

10. Téléchargement vers ProcessMind

Importez le fichier CSV dans ProcessMind. Mappez PaymentTransactionId à l'ID de cas, (ActivityName) à l'Activité et EventHorodatage à l'Horodatage. Assurez-vous que les colonnes numériques comme PaymentAmount sont associées comme attributs.

Configuration

Informations d'identification API : Nécessite une clé API et un secret/secret partagé. Assurez-vous qu'elles ont un accès en lecture aux points de terminaison de reporting des transactions.
URL de base : Définie sur https://api.commerce.fiserv.com pour la production ou l'URL spécifique du certificat/bac à sable fournie lors de l'intégration.
Plage de dates : La fenêtre d'extraction recommandée est de 30 à 90 jours en raison de la taille des charges utiles de l'API. Pour les chargements historiques, exécutez le script par blocs mensuels.
Taille de page : Configurée à 100 enregistrements par appel pour équilibrer l'utilisation de la mémoire et la surcharge réseau.
Fuseau horaire : L'API renvoie les horodatages en UTC. Le script conserve cette norme pour assurer la cohérence entre les régions.
Logique de nouvelle tentative : Mécanisme de nouvelle tentative de base inclus pour les délais d'attente réseau intermittents (HTTP 500/502/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()

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

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

Attributs de traitement des paiements

Activités de traitement des paiements

Guides d'extraction

Script Python d'API Fiserv Commerce Hub

Étapes

1. Configuration préalable

2. Configuration de l'environnement

3. Configuration du script

4. Implémentation de la logique d'authentification

5. Compréhension de la logique d'analyse

6. Gestion de la pagination

7. Exécution

8. Vérification de la sortie

9. Post-traitement (facultatif)

10. Téléchargement vers ProcessMind

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimiser le traitement des paiements et atteindre 98 % de STP aujourd'hui

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

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

Attributs de traitement des paiements

Activités de traitement des paiements

Guides d'extraction

Script Python d'API Fiserv Commerce Hub

Étapes

1. Configuration préalable

2. Configuration de l'environnement

3. Configuration du script

4. Implémentation de la logique d'authentification

5. Compréhension de la logique d'analyse

6. Gestion de la pagination

7. Exécution

8. Vérification de la sortie

9. Post-traitement (facultatif)

10. Téléchargement vers ProcessMind

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimiser le traitement des paiements et atteindre 98 % de STP aujourd'hui