Comment éviter les paiements en cryptomonnaie sur le mauvais réseau : guide d’intervention pour les commerçants

Une transaction peut être confirmée sur une blockchain sans pour autant correspondre au paiement demandé par votre entreprise. Le client peut avoir envoyé le bon montant dans le bon jeton, mais sur le mauvais réseau, envoyé un autre jeton à l’adresse prévue, versé un montant insuffisant ou transféré les fonds vers une adresse sans rapport avec la commande. Votre équipe d’assistance doit distinguer la preuve qu’un transfert a eu lieu de la preuve que la commande a été correctement payée.

Ce guide opérationnel s’adresse aux commerçants ; il ne s’agit pas d’un tutoriel de récupération de portefeuille. Il traite de la prévention, de la collecte des preuves, de la vérification dans un explorateur de blocs, de la classification des incidents, des demandes de remplacement, de la prévention des doublons et de la communication avec les clients. La courte FAQ destinée aux payeurs ayant utilisé le mauvais réseau reste utile aux clients ; ce guide explique au commerçant les démarches à effectuer en coulisses avant de leur répondre.

Une transaction confirmée n’est pas nécessairement un paiement reconnu

Une blockchain confirme une transaction conformément aux règles de son réseau. Votre processus de paiement ne reconnaît un règlement que lorsque le transfert observé correspond à la demande et atteint l’état d’acceptation défini par votre entreprise.

Pour un paiement normal, vérifiez tous les champs suivants :

Champ	Élément devant correspondre
Référence de commande ou de paiement	La demande en cours pour ce client et cet achat
Réseau	Le réseau sélectionné dans le parcours de paiement actif
Actif	Le jeton ou l’actif natif exact demandé, y compris le contrat ou l’adresse de création attendus le cas échéant
Destination	L’adresse de réception configurée pour ce mode de paiement
Montant	Le montant exigé par la demande et votre politique de tolérance sur les montants
Résultat de la transaction	Réussite sur le réseau concerné, et non simple envoi ou attente de traitement
État de confirmation	Le seuil ou l’état exigé par votre politique d’exécution des commandes
Unicité	La transaction n’a pas déjà été affectée à une autre commande ou opération d’exécution

La documentation de Circle sur les confirmations des blockchains explique que les transactions commencent par être en attente, que le processus de confirmation varie selon la blockchain et que les blocs récents peuvent subir des réorganisations. Un hash, une capture d’écran de portefeuille ou une page indiquant « réussite » constitue donc un élément à examiner, mais ne suffit pas, à lui seul, pour autoriser l’exécution de la commande.

Distinguer les principaux types d’incidents

Les clients qualifient souvent toute incohérence de « mauvais réseau ». Classez les faits avant de choisir une solution.

Incident	Ce qui s’est passé	Réponse du commerçant
Mauvais réseau	L’actif attendu a peut-être été envoyé, mais sur un réseau différent de celui sélectionné pour la demande	Vérifiez la transaction sur le réseau réellement utilisé ; déterminez si la destination est sous votre contrôle et si l’actif peut y être utilisé ; ne promettez pas de récupération
Mauvais jeton ou mauvaise devise	Le réseau est peut-être correct, mais l’actif transféré ne correspond pas à la demande	Vérifiez le contrat ou l’adresse de création du jeton ainsi que la destination ; suivez la procédure en cas de mauvaise devise
Mauvaise adresse	Le transfert a été envoyé à une adresse autre que la destination indiquée dans la demande	Vérifiez précisément les deux adresses ; le commerçant ne peut pas annuler un transfert qu’il n’a pas reçu
Paiement partiel	Le bon parcours a été utilisé, mais le montant reçu est inférieur au montant exigé	Suspendez l’exécution de la commande et suivez la procédure en cas de paiement partiel ; n’improvisez pas de consigne pour verser le complément
Confirmation retardée	La transaction correspondante est en attente ou n’a pas atteint l’état de confirmation exigé par le commerçant	Maintenez le dossier en attente, surveillez-le et déconseillez un second paiement tant que le résultat n’est pas connu
Paiement en double	Le client a payé plusieurs fois, ou l’ancienne demande et celle de remplacement ont toutes deux abouti	N’exécutez la commande qu’une fois, conservez chaque transaction et transmettez le reçu excédentaire pour examen

Ne supposez pas qu’un symbole boursier familier suffit à prouver que l’actif est correct. Circle décrit USDC comme un dollar numérique émis sur plusieurs blockchains, tandis que Tether publie une liste à jour des protocoles prenant en charge les jetons Tether. Ces listes d’émetteurs ne déterminent pas ce que Yolfi, votre portefeuille ou votre entreprise prend en charge. Proposez uniquement les combinaisons exactes d’actif et de réseau affichées dans votre configuration Yolfi active.

Prévenir l’incident avant la signature du client

La meilleure procédure contre les erreurs de réseau commence sur la page de paiement, pas auprès de l’assistance.

Traiter l’actif et le réseau comme un seul mode de paiement

Ne nommez pas une option uniquement « USDC » ou « USDT ». Utilisez partout une désignation combinée telle que « USDC sur [le réseau sélectionné] » : lors de la sélection, sur l’écran récapitulatif, dans les instructions du code QR, lors du passage au portefeuille, sur le reçu, dans les dossiers d’assistance et dans les exports de rapprochement.

Le guide des paiements en USDC et le guide des paiements en USDT expliquent pourquoi le choix du réseau fait partie intégrante du mode de paiement. Vos instructions publiques ne doivent répertorier que les combinaisons actuellement disponibles dans le parcours de paiement, et non tous les réseaux sur lesquels un émetteur propose son jeton.

Répéter les informations essentielles au moment de la décision

Avant que le portefeuille ne signe, affichez :

le nom et le symbole exacts de l’actif ;
le nom exact du réseau ;
le montant exact ;
l’adresse de destination, avec un bouton permettant de la copier ;
la référence de commande ou de paiement ;
la règle d’expiration ou de délai, le cas échéant ;
un avertissement demandant de ne pas choisir un autre réseau sous prétexte que son adresse semble similaire ;
une invitation à revenir sur la page d’état du paiement après l’envoi.

Ne dites pas aux utilisateurs qu’un changement de réseau déplace les jetons. Modifier le réseau sélectionné dans un portefeuille change la blockchain qu’il affiche et avec laquelle il interagit ; cela ne transfère pas un solde existant d’une blockchain à une autre. L’utilisation d’un pont ou le retrait depuis une plateforme d’échange constituerait une opération distincte, avec ses propres risques et limites d’assistance.

Réduire les choix superflus

N’activez que les options utilisées par vos clients et prises en charge par votre équipe. Chaque combinaison supplémentaire ajoute une adresse de règlement, un identifiant de jeton, un explorateur, une règle de confirmation et un traitement des exceptions. Examinez les options disponibles dans votre configuration active et consultez le répertoire des blockchains pour accéder aux pages de Yolfi propres à chaque réseau.

Effectuez un véritable test de faible valeur pour chaque combinaison activée. Vérifiez l’intitulé sur la page de paiement, la destination, l’invite du portefeuille, l’enregistrement dans l’explorateur, le changement d’état, la notification ou le webhook, l’écriture de rapprochement et le comportement d’exécution de la commande.

Constituer un dossier de preuves pour l’incident

Demandez toutes les informations nécessaires en une seule fois. Des demandes répétées allongent les délais et incitent le client à tenter des solutions non approuvées.

Preuves à demander au client

URL du lien de paiement ou identifiant de référence du paiement ;
référence de commande, de facture ou de compte ;
hash de la transaction et lien vers un explorateur de blocs, si disponible ;
actif et montant que le client pense avoir envoyés ;
réseau qu’il a réellement sélectionné ;
adresse du portefeuille expéditeur ;
heure approximative du transfert.

Preuves du côté du commerçant

actif, réseau, montant et destination affichés par la demande initiale ;
horodatages de création, d’expiration, de détection et de changement d’état de la demande ;
adresse de règlement configurée pour la combinaison demandée ;
notifications de paiement, identifiants de webhooks et résultats de traitement concernés ;
résultat de l’explorateur pour le réseau utilisé, vérifié indépendamment ;
messages du client et instructions fournies par votre équipe ;
références des paiements initial et de remplacement associés à la même commande ;
opérations d’exécution, d’avoir, de remboursement ou d’ouverture d’accès déjà réalisées.

Une capture d’écran peut avoir été modifiée, être obsolète ou provenir du mauvais réseau. Utilisez-la pour retrouver la transaction, puis vérifiez celle-ci de manière indépendante.

Vérifier le transfert dans le bon explorateur

Commencez par le réseau que le client affirme avoir utilisé, puis confirmez-le à partir des données de l’explorateur. Les conseils de MetaMask en cas d’envoi vers une mauvaise destination recommandent également de vérifier l’état de la transaction et l’explorateur de blocs avant de déterminer ce qui s’est passé.

Ouvrez un explorateur reconnu pour le réseau réellement utilisé.
Recherchez le hash complet de la transaction. Ne vous fiez pas au texte visible d’un lien ; vérifiez le domaine de l’explorateur conformément à votre procédure interne.
Déterminez si la transaction est en attente, réussie, échouée, abandonnée ou remplacée.
Vérifiez les adresses de l’expéditeur et de destination caractère par caractère.
Vérifiez l’actif transféré. Pour un transfert de jeton, contrôlez le contrat ou l’adresse de création, et pas seulement son symbole.
Vérifiez le montant brut du jeton dans l’événement de transfert. Obtenez séparément sa précision décimale depuis le contrat ou l’adresse de création de référence, ou depuis les métadonnées fiables de l’explorateur.
Consignez le bloc, l’horodatage, le nombre actuel de confirmations ou l’état de finalité, ainsi que tout journal pertinent.
Comparez chaque champ avec la demande de paiement initiale.
Vérifiez votre portefeuille de règlement ou votre registre de surveillance du portefeuille sur ce même réseau.
Recherchez dans vos registres internes si le hash a déjà été reconnu ou affecté ailleurs.

Le guide de démarrage rapide de Circle sur les transferts d’USDC dans un environnement EVM présente séparément les étapes consistant à choisir une blockchain, envoyer un transfert, recevoir un hash et consulter un explorateur. Il précise également que l’expéditeur a besoin du jeton natif de ce réseau pour payer les frais de gaz. Considérez-le comme un exemple de mécanisme de transfert, et non comme une liste des combinaisons disponibles dans votre compte Yolfi.

Suivre un arbre de décision au lieu de promettre une récupération

Suivez les embranchements dans l’ordre.

1. Existe-t-il une transaction valide sur le réseau indiqué ?

Non, ou elle est toujours en attente : n’exécutez pas la commande. Demandez au client de ne pas effectuer de nouvel envoi pendant votre surveillance ou pendant que son fournisseur de portefeuille traite la transaction en attente.
Échec ou annulation : aucun paiement n’a abouti dans cette transaction. Vérifiez l’état indiqué par le portefeuille du client et par l’explorateur avant d’émettre une demande de remplacement.
Réussite : poursuivez la vérification des champs.

2. Correspond-elle au réseau, à l’actif, à la destination, au montant et à la politique de confirmation ?

Oui : traitez-la dans le circuit normal de reconnaissance et appliquez un contrôle d’exécution idempotent.
Non : soumettez-la à l’examen des exceptions. Ne la marquez pas manuellement comme payée au seul motif qu’une valeur a été transférée quelque part.

3. Le commerçant contrôle-t-il la destination sur le réseau réellement utilisé ?

Ce n’est pas établi : n’affirmez pas que les fonds ont été reçus ou qu’ils peuvent être récupérés. Transmettez le dossier au propriétaire du portefeuille ou au dépositaire responsable de cette adresse.
Oui : confirmez que l’actif exact se trouve à cette adresse et qu’il peut être géré en toute sécurité selon vos procédures relatives au portefeuille, à la sécurité, à la comptabilité et à la conformité. Le contrôle de l’adresse ne signifie pas automatiquement que la commande initiale a été correctement payée.
Non : expliquez que votre entreprise ne peut pas déplacer des fonds depuis une adresse qu’elle ne contrôle pas. La FAQ d’assistance d’Ethereum.org rappelle que les transactions Ethereum ne peuvent pas être annulées par un opérateur central ; si un service connu contrôle la destination, son équipe d’assistance peut être l’interlocuteur approprié.

4. Une mesure corrective a-t-elle été approuvée ?

Les issues possibles comprennent la reconnaissance manuelle du transfert, la demande d’un nouveau paiement correct, le renvoi des fonds accessibles au moyen d’une nouvelle transaction, l’octroi d’un avoir documenté ou le refus de toute récupération. La bonne décision dépend du réseau, du contrôle de l’adresse, du jeton, du mode de conservation, des capacités techniques, des coûts, des contrôles de risque et de la politique commerciale.

Ne dites jamais que les fonds sont « toujours perdus » ou « toujours récupérables ». MetaMask décrit un cas courant sur les réseaux compatibles EVM, dans lequel une même adresse de portefeuille peut être accessible sur un autre réseau compatible EVM, mais aussi des situations sans garantie de récupération. Ces indications ne prouvent pas qu’un commerçant, une plateforme d’échange, un contrat intelligent, un portefeuille multisignature ou un système de paiement puisse accéder à un transfert précis ou le restituer.

Émettre des liens de paiement de remplacement en toute sécurité

Lorsque la demande initiale ne peut pas être reconnue et que votre politique autorise une nouvelle tentative, créez un nouveau lien de paiement Yolfi. Ne modifiez pas l’historique et ne dites pas simplement au client de « réessayer ».

La demande de remplacement doit :

conserver le même identifiant de commande ou de facture ;
recevoir un nouvel identifiant unique de référence de paiement ;
indiquer précisément l’actif, le réseau, le montant et la destination affichés dans le parcours actif ;
signaler que la demande précédente a été remplacée ou qu’elle est en cours d’examen ;
expliquer que la transaction initiale reste un incident distinct ;
demander au client de ne pas régler les deux liens ;
conserver toute règle d’expiration ;
soumettre les deux demandes à la détection des doublons avant l’exécution de la commande.

Ne demandez pas au client d’envoyer un complément non suivi, de refaire un envoi vers une adresse copiée depuis une conversation ou de changer de réseau après l’envoi comme si cela déplaçait les fonds initiaux.

Éviter les paiements et les exécutions en double

Une transaction retardée peut être confirmée après la création d’une demande de remplacement. Un client peut également payer deux fois en attendant la réponse de l’assistance. Prévoyez ces deux éventualités.

Utilisez un identifiant de commande unique au niveau de l’entreprise, associé à plusieurs tentatives de paiement immuables. Appliquez les contrôles suivants :

un hash de transaction ne peut être reconnu qu’une seule fois ;
une tentative de paiement ne peut pas servir à exécuter plusieurs commandes ;
une commande ne peut déclencher qu’une seule fois l’exécution ou l’ouverture d’un accès ;
les demandes initiale et de remplacement restent liées ;
toutes les tentatives en cours sont vérifiées juste avant l’exécution ;
les confirmations tardives et les paiements excédentaires sont soumis à examen ;
le traitement des webhooks et des notifications est idempotent ;
les remboursements nécessitent une approbation distincte, la vérification de la destination et la conservation des données de transaction.

Si deux transferts aboutissent, ne supprimez pas l’un d’eux, ne l’affectez pas discrètement à un autre achat et ne renvoyez pas automatiquement les fonds vers une adresse fournie dans un nouveau message adressé à l’assistance. Bloquez toute exécution en double et appliquez la politique documentée d’avoir ou de remboursement.

Définir les règles d’assistance et de sécurité du commerçant

Fournissez à l’équipe d’assistance de premier niveau un texte de réponse et des critères de transmission du dossier.

L’assistance peut demander des données publiques sur la transaction, des références de paiement, des détails de commande et des captures d’écran ne révélant aucun secret. Elle ne doit jamais demander de phrase de récupération, de clé privée, de mot de passe de portefeuille, de code à usage unique ni de prise de contrôle à distance de l’appareil du client. Toute personne disposant d’une phrase de récupération ou d’une clé privée peut être en mesure de contrôler le portefeuille.

Utilisez par exemple la formulation suivante :

Nous constatons qu’une transaction a été envoyée sur [réseau]. Nous vérifions si son actif, sa destination, son montant et son état de confirmation correspondent à la demande de paiement [référence]. Merci de ne pas effectuer d’autre paiement avant que nous vous transmettions un nouveau lien approuvé ou que nous vous indiquions la prochaine étape. Nous ne vous demanderons jamais votre phrase de récupération ni votre clé privée.

Fixez des délais pour accuser réception, examiner les preuves, transmettre le dossier, approuver une décision et tenir le client informé. Ne promettez aucune date de récupération avant d’avoir établi l’accès aux fonds et la faisabilité de la transaction.

Yolfi est un service sans garde : les paiements sont envoyés vers le portefeuille configuré par le commerçant au lieu d’être détenus par Yolfi. Il est donc indispensable de configurer correctement le portefeuille, d’en maîtriser l’accès et de définir une politique de gestion des incidents côté commerçant.

Liste de contrôle des incidents pour les commerçants

Avant d’accepter des paiements

Affichez l’actif et le réseau ensemble à chaque étape.
N’activez que les combinaisons disponibles dans la configuration Yolfi active.
Vérifiez chaque adresse de règlement et chaque identifiant de jeton.
Testez de bout en bout chaque parcours activé.
Définissez les règles de confirmation, de gestion des incohérences et des doublons, de remboursement et de transmission des dossiers.
Formez l’assistance pour qu’elle ne demande jamais les secrets d’un portefeuille.

À la réception d’un signalement

Suspendez l’exécution de la commande et découragez tout paiement en double.
Conservez la demande initiale et le signalement du client.
Constituez le dossier de preuves.
Vérifiez la transaction sur le réseau réellement utilisé.
Comparez le réseau, l’actif, la destination, le montant, l’état et les confirmations.
Vérifiez qui contrôle l’adresse sans présumer que les fonds sont récupérables.
Recherchez toute reconnaissance antérieure et toute tentative associée.
Consignez la décision approuvée et le message envoyé au client.

FAQ

Une transaction peut-elle être confirmée alors que le paiement reste impayé ?

Oui. La confirmation prouve qu’un réseau a traité une transaction. Pour être reconnu, un paiement doit également correspondre au réseau, à l’actif, à la destination, au montant et à la référence demandés, ainsi qu’à la politique de confirmation du commerçant.

Changer de réseau dans le portefeuille permet-il de récupérer ou de déplacer les fonds ?

Non. Changer le réseau sélectionné modifie la blockchain affichée par le portefeuille et celle avec laquelle il interagit. Cela ne déplace pas les jetons entre les réseaux. Dans certains cas concernant des réseaux EVM, le propriétaire d’une même adresse peut être en mesure de voir les actifs sur le réseau utilisé, mais tout transfert ou passage par un pont ultérieur constitue une opération distincte, dont la disponibilité ou la pertinence n’est pas garantie.

Faut-il demander immédiatement au client de payer à nouveau ?

Non. Commencez par déterminer si la transaction initiale est en attente, échouée, réussie ou non conforme. Si une nouvelle tentative est approuvée, émettez une nouvelle demande de paiement associée à la première et activez la détection des doublons pour les deux tentatives.

Yolfi peut-il récupérer un paiement effectué sur le mauvais réseau ?

Ne partez pas de ce principe. Dans un parcours sans garde, les fonds sont envoyés vers le portefeuille configuré par le commerçant. La solution possible dépend de la destination réelle, du réseau, de l’actif, du contrôle du portefeuille, des capacités techniques et de la politique du commerçant.

Que faire si le client a utilisé le bon réseau, mais le mauvais jeton ?

Traitez le cas comme un incident lié à une mauvaise devise. Vérifiez le contrat ou l’adresse de création du jeton, le montant, la destination et la réception dans le portefeuille, puis suivez la procédure documentée de gestion des exceptions au lieu de marquer la commande comme payée.

Que faire si la transaction est toujours en attente ?

Maintenez la commande en attente et ne l’exécutez pas. Surveillez l’explorateur et l’état du paiement conformément à votre politique de confirmation. Découragez un second transfert jusqu’à ce que la transaction en attente aboutisse ou échoue, ou jusqu’à l’approbation d’un remplacement encadré.

Une capture d’écran suffit-elle pour approuver l’exécution de la commande ?

Non. Utilisez le hash pour retrouver la transaction et vérifiez-la de manière indépendante dans le bon explorateur. Faites ensuite correspondre la transaction à la demande de paiement et assurez-vous qu’elle n’a pas déjà été utilisée.

Conclusion

La prévention des erreurs de réseau exige des indications sans ambiguïté sur l’actif, le réseau, la destination, le montant et l’état de confirmation. Le traitement des incidents nécessite des données de transaction vérifiées, des contrôles prudents sur la maîtrise du portefeuille, l’absence de promesses de récupération et la prévention des doublons.

Commencez par les combinaisons affichées dans votre configuration Yolfi active, testez-les et fournissez à l’assistance un arbre de décision unique. Lorsqu’une nouvelle tentative est nécessaire, créez une demande de remplacement associée à la première au lieu d’improviser dans une conversation. L’objectif est de reconnaître le bon paiement, de n’exécuter la commande qu’une fois et de conserver la trace de chaque décision relative aux exceptions.