search

pagseguro / pagseguro-sdk-php

Biblioteca de integração em PHP
298 stars 149 forks source link

Como obter o senderHash no backend? #191

Open geeksilva97 opened 4 years ago

geeksilva97 commented 4 years ago

Estou desenvolvendo uma integração com o Pagseguro utilizando Python. Porém não estou conseguindo testar os pagamentos em Produção, pois retorna o erro:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<errors>
    <error>
        <code>53150</code>
        <message>sender hash is required.</message>
    </error>
</errors>

Bom, como estou trabalhando em backend não posso utilizar o método do PagSeguroDirectPayment para obtê-lo.

A pergunta é, como obter o senderHash via requisição? Sem ser pela SDK.

renandelmonico commented 4 years ago

Estou com o mesmo problema. Engraçado que no sandbox não ocorreu problema, somente quando foi para produção.

geeksilva97 commented 4 years ago

Estou com o mesmo problema. Engraçado que no sandbox não ocorreu problema, somente quando foi para produção.

Pois é, comigo foi igual. Foi por isso que me iludi achando que ia dar certo. Mas entrei em contato com eles em Dezembro ainda e obtive a seguinte resposta.

Bom dia Edigleysson! Tudo bem? O senderHash só pode ser gerado em front através da nossa biblioteca JS. nâo é posível realizar todo o processo de checkout em backend por essa razão. Caso esteja desenvolvendo um aplicativo, temos a biblioteca checkout in app, porém a mesma foi descontinuada e no momento não receberá evoluçoes ou correções para possíveis erros. Se houver alguma dúvida, estamos à disposição.

E foi isso, daí fiz utilizando o Mercado Pago.

alecshoppe commented 4 years ago

Como todo o processo é feito no frontend antes de ir pro backend. Seu frontend deve usar o seguinte método: //após ter importado o script <script type="text/javascript" src="https://stc.pagseguro.uol.com.br/pagseguro/api/v2/checkout/pagseguro.directpayment.js"></script>

Após isso, você deve iniciar uma sessão através do backend (porque usa as credenciais de e-mail e token): // Basicamente um POST para: https://ws.pagseguro.uol.com.br/v2/sessions/ com suas credenciais. // Vai retornar um ID.

Após ter o ID da sessão: // Frontend: PagSeguroDirectPayment.setSessionId(ID RETORNADO DA CHAMADA A SUA API RODANDO O PASSO ANTERIOR EM BACKEND);

Quando o usuário clicar em FINALIZAR COMPRA aí você gera o código dele: hash = PagSeguroDirectPayment.getSenderHash(); // envie este hash junto com todos os outros dados: card token, payment method e etc..

lenivene commented 4 years ago

Como todo o processo é feito no frontend antes de ir pro backend. Seu frontend deve usar o seguinte método: //após ter importado o script <script type="text/javascript" src="https://stc.pagseguro.uol.com.br/pagseguro/api/v2/checkout/pagseguro.directpayment.js"></script>

Após isso, você deve iniciar uma sessão através do backend (porque usa as credenciais de e-mail e token): // Basicamente um POST para: https://ws.pagseguro.uol.com.br/v2/sessions/ com suas credenciais. // Vai retornar um ID.

Após ter o ID da sessão: // Frontend: PagSeguroDirectPayment.setSessionId(ID RETORNADO DA CHAMADA A SUA API RODANDO O PASSO ANTERIOR EM BACKEND);

Quando o usuário clicar em FINALIZAR COMPRA aí você gera o código dele: hash = PagSeguroDirectPayment.getSenderHash(); // envie este hash junto com todos os outros dados: card token, payment method e etc..

Isso não é bom, pelo fato de querer usar o checkout transparente em react native, por exemplo. Ai como pegaria esse hash?

Sem contar, que mesmo fazendo esse processo em um frontend (web), o pagamento cobra do cartão e logo depois o PagSeguro cancela image

alecshoppe commented 4 years ago

Cara, nunca tentei mas vendo os endpoints das apis da web, cheguei na url: https://pagseguro.uol.com.br/checkout/direct-payment/i-ck.html Ao mandar um GET e pegar o código raw da página pode ver que tem um sender hash incluso, basta só dar um parse na página. O mesmo não se difere para sandbox/produção.

O pagseguro.directpayment está basicamente colocando um iframe desta página no site pra fazer uma conexão direta, por isso não aparece consultadas na aba network do chrome.

-- lembrando que a alternativa acima não é nada oficial, se for fazer pra produção teste muito e deixe um script pra testar o código diariamente pra ver se consegue puxar um token e ofereça uma alternativa ao cliente final, recomendo também fazer este "parse" no lado do cliente se possível, porque este hash deve ter alguma relação com ip -- A prova desta relação é que no pagamento de recorrência você pode usar o ip ao invés do hash.

Após pegar este hash, o resto fica mais fácil pois cada uma das outras funções possui um endpoint.

Para pegar os meios de pagamento disponíveis manda um GET para: (produção) https://ws.pagseguro.uol.com.br/payment-methods?amount=VALOR_COMPRA&sessionId=SESSAO

Para pegar a bandeira do cartão basta mandar um GET para: https://df.uol.com.br/df-fe/mvc/creditcard/v1/getBin?tk=ID_SESSAO&creditCard=BIN_6DIG_CARTAO

(este id sessão é pego do POST https://ws.pagseguro.uol.com.br/v2/sessions?email=&token=)

Para obter o token do cartão basta mandar um POST para: https://df.uol.com.br/v2/cards Header: Content-Type: application/x-www-form-urlencoded sessionId=ID DE SESSÃO amount=VALOR cardNumber=NÚMERO DO CARTÃO cardBrand=BANDEIRA DO CARTÃO cardCvv=CVV cardExpirationMonth=MÊS DE EXPIRAÇÃO cardExpirationYear=ANO DE EXPIRAÇÃO

Para as parcelas um GET para: (produção) https://pagseguro.uol.com.br/checkout/v2/installments.json?sessionId=ID_SESSÃO&amount=VALOR&creditCardBrand=BANDEIRA&maxInstallmentNoInterest=parcelas_sem_juros

Note que as urls que coloquei "(produção)" precisam de sandbox. se for usada em sandbox, igual as já comentadas pela documentação.

Infelizmente é uma zona esta api, as vezes usa xml, as vezes json, as vezes você precisa enviar os dados de um jeito, as vezes de outro. É algo que o PagSeguro realmente precisa melhorar porque é um ponto que ele está ficando pra trás. Vi que eles estão fazendo uma versão nova mas me parece ainda estar relacionada com a antiga de algum jeito e é algo de extrema importância que já deveria estar pronto, incrível que na parte frontend existem atualizações semanais no painel de vendas que de tantas, chega a incomodar. Isso de um usuário que usa a plataforma há quase 10 anos.

Sobre seus cancelamentos, tome muito cuidado ao testar coisas em produção, meu e-mail pessoal foi banido do pagseguro sem direito a esclarecimentos, e olha que tive contato com gerentes pessoalmente. Mas creio que foi justamente por isso, eu testava com meus cartões e meu e-mail, depois estornava e etc. Tente a mesma operação em outro ip e com outro e-mail, aliás o pagseguro é muito chato com dados informados, verifique sua data de nascimento e coisas deste tipo, porque a verificação destas informações é só feita após a finalização.

lenivene commented 4 years ago

@alecshoppe sobre o hash poder ser um IP, eu não sabia.

Sobre fazer testes em produção, eu já desisti, nenhuma transação é aprovado, as únicas que passa, é pelo próprio site do pagseguro, aquela que eles geram um LINK para você usar o próprio site deles.

Os mesmos dados que eu usei para fazer as compras via API, eu usei os mesmo dados no site.

alecshoppe commented 4 years ago

@lenivene Estou terminando uma integração de checkout transparente e uma de recorrência transparente, quando terminar te falo se está funcionando 100%. Mas posso adiantar que o outro checkout transparente que tenho está funcional. Ele é web e segue os padrões da documentação. Sobre os testes em produção, testou com outros e-mails, pessoas, cartões, pcs?

lenivene commented 4 years ago

@alecshoppe Sim, já testei com tudo. Pc diferente, cartão diferente, email e etc. bizarro

Para tu ter uma ideia melhor do bizarro: Eu instalei um WordPress e coloquei os plugin de WooCommerce + PagSeguro e configurei tudo certo e não VAI.

A compra passa e depois cancela.

É tipo assim: Compra aprovada -> Compra cancelada

valterh4ck3r commented 3 years ago

Estou implementando e passei por isso nesse momento.

lenivene commented 3 years ago

Estou implementando e passei por isso nesse momento.

Fala @valterh4ck3r , blz? Teve algum sucesso ai? Eu chutei o pau da barraca e parti pra outros gateway e foi a melhor escolha que fiz, já que suporte para dev do PagSeguro é uma merda.

valterh4ck3r commented 3 years ago

Olá @lenivene , sim eu consegui fazer da seguinte forma:

Você deve enviar da seguinte forma o objeto no backend.

https://gist.github.com/valterh4ck3r/1bf974ce537c663fd8f77d602fd15bbd

sender.hash

lenivene commented 3 years ago

Fala @valterh4ck3r, blz? Eu fiz o mesmo, inclusive seu object tá igual, mas eu acho que no meu caso, o problema era conta. Por que eu cheguei a utilizar códigos prontos, como Woocommerce + Pagseguro e não funcionava.

É bizarro!!! Inclusive um colega meu já usava e quando fui configurar pra colocar no meu código ou no woocommerce, a conta desse meu colega, parou de funcionar também.

É como se tivesse levado algum tipo de block, talvez por ip.

alecshoppe commented 3 years ago

Bom deixar claro aqui para os devs que vierem a implementar com o PagSeguro mesmo com os problemas já citados. Leve em consideração essa frase genial, aconteceu a mesma coisa comigo após o Pix:

Fala valterh4ck3r , blz? Teve algum sucesso ai? Eu chutei o pau da barraca e parti pra outros gateway e foi a melhor escolha que fiz, já que suporte para dev do PagSeguro é uma merda.

Mas se você tomou a decisão que mesmo assim será seu gateway lembre-se:

Vários devs já relataram que sofreram blocks, pode não ser um problema no seu código: O meu block por exemplo foi no meu e-mail principal mas provavelmente pode vir de várias outras formas como ip, browser, domínio. No meu caso a minha empresa tinha gerentes físicos que iam para reuniões, me encaminharam para o suporte, o suporte me encaminhou para os técnicos e depois de alguns dias obtive a resposta que essa minha conta com este e-mail foi banida do PagSeguro e o motivo não pode ser esclarecido para mim.

Creio que tenha sido por causa dos meus testes em produção, que são inevitáveis: O PagSeguro usa um sistema de Sandbox bem desacoplado da api de pagamentos real com urls diferentes, tokens diferentes e você vai ter que testar em produção com cartões da empresa. No meu caso lembro de ter feito uma sequência de pelo menos 20 testes e devoluções até confirmar a funcionalidade de tudo.

Se o objetivo é recorrência, ambiente nativo ou pix.. não recomendo.

symonlopes commented 1 week ago

Para qual gateway de pagamentos vocês migraram ?