Analyser l'activité des transactions
Suivre une commande de sa création jusqu'à son traitement, son authentification, son paiement, sa capture, son annulation ou son remboursement dans DEUNA Admin.
Sur cette page
- Avant de commencer
- Choisissez la vue appropriée
- Consulter l'historique des transactions
- Suivez l'historique du paiement
- Inspecter les événements techniques
- Regrouper et rechercher le trace
- Enquêter sur un paiement échoué ou retardé
- Préparez les preuves pour le support
- Limites et récupération
- Prochaines étapes
Utiliser l'activité des transactions lorsque la commande est en attente, rejetée, retardée ou présente un comportement différent de l'intégration avec le commerçant. DEUNA Admin combine un historique de paiement au niveau de l'entreprise avec des enregistrements de requêtes et de réponses techniques, permettant aux équipes opérationnelles et d'intégration d'analyser la même transaction sans avoir à changer d'outils.
L'activité des transactions est en lecture seule. La consultation d'un événement ne permet pas de relancer une requête, de modifier une commande ou de contacter un processeur de paiement.
Avant de commencer#
Votre rôle doit inclure les section "Afficher les commandes" Autorisation. Veuillez vérifier le commerçant et l'environnement sélectionnés avant de rechercher, les données sont limitées à ce contexte.
Disposer d'au moins un identifiant :
- ID de commande ou jeton de commande
- Transaction ID
- Adresse e-mail du client, si cela est autorisé par votre politique de confidentialité
- Date approximative de création
Si vous ne pouvez pas ouvrir Paiements > Commandes, demand à un utilisateur administrateur de valider Rôles et autorisations.
Choisissez la vue appropriée#
Les détails de la commande fournissent deux surfaces d'investigation connexes. Commencez par Afficher l'historique, puis utilisez Technique lorsque vous avez besoin des échanges sous-jacents.
| Surface | Idéal pour | Ce que cela montre |
|---|---|---|
| Afficher l'historique | Comprendre le cycle de vie du paiement | Création et mises à jour de commandes, création et modifications de statut de paiement, routage, 3DS et événements de fraude, avec les champs pertinents pour chaque événement. |
| Technique | Diagnostiquer un échange entre un intégrateur ou un fournisseur | Événements de transaction enregistrés, méthode HTTP et destination, code de réponse, données de requête et de réponse, horodatages et identifiants de requête, trace et span disponibles. |
| Journaux d'activité | Actions effectuées par les utilisateurs Administrateurs | Qui a modifié une configuration ou effectué une action d'administrateur. Les journaux d'activité ne représentent pas le suivi de l'exécution du paiement. |
Consulter l'historique des transactions#
- Connectez-vous à DEUNA Admin.
- Sélectionnez le commerçant et l'environnement associés à la transaction.
- Ouvrez Paiements > Commandes.
- Recherchez par ID de commande ou adresse e-mail, ou utilisez les filtres de date et de paiement pour réduire la liste.
- Ouvrez le menu Actions de ligne et sélectionnez Afficher les détails.
- Pour le résumé du cycle de vie, sélectionnez Afficher l'historique. Pour consulter l'historique des transactions, ouvrez Technique.
Si la commande ne comporte aucun événement technique enregistré, Technique affiche Aucune activité technique. Cela ne permet pas d'identifier de manière autonome la cause ou le résultat du paiement.
Suivez l'historique du paiement#
Sélectionnez Afficher l'historique à partir de l'en-tête des détails de la commande. L'historique est présenté sous forme de chronologie, avec le dernier événement enregistré en premier.
Les champs exacts dépendent de l'événement :
| Événement | Preuves que vous pouvez trouver |
|---|---|
| Commande créée | Montant initial, devise et statut de la commande. |
| Commande mise à jour | Statut actuel de la commande et du paiement. |
| Paiement créé | Montant et devise du paiement. |
| Statut du paiement mis à jour | Statut du paiement et détails du processeur, de l'autorisation, du prélèvement, du remboursement ou de l'erreur applicables. |
| Itinéraire généré | Règle et chemin appliqués, ainsi que le processeur de paiement ou de fraude représenté par cet itinéraire. Une décision d'itinérance peut créer plusieurs entrées de chronologie. |
| 3DS mis à jour | État d'authentification, fournisseur 3DS et un code ou message d'erreur en cas de problème. |
| Analyse de la fraude | Détails disponibles concernant le fournisseur, la décision, l'évaluation des risques ou le mode "shadow". |
Ne considérez pas un événement intermédiaire comme le résultat financier final. Par exemple, une authentification 3DS réussie permet de poursuivre le traitement du paiement, mais cela ne signifie pas que le paiement a été autorisé ou débité.
Inspecter les événements techniques#
Ouvrez Technique. Cette vue comporte deux zones : Activité et Données.
Activité technique dans DEUNA Admin. Toutes les valeurs de commerçant, d’utilisateur, de fournisseur, d’identifiant, de durée et de charge utile de cet exemple sont fictives.
Ce que contient la vue technique
| Domaine | Ce qui s'affiche | Comment l'utiliser |
|---|---|---|
| Contexte de la commande | Montant total de la commande, statut de la commande et du paiement, dernière mise à jour, jeton de commande, ID de commande et ID du client. | Vérifiez que vous avez ouvert la commande correcte et que l'environnement est celui prévu avant d'interpréter un événement. |
| Contrôles d'activité | Nombre d'événements enregistrés, contrôle de tri, recherche par nom d'événement et trois modes de regroupement : Aucun, Requête et Suivi. | Réduisez une longue traçabilité de transaction aux événements liés à l'opération que vous étudiez. |
| En-tête de groupe | Type de groupe, ID de requête ou ID de traçage abrégé, nombre d'événements et la somme du temps d'exécution des événements dans ce groupe. | Développez ou repliez les points de contrôle pertinents et comparez une requête ou une traçabilité avec une autre. |
| Point de contrôle d'activité | Badge de code de réponse, nom de l'événement, heure de création de l'événement et horodatage du journal enregistré. | Sélectionnez le point de contrôle qui correspond le mieux à l'étape échouée, retardée ou inattendue. |
| Résumé de l'échange | Méthode HTTP ou protocole, destination, ID de requête, ID de traçage et ID de span. Les identifiants disponibles incluent les contrôles de copie. | Corrélez l'événement avec les journaux du commerçant, les preuves du fournisseur ou une enquête de support DEUNA. |
| Visualiseur de données | Onglets "Requête" et "Réponse", badge de code de réponse, valeur de temps écoulé (si disponible), et données de charge utile formatées avec un contrôle de copie. | Comparez les données de sortie avec le résultat retourné. Copiez uniquement les preuves minimales et sécurisées nécessaires. |
Le visualiseur de charge utile affiche les noms d'objets et de champs pour que vous puissiez inspecter la structure de l'échange. Les valeurs et le niveau d'imbrication varient en fonction de l'événement et du fournisseur. Un champ présenté dans l'exemple n'est pas garanti d'apparaître dans chaque transaction.
Lire un événement
- Sélectionnez un événement dans Activité. Sur mobile, développez l'événement.
- Vérifiez le nom de l'événement et l'horodatage.
- Compare la méthode HTTP, la destination et le code de réponse avec l'opération attendue.
- Basculer entre Demande et Réponse dans Données.
- Enregistrer l'ID de la requête, l'ID de suivi ou l'ID de span lorsque ces identifiants sont présents.
Lorsqu'un événement possède une 4xx réponse, l'interface d'administration DEUNA peut afficher Message d'erreur Au-dessus des données de réponse. Les autres codes de réponse restent visibles dans l'événement et dans le panneau de données.
Le code de réponse indique l'état de la transaction technique, et non nécessairement le résultat final du paiement. Avant de traiter une commande, comparez ce code avec Statut de paiement, Afficher l'historique, et notifications de statut asynchrones.
Événements produits lors d'un processus de commande
Les activités disponibles dépendent du chemin suivi par la transaction. Les groupes courants comprennent :
| Scène | Exemples visibles dans l'activité | Que vérifier |
|---|---|---|
| Commande | Une nouvelle commande a été créée ; la commande a été mise à jour | Les identifiants de commande et l'état sont retournés à l'intégration du commerçant. |
| Routage | Générer le routage de paiement | Le chemin sélectionné et les échanges avec le prestataire. |
| Paiement | Générer le paiement ; demander l'autorisation | Demander le montant et la devise, réponse du processeur et statut du paiement résultant. |
| Authentification | Évaluation 3DS démarrée, contestée, mise à jour, terminée ou échouée | Indiquer si une action du client était nécessaire et si le traitement du paiement a continué par la suite. |
| Vérification de l'adresse | Validation AVS, suppression ou annulation | Résultat de validation normalisé et l'action de paiement qui en a résulté. |
| Fraude | Générer l'analyse du moteur de prévention de la fraude ; évaluation "shadow" | Résultat du prestataire et si la transaction a continué vers le traitement du paiement ou la revue. |
| Opérations post-paiement | Capture, capture partielle, remboursement, remboursement partiel, annulation ou demande d'annulation | Montant de l'opération et identifiant, réponse et l'événement de statut de paiement ultérieur qui confirme le résultat. |
Certains événements enregistrent qu'une étape s'est produite, mais ne contiennent pas de corps de requête ou de réponse. La disponibilité des données varie en fonction de l'opération et du prestataire.
Regrouper et rechercher le trace#
Dans Activité, utilisez les contrôles suivants pour réduire une trace longue :
- Aucun affiche chaque événement dans une liste plate.
- Demande regroupe les événements qui partagent un ID de requête. Utilisez-le pour suivre le travail initié par une requête entrante.
- Trace regroupe les événements qui partagent un ID de trace. Utilisez-le pour suivre une transaction à travers les étapes de traitement connexes.
- Rechercher un événement Filtre par le nom de l'événement affiché.
- Trier l'activité inverse l'ordre des événements.
Lorsqu'un événement n'a pas de valeur pour l'identifiant de regroupement sélectionné, DEUNA Admin le place dans Orphelin. Cet événement peut encore être utile lorsque son ID de transaction, son horodatage et les événements voisins correspondent à la fenêtre d'incident.
Enquêter sur un paiement échoué ou retardé#
Suivez cet ordre afin d'éviter de confondre une erreur technique intermédiaire avec le résultat final :
- Vérifiez l'environnement, le statut actuel de la commande, le statut actuel du paiement. Order IDet Transaction ID.
- Ouvrez Afficher l'historique et identifier le dernier événement du cycle de vie.
- Ouvrez Technique et regrouper par Trace.
- Trouvez l'événement de paiement, de routage, d'authentification, de lutte contre la fraude ou de suivi correspondant.
- Comparez son code de réponse et ses données avec l'événement suivant dans la trace.
- Vérifiez si une mise à jour ultérieure de l'état a permis de récupérer le paiement, de le transférer à un autre prestataire ou de confirmer un échec définitif.
- Comparez le statut final de DEUNA avec le statut reçu via votre webhook de paiement.
En cas de rejet, consultez la référence publique des codes d'erreur en utilisant le code d'erreur DEUNA. Les codes et messages spécifiques au fournisseur doivent être interprétés en fonction de la documentation du fournisseur.
Préparez les preuves pour le support#
Lorsque vous avez besoin du support DEUNA pour une enquête, fournissez les preuves minimales requises :
- Nom du commerçant et environnement
- ID de commande ou jeton de commande
- Transaction ID
- Horodatage UTC et période de l'incident
- Nom de l'événement et code de réponse affichés
- ID de la requête, ID de suivi et ID de span, si disponibles
- Statut actuel de la commande et du paiement
- Comportement attendu et comportement observé
Envoyer uniquement le payload complet lorsque le support le demande via un canal approuvé.
Limites et récupération#
- L'activité de transaction est un enregistrement d'observabilité, et non un mécanisme de relecture ou de nouvelle tentative.
- Tous les stades ne produisent pas un corps de requête et de réponse.
- Les événements peuvent arriver après la requête initiale lorsque le fournisseur signale un résultat asynchrone.
- L'absence d'activité ne permet pas de déterminer si le fournisseur a traité la transaction.
- Le statut actuel du paiement ou de la commande est la vue administrative autoritaire ; utilisez les webhooks et la réponse API appropriée pour la gestion de l'état côté intégration.
Si les identifiants et l'environnement sont corrects, mais que l'événement requis est toujours absent, rassemblez les preuves ci-dessus et contactez le support DEUNA. Ne réessayez pas une opération de paiement avant d'avoir confirmé qu'il est sûr de le faire.