Histórico de mensagens sobre integrador em sugestões

Na verdade, a ideia é que o integrador não precisa usar tantos comecaCom ou terminaCom...

Não jogar essa responsabilidade para o integrador.

Pessoal, acabei de passar por uma situação aqui com a API de envio de PIX.

Aqui na Xerpa temos um produto que oferece antecipação salarial. Os colaboradores fazem "saques" do salário a qualquer dia/hora.

Fizemos um lançamento interno aqui e API falhou bastante. Motivo: múltiplos saques simultaneamente.

Segundo o <@!671762828046106646> a API de envio de PIX só pode receber uma requisição por vez.

1. Gostaria de confirmar esse entendimento. É uma requisição por vez? Isso é limitante demais!
2. Podemos discutir uma forma da serialização ser feita por parte da GN e não do integrador?

No caso de implementar no ato do callback, eu tô pensando mesmo é em deixar o integrador desativar de vez, se assim permitir a spec.

Integrador precisa validar por exemplo se o webhook é de test ou transacional para enviar o x-mtls-check da forma correta.

e o integrador tb pode "só enviar um header e pronto" na hora que recebe o callback, da mesma forma.. qual a dificuldade?

Eu acho que isso demanda demais configurações para o script, algo um pouco desnecessário. O modelo da GN é bem mais fácil o qual o integrador só envia no header e pronto.

isso dá mais flexibilidade pra um integrador que recebe os webhooks de ligar/desligar o mTLS bypass sem interferência no script que tá fazendo o envio do PUT

hoje:
- GN envia "callback" simulado sem certificado (se for aceito pelo integrador, é uma falha; dá "break" aqui)
- GN envia "callback" simulado com certificado (que deve retornar 200)

poderia ficar assim:
- GN envia "callback" simuilado sem certificado:
--> se receber de volta 200 + um header x-mtls-bypass: true, tá ok e dá break;
--> se receber de volta 200 sem o header, é falha e dá break;
--> se receber de volta 4xx, segue adiante
- GN envia "callback" simulado com certificado (que deve retornar 200)

Como assim <@!522899003663450113> ? A validação durante o cadastro continua. Opcionalmente o integrador fará um "bypass" desse recurso, se achar necessário. De resto, continua tudo como está.

Enfim, tornar a validação opcional não resolve 100% do problema, mas abre caminhos para que o integrador consiga resolver.

Desabilitar o check mas ainda exigir mTLS nas efetivas notificações ajuda em algo o integrador com problemas em ambientes compartilhados ?

basicamente.. o Itaú tá usando QR estático para um cenário onde deveria estar usando dinâmico. apenas se pouparam de ter que oferecer a leitura de qr codes via payload. deixaram todos os dados da cobrança a cargo do integrador, guardando somente a associação txid <-> valor, e rejeitando o que não coincidir

Pessoal, gostaria de opiniões e sugestões em cima desse desenho de endpoint:

PUT /config

Objetivo: permitir que o integrador controle alguns comportamentos. Por hora: receber ou não webhooks, receber ou não a tarifa cobrada como atributo na notificação do webhook, setar uma regex que será considerada na validação do txid.

A respeito do discutido em https://discord.com/channels/775322853884821504/775328670784159744/796748024566120519:

A GN poderia oferecer na parte de API > Aplicações, uma opção para compartillhar os direitos de acesso à essa aplicação com um integrador parceiro por dentro da plataforma da GN, que poderia ver o client_id e client_secret e solicitar certificados.

Assim não dependeria do cliente fazer o processo de obtenção de credenciais, solicitar certificado, receber senha por SMS (que tem período de validade relativamente curto - 4 horas) e depois encaminhar tudo isso pro integrador por fora do sistema.

então vazios e estáticos vão para o teste de regex, e aí o integrador decide o que fazer

a ideia é testar se o regexp do integrador admite txid "vazio"

Não deveria ter um segundo condicionante antes de jogar para a regex do integrador, que verifique se o txid tem 1-25 caracteres? Pois se passar txid com 26-35 (que deveria ser relativo a uma cobrança) para o regex do integrador testar (sem haver uma cobrança), significa que o payload foi manipulado/mal-interpretado/etc...

Pessoal, o que acham dessa proposta? A ideia é dar mais liberdade ao integrador na decisão de aprovar ou não um Pix.

Bom dia Renato! Faz sentido sim, mas estamos deixando os integradores colocarem seus projetos relacionados ao Pix para que o canal possa crescer e a comunidade interagir cada vez mais. Qualquer mudança nas regras relativas a este tema vamos avisar a todos. Muito obrigado pelos seus feedbacks, eles auxiliam na melhoria da nossa plataforma e neste servidor.