Histórico de mensagens sobre possível

Sim.. só dei a dica porque aí você não precisaria depender da GN, dá mais trabalho, mas.. é sempre bom depender o mínimo possível de terceiros eheh

É possível enviar nas notificações de pix o campo infoAdicionais ?

mas o webhook, de qualquer forma (com ou sem o campo 01 com valor 12), teria referência somente a esse novo pagamento (pelo menos no caso da GN, que eu me lembre, as notificações são sempre individuais, assim como nos boletos). essa questão de poder unificar mais Pix numa só notificação, eu não sabia nem ser possível (o Rubens que mencionou agora)

aí, tem duas saídas:

1. confiar que o PSP vai acatar sempre apenas 1 Pix por cobrança e que virá só 1 elemento nos webhooks e consultas e tratar apenas a posição zero do array, sempre. consequência possível: o PSP acatar um segundo Pix pra mesma cobrança e vc terá que se matar pra debugar esses casos no futuro...

2. ler o array todo, tratar o elemento da posição zero e, se houver qualquer elemento adicional, acionar um alerta / marcar uma flag de problema / etc...

Tudo é possível quando ainda não se sabe qual é o problema...

PUT /v2​/webhook/:chave
na URL, ":chave" é a sua chave PIX na GN. Você consegue vê-la/gerá-la através do App da Gerencianet. Não é possível vê-la pelo site, somente pelo App

no body
"webhookUrl", você deve informar a url de callback do seu sistema, que irá receber as notificações de alterações de status da cobrança

> É possível uma transação falhar e ainda ser processada pelo sistema?
@reidoscoins se alguém souber sobre, agradeço.

É possível uma transação falhar e ainda ser processada pelo sistema?

Especulação minha, eu acho que há algum entrave relacionado ao financeiro.
Se a GN fizer tal filtro, seria possível receber todos os pagamentos via qr code estático, sem custo, e ainda fazer a conciliação, bastando para isso gerar qr code estático com txid.

entendi perfeitamente e, se me lembro bem, já foi sugerido pela própria GN (mas da forma que sugeriram, não seria possível receber qr codes estáticos, mesmo que tivessem txid). o filtro ternário seria $aceita = existe cobrança ? sim : não

<@!783359762917752843> quando você cria uma cobrança e vincula ela ao txid, então ela sempre receberá o pagamento viculado ao txid. Então isso não seria possível, como também a analise do cpf do pagador

Sim, eu sempre envio txid.. o que eu gostaria é que a minha chave não recebesse pagamento sem txid e nem se o cpf devedor for diferente do pagador, é possível?

Bom dia pessoal, parabéns pela plataforma e pelo suporte prestado! Tenho duas questões:

- Recebi o certificado, utilizei a senha para descompacta-lo e deu certo, no entanto, quando tento converte-lo em .pem (de acordo com o repositório PHP), dá um erro dizendo que a senha é inválida (digitei a mesma senha recebida por SMS e não deu certo). Preciso gerar outra senha?

- É possível gerar um QR code para enviar um PIX para uma chave externa? (BB, Itaú, Sicoob, etc..) ou só dá pra receber exclusivamente na minha chave PIX gerencianet?

Grato!

<@!783359762917752843>, verifiquei sim esta sua demanda.
Realizei vários testes, e constatei que realmente uma devolução realizada através do app, não é possível consultá-la através da rota /v2/pix/:e2eId/devolucao/:id

Acredito que isso acontece para evitar consulta excessiva. Pois para consultar a rota citada acima, necessita saber o id da devolução. Neste caso então, você não terá este id.

Com isso terá primeiro que realizar uma consulta na rota /v2/pix/:e2eId para obter o id da devolução, e nela você já possui todas as demais informações da devolução, não tendo necessidade de realizar outra consulta na rota /v2/pix/:e2eId/devolucao/:id

Mas de qualquer forma, levantamos esta questão para nosso time da API para melhor esclarecimento.

a validação de CRC é importante principalmente nos QR codes estáticos. pois um caractere lido errado pode ocasionar (extrapoladas as probabilidades, mas ainda é possível) um pagamento pro destinatário correto (verificável pelo pagador na tela do app) com txid incorreto (difícil ou até impossível de ser verificado, se não tiver essa referência fora do próprio QR pra ele conferir), ou recebedor + txid correto mas valor incorreto, etc...

nos QR codes dinâmicos o conjunto recebedor + txid + valor vem todo do payload, então se a leitura do QR for errada, vai carregar um conjunto todo diferente, o que é um problema muito menor

<@!783359762917752843>

estático, menor possível

um estático com chave email de 6 caracteres, [email protected] seria o menor brcode possível

monta um brcode com o menor tamanho possível (somente campos obrigatórios), com o valor mais curto que fizer sentido, e vc vai ter uma noção

Em relação ao ponto levantado: A realização de devolução de Pix via API é feita unicamente pelo Recebedor, não sendo possível que um pagador solicite o reembolso por este endpoint. No entanto, poderá ocorrer casos em que o Pagador não reconheça a trasação, ou entre em desacordo comercial com o Recebedor. Neste caso, o Pagador entrará em contato com a instituição de pagamento, e se dará início a uma averiguação, onde as partes serão comunicadas sobre o processo. O estorno pela instituição ocorrerá, ou não, após a avaliação do caso. No caso de uma devolução do valor pago, a transação não será realizada necessariamente via Pix.

<@!374888688515022850> a probabilidade de o CRC ter apenas 1 ou 2 caracteres é rara, mas ainda é possível. então o ideal seria vc fazer assim:

$hex = str_pad((string) $hex, 4, "0", STR_PAD_LEFT);