LE PAIEMENT ÉTAIT RÉEL.
LE REÇU ÉTAIT RÉEL.
JE NE LÂCHERAIS POURTANT PAS LA COMMANDE.
Voici le genre de situation P2P qui peut sembler totalement propre au premier abord.
Un vendeur a deux commandes USDT ouvertes à peu près au même moment.
La commande A attend un paiement.
La commande B est également active.
Puis un acheteur envoie un virement bancaire et publie le reçu dans le chat Binance P2P.
Rien ne paraît faux.
L’argent est vraiment arrivé sur le compte bancaire du vendeur.
Le reçu provient vraiment d’un virement réussi.
Même le montant semblait raisonnable.
Il serait très facile de penser :
« Paiement confirmé. Libérer. »
Mais avant de toucher à la libération, il reste une question :
À quelle commande ce paiement appartient-il réellement ?
C’est là que la situation change.
Quand le vendeur compare le payeur, le montant, l’ID de commande et les deux commandes actives, les lignes du paiement correspondent à l’autre transaction.
Le paiement est réel.
La preuve est réelle.
Mais ensemble, ils sont utilisés pour faire passer la mauvaise commande pour payée.
Alors le vendeur s’arrête.
Pas d’hypothèses.
Pas de libération d’abord et de tri ensuite.
Les deux conversations restent dans Binance P2P. Le vendeur garde ensemble les deux ID de commande, la transaction bancaire et l’historique du chat, tandis que la crypto reste protégée par le processus de commande.
Si l’attribution ne peut toujours pas être résolue clairement, c’est justement à quoi servent Appel/Support.
Ce que je trouve intéressant dans ce type de cas, c’est que la question « faux vs réel » n’est pas toujours la plus difficile dans le P2P.
Parfois, chaque élément de preuve peut être authentique.
L’erreur consiste à supposer que ces éléments appartiennent à la même transaction.
Avant de libérer, je préférerais répondre à une question en plus :
Non seulement « L’argent est-il arrivé ? »
Mais :
« À quelle commande exacte cet argent a-t-il réglé ? »
@Binance Vietnam #BinanceP2PAnToan
LE REÇU ÉTAIT RÉEL.
JE NE LÂCHERAIS POURTANT PAS LA COMMANDE.
Voici le genre de situation P2P qui peut sembler totalement propre au premier abord.
Un vendeur a deux commandes USDT ouvertes à peu près au même moment.
La commande A attend un paiement.
La commande B est également active.
Puis un acheteur envoie un virement bancaire et publie le reçu dans le chat Binance P2P.
Rien ne paraît faux.
L’argent est vraiment arrivé sur le compte bancaire du vendeur.
Le reçu provient vraiment d’un virement réussi.
Même le montant semblait raisonnable.
Il serait très facile de penser :
« Paiement confirmé. Libérer. »
Mais avant de toucher à la libération, il reste une question :
À quelle commande ce paiement appartient-il réellement ?
C’est là que la situation change.
Quand le vendeur compare le payeur, le montant, l’ID de commande et les deux commandes actives, les lignes du paiement correspondent à l’autre transaction.
Le paiement est réel.
La preuve est réelle.
Mais ensemble, ils sont utilisés pour faire passer la mauvaise commande pour payée.
Alors le vendeur s’arrête.
Pas d’hypothèses.
Pas de libération d’abord et de tri ensuite.
Les deux conversations restent dans Binance P2P. Le vendeur garde ensemble les deux ID de commande, la transaction bancaire et l’historique du chat, tandis que la crypto reste protégée par le processus de commande.
Si l’attribution ne peut toujours pas être résolue clairement, c’est justement à quoi servent Appel/Support.
Ce que je trouve intéressant dans ce type de cas, c’est que la question « faux vs réel » n’est pas toujours la plus difficile dans le P2P.
Parfois, chaque élément de preuve peut être authentique.
L’erreur consiste à supposer que ces éléments appartiennent à la même transaction.
Avant de libérer, je préférerais répondre à une question en plus :
Non seulement « L’argent est-il arrivé ? »
Mais :
« À quelle commande exacte cet argent a-t-il réglé ? »
@Binance Vietnam #BinanceP2PAnToan