Histórico de mensagens sobre dados em pix

a presença dos dados do devedor na cobrança não gera um campo "preenchível" na tela de pagamento para o pagador

o <@!374888688515022850> tá perguntando dos dados do devedor => opcionais. Funciona sem eles. Funciona com eles. Se incluir, o devedor da cobrança está identificado (e pode ser protestado se não pagar e for uma cobrança de produto/serviço já entregue/realizado, por exemplo);

acho que ele estava perguntando sobre os dados do recebedor (nome, cpf/cnpj) não o campo solicitação

estes são os dados do seu ultimo

Bacana Magno, usei o (string)

Para quem for ou vai utilizar o endpoint do webhook em produção do PUT da url de retorno, na documentação tem esta url https://api-pix-h.gerencianet.com.br/v2/webhook/:chave
Porém, para funcionar precisamos retirar os dois pontos antes da palavra" :chave" e claro a própria palavra "chave" ficando assim = https://api-pix.gerencianet.com.br/v2/webhook/---- no caso este é um exemplo com uma chave aleatoria, as demais chaves utlizem o que o manual recomenda 🙂 Substituir o por seus dados.

De qualquer maneira, mesmo informando o txid o retorno será um array, mas contendo um único objeto. Vale ressaltar que se escrever "txid" ou "txID" ou "TXID" no nome do parâmetro a GN vai retornar null. Só consegui retornar dados informando "txId" (com i maiusculo)

sim, se eu tiver os dados do seu cartão de crédito posso comprar...

Os dois, basta ter os dados, não faz diferença, quem vai validar a conversa é o mTLS, e ainda não sei para que ele serve.

Já que fiquei o dia baseado no exemplo de retorno do webhook que não serve para os testes com o postman, alguém tem um retorno válido de webhook que possa postar, por gentileza ( troquem os dados sensíveis), preciso apenas da estrutura do json, tendo em vista que não fiz nada em produção exatamente para poder testar tudo em homologação e depois só trocar o client id client secret e .pem . Esqueci até que ainda tem o error 403 forbidden no modo dev.

as URLs de location (payload JSON) hospedados no subdomínio qrcodes-pix-h (homologação) só estão abrindo de IPs brasileiros

Certo <@!783359762917752843>. Em relação ao getPayload() no montarBrCode, não será mesmo necessário.
Para Campo 59-nome do recebedor, foi inserido uma variável no config.json com o nome do recebedor irá utilizá-lo.
Para o txID, foi implementada a condição para preencher caso o QR Code seja dinâmico
E no valor foi realmente utilizando o valor que está em $dadosPix["valor"]["original"]

<@!775350441965649951> Ainda sobre o payload, o montarBrCode busca apenas o valor da transação, será que é necessário esse request ao getPayload mesmo?

Porque o nome é o do Recebedor...
o txid dinâmico é
e o valor é o mesmo em $dadosPix["valor"]["original"]

Retomando algumas dúvidas e questionamento aqui...
Como o Renato havia citado anteriormente, o campo 62 é obrigatório. Para isso seguindo nossa SKD, Magano, poderá informar o campo 62 da seguinte forma:

$txID = ($tipo === "dinamico") ? '' : $dadosPix["txid"]; // [opcional] Identificador da transação.
$aditional_data_field_template = '05' . preencheCampo($txID);
$payloadBrCode .= '62' . preencheCampo($aditional_data_field_template);

Boa noite. Quero propor uma mudança no Art. 1º da Lei 7.089/1983 (http://www.planalto.gov.br/ccivil_03/LEIS/L7089.htm). Ele determina que títulos com vencimento em sábados, domingos e feriados podem ser pagos no primeiro dia [útil] subsequente sem juros de mora.

Os PSPs (prestadores de serviços de pagamento) que estão implantando o recurso de cobranças Pix (com vencimento, regras de multa/juros, etc, similar a um boleto registrado) estão com uma dificuldade absurda de implantar isso por causa dessa lei.

A minha proposta é que a redação da lei seja atualizada para o que ela efetivamente propunha em 1983: que os títulos possam ser pagos no primeiro dia útil subsequente ao vencimento quando da impossibilidade de fazê-lo por indisponibilidade do meio de pagamento (ex: bancos simplesmente não podem acatar o pagamento de boletos aos fds/feriados pois não há processo de compensação nestes dias). O Pix é diferente e funciona 24/7/365.

Se a lei for alterada, quem gerar cobranças com possibilidade de pagamento por Pix + boleto, se o pagamento cair num feriado, o boleto continuaria pagável no dia útil subsequente sem juros. O Pix, no entanto, está disponível nos feriados normalmente, então se a cobrança for paga especificamente por Pix no dia útil subsequente ao vencimento, seria cobrado 1 dia de juros normalmente (em outras palavras: o conceito de dia útil/não útil deixaria de valer para o cálculo de juros no Pix - e qualquer outro meio de pagamento 24//7/365).

Pode parecer um retrocesso para o consumidor, mas simplesmente não existe um banco de dados com os feriados municipais de todo o país disponível de forma pública. Somente fontes não oficiais, pagas, que dificultam enormemente a gestão das cobranças e o correto acolhimento dos pagamentos por parte dos PSPs que trabalham com o Pix e encarecerão o uso do Pix para os PSPs e para as empresas, que repassarão esse custo para o consumidor. Detalhes: https://github.com/bacen/pix-api/issues/225 . Obrigado!

"Se preferir, você pode também receber os dados no formato JSON, bastando incluir o parametro "json=true" na URL:"

não vou dar código pronto, mas vou dar uma dica: monta um array único, com todos os dados que a string tem que ter (use como chave os ids dos templates). os templates que tiverem múltiplos campos dentro (26 e 62), devem ter 1 array como elemento (com os campos internos, novamente usando os ids como chave). depois, faz um laço no array externo e vai montando a string com tudo que encontrar (e não for uma string vazia).

É que o reference label é esse campo, essa norma server justamente pra não acessar a url e obter os dados, é uma "eliminiação prelimitar"

Bom dia a todos!
o campo 59 Merchant Name segundo o manual do BR Code Versão 2.0.1 deve conter TAM 01..25 nome do beneficiário/recebedor

Porém no SDK está:

$payloadBrCode .= ($tipo === "dinamico") ? preencheCampo($payload["devedor"]["nome"]) : preencheCampo($dadosPix["devedor"]["nome"]); // [opcional] Nome do beneficiário/recebedor. Máximo: 25 caracteres.

Ou seja pegando o nome do pagador no meu entendimento... Creio que na maioria da vezes maior que 25 caracteres.

Podem investigar?

Estou na SAGA DO PIX, Capítulo de hoje Webhook, Create no banco de dados da cobrança, montado e feito as relações, "FIZEMOS PROGRESSO" amanhã temos outro capítulo 🙂