O PAGAMENTO ERA REAL.
O COMPROVANTE ERA REAL.
Mesmo assim, eu ainda não liberaria o pedido.
Aqui está o tipo de situação P2P que pode parecer totalmente limpa à primeira vista.
Um vendedor tem dois pedidos de USDT abertos em horários parecidos.
O Pedido A está aguardando pagamento.
O Pedido B também está ativo.
Então um comprador envia uma transferência bancária e publica o comprovante no chat do Binance P2P.
Nada parece falso.
O dinheiro realmente chegou na conta bancária do vendedor.
O comprovante realmente veio de uma transferência bem-sucedida.
Até o valor parecia razoável.
Seria muito fácil pensar:
“Pagamento confirmado. Liberar.”
Mas antes de mexer em “Liberar”, ainda há uma pergunta:
A qual pedido, na prática, esse pagamento pertence?
É aí que a situação muda.
Quando o vendedor compara o pagador, o valor, o ID do Pedido e os dois pedidos ativos, o pagamento se encaixa na outra transação.
O pagamento é real.
A prova é real.
Mas, juntos, eles estão sendo usados para fazer o pedido errado parecer pago.
Então o vendedor para.
Sem achismo.
Sem liberar primeiro e resolver depois.
As duas conversas ficam dentro do Binance P2P. O vendedor mantém os dois IDs de Pedido, a transação bancária e o histórico do chat juntos, enquanto a cripto permanece protegida pelo processo do pedido.
Se o mapeamento ainda não puder ser resolvido com clareza, é para isso que serve Appeal/Suporte.
O que acho interessante em casos como esse é que “falso vs. real” nem sempre é a pergunta mais difícil no P2P.
Às vezes, cada peça individual de evidência pode ser genuína.
O erro é presumir que essas peças pertencem à mesma transação.
Antes de liberar, eu prefiro responder uma pergunta extra:
Não só “O dinheiro chegou?”
Mas:
“Qual pedido exato esse dinheiro liquidou?”
@Binance Vietnam #BinanceP2PAnToan
O COMPROVANTE ERA REAL.
Mesmo assim, eu ainda não liberaria o pedido.
Aqui está o tipo de situação P2P que pode parecer totalmente limpa à primeira vista.
Um vendedor tem dois pedidos de USDT abertos em horários parecidos.
O Pedido A está aguardando pagamento.
O Pedido B também está ativo.
Então um comprador envia uma transferência bancária e publica o comprovante no chat do Binance P2P.
Nada parece falso.
O dinheiro realmente chegou na conta bancária do vendedor.
O comprovante realmente veio de uma transferência bem-sucedida.
Até o valor parecia razoável.
Seria muito fácil pensar:
“Pagamento confirmado. Liberar.”
Mas antes de mexer em “Liberar”, ainda há uma pergunta:
A qual pedido, na prática, esse pagamento pertence?
É aí que a situação muda.
Quando o vendedor compara o pagador, o valor, o ID do Pedido e os dois pedidos ativos, o pagamento se encaixa na outra transação.
O pagamento é real.
A prova é real.
Mas, juntos, eles estão sendo usados para fazer o pedido errado parecer pago.
Então o vendedor para.
Sem achismo.
Sem liberar primeiro e resolver depois.
As duas conversas ficam dentro do Binance P2P. O vendedor mantém os dois IDs de Pedido, a transação bancária e o histórico do chat juntos, enquanto a cripto permanece protegida pelo processo do pedido.
Se o mapeamento ainda não puder ser resolvido com clareza, é para isso que serve Appeal/Suporte.
O que acho interessante em casos como esse é que “falso vs. real” nem sempre é a pergunta mais difícil no P2P.
Às vezes, cada peça individual de evidência pode ser genuína.
O erro é presumir que essas peças pertencem à mesma transação.
Antes de liberar, eu prefiro responder uma pergunta extra:
Não só “O dinheiro chegou?”
Mas:
“Qual pedido exato esse dinheiro liquidou?”
@Binance Vietnam #BinanceP2PAnToan