Histórico de mensagens em sugestões

Na verdade nem vai precisar atualizar o SDK, adicionando isso na API o SDK não vai sofrer interferência.

Se possivel assim que atualizarem o endpoint, sdk php, nos avisem, para eu poder voltar a utilizar o qr de vocês.

Realmente bradesco não estava pegando, fiquei umas 8 horas seguidas para gerar meu proprio QR já com a correção do Point of Initiation Method, ai funcionou de boa.

O <@!326311059759693826> utiliza o endpoint e não estava conseguindo receber os pagamentos.

Ótimo, alguma posição

Conferindo aqui 👍

<@!816632817441177600>

Sugiro que acrescente o "Point of Initiation Method" na geração do QRCode no GET /loc/:id/qrcode, alguns PSPs como o Bradesco não estão lendo o QRCode.

A melhoria já esta em nosso backlog! Jaja estará disponível. Muito obrigado pela sugestão

Sugestão seria: No link de pagamento, além do cartão e boleto, a GerenciaNet podia prover recebimento via Pix da conta. Seria fantástico!

1 dia de aumento de prazo é super de boa. até achei que fosse aumentar mais

Pessoal, bom dia.

Sobre a proposta puxada pelo <@!440035527127990273>, corroborada pelo <@!780500321994539068> e pelo <@!522899003663450113>, entendemos que se faz interessante no momento que estamos (antes da implantação). Na verdade, chegamos a discutir isso internamente mas acabou passando. Basicamente precisaremos alterar a nossa camada de comunicação da API, input e output.

Como resposta ao <@!742492546198143151> e sinalização de prazo aos interessados, já estávamos validando a solução desenvolvida, bem com toda a sua integração interna, mas alinhei com as frentes aqui e vimos a alteração como algo positivo e mais tranquilo de ser feito agora, entrando em produção se torna mais difícil.

Vamos fazê-la mas aumentamos em um dia a data proposta para a entrega, passando para quinta-feira (11/03).

Isso isso isso

Entendi. Então você tá apoiando por que é melhor pro EC e por que vai na linha da API do BACEN, apesar da minha sugestão ter sido motivada, principalmente, pela economia de recursos da GN para processar os dados em um formato que tenha as chaves pix como índice. Apenas motivações diferentes.

(E pela homogeneidade com a API padrão do BACEN)

É pela legibilidade que apoiei a idéia, vide acima.

é muito mais legível uma estrutura assim:

Você achar mais "entendível" um objeto não ter o seu identificador (a chave Pix) como índice e ser um elemento interno / propriedade do próprio objeto, só demonstra que você está aplicando um argumento válido (o formato deve ser entendível para quem vai consumir a API, concordo) num local onde ele não faz sentido (o formato que escolheram não é o mais entendível e não é prático de se trabalhar, mesmo do ponto de vista do EC).

Essa premissa não é verdade. Em geral a representação interna é estudada para melhor atendimento da missão, e a externa para melhor entendimento. Usar a mesma só se for por falta de pensar a arquitetura.