> 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 de traitement des paiements (20) Activités de 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 à 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 robuste qui met en évidence les inefficacités et les risques de conformité au sein de 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

Nouveau dans 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 10 Recommandé 5 Facultatif

	Nom	Description
	ID de transaction de paiement PaymentTransactionId	L'identifiant unique de l'instruction de paiement ou du dossier de transaction spécifique.
Description 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 essentiel 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 c'est important C'est l'ID de cas fondamental requis pour regrouper les événements en instances de processus. Où obtenir 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.
Description 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 carte des processus et est essentiel 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 c'est important Définit les événements qui constituent la chronologie du processus. Où 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é
	Timestamp de l'événement EventTimestamp	La date et l'heure exactes de l'activité.
Description Cet attribut enregistre le moment précis où un événement a eu lieu. Il constitue la base de toute analyse temporelle, y compris les temps de cycle, les délais et l'identification des goulots d'étranglement. 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 c'est important Requis pour ordonner les événements et calculer les durées de performance du processus. Où obtenir 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
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière extraction ou rafraîchissement de l'enregistrement.
Description Indique la fraîcheur des données utilisées pour l'analyse. Ceci est crucial pour déterminer si les tableaux de bord 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 goulots d'étranglement actifs. Pourquoi c'est important Garantit l'actualité et la fiabilité des données. Où 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	Le nom du système d'où proviennent les données.
Description 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 c'est important Fournit le contexte technique et la lignée des données. Où obtenir Codé en dur lors de l'extraction ou des métadonnées système. Exemples Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Code d'erreur ErrorCode	Le code spécifique généré lorsqu'un paiement échoue à la validation.
Description 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 c'est important Identifie les causes profondes des reprises. Où obtenir 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.
Description Spécifie la devise dans laquelle le paiement est libellé (par exemple, USD, EUR). Cet attribut est essentiel 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 c'est important Nécessaire pour l'analyse du traitement multi-devises. Où obtenir 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é.
Description 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 livraison à temps et aide l'organisation à maintenir la confiance avec les bénéficiaires. Pourquoi c'est important Point de référence pour mesurer le respect des SLA. Où obtenir Détails de l'instruction de paiement. Exemples 2023-11-012023-11-15
	Durée de traitement ProcessingDuration	Le temps nécessaire à l'achèvement de l'activité spécifique.
Description Représente la durée de l'activité elle-même ou le temps écoulé depuis l'activité précédente. Cela permet une analyse granulaire de la répartition du temps dans le processus. Cet attribut est utilisé pour alimenter le mappage générique du « temps de traitement » et aide à identifier les étapes spécifiques qui sont systématiquement plus lentes que prévu. Pourquoi c'est important Mesure l'efficacité des étapes individuelles du processus. Où obtenir Calculé à partir des différences d'horodatage. Exemples 00:05:0024:00:0000:00:30
	Est STP IsStraightThroughProcessing	Indicateur signalant si le paiement n'a pas nécessité d'intervention manuelle.
Description 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 soutient directement 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 c'est important Métrique clé pour l'efficacité des processus et le succès de l'automatisation. Où obtenir 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).
Description Classifie la transaction par son canal de traitement. Cet attribut est fondamental 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 méthode 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 c'est important Segmente les flux de processus par l'infrastructure utilisée. Où obtenir 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.
Description 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 essentiel 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 c'est important Critique pour l'analyse des risques financiers et la détection des doublons. Où obtenir 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.
Description Identifie le compte destinataire. Comme le compte du payeur, cet élément est essentiel 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 c'est important Essentiel pour la détection des doublons et l'analyse des bénéficiaires. Où obtenir 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.
Description 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 c'est important Essentiel pour la détection des doublons et l'analyse des fraudes. Où obtenir 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é.
Description 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 tableaux de bord 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 goulots d'étranglement où des approbateurs spécifiques sont surchargés de demandes. Pourquoi c'est important Permet l'analyse des ressources et l'identification des goulots d'étranglement. Où obtenir 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.
Description 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 c'est important Analyse des dépendances externes. Où obtenir 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.
Description 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 c'est important Critique pour la conformité opérationnelle et la gestion de la liquidité. Où obtenir Calculé en comparant EventTimestamp avec la table de référence des délais. Exemples truefaux
	Est un retravail IsRework	Indicateur signalant si cette activité spécifique fait partie d'une boucle de reprise.
Description 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 carte 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 c'est important Isole le travail à valeur ajoutée du travail de correction. Où obtenir Calculé en fonction des boucles de processus. Exemples truefaux
	Niveau d'approbation ApprovalLevel	Le niveau hiérarchique requis ou utilisé pour autoriser le paiement.
Description 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 goulots d'étranglement. 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 c'est important Segmente les goulots d'étranglement d'approbation par hiérarchie. Où obtenir Tables des rôles utilisateur ou des workflows d'approbation. Exemples Niveau 1ResponsableDirecteurCFO
	Unité commerciale BusinessUnit	Le département ou la division qui a initié le paiement.
Description 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 c'est important Fournit un contexte organisationnel pour la performance. Où obtenir 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é	Description
	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 c'est important Marque le début de la chronologie du processus. Essentiel pour calculer le temps de cycle total et identifier les goulots d'étranglement d'admission. Où obtenir 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 Enregistré 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 c'est important Critique pour le « Moniteur de conformité des délais de traitement ». Garantit que l'organisation respecte les délais bancaires quotidiens. Où obtenir Journaux de traitement par lots ou horodatages de génération de fichiers. Souvent enregistrés comme 'Lot créé' ou 'Fichier transmis'. Capture Enregistré 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 c'est important Clé pour l'« Analyse du temps de cycle d'autorisation ». Les retards ici indiquent des goulots d'étranglement dans la chaîne d'approbation humaine. Où obtenir Journaux d'audit montrant une action utilisateur qui modifie le statut de 'En attente d'approbation' à 'Approuvé'. Capture Enregistré 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 c'est important Requis pour le 'Délai de Règlement au Rapprochement'. Assure la clôture exacte des comptes financiers. Où obtenir Journal des événements du module de rapprochement lorsque le statut passe à 'Rapproché' ou 'Compensé'. Capture Enregistré 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 c'est important Le point final principal pour le 'Taux de Traitement Direct'. Indique que les fonds ont effectivement été transférés. Où obtenir Statut de transaction 'Comptabilisée' ou présence d'un horodatage 'Date de Comptabilisation' dans le grand livre. Capture Enregistré 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 c'est 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. Où obtenir 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 c'est 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. Où obtenir Le champ de statut de la transaction passe à un code d'exception (par exemple, 'Invalide', 'En attente', 'Erreur'). Capture Enregistré 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 c'est important Essentiel pour le calcul du « Temps moyen de résolution des erreurs de paiement ». Il aide à mesurer l'efficacité de l'équipe des opérations. Où obtenir 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 c'est important Soutient la 'Vitesse et Réactivité des Notifications'. Des délais importants après le règlement réduisent la confiance des clients. Où obtenir Journaux de communication ou tables d'historique d'interaction client liés à l'ID de transaction. Capture Enregistré 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 c'est important Identifie le gaspillage et le travail abandonné. Des taux d'annulation élevés après approbation suggèrent des inefficacités de processus. Où obtenir Changement de statut en 'Annulé', 'Nul' ou 'Arrêté'. Capture Enregistré 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 c'est 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 ». Où obtenir 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 c'est 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. Où obtenir Journaux de traitement des fichiers entrants ou codes de réponse API accusant réception. Capture Enregistré à 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 c'est 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. Où obtenir 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 EventTimestamp 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 EventTimestamp à l'Horodatage. Assurez-vous que les colonnes numériques comme PaymentAmount sont mappé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 pour le Traitement des Paiements

Votre Modèle de Données pour le 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 pour le Traitement des Paiements

Votre Modèle de Données pour le 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