Histórico de mensagens sobre possível em sugestões

É possível também criar novas chaves Pix do tipo aleatória e excluí-las também.
https://dev.gerencianet.com.br/docs#section-criar-chave-evp
https://dev.gerencianet.com.br/docs#section-remover-chave-evp

É isso mesmo. Eu só descreveria de outra forma pq sem txid e sem a informação do método de iniciação de pagamento, saber se era um QR dinâmico, um QR estático ou um Pix via chave é impossível... ao menos até que isso venha na PACS.008 como está planejando o BACEN. Acho que só o Pix manual vem diferente.

5º - Se a opção "Habilita o checkout em um passo" está desabilitada na configuração do plugin, e o valor do pedido for inferior a R$ 5,00 fica impossível seguir para a parte de gerar o QR Code

seria possível o tempo de execução ser medido também em produção? desarmaria o validador de txid se estourar o prazo de validação X vezes dentro de Y tempo

<@!370847985199742977> eu acho que é possível dar uma simplificada no input, de forma que, no final das contas, não importa se o backend trata o match com ifs ou glob ou até uma "regex confiável"

Não vi necessidade de serem múltiplos, pensei em ser um só. Porém, é possível aceitarmos múltiplos e aplicarmos OR ou AND entre eles, se vocês virem como positivo.

Pessoal, eu pago alguns boletos gerado pelo Gerencianet, não seria possível que o pagamento do boleto fosse dado baixa automaticamente quando o boleto fosse emitido pela Gerencianet? Entendo que o boleto foi emitido pelo banco e que tem todo o fluxo bancário, mas seria interessante uma confirmação na hora sempre que pago pelo sistema da Gerencianet.

esclarecendo melhor essa pergunta: é possível saber se o EC tá exigindo o mTLS ou se tá ignorando (no próprio callback individual, não em teste prévio)?

e do lado de vocês, é possível "exigir o mTLS" pra decidir se os dados devem ser enviados (no momento do callback em si)?

talvez com um contrato específico, como você falou antes + a retirada de informações do callback (deixar só chave + txid se houver), aí o EC teria que consultar a API, creio que seja possível o BACEN aprovar

"mexer o menos possível no PUT"? mas quem tá propondo a mudança no PUT não sou eu 🤔

Sim, entendi o seu ponto. A questão é mexer o menos possível no PUT, nesse momento. Sem remover funcionalidades dele, mas dando uma flexibilizada. Certamente voltaremos a falar do callback.

se vc quer recusar absolutamente tudo que não for cobrança, é só colocar no seu regex qualquer dado impossível de existir em forma de txid, como ^-$ que nunca vai passar por ele.

Sugestões para a parte de marketplace:(https://gerencianet.com.br/solucoes/#marketplace)
- Opção de repassar por Pix ao invés de só para contas Gerencianet independente do modo de pagamento
- Opção de fazer split também de recebimento Pix, usando os métodos discutidos no GitHub do BACEN para maior proximidade de um possível padrão futuro

Report de bug:

Os payloads de cobrança pagas estão retornando um JSON contendo erro: "status_cobranca_invalido", mensagem: "A cobrança não está mais com o status ATIVA". Assim, os apps dos PSPs pagadores estão apresentando "erro ao ler o QR".

O payload deveria continuar sendo retornado no padrão JOSE (com certificado e assinatura, igual as cobrança ativas), com o status alterado para CONCLUIDA, para tratamento adequado, conforme status + possível presença do template 01 com valor 12 (qr code de apresentação única).

"a)Fase 1 – até 01/02/2021: Canais de atendimento, produtos e serviços mais relevantes, como contas de depósito à vista e operações de crédito;

b)Fase 2 – até 15/07/2021: Cadastros e transações de clientes relativas aos produtos e serviços da fase 1;

c)Fase 3 – até 30/08/2021: Serviços de iniciação de transação de pagamentos e encaminhamento de proposta de operação de crédito;

d)Fase 4 – até 15/12/2021: Outros produtos, serviços e transações de clientes, como operações de câmbio, investimentos, seguros e contas-salário."

Eu tenho impressão que na fase 1 tem só a tarifa máxima mesmo. Mas um possível pedido seria seguir o mesmo layout do OpenBanking de tarifas públicas disponível via interface autenticada.

a falha de segurança não existe se a GN valida que apenas requests com mTLS serão respondidos, Rafael. entendo que você queira sugerir um exemplo onde o ssl_verify_client seja on, mas isso só é possível em server {} exclusivo para webhooks. o exemplo dado é para um server {} onde requests de webhook (mTLS) e outros requests coexistem, e não há nada de inseguro nisso, especialmente depois de passar por validação.

é recomendado usar ssl_verify_client optional; o que é uma possível falha de segurança