Usuários burlando valor mercadoria PagSeguro

[diasgabrie 0]

Amigos,

 

Não é a primeira vez que usuários burlam o valor da mercadoria para um valor menor em meu site.

 

Eles abrem o codigo de fonte da pagina, copiam a parte do meu form, alteram o valor e salvam uma pagina .htm e fazem a compra. Uma mercadoria de R$500,00 eles pagam R$1,00. Meu código atual:

 

<p> <!-- INICIO FORMULARIO BOTAO PAGSEGURO -->
<form target="pagseguro" action="https://pagseguro.uol.com.br/security/webpagamentos/webpagto.aspx" method="post">
<input type="hidden" name="email_cobranca" value="meuemailpagaseguro@meuservidor.com">
<input type="hidden" name="tipo" value="CP">
<input type="hidden" name="moeda" value="BRL">
<input type="hidden" name="item_id_1" value="<?php echo"$idd";?>">
<input type="hidden" name="item_descr_1" value="Produto">
<input type="hidden" name="item_quant_1" value="1">
<input type="hidden" name="item_valor_1" value="50000">
<input type="hidden" name="item_frete_1" value="000">
<input type="image" src="https://pagseguro.uol.com.br/Security/Imagens/btnComprar.jpg" name="submit" alt="Pague com PagSeguro - é rápido, grátis e seguro!" width="73" height="24">
</form>
<!-- FINAL FORMULARIO BOTAO PAGSEGURO -->

Enfim, como eu poderia barrar esta pratica? uso PHP em meu site.

Obrigada,

Gabriela

[klaygomes 0]

Não adianta, é possível também alterar o valor a partir da própria página do PAGSEGURO. Estou efrentando este mesmo tipo de problema, embora envie o post automaticamente para o pagseguro (sem o uso de formulário) os usuários estão alterando o valor da compra a partir da página responsável pela geração do boleto no próprio pagseguro.

 

O pior e você ficar com qualificação baixa por que o usuário faz várias compras com valor de UM CENTAVO e depois abre disputas solicitando o valor informando que não recebeu a mercadoria e agente não pode fazer nada.

[diasgabrie 0]

É aquela velha mania de querer levar vantagem em tudo que alguns clientes tem.

 

E o pagseguro também precisa arrumar uma solução. além de desorganizar nossa administração das compras ainda acaba com nossa reputação.

Ele ganha um valor alto sobre nossas vendas, o minimo que deve fazer é proporcionar um sistema mais confiavel aos usuários.

 

Obrigada,

Gabriela

[Comunicação PagSeguro 0]

É aquela velha mania de querer levar vantagem em tudo que alguns clientes tem.

 

E o pagseguro também precisa arrumar uma solução. além de desorganizar nossa administração das compras ainda acaba com nossa reputação.

Ele ganha um valor alto sobre nossas vendas, o minimo que deve fazer é proporcionar um sistema mais confiavel aos usuários.

 

Obrigada,

Gabriela

 

Bom dia.

 

Já estamos trabalhando em uma solução que irá impedir este tipo de situação. Será disponibilizada em breve, assim que concluirmos os testes.

[666999 0]

cara eu tambem estou querendo usar este sistema de botão de pagamento do pagseguro

 

to com uma ideia que iria ajudar minimizar

 

tipo cria 2 pagina

uma com iframe e a outra com a pagina dentro com o botão pagamento

ai você criptografa

as 2 pagina

 

ai o cara não consegue ver o codico fonte da pagina

não consegue abrir a pagina offline

e não consegue tirar print screen

 

utilize HTMLProtector

[brcontainer 16]

cara eu tambem estou querendo usar este sistema de botão de pagamento do pagseguro

 

to com uma ideia que iria ajudar minimizar

 

tipo cria 2 pagina

uma com iframe e a outra com a pagina dentro com o botão pagamento

ai você criptografa

as 2 pagina

 

ai o cara não consegue ver o codico fonte da pagina

não consegue abrir a pagina offline

e não consegue tirar print screen

 

utilize HTMLProtector

É uma ideia aproveitavel, porem seria melhor fazer a aplicação via SESSION (cookies de servidor), na hora de finalizar (ONSUBMIT) a compra o AJAX pegaria os valores gravados no SESSION e retornaria para o formulario, assim não dando tempo de alterar o FORM. Porem tem usuario que consegue burlar isso facilmente (facil mesmo).

 

O pagseguro que deveria mudar isso logo, fazer SERVER=>SERVER e não CLIENTE=>SERVER, ou então o cliente criar um JSON ou XML (seria um extrutura que nem a do sitemaps, seria um estrutura padrão) com todos produtos que seria requisitado pelo retorno automatico para alem de validar o POST validaria os produtos.

 

¬¬ mas acho que o pessoal do pagseguro não esta muito preucupado "ainda".

[djc 0]

 

É aquela velha mania de querer levar vantagem em tudo que alguns clientes tem.

 

E o pagseguro também precisa arrumar uma solução. além de desorganizar nossa administração das compras ainda acaba com nossa reputação.

Ele ganha um valor alto sobre nossas vendas, o minimo que deve fazer é proporcionar um sistema mais confiavel aos usuários.

 

Obrigada,

Gabriela

 

Bom dia.

 

Já estamos trabalhando em uma solução que irá impedir este tipo de situação. Será disponibilizada em breve, assim que concluirmos os testes.

 

 

Olá,

 

Uma outra solução(do lado do desenvolverdor) também, poderia ser no momento do pagamento(clique pelo cliente) ser feito o envio do POST via SERVER -> SERVER com os dados da compra, a pagseguro iria retornar um token de "pré-cobrança" que poderia ser associado a alguma URL no retorno para o cliente, para que o mesmo continuasse o processo de pagamento.

 

Assim a pagseguro saberia quem é o cliente que realiza o pagamento e os dados não poderiam ser manipulados pelo cliente (considerando que as informações de compra estejam armazenadas na Sessão).

[Manoel Netto 0]

Usando NPI, você pode conferir o valor pago no PagSeguro com o valor do produto em sua loja, no momento do primeiro retorno do PagSeguro (quando a transação for gerada).

 

Isso impede que você envie o produto, por estar em um processo automatizado e se tiver muitos pedidos por dia, fica difícil acompanhar. No momento em que você detectar a fraude, marca o pedido como cancelado e dentro do PagSeguro marca para devolver o dinheiro ao comprador.

 

Mais informações aqui: https://pagseguro.uol.com.br/desenvolvedor/retorno_automatico_de_dados.jhtml

 

Abs

[Eduardo Kraus 0]

 

Amigos,

 

Não é a primeira vez que usuários burlam o valor da mercadoria para um valor menor em meu site.

 

Eles abrem o codigo de fonte da pagina, copiam a parte do meu form, alteram o valor e salvam uma pagina .htm e fazem a compra. Uma mercadoria de R$500,00 eles pagam R$1,00. Meu código atual:

 

<p> <!-- INICIO FORMULARIO BOTAO PAGSEGURO -->
<form target="pagseguro" action="https://pagseguro.uol.com.br/security/webpagamentos/webpagto.aspx" method="post">
<input type="hidden" name="email_cobranca" value="meuemailpagaseguro@meuservidor.com">
<input type="hidden" name="tipo" value="CP">
<input type="hidden" name="moeda" value="BRL">
<input type="hidden" name="item_id_1" value="<?php echo"$idd";?>">
<input type="hidden" name="item_descr_1" value="Produto">
<input type="hidden" name="item_quant_1" value="1">
<input type="hidden" name="item_valor_1" value="50000">
<input type="hidden" name="item_frete_1" value="000">
<input type="image" src="https://pagseguro.uol.com.br/Security/Imagens/btnComprar.jpg" name="submit" alt="Pague com PagSeguro - é rápido, grátis e seguro!" width="73" height="24">
</form>
<!-- FINAL FORMULARIO BOTAO PAGSEGURO -->

Enfim, como eu poderia barrar esta pratica? uso PHP em meu site.

Obrigada,

Gabriela

 

Eu faço sistema a prova de fraude. Totalmente a prova de fraude.

 

Ninguém nunca conseguiu burlar o sistema que fiz em http://www.eduardokraus.com/integrao-moodle-pagseguro

[alcaidedigital 57]

Bom, não sei porque ressuscitaram um post de 2010, mas... Enfim, quem estiver pesquisando o PagSeguro já tem solução para isso disponível para todos.

 

É o uso das APIs.

 

No momento da compra utilize a API de pagamentos, assim os dados não são expostos no momento da requisição, porque toda requisição será feita servidor para servidor.
Para acompanhar as transações tem a API de notificações que ao inves de retornar todos dados e depois o sistema é obrigado a validar para ter certeza que está tudo okay, o PagSeguro só enviará um código o tipo do código, com o e-mail e token o sistema requisita detalhes daquele código, se for um código simulado (alguém má intencionado tenta burlar o sistema) o PagSeguro irá retornar um erro.

 

Bom, se alguém estiver usando PHP, pode usar meus tutoriais de graça para aprender a aplicar isso no sistema:
API Pagamentos: http://sounoob.com.br/2011/11/09/criando-uma-requisicao-de-pagamento-do-pagseguro-via-parametros-http-usando-php-sem-utilizar-a-biblioteca-oficial/

API notificações: http://sounoob.com.br/2011/09/06/recebendo-notificacoes-do-pagseguro-usando-php-sem-utilizar-a-biblioteca-oficial/

[Thiago Moraes 32]

senartes, estava precisando deste passo-a-passo, obrigado por compartilhar.

[CleitonGarcia 31]

Colegas,

 

Esse tipo de situação o PagSeguro tem lá suas responsabilidades em resolver. No entanto, eu acredito profundamente que a responsabilidade maior é do ecommerce/loja que dispõe um método falho em seu site.

 

O formulário não há problema, nem com o PagSeguro ou qualquer método que seja. Há problema na autenticação e validação da compra antes do gateway.

 

Isso é facilmente resolvido se você tratar os dados que recebe ao invés de envia-los diretamente ao gateway responsável.

 

É preciso realizar o tratamento dos dados informados no HTML - deve ser recuperado o que está sendo comprado com POST, e fará uma conexão com o banco de dados, e após ser analisado o que está sendo comprado, número de itens, etc. Você redireciona para o gateway.

[alcaidedigital 57]

CleitonGarcia,

 

A recomendação anteriormente era clara, enviar os dados (via HTML) depois no retorno de dados verificar produto a produto se os valores são os mesmos que estão no banco de dados.

 

Até ai blz, mas imagina que na sua loja o produto altera o preço e o sistema não grava histórico de preços?

 

Mesmo assim iria dar um grande trabalho.

 

A solução mais simples é essa, usar a API de pagamento o qual nesse processo fica praticamente impossível de alguém burlar. Até a API de notificação sofreu alteração para evitar outro esquema de "burlar" que existia antes no retorno automático.

 

Sendo assim também concordo que é de responsabilidade do e-commerce tratar isso, mas recomendo seriamente tratar usando as APIs o que faz o trabalho ficar muito mais simples, e ao meu ponto de vista, mais robusto e confiável.

[CleitonGarcia 31]

CleitonGarcia,

 

A recomendação anteriormente era clara, enviar os dados (via HTML) depois no retorno de dados verificar produto a produto se os valores são os mesmos que estão no banco de dados.

 

Até ai blz, mas imagina que na sua loja o produto altera o preço e o sistema não grava histórico de preços?

 

Mesmo assim iria dar um grande trabalho.

 

A solução mais simples é essa, usar a API de pagamento o qual nesse processo fica praticamente impossível de alguém burlar. Até a API de notificação sofreu alteração para evitar outro esquema de "burlar" que existia antes no retorno automático.

 

Sendo assim também concordo que é de responsabilidade do e-commerce tratar isso, mas recomendo seriamente tratar usando as APIs o que faz o trabalho ficar muito mais simples, e ao meu ponto de vista, mais robusto e confiável.

 

Não meu caro, a solução mais simples é a que eu disse mesmo.

 

Ao que entendi seu método, é validação no retorno dos dados? Que incoerente isso. A autenticação e validação das informações deve ser feita antes mesmo de chegar no gateway.

 

Será que é tão dificil? Basta a página que irá tratar os dados recuperar em prioridade o ID do produto e a quantidade de itens. Simples assim você irá pegar o ID informado e entrar no banco de dados, pegar o valor correto do produto e todas informações necessárias e transferir o mesmo ao gateway. Em relação à histórico de preços, é desnecessário, uma vez que a verificação recupera direto do valor da tabela, mudou lá, mudou no formulário!

 

Isso é mais simples e muito prático!

[alcaidedigital 57]

Sim, acho que não me expressei bem, o que quer dizer é que com a API de pagamentos tudo isso é desnecessário, já que nada vai para o formulário.

 

Mas tranquilo, entendi seu ponto :)