Un client affirme avoir payé, mais la commande apparaît toujours comme impayée. Le portefeuille peut afficher la transaction comme envoyée, tandis que le marchand ne la retrouve pas dans l’enregistrement de paiement attendu. Avant de demander au client de payer de nouveau ou de supposer que les fonds sont perdus, l’entreprise doit mener une enquête structurée. Ce guide explique comment retracer un paiement crypto manquant depuis la commande initiale et l’identifiant de transaction jusqu’à la blockchain, la passerelle de paiement et l’enregistrement final du marchand.
Que signifie réellement « paiement crypto manquant » ?
Un paiement crypto manquant ne signifie pas toujours que la transaction a disparu.
En pratique, cette expression peut décrire plusieurs situations différentes :
- le client a créé une transaction, mais elle n’a pas encore atteint le réseau ;
- la transaction existe, mais elle est toujours en attente ;
- le client a envoyé le paiement sur le mauvais réseau blockchain ;
- l’adresse de destination ou le token était incorrect ;
- le client a envoyé moins que le montant demandé ;
- la facture a expiré avant que le client ne termine le paiement ;
- OxaPay a détecté le paiement, mais le système du marchand n’a pas mis à jour la commande ;
- le paiement existe, mais le marchand ne parvient pas à le faire correspondre au bon client ou à la bonne commande.
Ces situations nécessitent des actions différentes. Le premier objectif n’est donc pas simplement de « retrouver l’argent », mais de déterminer à quel moment le paiement a cessé de correspondre au flux attendu.
Le cycle de vie d’un paiement crypto au sens large explique pourquoi la détection de la transaction, l’acceptation du paiement, l’exécution de la commande et la clôture opérationnelle sont des étapes distinctes. Un paiement peut être visible on-chain sans avoir encore produit le résultat commercial attendu.
Avant de commencer : ne demandez pas au client de payer de nouveau
Un second paiement peut transformer une enquête simple en problème de double paiement et de remboursement.
Tant que la première transaction n’a pas été localisée et classée, le support ne doit pas demander au client de renvoyer les fonds. Il ne doit jamais non plus demander au client :
- sa clé privée ;
- sa seed phrase ou phrase de récupération ;
- le mot de passe de son portefeuille ;
- son code d’authentification.
L’enquête nécessite uniquement les références de paiement et des informations de transaction vérifiables publiquement.
Enquête sur un paiement crypto manquant : étape par étape
Étape 1 : collecter les références de paiement
Commencez par les propres enregistrements du marchand plutôt que de rechercher immédiatement la transaction sur la blockchain.
Demandez ou récupérez :
| Informations requises | Objectif |
|---|---|
| ID de commande ou de facture | Identifie la demande commerciale |
| OxaPay track ID | Identifie la session de paiement OxaPay |
| ID de transaction ou TXID | Identifie la transaction blockchain |
| Cryptomonnaie | Confirme quel actif a été envoyé |
| Réseau blockchain | Détermine sur quel réseau la transaction doit être recherchée |
| Montant envoyé | Révèle un sous-paiement ou un écart de montant |
| Heure approximative du paiement | Réduit le périmètre de l’enquête |
| Résultat attendu | Indique si le client attend une livraison, un crédit sur son compte, un renouvellement ou un autre résultat |
Lorsque les marchands génèrent une facture OxaPay, ils peuvent inclure leur propre order_id. OxaPay fournit également un track_id, que les marchands peuvent ensuite utiliser pour récupérer l’enregistrement Payment Information associé.
La combinaison de Order ID, track ID et TXID offre trois perspectives différentes :
- Order ID : ce que le client essayait d’acheter ;
- Track ID : la manière dont la passerelle de paiement représente le paiement ;
- TXID : ce qui s’est passé sur la blockchain.
L’article OxaPay Crypto Transaction ID expliqué fournit une explication accessible aux clients sur la manière de trouver et d’utiliser un TXID pour retracer un transfert.
Étape 2 : vérifier que le TXID est valide
Une capture d’écran du portefeuille indiquant « envoyé » ne prouve pas que le portefeuille a effectivement diffusé la transaction sur le réseau.
Copiez directement le TXID et recherchez-le à l’aide d’un explorateur de blocs pour le réseau que le client dit avoir utilisé.
Vérifiez si :
- l’explorateur reconnaît le TXID ;
- la transaction appartient à la blockchain attendue ;
- la transaction est en attente, confirmée, échouéeou reste autrement non résolue ;
- l’heure d’envoi correspond à la tentative de paiement.
Les réseaux comme Ethereum génèrent un hash de transaction lorsqu’un utilisateur soumet une transaction. Le réseau diffuse ensuite la transaction et attend son inclusion dans un bloc. Les transactions Bitcoin reçoivent de la même manière des confirmations après leur inclusion dans des blocs par les mineurs.
Si vous ne trouvez pas le TXID
Les explications possibles incluent :
- le TXID a été copié incorrectement ;
- le client recherche sur le mauvais réseau ;
- le portefeuille a créé la transaction localement, mais ne l’a pas diffusée ;
- le portefeuille affiche une référence interne plutôt que le TXID de la blockchain ;
- la transaction n’a jamais été soumise avec succès.
Demandez au client d’ouvrir les détails de la transaction dans son portefeuille et de confirmer le réseau exact ainsi que le TXID.
Ne marquez pas la commande comme payée si aucune transaction vérifiable ne peut être trouvée.
Étape 3 : vérifier le réseau, l’actif, l’adresse et le montant
Trouver la transaction n’est que le début. Elle doit correspondre à la demande de paiement.
Comparez quatre éléments.
Réseau
Confirmez que le paiement a été envoyé sur le réseau sélectionné lors du checkout.
C’est particulièrement important pour des actifs comme USDT et USDC, qui peuvent exister sur plusieurs réseaux. Une transaction effectuée sur un réseau n’apparaîtra pas lorsqu’elle est recherchée sur un autre.
Actif
Confirmez que le client a envoyé la cryptomonnaie ou le contrat de token attendu.
Le même format d’adresse peut parfois exister sur des réseaux compatibles, mais cela ne signifie pas que chaque token ou chaque route réseau est pris en charge.
Adresse de destination
Comparez l’adresse du destinataire dans la transaction blockchain avec l’adresse affichée dans la demande de paiement.
Une transaction confirmée envoyée à une autre adresse n’est pas manquante sur la blockchain. Elle a été envoyée par une autre route.
Montant
Comparez le montant reçu au montant demandé.
Le client peut avoir :
- saisi un montant incorrect ;
- payé seulement une partie de la facture ;
- mal compris quels frais étaient séparés du montant du paiement ;
- envoyé plusieurs petites transactions au lieu d’un paiement complet.
Une passerelle de paiement professionnelle évalue le réseau, la destination, le token, le montant, le timing et les preuves de confirmation avant de classer un transfert comme paiement valide.

Étape 4 : déterminer l’état de la blockchain
Si la transaction existe et que les détails du paiement sont corrects, déterminez si elle a suffisamment progressé pour être acceptée.
En attente ou non confirmée
Le réseau a vu la transaction, mais elle n’a pas encore atteint l’état de confirmation ou de finalité requis.
Dans ce cas :
- ne demandez pas au client de renvoyer les fonds ;
- expliquez que la transaction a été localisée ;
- donnez au client un prochain point de vérification clair ;
- continuez la vérification conformément à la politique de paiement du marchand.
Le délai de confirmation varie selon le réseau et les conditions actuelles. La visibilité d’une transaction et la finalité du paiement ne doivent pas être considérées comme le même événement.
Confirmée
Une transaction confirmée prouve que le réseau a traité le transfert. Elle ne prouve pas automatiquement que le paiement a satisfait la facture du marchand.
L’adresse, l’actif, le montant, le réseau, le timing de la facture et l’enregistrement de paiement associé doivent toujours correspondre.
Échouée ou non réussie
Si l’explorateur indique que la transaction a échoué, le paiement ne s’est pas effectué comme prévu.
Le support doit expliquer le résultat vérifié et demander au client de vérifier son portefeuille avant de tenter un autre paiement. Le marchand ne doit pas marquer la commande comme payée sur la seule base de la tentative de transfert.
Étape 5 : vérifier l’enregistrement de paiement OxaPay
Une fois les preuves blockchain comprises, examinez l’enregistrement OxaPay à l’aide du track ID.
Chez OxaPay, Payment Information d’OxaPay , en tant qu’endpoint, récupère des informations détaillées sur un paiement précis. Payment History peut également être filtré par track ID, statut, type de paiement, actif, réseau, montant, adresse et période.
Comparez :
- le statut OxaPay ;
- le montant attendu et le montant reçu ;
- la devise de paiement ;
- le réseau ;
- les informations de transaction ;
- le timing de la facture ;
- la référence de commande du marchand.
OxaPay documente les statuts de paiement suivants :
- new ;
- waiting ;
- paying ;
- paid ;
- manual_accept ;
- underpaid ;
- refunding ;
- refunded ;
- expired.
Ce que le statut peut indiquer
| Statut OxaPay | Signification pour l’enquête |
|---|---|
| New ou waiting | Aucun paiement admissible n’a encore été associé à la facture |
| paying | Une activité de paiement existe, mais le paiement n’est pas encore entièrement accepté |
| paid | OxaPay a accepté la facture comme entièrement payée |
| underpaid | Un paiement a été reçu, mais le montant requis n’a pas été entièrement versé |
| expired | La facture n’a pas été finalisée pendant sa fenêtre de paiement active |
| Manual accept | Le marchand a accepté manuellement le paiement |
| Refunding ou refunded | Le paiement est en cours de remboursement ou le remboursement est terminé |
Si OxaPay affiche paid alors que la commande du client reste impayée, l’enquête ne porte plus sur la blockchain. Le problème probable se situe désormais dans la mise à jour de la commande, l’intégration ou le processus d’exécution du marchand.
Étape 6 : comparer le paiement à la commande du marchand
Vérifiez si l’enregistrement de paiement OxaPay est lié à la bonne commande interne.
Vérifiez :
- le Order ID enregistré ;
- le track ID enregistré ;
- le montant attendu ;
- le client ou le compte ;
- le statut de la commande ;
- le statut d’exécution ou de crédit du compte ;
- toute modification manuelle ou action précédente du support.
Cette étape révèle généralement l’un de trois résultats.
Le paiement est correct, mais la commande n’a pas été mise à jour
Le paiement n’est pas réellement manquant. Le système du marchand n’a pas transformé le statut du paiement en action commerciale attendue.
Si l’intégration repose sur des callbacks, vérifiez la configuration Webhook d’OxaPay et le chemin de livraison avant de considérer le cas comme un problème blockchain.
Escaladez le cas vers Payment Operations ou Engineering avec tous les identifiants et statuts actuels.
Le paiement a été lié à la mauvaise commande
Ne déplacez pas silencieusement le paiement sans consigner la décision.
Confirmez le bon client et la bonne commande, corrigez l’association via le processus approuvé et conservez une piste d’audit.
Aucune commande ne peut être mise en correspondance avec certitude
Placez le paiement dans une file d’exceptions. Utilisez le montant, l’heure, l’adresse, les informations client et le TXID comme éléments de preuve, mais ne faites pas d’hypothèse lorsque les données disponibles peuvent correspondre à plusieurs commandes.
Le processus détaillé de rapprochement sera présenté dans How to Match Orders, Track IDs, and Blockchain Transactions.

Étape 7 : classer la cause racine
À la fin de l’enquête, le cas doit avoir une classification claire.
| Constat | Cause probable | Action suivante |
|---|---|---|
| Aucun TXID valide | La transaction n’a pas été diffusée ou la référence est incorrecte | Renvoyer vers le client pour vérification du portefeuille |
| Le TXID existe mais la transaction est en attente | Le traitement par le réseau est incomplet | Surveiller et définir un point de suivi |
| Mauvais réseau, token ou adresse | La route du paiement ne correspond pas à la demande | Escalader sans promettre de récupération |
| Le montant est trop faible | Sous-paiement | Appliquer la politique de sous-paiement du marchand |
| Le paiement est arrivé après expiration | Paiement tardif ou expiré | Examiner selon la politique de facturation |
| OxaPay affiche paid, la commande affiche unpaid | Problème de synchronisation ou d’exécution côté marchand | Escalader en interne |
| Le paiement existe mais aucune commande ne correspond | Référence manquante ou problème de corrélation | Créer une exception de rapprochement |
| Le remboursement est en cours | Le paiement initial est entré dans un processus d’annulation | Suivre le remboursement plutôt que l’acceptation du paiement |
OxaPay propose des options spécifiques pour les factures sous-payées et expirées, notamment l’examen par le marchand, l’acceptation, la prolongation ou le remboursement selon le scénario et le comportement actuel du produit. Comment OxaPay gère les factures sous-payées et expirées explique ces situations plus en détail.
Quand faut-il escalader le cas vers OxaPay ?
Escaladez une enquête côté fournisseur lorsque :
- la transaction blockchain correspond à l’adresse, au réseau, à l’actif, au montant et au timing attendus, mais aucun paiement OxaPay correspondant n’apparaît ;
- Payment Information et Payment History affichent des résultats contradictoires ;
- le statut du paiement ne reflète pas les preuves de transaction disponibles ;
- un remboursement ou une action manuelle sur le paiement reste non résolu ;
- le marchand ne peut pas expliquer l’enregistrement côté fournisseur à partir de la documentation disponible.
Fournissez un dossier complet :
- référence Merchant API ou de compte, le cas échéant ;
- track ID ;
- order ID ;
- TXID ;
- actif et réseau ;
- le montant attendu et le montant reçu ;
- heure du paiement ;
- statut OxaPay actuel ;
- preuves de l’explorateur blockchain ;
- statut de la commande du marchand ;
- description concise de l’écart.
Une escalade complète réduit les questions répétitives et aide à distinguer une enquête côté fournisseur des problèmes liés au client, au portefeuille ou à l’intégration du marchand.
Comment prévenir les cas de paiement manquant
De nombreuses enquêtes sur des paiements manquants commencent par des références insuffisantes ou des instructions peu claires pour les clients.
Les marchands peuvent réduire les cas futurs en :
- enregistrant le order ID et le track ID lors de la création du paiement ;
- affichant clairement l’actif, le réseau, le montant et l’échéance de paiement ;
- conservant les enregistrements de paiement après le checkout ;
- informant les clients avec des statuts de paiement explicites ;
- surveillant les commandes paid qui restent non exécutées ;
- maintenant une seule file d’exceptions partagée ;
- testant les scénarios de retard, de sous-paiement, d’expiration et d’échec de paiement ;
- formant le support à demander les bonnes preuves.
Chez OxaPay, Generate Invoice endpoint prend en charge un order_id interne, tandis que Payment Information et Payment History aident les marchands à récupérer et examiner les enregistrements de paiement. Ensemble, ces références créent une piste d’enquête plus solide.
Comment OxaPay facilite les enquêtes sur les paiements manquants
OxaPay fournit plusieurs niveaux de visibilité sur les paiements :
- order_id pour la référence interne du marchand ;
- track_id pour la session de paiement OxaPay ;
- Payment Information pour un paiement précis ;
- Payment History pour des recherches plus larges au niveau du compte ;
- des statuts de paiement documentés ;
- la gestion des factures pour les cas de sous-paiement et d’expiration.
Ces outils aident les marchands à déterminer si un paiement signalé est manquant, en attente, sous-payé, expiré, non rapproché ou déjà accepté.
Le marchand reste responsable de relier le paiement à ses propres enregistrements de commande, de client, d’exécution et de support.
Enquêter sur le paiement avant de décider de l’issue
Un paiement manquant doit être traité comme un problème de preuve, pas comme une supposition.
La séquence d’enquête correcte est la suivante :
- collecter le order ID, le track ID et le TXID ;
- vérifier que la transaction existe sur le réseau attendu ;
- comparer l’actif, l’adresse, le montant et le timing ;
- déterminer si la transaction est en attente ou confirmée ;
- examiner l’enregistrement de paiement OxaPay ;
- le comparer avec la commande du marchand et l’état d’exécution ;
- classer la cause racine et attribuer la bonne action suivante.
Ce processus évite les doubles paiements, les erreurs d’exécution, les promesses de récupération non justifiées et les cas clients non résolus.
La passerelle de paiement crypto OxaPay fournit aux marchands les références de paiement, les enregistrements de statut et l’historique nécessaires pour retracer l’activité de paiement. Reliez ces capacités à un processus d’enquête cohérent afin que les clients reçoivent des réponses claires et que chaque paiement aboutisse à un résultat documenté.




