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

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

Adyen

← Retour au Guide d'amélioration

Attributs de traitement des paiements (19) Activités de traitement des paiements (16) Guides d'extraction (2)

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

Ce modèle fournit un guide détaillé pour la collecte des données nécessaires afin d'analyser votre traitement des paiements dans Adyen. Il décrit tous les attributs de données essentiels et les activités de processus à suivre, ainsi que des instructions pratiques pour l'extraction des données. Utilisez ceci pour vous assurer de capturer toutes les informations critiques pour un Process Mining efficace.

Attributs recommandés à collecter
Activités clés à suivre
Guide pratique d'extraction pour Adyen

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

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre traitement des paiements au sein d'Adyen.

5 Obligatoire 6 Recommandé 8 Facultatif

	Nom	Descriptionn
	Horodatage de l'événement EventDate	La date et l'heure auxquelles l'activité de paiement spécifique a eu lieu.
Descriptionn Cet attribut enregistre l'horodatage précis du moment où un événement (comme une autorisation ou un règlement) a été enregistré dans le système. Il permet l'ordonnancement chronologique des activités au sein d'un cas. En analyse, ceci est impératif pour calculer les temps de cycle, identifier les points de blocage et déterminer le débit du système au fil du temps. Il prend en charge tous les KPI basés sur le temps, tels que le 'Temps de cycle global des paiements'. Pourquoi est-ce important ? : Primordial pour l'ordonnancement des événements et le calcul de toutes les métriques basées sur la durée. Source des données : Champ 'eventDate' des webhooks de notification Adyen. Exemples 2023-10-27T10:00:00+01:002023-10-27T10:05:30+01:002023-10-28T09:15:00+01:00
	ID de transaction de paiement PspReference	L'identifiant de référence unique attribué par Adyen à chaque transaction de paiement.
Descriptionn Cet attribut sert de clé primaire pour l'ensemble du cycle de vie des paiements dans l'écosystème Adyen. Il relie la demande de paiement initiale à des événements ultérieurs tels que l'autorisation, la capture, le règlement, et les remboursements potentiels ou les rétrofacturations. En analyse, cet ID est utilisé pour regrouper des événements discrets en un seul cas, permettant la reconstruction du processus complet. Il permet aux analystes de suivre le parcours spécifique d'un paiement de l'initiation par l'acheteur jusqu'au règlement financier final. Pourquoi est-ce important ? : C'est le lien clé qui regroupe les événements déconnectés en une seule instance de processus pour le Process Mining. Source des données : Réponse de paiement Adyen 'pspReference' ou colonne 'PSP Reference' du rapport de règlement. Exemples 851564567890123479145612345678908825641234567890
	Nom de l'activité EventCode	L'étape ou l'action spécifique se produisant dans le cycle de vie du paiement.
Descriptionn Cet attribut définit l'événement spécifique qui s'est produit, tel que AUTHORISATION, CAPTURE ou REFUND. Il dicte les nœuds de la carte de processus et détermine le flux de la transaction. En analyse, ces codes sont traduits en noms d'activités lisibles par l'homme pour visualiser le flux de processus. Les variations dans la séquence de ces codes indiquent différents chemins de processus, tels que le traitement direct versus la gestion des exceptions. Pourquoi est-ce important ? : Définit le 'quoi' du modèle de Process Mining, pour visualiser des flux de processus. Source des données : Champ 'eventCode' des webhooks de notification Adyen. Exemples AUTHORISATIONCAPTUREREFUNDCANCELLATIONCHARGEBACK
	Dernière mise à jour des données LastDataUpdate	Heure de la dernière extraction ou rafraîchissement de l'enregistrement.
Descriptionn Cet attribut indique la la réactualisation des données dans le modèle de Process Mining. Il aide les utilisateurs à comprendre s'ils consultent des données en temps réel ou un instantané. En analyse, il s'agit principalement d'un champ technique utilisé pour la gouvernance des données et la validation du bon fonctionnement du pipeline. Pourquoi est-ce important ? : Champ technique pour suivre la la réactualisation des données. Source des données : Heure système lors de l'extraction. Exemples 2023-10-30T12:00:00Z
	Système source SourceSystem	Le nom du système d'où proviennent les données.
Descriptionn Cet attribut statique identifie que l'enregistrement provient d'Adyen. Dans le Process Mining multi-système (par exemple, en combinant Adyen avec SAP), ceci est impératif pour la lignée. En analyse, il permet aux utilisateurs de filtrer les activités qui se sont spécifiquement produites dans la passerelle de paiement par rapport à l'ERP ou au système de gestion des commandes. Pourquoi est-ce important ? : Primordial pour la traçabilité des données dans le Process Mining multi-systèmes. Source des données : Valeur statique lors de l'extraction. Exemples AdyenAdyen_Production
	Compte Marchand MerchantAccount	Le compte marchand spécifique au sein d'Adyen traitant la transaction.
Descriptionn Adyen permet d'avoir plusieurs comptes marchands sous un seul compte d'entreprise. Cet attribut identifie l'unité commerciale, la marque ou l'entité régionale spécifique qui a traité le paiement. En analyse, il sert de dimension principale pour la segmentation. Il permet aux parties prenantes de comparer les performances, les taux d'échec et les volumes entre différentes unités commerciales ou marques afin d'identifier les domaines spécifiques à améliorer. Pourquoi est-ce important ? : Clé pour segmenter la performance par unité commerciale ou filiale. Source des données : Requête/Réponse de paiement Adyen 'merchantAccount'. Exemples MyStore_UKMyStore_USGlobalSales_Main
	Est un reprises IsRework	Indicateur signalant si la transaction a impliqué des tentatives infructueuses ou des corrections d'erreur.
Descriptionn Un indicateur booléen qui est vrai si le cas contient plusieurs tentatives d'autorisation, ou des activités comme 'Paiement Refusé' suivies d'une nouvelle tentative. En analyse, ceci alimente le tableau de bord 'Points chauds de reprise et d'exception de paiement'. Il permet aux analystes de filtrer spécifiquement les cas problématiques pour comprendre pourquoi les flux de processus ne suivent pas le chemin idéal. Pourquoi est-ce important ? : Identifie les cas inefficaces nécessitant une intervention manuelle ou système. Source des données : Calculé sur la base de l'occurrence des événements d'échec > 0. Exemples truefaux
	Méthode de paiement PaymentMethod	La méthode spécifique utilisée par l'acheteur pour payer, telle que Visa ou PayPal.
Descriptionn Cet attribut capture le type d'instrument de paiement utilisé, y compris les marques de cartes de crédit (Visa, MC), les portefeuilles numériques (PayPal, Apple Pay) ou les méthodes de paiement locales (iDEAL, Sofort). En analyse, ceci est indispensable à le tableau de bord 'Aperçus de la performance des méthodes de paiement'. Il aide à établir des corrélations entre les méthodes de paiement spécifiques et les taux d'autorisation, les vitesses de traitement ou les échecs techniques. Pourquoi est-ce important ? : Indispensable pour l'analyse des taux de succès et des coûts à travers différents fournisseurs de paiement. Source des données : Réponse de paiement Adyen 'paymentMethod.brand' ou 'paymentMethod.type'. Exemples visamcpaypalidealklarna
	Montant de la transaction PaymentAmount	La valeur monétaire de la transaction de paiement.
Descriptionn Cet attribut représente la valeur financière associée à la transaction. Il est généralement stocké en tant qu'unité mineure (par exemple, cents) dans les données brutes mais doit être converti pour les rapports. En analyse, cela active le tableau de bord 'Débit des paiements' et aide à prioriser les cas de reprise à forte valeur. Il est également utilisé pour calculer le volume total traité et l'impact financier des transactions échouées. Pourquoi est-ce important ? : Nécessaire pour l'analyse d'impact financier et le monitoring du débit. Source des données : Requête de paiement Adyen 'amount.value'. Exemples 10005509900
	Motif du refus RefusalReason	La description textuelle expliquant pourquoi un paiement a été refusé ou a échoué.
Descriptionn Lorsqu'une transaction échoue, Adyen fournit un code de motif ou une description (par exemple, 'Solde insuffisant', 'CVC refusé', 'Carte expirée'). En analyse, c'est le principal moteur du tableau de bord 'Taux d'échec des transactions de paiement'. L'analyse de ces motifs aide à identifier si les échecs sont dus à des problèmes techniques, des règles de fraude ou au comportement de l'acheteur, orientant des actions de remédiation spécifiques. Pourquoi est-ce important ? : L'attribut clé pour l'analyse des causes profondes des paiements échoués. Source des données : Réponse de paiement Adyen 'refusalReason'. Exemples RefuséSolde insuffisantCarte expiréeErreur de l'acquéreurFraude
	Statut du paiement PaymentStatus	L'état actuel du paiement (par exemple, Autorisé, Réglé, Refusé).
Descriptionn Cet attribut reflète le dernier statut connu de la transaction de paiement. Il est souvent dérivé de l'activité la plus récente dans le cas. En analyse, il permet un filtrage rapide des cas (par exemple, 'Montrez-moi tous les paiements actuellement refusés'). Il est indispensable pour le tableau de bord 'Débit des paiements et surveillance du statut'. Pourquoi est-ce important ? : Fournit un instantané de l'état actuel de la transaction. Source des données : Dérivé du dernier code d'événement dans le cas. Exemples RégléeRefuséAutorisé
	Code d'autorisation AuthorisationCode	Le code d'autorisation renvoyé par l'émetteur après approbation.
Descriptionn Un code indiquant que les fonds ont été réservés sur la carte de l'acheteur. C'est la preuve d'une autorisation réussie. En analyse, ceci est principalement destiné à l'audit et à la traçabilité. Il valide que l'activité 'Paiement Autorisé' était légitime. Pourquoi est-ce important ? : Preuve d'autorisation réussie pour les pistes d'audit. Source des données : Réponse de paiement Adyen 'authCode'. Exemples 123456098712
	Devise PaymentCurrency	Le code ISO à trois lettres indiquant la devise de la transaction.
Descriptionn Cet attribut définit la devise dans laquelle le `PaymentAmount` est exprimé. Les valeurs courantes incluent EUR, USD, GBP, etc. En analyse, ceci est utilisé pour regrouper les transactions par marché et est indispensable pour normaliser les valeurs financières lors de l'agrégation de données à travers différentes régions. Pourquoi est-ce important ? : Contextualise le champ de montant pour le reporting multi-devises. Source des données : Requête de paiement Adyen 'amount.currency'. Exemples EURUSDGBP
	ID client ShopperReference	Une référence unique utilisée pour identifier l'acheteur à travers plusieurs transactions.
Descriptionn Cet identifiant relie différentes transactions à la même entité client. Il est fourni par le commerçant lors de la demande de paiement. En analyse, cela permet une analyse orientée client, permettant la détection des récidivistes dans les cas de fraude ou des clients fidèles dans l'analyse des transactions réussies. Il facilite le mappage générique 'Client'. Pourquoi est-ce important ? : Permet l'agrégation au niveau du client et l'analyse comportementale. Source des données : Requête de paiement Adyen 'shopperReference'. Exemples CUST-001user_1, 2, 3, 45email@example.com
	Numéro de lot de règlement BatchNumber	Le numéro de lot associé au règlement des fonds.
Descriptionn Adyen regroupe les paiements réglés en lots pour le versement. Cet attribut identifie à quel lot une transaction spécifique appartient. En analyse, il est utilisé pour regrouper les paiements par leur cycle de versement. Il aide à vérifier si des lots spécifiques sont retardés et prend en charge le suivi de l'activité 'Paiement Réglé'. Pourquoi est-ce important ? : Lie les transactions individuelles aux règlements financiers groupés. Source des données : Rapport de détail des règlements Adyen 'Batch Number'. Exemples 100255
	Pays de l'acheteur ShopperCountry	Le code pays à deux lettres de l'acheteur.
Descriptionn Cet attribut indique la localisation de l'acheteur, généralement dérivée du pays d'émission de la carte ou de l'adresse de facturation. En analyse, il est utilisé pour l'analyse des performances régionales. Il aide à identifier si certains pays ont des taux de refus plus élevés ou des temps de traitement plus lents en raison de l'infrastructure bancaire locale. Pourquoi est-ce important ? : Permet une segmentation géographique de la performance des paiements. Source des données : Requête de paiement Adyen 'countryCode' ou 'billingAddress.country'. Exemples NLUSDE
	Référence de l'acquéreur AcquirerReference	Numéro de référence fourni par la banque acquéreuse.
Descriptionn Il s'agit de la référence externe attribuée par l'institution financière sous-jacente (acquéreur) qui traite la transaction par carte. Elle est distincte de la référence PSP d'Adyen. En analyse, ce champ est indispensable pour l''Analyse des retards de rapprochement des paiements'. C'est la clé utilisée pour faire correspondre les enregistrements Adyen avec les relevés bancaires dans les grands livres externes. Pourquoi est-ce important ? : Primordial pour le rapprochement triple et la réconciliation externe. Source des données : Réponse de paiement Adyen 'additionalData.acquirerReference'. Exemples 1234567890987654321
	Score de risque de fraude RiskScore	Le score de risque attribué à la transaction par le moteur de fraude.
Descriptionn Le moteur RevenueProtect d'Adyen attribue un score numérique (0-100) indiquant la probabilité de fraude. Des scores plus élevés déclenchent souvent un examen manuel ou un blocage automatique. En analyse, ceci soutient la 'Vue d'ensemble des risques de conformité financière'. La corrélation des scores de risque élevés avec les rétrofacturations aide à ajuster les règles de fraude. Des scores élevés qui débouchent sur des paiements réussis pourraient indiquer des faux positifs dans le modèle de risque. Pourquoi est-ce important ? : Primordial pour analyser l'efficacité de la logique de prélèvement.vention de la fraude. Source des données : Réponse de l'API Adyen Risk ou Reporting 'fraudResult.accountScore'. Exemples 025100
	Type d'interaction client ShopperInteraction	Indique si le paiement était E-commerce, POS ou un abonnement (ContAuth).
Descriptionn Cet attribut catégorise la nature de l'interaction entre l'acheteur et le commerçant. Les valeurs typiques sont `Ecommerce` (en ligne), `POS` (en magasin) ou `ContAuth` (récurrent/abonnement). En analyse, cela aide à distinguer les différents modèles commerciaux et canaux de vente. Les flux de processus diffèrent souvent significativement entre le POS et l'Ecommerce, ce qui en fait un filtre vital pour une découverte de processus propre. Pourquoi est-ce important ? : Différencie les flux de processus entre les paiements en ligne, en magasin et récurrents. Source des données : Requête de paiement Adyen 'shopperInteraction'. Exemples E-commerceContAuthPOSMoto

Obligatoire Recommandé Facultatif

Activités de traitement des paiements

Ce sont les étapes clés du processus et les jalons à capturer dans votre journal d'événements pour une découverte de processus précise dans vos flux de paiements Adyen.

5 Recommandé 11 Facultatif

	Activité	Descriptionn
	Demande de paiement reçue	La réception initiale de la demande de transaction par la plateforme de paiement Adyen. Ceci est capturé à partir de l'horodatage initial de la demande API ou de la création de la pspReference.
Pourquoi est-ce important ? : Marque le début absolu de l'instance de processus. Primordial pour le calcul du temps de cycle total complet. Source des données : Journaux de l'API de paiement Adyen ou horodatage associé à la création du pspReference. Capture Comptabilisé lorsque le pspReference est généré via l'API Type d'événement explicit
	Paiement autorisé	L'émetteur de la carte ou le moyen de paiement a approuvé la transaction et les fonds sont réservés. Capturé via le webhook de notification standard d'Adyen.
Pourquoi est-ce important ? : Un jalon critique indiquant que la transaction est valide et que les fonds sont disponibles. Précondition pour la capture. Source des données : Webhook de notification Adyen : eventCode 'AUTHORISATION' avec success='true'. Capture Comptabilisé lors du succès du webhook AUTHORISATION Type d'événement explicit
	Paiement Capturé	L'ordre de transfert de fonds de l'acheteur vers le commerçant a été traité avec succès. Cela peut être immédiat (auto-capture) ou différé (capture manuelle).
Pourquoi est-ce important ? : Confirme la reconnaissance des revenus. Le temps entre l'autorisation et la capture est indispensable pour le KPI 'Délai d'autorisation de paiement'. Source des données : Webhook de notification Adyen : eventCode 'CAPTURE' avec success='true'. Capture Comptabilisé lors du succès du webhook CAPTURE Type d'événement explicit
	Paiement refusé	La transaction a été refusée par l'émetteur ou les règles de risque d'Adyen. Capturé via le webhook d'autorisation avec un statut d'échec.
Pourquoi est-ce important ? : Impacte directement le KPI 'Taux d'échec des transactions de paiement'. L'analyse des raisons de refus aide à optimiser les taux d'autorisation. Source des données : Webhook de notification Adyen : eventCode 'AUTHORISATION' avec success='false'. Capture Comptabilisé lors de l'échec du webhook AUTHORISATION Type d'événement explicit
	Paiement réglé	Les fonds ont été compensés et crédités avec succès sur le compte Adyen du commerçant. Ceci apparaît dans le rapport de détail des règlements.
Pourquoi est-ce important ? : La conclusion financière du processus réussi. Essentielle pour le 'Temps de cycle global des paiements' et l''Analyse des retards de rapprochement des paiements'. Source des données : Rapport de détail des règlements Adyen (SDR), type d'enregistrement 'Settled'. Capture Comptabilisé lorsque la transaction apparaît dans le rapport de règlement Type d'événement explicit
	Capture échouée	La tentative de capture des fonds autorisés a échoué, souvent en raison d'un délai d'attente technique ou de changements de statut de carte entre l'autorisation et la capture.
Pourquoi est-ce important ? : Point d'erreur critique nécessitant une reprise ou une nouvelle tentative. Contribue au 'Taux d'exception de paiement'. Source des données : Webhook de notification Adyen : eventCode 'CAPTURE_FAILED'. Capture Comptabilisé lors du webhook CAPTURE_FAILED Type d'événement explicit
	Erreur technique enregistrée	Une erreur système s'est produite pendant le traitement, telle qu'une défaillance de webhook ou un timeout d'API. Identifiée via des codes d'erreur spécifiques dans l'interface.
Pourquoi est-ce important ? : Facilite l'analyse du 'Taux d'échec des transactions de paiement' en catégorisant les échecs techniques versus financiers. Source des données : Journaux d'interface Adyen ou réponses d'échec spécifiques dans les appels API. Capture Comptabilisé lorsqu'un code de réponse d'erreur 5xx ou 4xx est retourné Type d'événement explicit
	Filtrage des risques effectué	Le moteur RevenueProtect d'Adyen analyse la transaction pour détecter les signaux de fraude. Ceci est déduit de la présence d'un score de fraude ou d'un résultat de risque dans la réponse d'autorisation.
Pourquoi est-ce important ? : Des scores de risque élevés peuvent déclencher des examens manuels ou des refus automatiques, créant des points de blocage ou des points de terminaison de processus. Source des données : Réponse de paiement Adyen (champ fraudResult) ou journaux de gestion des cas. Capture Infére de la présence de l'objet fraudResult Type d'événement inferred
	Notification de rétrofacturation reçue	Adyen a reçu une notification de litige du système de carte. Cela déclenche le workflow de litige.
Pourquoi est-ce important ? : Indicateur majeur de conformité et de risque. Il alimente le 'Taux d'incidents de conformité' et nécessite une intervention manuelle immédiate. Source des données : Webhook de notification Adyen : eventCode 'CHARGEBACK' ou 'NOTIFICATION_OF_CHARGEBACK'. Capture Comptabilisé lors du webhook CHARGEBACK Type d'événement explicit
	Paiement annulé	L'autorisation a été annulée avant que les fonds ne soient capturés. Cela libère les fonds réservés sur la carte de l'acheteur.
Pourquoi est-ce important ? : Représente une boucle de processus où une commande valide est terminée avant son achèvement, souvent en raison d'une demande du client ou d'un délai d'expiration du stock. Source des données : Webhook de notification Adyen : eventCode 'CANCELLATION'. Capture Comptabilisé lors du webhook CANCELLATION Type d'événement explicit
	Paiement envoyé pour règlement	Adyen a transmis la transaction à la banque acquéreuse ou au réseau pour traitement financier. Le statut passe à SentForSettlement.
Pourquoi est-ce important ? : Marque la transition du traitement opérationnel à la compensation financière. Les retards ici affectent la trésorerie. Source des données : API de statut de transaction Adyen ou inféré des journaux d'historique de changement de statut. Capture Comparer la transition du champ de statut à SentForSettlement Type d'événement inferred
	Remboursement initié	Une demande de retour de fonds à l'acheteur a été déclenchée. Cela initie un flux de processus inverse.
Pourquoi est-ce important ? : Indique une exception post-règlement. Des taux de remboursement élevés peuvent indiquer des problèmes de qualité en amont. Source des données : Webhook de notification Adyen : eventCode 'REFUND'. Capture Comptabilisé lors du déclenchement du webhook REFUND Type d'événement explicit
	Remboursement réglé	Le remboursement a été traité financièrement et débité du compte marchand. Confirmé via le rapport détaillé de règlement.
Pourquoi est-ce important ? : Clôture le processus de remboursement. Important pour le 'Temps moyen de résolution des erreurs' si le remboursement était dû à une erreur. Source des données : Rapport de détail des règlements Adyen, type d'enregistrement 'Refunded' ou 'RefundedReversed'. Capture Comptabilisé lorsque le remboursement apparaît dans le rapport de règlement Type d'événement explicit
	Rétrofacturation défendue	Des preuves ont été soumises à Adyen pour contester une rétrofacturation. Cela représente une activité de reprise/manuelle dans le flux de litige.
Pourquoi est-ce important ? : Suit les efforts consacrés à la protection des revenus. Important pour le 'Taux de reprise des paiements'. Source des données : API Adyen Disputes ou journaux de gestion des cas montrant la soumission des preuves. Capture Infére du changement de statut à 'Défense fournie' Type d'événement inferred
	Rétrofacturation inversée	Le litige a été gagné et les fonds sont retournés au commerçant. C'est une résolution réussie d'une exception.
Pourquoi est-ce important ? : Résultat positif pour la gestion des risques. Compense l'impact financier de la rétrofacturation initiale. Source des données : Webhook de notification Adyen : eventCode 'CHARGEBACK_REVERSED'. Capture Comptabilisé lors du webhook CHARGEBACK_REVERSED Type d'événement explicit
	Versement confirmé	Les fonds associés à un lot de transactions réglées ont été versés sur le compte bancaire du commerçant.
Pourquoi est-ce important ? : Représente le transfert de fonds réel à l'entreprise, lié au 'Temps de cycle de rapprochement des paiements'. Source des données : Webhook de notification Adyen : eventCode 'PAYOUT_THIRD_PARTY' ou inféré du rapport de paiement. Capture Joindre l'ID de lot du rapport de paiement à l'ID de transaction Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données d'Adyen

Étapes

Connectez-vous à l'Espace Client Adyen avec un compte utilisateur disposant du rôle Merchant Report.
Accédez à Reports et sélectionnez Settlement details dans le menu.
Recherchez les paramètres de Automatic generation ou choisissez Generate report pour un export ponctuel.
Dans le panneau de configuration, assurez-vous que le Format est défini sur CSV (valeurs séparées par des virgules).
Sous Include columns, veillez à sélectionner All ou cochez spécifiquement : Company Account, Merchant Account, Psp Reference, Merchant Reference, Payment Method, Creation Date, TimeZone, Type, Modification Reference, Gross Currency, Gross Debit, Gross Credit, Exchange Rate, Net Currency, Net Debit, Net Credit, Commission, Markup, Scheme Fees et Interchange.
IMPORTANT : assurez-vous que le périmètre du rapport inclut tous les Journal Types (Settled, Refunded, Chargeback, PaidOut, etc.) pour capturer l'intégralité du cycle de vie financier.
Générez le rapport pour la plage de dates souhaitée (ex : les 90 derniers jours). Notez que les rapports de règlement sont générés en fonction de la date du lot de règlement (settlement batch date), et non de la date de transaction.
Téléchargez le fichier CSV généré dans votre environnement d'extraction local.
Exécutez le script de transformation (fourni ci-dessous) pour transformer le grand livre CSV au format « wide » en un format d'journal d'événements « long » requis par ProcessMind.
Le script effectue des transformations cruciales : il « dépivote » la Creation Date pour créer des events « Payment Request Received » et mappe la colonne Type à des activités financières spécifiques.
Vérifiez que le fichier CSV de sortie contient les en-têtes : PspReference, EventCode, EventDate, SourceSystem.
Téléchargez le fichier CSV final transformé dans ProcessMind.

Configuration

Type de rapport : Settlement Detail Report (grand livre financier)
Format de fichier : CSV (séparation standard par virgules)
Granularité : niveau transaction (une ligne par écriture comptable)
Fuseau horaire : UTC (fortement recommandé pour aligner l'extraction avec les autres systèmes)
Plage de dates : alignée sur les lots de règlement (Batch Closed Date) et non sur la date de création de la transaction. Assurez-vous de gérer les chevauchements en cas d'exécution incrémentielle.
Colonnes requises : Psp Reference (Clé), Type (Activity), Creation Date, Booking Date (horodatages d'event), Merchant Account.
Paramètres de filtrage : assurez-vous qu'aucun filtre n'exclut les types « Chargeback » ou « Refund » afin de garantir l'exhaustivité du processus.

a Exemple de requête config

import pandas as pd
from datetime import datetime

# CONFIGURATION
INPUT_FILE = 'settlement_detail_report.csv'
OUTPUT_FILE = 'adyen_event_log.csv'
SOURCE_SYSTEM = 'Adyen'

# Load the Adyen Settlement Detail Report
# Skip standard Adyen header rows if present (often reports start on row 1 or have metadata on top)
df = pd.read_csv(INPUT_FILE, keep_default_na=False)

# Define the output list
event_log = []

# Helper function to append events
def add_event(psp_ref, activity, timestamp, attributes):
    if not timestamp or str(timestamp).strip() == '':
        return
    base_event = {
        'PspReference': psp_ref,
        'EventCode': activity,
        'EventDate': timestamp,
        'SourceSystem': SOURCE_SYSTEM,
        'LastDataUpdate': datetime.utcnow().isoformat(),
        'MerchantAccount': attributes.get('Merchant Account', ''),
        'PaymentMethod': attributes.get('Payment Method', ''),
        'PaymentAmount': attributes.get('Gross Credit', 0) if attributes.get('Gross Credit') else attributes.get('Gross Debit', 0) * -1
    }
    # Merge optional attributes
    base_event.update(attributes)
    event_log.append(base_event)

# Iterate through the ledger rows
for index, row in df.iterrows():
    psp_ref = row.get('Psp Reference')
    journal_type = row.get('Type')
    creation_date = row.get('Creation Date') # Used for Auth/Request
    booking_date = row.get('Booking Date')   # Used for Settlement/Financials
    
    # Common attributes for this row
    row_attrs = {
        'MerchantAccount': row.get('Merchant Account'),
        'PaymentMethod': row.get('Payment Method'),
        'RefusalReason': row.get('Refusal Reason', ''),
        'PaymentStatus': journal_type
    }

    # --- 1. DERIVED UPSTREAM ACTIVITIES ---
    # Since this is a settlement report, we infer the Request/Auth from the Creation Date
    # of the first record we see for this PSP Reference. 
    # Logic: If Creation Date exists, implies Request and Auth occurred.
    
    if creation_date:
        # Activity: Payment Request Received
        add_event(psp_ref, 'Payment Request Received', creation_date, row_attrs)
        
        # Activity: Risk Screening Performed (Inferred from existence of transaction)
        # Note: True risk score requires 'Payments Accounting Report', inferred here for process continuity
        add_event(psp_ref, 'Risk Screening Performed', creation_date, row_attrs)
        
        # Activity: Payment Authorised
        # Typically happens immediately after request for successful settled items
        add_event(psp_ref, 'Payment Authorised', creation_date, row_attrs)

    # --- 2. MAPPED FINANCIAL ACTIVITIES ---
    # Map Adyen Ledger Types to Process Activities using Booking Date
    
    if journal_type == 'Settled':
        add_event(psp_ref, 'Payment Settled', booking_date, row_attrs)
        
        # Activity: Payment Sent for Settlement
        # Inferred: Occurs shortly before settlement. 
        # Using Creation Date if Booking Date is distinct, or defaulting to Booking Date.
        sent_date = creation_date if creation_date else booking_date
        add_event(psp_ref, 'Payment Sent for Settlement', sent_date, row_attrs)

    elif journal_type == 'Refunded':
        add_event(psp_ref, 'Refund Initiated', creation_date, row_attrs)
        add_event(psp_ref, 'Refund Settled', booking_date, row_attrs)

    elif journal_type == 'Chargeback':
        add_event(psp_ref, 'Chargeback Notification Received', booking_date, row_attrs)

    elif journal_type == 'ChargebackRetried':
        add_event(psp_ref, 'Chargeback Defended', booking_date, {'IsRework': 'True'})

    elif journal_type == 'ChargebackReversed':
        add_event(psp_ref, 'Chargeback Reversed', booking_date, row_attrs)

    elif journal_type == 'PaidOut':
        # Payouts often group many transactions. 
        # If the report is at transaction level, this row represents the batch payout.
        add_event(psp_ref, 'Payout Confirmed', booking_date, row_attrs)

    elif journal_type == 'CaptureFailed':
        add_event(psp_ref, 'Capture Failed', booking_date, {'IsRework': 'True'})

    # --- 3. EXCEPTION HANDLING ---
    # These statuses often appear in 'Received payment details' reports but rarely in Settlement
    # unless fees were applied.
    
    elif journal_type == 'Refused': 
        add_event(psp_ref, 'Payment Refused', creation_date, row_attrs)
        
    elif journal_type == 'Cancelled':
        add_event(psp_ref, 'Payment Cancelled', creation_date, row_attrs)

    elif journal_type == 'Error':
        add_event(psp_ref, 'Technical Error Logged', booking_date, {'IsRework': 'True'})

# Convert to DataFrame
events_df = pd.DataFrame(event_log)

# Deduping: Adyen reports may have multiple lines for partial settlements.
# We sort by date and keep unique Activity per PSP Reference if timestamps match exactly.
events_df.drop_duplicates(subset=['PspReference', 'EventCode', 'EventDate'], inplace=True)

# Output
events_df.to_csv(OUTPUT_FILE, index=False)
print(f'Successfully extracted {len(events_df)} events to {OUTPUT_FILE}')

Étapes

Configuration préalable : assurez-vous de disposer d'un utilisateur de rapport Adyen avec le rôle Merchant Report activé. Récupérez votre API Key dans l'Espace Client sous Développeurs > Identifiants API.
Identification des rapports requis : cette extraction repose sur deux rapports CSV clés générés par Adyen : le Settlement Detail Report (pour les événements financiers tels que les règlements, les rétrofacturations et les remboursements) et le Received Payment Detail Report (pour les événements opérationnels tels que les demandes, les refus et les autorisations).
Configuration de l'environnement Python : installez les bibliothèques nécessaires via pip : pandas, requests et numpy. Elles seront utilisées pour la communication avec l'API et la transformation des données.
Implémentation de la connexion API : configurez le script Python (fourni ci-dessous) pour s'authentifier auprès des points de terminaison https://management-test.adyen.com ou https://management-live.adyen.com. Vous utiliserez l'API Report pour lister les rapports disponibles pour votre période spécifique et télécharger les URL.
Ingestion des données : le script lit les données CSV brutes dans des DataFrames pandas. Les rapports Adyen sont généralement au format « large » (une ligne par transaction avec plusieurs colonnes de statut), une transformation est donc nécessaire.
Mappage des activités - Opérationnel : traitez le Received Payment Detail Report. Mappez la CreationDate sur Payment Request Received. Utilisez une logique pour inspecter la colonne Status (ex : Authorised, Refused, Error) afin de générer les événements Payment Authorised, Payment Refused ou Technical Error Logged.
Mappage des activités - Financier : traitez le Settlement Detail Report. Ce rapport contient une colonne JournalType. Mappez les valeurs telles que Settled sur Payment Settled, Refunded sur Refund Initiated et Chargeback sur Chargeback Notification Received.
Déduction d'activités complexes :
- Risk Screening Performed : vérifiez si la colonne FraudScore est renseignée et supérieure à -1.
- Payout Confirmed : liez les transactions via le BatchNumber à l'entrée Payout dans le rapport de règlement.
- Chargeback Defended : recherchez les types de journaux SecondChargeback ou Defense.
Transformation des données : appliquez une opération « melt » ou « stack » dans pandas pour convertir le jeu de données large en un format d'journal d'événements long où chaque activité correspond à une ligne distincte.
Standardisation des attributs : renommez les colonnes pour correspondre au schéma cible : PspReference, EventCode, EventDate, SourceSystem (fixé à « Adyen ») et PaymentAmount. Assurez-vous que les dates sont converties au format ISO 8601.
Filtrage : filtrez les lignes de rapprochement interne qui ne représentent pas des étapes du processus (par exemple, les lignes d'en-tête ou les reports de solde) à l'aide du filtre Type.
Exportation finale : le script exporte le DataFrame traité vers un fichier CSV nommé adyen_event_log.csv, prêt à être importé dans ProcessMind.

Configuration

Environnement API : basculez entre les points de terminaison Adyen Test (management-test.adyen.com) et Live (management-live.adyen.com) selon la phase de déploiement.
Authentification : utilisez x-api-key dans l'en-tête. N'utilisez pas l'authentification de base (Basic Auth) pour l'API Management.
Types de rapports :
- settlement_detail_report : essentiel pour les événements du cycle de vie financier.
- received_payment_detail_report : essentiel pour la logique de requête initiale et d'autorisation.
Plage de dates : les rapports Adyen sont générés en fonction de la clôture des lots (batch). Assurez-vous que le script demande des rapports couvrant la CreationDate concernée + 7 jours pour capturer les règlements différés.
Périmètre du Merchant Account : si vous possédez plusieurs comptes marchands, parcourez la liste des comptes ou utilisez le rapport au niveau du Company Account si disponible.
Configuration Pandas : assurez-vous que low_memory=False est défini lors de la lecture des fichiers CSV si le volume de transactions dépasse 100 000 lignes afin d'éviter les erreurs d'inférence de type.

a Exemple de requête python

import pandas as pd
import requests
import io
import numpy as np
from datetime import datetime

class=class="hl-string">"hl-comment"># Configuration
API_KEY = class="hl-string">'YOUR_ADYEN_API_KEY'
MERCHANT_ACCOUNT = class="hl-string">'YOUR_MERCHANT_ACCOUNT'
BASE_URL = class="hl-string">'https://management-live.adyen.com/v1'
HEADERS = {class="hl-string">'x-api-key': API_KEY, class="hl-string">'Content-Type': class="hl-string">'application/json'}

class=class="hl-string">"hl-comment"># Placeholder for fetching report URLs via API
class=class="hl-string">"hl-comment"># In production, use GET /companies/{companyId}/reports or /merchants/{merchantId}/reports
class=class="hl-string">"hl-comment"># For this script, we assume the CSV content is loaded into DataFrames

def transform_adyen_data(received_payments_csv_path, settlement_details_csv_path):
    
    class=class="hl-string">"hl-comment"># 1. Load Data
    print(class="hl-string">'Loading reports...')
    df_received = pd.read_csv(received_payments_csv_path)
    df_settled = pd.read_csv(settlement_details_csv_path)

    events = []

    class=class="hl-string">"hl-comment"># 2. Process Received Payment Detail Report (Operational Events)
    class=class="hl-string">"hl-comment"># This report covers: Request, Auth, Refusal, Risk, Capture, Errors
    
    for _, row in df_received.iterrows():
        psp = str(row.get(class="hl-string">'PspReference', class="hl-string">''))
        created_date = pd.to_datetime(row.get(class="hl-string">'CreationDate'))
        amount = row.get(class="hl-string">'Amount', 0)
        status = row.get(class="hl-string">'Status', class="hl-string">'')
        fraud_score = row.get(class="hl-string">'FraudScore', None)
        refusal_reason = row.get(class="hl-string">'RefusalReason', class="hl-string">'')
        
        class=class="hl-string">"hl-comment"># Activity: Payment Request Received
        events.append({
            class="hl-string">'PspReference': psp,
            class="hl-string">'EventCode': class="hl-string">'Payment Request Received',
            class="hl-string">'EventDate': created_date,
            class="hl-string">'PaymentAmount': amount,
            class="hl-string">'PaymentMethod': row.get(class="hl-string">'PaymentMethod', class="hl-string">''),
            class="hl-string">'RefusalReason': None,
            class="hl-string">'SourceSystem': class="hl-string">'Adyen'
        })

        class=class="hl-string">"hl-comment"># Activity: Risk Screening Performed
        class=class="hl-string">"hl-comment"># Inferred if a fraud score was calculated
        if pd.notna(fraud_score):
            events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': class="hl-string">'Risk Screening Performed',
                class="hl-string">'EventDate': created_date + pd.Timedelta(seconds=1), class=class="hl-string">"hl-comment"># Slight offset
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'SourceSystem': class="hl-string">'Adyen'
            })

        class=class="hl-string">"hl-comment"># Activity: Payment Authorised / Refused / Error
        if status == class="hl-string">'Authorised':
            events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': class="hl-string">'Payment Authorised',
                class="hl-string">'EventDate': created_date + pd.Timedelta(seconds=2),
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'SourceSystem': class="hl-string">'Adyen'
            })
        elif status == class="hl-string">'Refused':
            events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': class="hl-string">'Payment Refused',
                class="hl-string">'EventDate': created_date + pd.Timedelta(seconds=2),
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'RefusalReason': refusal_reason,
                class="hl-string">'SourceSystem': class="hl-string">'Adyen'
            })
        elif status == class="hl-string">'Error':
            events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': class="hl-string">'Technical Error Logged',
                class="hl-string">'EventDate': created_date + pd.Timedelta(seconds=2),
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'RefusalReason': row.get(class="hl-string">'AcquirerResponse', class="hl-string">'Technical Error'),
                class="hl-string">'SourceSystem': class="hl-string">'Adyen'
            })
        elif status == class="hl-string">'Cancelled':
            events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': class="hl-string">'Payment Cancelled',
                class="hl-string">'EventDate': created_date + pd.Timedelta(seconds=5),
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'SourceSystem': class="hl-string">'Adyen'
            })

    class=class="hl-string">"hl-comment"># 3. Process Settlement Detail Report (Financial Events)
    class=class="hl-string">"hl-comment"># This report covers: Capture, Settlement, Refunds, Chargebacks, Payouts
    
    for _, row in df_settled.iterrows():
        psp = str(row.get(class="hl-string">'PspReference', class="hl-string">''))
        journal_type = row.get(class="hl-string">'JournalType', class="hl-string">'')
        process_date = pd.to_datetime(row.get(class="hl-string">'CreationDate')) class=class="hl-string">"hl-comment"># Or ProcessingDate
        amount = row.get(class="hl-string">'NetCredit', 0) if pd.notna(row.get(class="hl-string">'NetCredit')) else row.get(class="hl-string">'GrossCredit', 0)
        
        class=class="hl-string">"hl-comment"># Map JournalType to Activities
        activity_name = None
        
        if journal_type == class="hl-string">'SentForSettlement':
            activity_name = class="hl-string">'Payment Sent for Settlement'
        elif journal_type == class="hl-string">'Settled':
            activity_name = class="hl-string">'Payment Settled'
        elif journal_type == class="hl-string">'SentForRefund' or journal_type == class="hl-string">'Refunded':
            activity_name = class="hl-string">'Refund Initiated'
        elif journal_type == class="hl-string">'SettledRefund':
            activity_name = class="hl-string">'Refund Settled'
        elif journal_type == class="hl-string">'Chargeback':
            activity_name = class="hl-string">'Chargeback Notification Received'
        elif journal_type == class="hl-string">'SecondChargeback' or journal_type == class="hl-string">'Defense':
            activity_name = class="hl-string">'Chargeback Defended'
        elif journal_type == class="hl-string">'ChargebackReversed':
            activity_name = class="hl-string">'Chargeback Reversed'
        elif journal_type == class="hl-string">'CaptureFailed':
            activity_name = class="hl-string">'Capture Failed'
        elif journal_type == class="hl-string">'PaidOut':
            class=class="hl-string">"hl-comment"># PaidOut is usually batch level, if psp is present, map it
            activity_name = class="hl-string">'Payout Confirmed'
        
        class=class="hl-string">"hl-comment"># Logic for class="hl-string">'Payment Captured' 
        class=class="hl-string">"hl-comment"># Adyen often auto-captures. If we see Settled, we assume Captured occurred prior if not explicitly logged.
        class=class="hl-string">"hl-comment"># Here we rely on class="hl-string">'SentForSettlement' as the trigger for Capture success in many flows.
        if journal_type == class="hl-string">'SentForSettlement':
             events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': class="hl-string">'Payment Captured',
                class="hl-string">'EventDate': process_date - pd.Timedelta(seconds=1),
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'SourceSystem': class="hl-string">'Adyen'
            })

        if activity_name:
            events.append({
                class="hl-string">'PspReference': psp,
                class="hl-string">'EventCode': activity_name,
                class="hl-string">'EventDate': process_date,
                class="hl-string">'PaymentAmount': amount,
                class="hl-string">'SourceSystem': class="hl-string">'Adyen',
                class="hl-string">'MerchantAccount': row.get(class="hl-string">'MerchantAccount', MERCHANT_ACCOUNT),
                class="hl-string">'PaymentMethod': row.get(class="hl-string">'PaymentMethod', class="hl-string">'')
            })

    class=class="hl-string">"hl-comment"># 4. Create DataFrame
    df_events = pd.DataFrame(events)
    
    class=class="hl-string">"hl-comment"># 5. Post-Processing & Cleanup
    if not df_events.empty:
        class=class="hl-string">"hl-comment"># Ensure standard columns
        df_events[class="hl-string">'LastDataUpdate'] = datetime.now().isoformat()
        df_events[class="hl-string">'TotalCycleTime'] = None class=class="hl-string">"hl-comment"># Calculated in ProcessMind
        df_events[class="hl-string">'IsRework'] = df_events[class="hl-string">'EventCode'].apply(lambda x: 1 if class="hl-string">'Chargeback' in x or class="hl-string">'Refused' in x else 0)
        df_events[class="hl-string">'PaymentStatus'] = df_events.sort_values(class="hl-string">'EventDate').groupby(class="hl-string">'PspReference')[class="hl-string">'EventCode'].transform(class="hl-string">'last')
        
        class=class="hl-string">"hl-comment"># Filter invalid rows (empty PspReference)
        df_events = df_events[df_events[class="hl-string">'PspReference'] != class="hl-string">'nan']
        df_events = df_events[df_events[class="hl-string">'PspReference'] != class="hl-string">'']

        class=class="hl-string">"hl-comment"># Sort
        df_events = df_events.sort_values([class="hl-string">'PspReference', class="hl-string">'EventDate'])
        
    return df_events

class=class="hl-string">"hl-comment"># Execution Entry Point
class=class="hl-string">"hl-comment"># Replace paths with actual file locations or API download streams
if __name__ == class="hl-string">'__main__':
    class=class="hl-string">"hl-comment"># Example usage
    df_log = transform_adyen_data(class="hl-string">'received_payment_detail_report.csv', class="hl-string">'settlement_detail_report.csv')
    
    class=class="hl-string">"hl-comment"># Export
    df_log.to_csv(class="hl-string">'ProcessMind_Adyen_Log.csv', index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">'Extraction Complete. Generated {len(df_log)} events.')

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

Exportation du rapport de détail des règlements Adyen

Étapes

Configuration

a Exemple de requête config

Extraction Python via l'API de Reporting

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Déverrouillez un Traitement des facturess factures fournisseurs factures fournisseurs Paiements Fluide dans Adyen Dès 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

Exportation du rapport de détail des règlements Adyen

Étapes

Configuration

a Exemple de requête config

Extraction Python via l'API de Reporting

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Déverrouillez un Traitement des facturess factures fournisseurs factures fournisseurs Paiements Fluide dans Adyen Dès Aujourd'hui.