Termos mais procurados:
Notar que do envio x recebimento você nem precisa olhar a chave... apesar disso ser prudente por questões de segurança. Mas para recebimento (e devolução de recebimento) mapear o handler de recebimento na configuração do webhook, e no de envio, mapear o de tratamento de eventos de Pix enviados.
De fato. Ainda me parece um pouco invertido o caminho, pois apesar de eu ter salvo no meu bd que uma devolução foi solicitada, o controller que recebe esse payload ainda não sabe disso. Então é como se eu precisasse primeiro hidratar o meu handler com contexto sobre aquele evento antes de poder tratá-lo, agregando dados de uma ou mais tabelas pra daí poder prosseguir (não que isso seja um grande problema). A sugestão que você deu sobre as chaves serem os discriminantes é um exemplo disso: primeiro eu tenho que puxar minhas chaves e aí mapear o evento.
Posso estar complicando demais, pois ainda não comecei a implementação, mas não está muito trivial arquitetar isso com o meu patinho de borracha 😅 .
Por acaso vc conhece algum repo aberto com um exemplo bacana de implementação?
Agora, de devolução o mais simples é o seu handler saber que uma devolução foi solicitada, já que é você que solicita... não vai vir de surpresa uma devolução. Então se o Pix x teve uma devolução solicitada, ou uma nova devolução solicitada (pode haver mais de uma devolução para um mesmo Pix), aí se observa o campo de devolução.
A devolução é uma atualização do mesmo objeto. Antes ele não tinha devolução, agora tem. Notar que uma devolução só acontece quando você pede, não quando o cliente pede... então de qualquer forma você nem precisaria de atualização assíncrona no webhook se a devolução sempre desse certo. Mas como pode não dar certo, por isso há uma notificacão da mudança de estado.
@rubenskuhl , o que quero dizer é que, programaticamente falando, como você diferenciaria um evento de recebimento de um evento de devolução, por exemplo?
Pelos prints, vc pode ver que o conteúdo de um evento de recebimento é um subconjunto do conteúdo de uma devolução, e parece que esse é o único critério que eu consigo usar para diferenciá-los.
A taxa pela transação não é reembolsada. Por outro lado, não há cobrança pela devolução como se fosse um envio de Pix, como há em alguns PSPs.
estou justamente nesta parte e já me deparei com algum erro de lógica aqui:
if(isset($dadosrecebidos['pix'][0]['gnExtras']['tarifa'])){
//FAÇA VERIFICAÇÃO DE PIX COM TARIFA
}else if(isset($dadosrecebidos['pix'][0]['gnExtras']['idEnvio'])){
//FAÇA VERIFICAÇÃO ENVIO DE PIX
}else if(isset($dadosrecebidos['pix'][0]['devolucoes'])){
//FAÇA VERIFICAÇÃO DE DEVOLUÇÃO
}else{
//FAÇA VERIFICAÇÃO RECEBIMENTO
$dadosUpdate = array(
"endToEndId" => $dadosrecebidos['pix'][0]['endToEndId'],
"payment_status" => 'finished',
"on_off" => 1
);
O envio de Pix você pode separar dos recebimentos colocando em outra chave Pix. A separação de devolução de pagamento é necessária nos 3 métodos, e precisa ser implementada de qualquer forma...
Sim, o webhook é melhor, porém não é muito elegante fazer if() para saber se é uma devolução, se é um pagamento, se é um envio de pix. Eu mesmo ainda não finalizei essa parte por conta desse retorno que não retorna tipo nem status....os GET's seriam uma melhor solução para mim. Mas preciso usar os webhooks.
Pra não ter duvida,o id que vai atrás de devolução não é o txid né? Pois se eu for fazer 2 devolucao ele fala qur tem que ser único
Boa noite, @ftgk
O erro 422 no _endpoint_ de devolução está atrelado a algumas possibilidades:
1. Identificador inválido;
2. _Status_ de pagamento inválido para devolução;
3. Valor de devolução superior ao valor recebido;
4. Saldo insuficiente.
O webhook é configurado por chave Pix, e acionado para qualquer pagamento que tenha um txid ou evolução da situação de devolução caso você solicite devolução.
O que você pode configurar é a conta para não aceitar transações que não pagamentos... por exemplo, recusar Pix por dados bancários e Pix por chave. (
/v2/gn/config)
O webhook é acionado sempre quando há alguma alteração na cobrança Pix. Então você recebe a notificação quando for paga, e se tiver devolução.
Então ao receber a notificação com os detalhes em Json, sua aplicação poderá tratar estes dados.
https://dev.gerencianet.com.br/docs/api-pix-endpoints#recebendo-callbacks
Boa tarde @vinixdl ! Em nossa documentação, na descrição dos endpoints, você encontra os possíveis status. Mas resumidamente:
- Cobrança Pix "ATIVA", "CONCLUIDA", "REMOVIDA_PELO_USUARIO_RECEBEDOR", "REMOVIDA_PELO_PSP"
- Envio de Pix: "EM_PROCESSAMENTO", "REALIZADO", "NAO_REALIZADO"
- Devolução: "EM_PROCESSAMENTO", "DEVOLVIDO", "NAO_REALIZADO"
Pessoal, boa tarde. Estou tomando um 500 ao tentar solicitar a devolução de um pix com split. Sabem me dizer se isso não é suportado?
