dev-gto

Bom dia, > Particularmente, em nenhum momento foi definido que *** é obrigatório em um BRCode. É verdade que no manual do BR Code não consta o `***` como obrigatório,...

A documentação do ManualBRCode v2.0.1 (em particular na tabela 1, página 10) omitiu os tipos dos campos definidos na norma EMV. https://www.bcb.gov.br/content/estabilidadefinanceira/spb_docs/ManualBRCode.pdf Minha sugestão é seguir o que está na...

@dmkamers: verdade, o grupo de caracteres ficou ainda mais restrito no BR Code #197 Nomes Fantasia com `&` precisarão de tratamento, creio

> Não entendo qual seria a relação da devolução com essa operação específica. Perdão pela confusão, o termo que me referia é cancelamento/estorno da transação. No contexto do cliente recebedor,...

> Não há Pix a ser cancelado/devolvido se o pagamento nunca aconteceu. Entendi, então a cobrança, se tiver um vetor de pix populado, é porque foi pago (ainda que parcialmente)....

> Se houver recebimentos, não tem como cancelar a cobrança. Ela já estará com status CONCLUIDA a partir do momento que entrar um Pix relacionado a ela. Só precisa devolver...

> O BACEN não foi incisivo o suficiente na documentação (e nem aqui no GitHub), no princípio, para deixar claro que uma cobrança não pode ser paga com valor inferior...

> Se tem Pix, ela sempre estará concluída (assim como um boleto pago, está sempre pago/baixado e não se pode cancelar o boleto, neste caso). Entendo que não dá para...

> > Veja, quem implanta o sistema de cliente recebedor eventualmente levantarão as mesmas dúvidas que tive: como cancelar apropriadamente uma transação (e aí incluem-se ambos cobrança e pix) >...

> A possibilidade de múltiplos Pix no array decorre não de uma única transação, mas de situações de alto tráfego de um EC. Se vier mais de um Pix na...