Termos mais procurados:
No link a seguir, você encontra uma tabela contendo todos os dados sobre os parâmetros passados para o endpoint. Como obrigatoriedade, tipo e regras de criação
https://dev.gerencianet.com.br/docs/api-pix#section-criar-cobran-a-
Caso seja utilizado o endpoint "Criar cobrança imediata", não é necessário informar o txId. Nesse caso ele é gerado pela API.
outra duvida o {txid} é um numero q eu gero randomicamente.. seguinto as regras... ? e qual a diferenca deste endpoint /v2/cob/{txid} (Criar cobrança) para este endpoint? /v2/cob (Criar cobrança imediata)
A crítica das regras EMV/BRCode/Pix varia mesmo conforme a IF/IP. Mas tendo erro, fatalmente vai dar problema.
@Efí como faço para saber qual taxa foi cobrada em cima da transação liquidada do pix? eu sei que tem as regras lá no site, mas supondo que isso mude, a "fee" deveria vir no callback da confirmação/devolução, não? em último caso, talvez estar disponível ao consultar o pix recebido
(eu li a discussão nas sugestões, deu a entender que querem colocar no postback do webhook, será isso mesmo?)
<@!781134406680838216> como faço para saber qual taxa foi cobrada em cima da transação liquidada do pix? eu sei que tem as regras lá no site, mas supondo que isso mude, a "fee" deveria vir no callback da confirmação/devolução, não? em último caso, talvez estar disponível ao consultar o pix recebido
Depende!
No meu cenário a regra seria: não tem txid = não entra; tem txid = entra. Pois também vou trabalhar com estáticos.
Então o ideal mesmo seria um ajuste fino das regras (e por chave, de preferência), com seletores no painel:
Ai complica, seria muito bom se este processo de certificados e tudo mais ficasse na responsabilidade da GN, ai só iriamos consumir a API da GN e não fazer uma ponte entre GN e Banco Central.. Não sei como é todas as regras mas está me parecendo que estamos indo direto no Banco Central para pegar estas informação...
cara, tem 2 regras:
- o campo 63 precisa ter 4 caracteres
- o CRC16 é calculado em cima de toda a string (incluindo 6304)
então o certo é comparar seguindo a norma:
- pega a string e retira apenas o valor do campo 63 (mantém 6304)
- calcula o CRC em cima do que sobrou
se o CRC do que sobrou é "924" (ou "0924", dependendo da função que vc use pra calcular o CRC já é normal o "0" à esquerda estar presente) o valor do campo tem que ser considerado um "match"
- se algum PSP não considerar a string com "0924" match, tá errado
- se algum PSP considerar a string com "924" match, também tá errado (pq o campo tem que ter 4 caracteres e essa regra já estaria quebrada independentemente do teste de CRC)
Em prol do grupo exatamente! e não de suas próprias conclusões sobre o que é ou não é o certo ou o errado.
Assim, o pessoal da GN são 100% e sabem conduzir as coisas, este é um grupo onde podem surgir esporadicamente alguns assuntos que possam ser levados ao off-topic e vice versa.
O que não dá é um sujeito se achar o "rei da cocada preta" e se intrometer em tudo com autoritarismo.
Tá insatisfeito, ofendido, ou acha que alguém violou as regras?
Aciona os Admin e não fica dando indiretas como uma criança cheia de mimimi, isso é pior do que assuntos paralelos.
Pessoal, como a comunidade está crescendo, elaboramos algumas regras para deixar o ambiente ainda mais produtivo e agradável para todos. Pedimos que visitem o canal <#📋regras> e se atentem às boas práticas! 😊
E mesmo em cobrança com vencimento, ele precisa ser algum valor plausível dentro das regras de cobrança... maior ou igual ao valor sem juros, caso não haja desconto.
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!
Rafael, se o seu hostname é webhook.example.com (e ele tem o ssl_verify_client on) enquanto o host example.com não tem nenhuma exigência, eu posso dizer que é "quase mTLS"? Acho que não. Vc vai argumentar "são hosts diferentes, com regras diferentes".
Então se eu tenho um único server {} para o hostname example.com, que aceita requests com/sem mTLS, e valida dentro de um location /webhook, por que o request para /webhook é um "quase mTLS" enquanto o "/" aceita requests sem mTLS? O meu argumento contrário é que "são locations diferentes, com regras diferentes" 😉
<@!780500321994539068> Mas a da OpenPix não compara com regras do BRCode, por exemplo ele vai mostrar o campo 62 05 com 35 caracteres quando o BRCode limita a 25 caracteres
Vamos corrigir!
Seguem mais ferramentas de decodificação de EMV caso se acredite que o https://pix.nascent.com.br/tools/pix-qr-decoder/ não esteja fazendo certo
https://openpix.com.br/qrcode/scanner/
https://openpix.com.br/qrcode/debug/
Mas a da OpenPix não compara com regras do BRCode, por exemplo ele vai mostrar o campo 62 05 com 35 caracteres quando o BRCode limita a 25 caracteres
Mas como vamos usar a biblioteca de EMV que sugeri acima e código nosso seguindo as regras do BR Code e do Pix, não é blocante. E eu sugiro fazer o mesmo... essa geração não é parte da API do BACEN, então de qualquer forma já não é portável.
https://github.com/dongri/emv-qrcode pode ajudar a montar o EMV, mas você que precisa seguir as regras do BRCode e do Pix, como colocar 62 05.
