Histórico de mensagens sobre regras

uma informacao a mais .. usei hj o insomnia .. coloquei as regras do proxy funcionou .. mas no codigo direto .. sem sucesso

Oi <@!177276428675448832> tudo bem? 🙂
O campo aceita ambos os valores, true e false.
Adição do header x-skip-mtls-checking no endpoint PUT /v2/webhook/:chave para permitir o cadastro de servidores webhooks sem validação de mTLS durante o consumo.
Regras explicadas:

Se o parâmetro não for enviado, iremos validar mTLS;
Se o parâmetro for enviado e valor igual à true, não validaremos mTLS ;
Se o parâmetro for enviado e valor diferente de true, validaremos mTLS;

Salientamos que a Gerencianet continuara a fornecer a comunicação com mTLS, ou seja, na comunicação da notificação nada mudou. O POST entre Gerencianet e EC continua enviando o certificado.

Para mais detalhes verifique o roadmap no link https://gnetbr.com/rke4baDVyd

Sabia que a solução Marketplace da Gerencianet também é conhecida como Split de Pagamento? A funcionalidade permite a divisão e distribuição dos valores recebidos em uma transação financeira entre várias contas Gerencianet, de forma automatizada. O usuário só precisa definir as regras de distribuição ao emitir a cobrança e a Gerencianet executa a divisão. Além disso, é possível utilizar o Link de Pagamento (para receber via boleto ou cartão de crédito) em conjunto com o Marketplace. A documentação está lá no portal do DEV. E se tiver dúvidas, chame a nossa equipe, aqui mesmo, no Discord.

BC aprimora normas para os cartões de crédito

Resolução tem como objetivo alinhar as regras das contas de pagamento pós-pagas e pré-pagas à regulação sobre a conta de depósitos (conta-corrente). https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=96

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)

Não, pois de certa forma estaríamos impedindo o recebimento de Pix, os casos onde ser quer bloquear os recebimentos são bastante específicos, oque justifica a configuração padrão de aceitar todos e opcionalmente criar regras de recusa

A crítica das regras EMV/BRCode/Pix varia mesmo conforme a IF/IP. Mas tendo erro, fatalmente vai dar problema.

Há 3 regras aplicáveis: do padrão EMV, do padrão BRCode e do Pix.

Confesso que não entendi o problema. Se algum PSP comete a atrocidade de enviar uma chave Pix em uma transação manual (com ag. e conta definidos pelo pagador), a GN tem duas opções:

1. tratar com base nas regras da chave enviada (segue a regra de aceite definida pra essa chave); ou
2. trata como manual (e a opção "receberSemChave" vai barrar, se o EC quiser).

Pensando na implementação lógica, o fluxo seria mais ou menos esse:

-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.

se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).

se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).

e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).

e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.

bom dia. voltando à questão do regex para aceitar/não os recebimentos com base no txid. alguém da GN pode me esclarecer quais os cenários específicos onde vocês visualizaram uma necessidade de aceitação com base em regex? que eu me lembre, essa ideia apareceu como como uma evolução da necessidade de barrar recebimentos com txid vazio. porém:

- para recebimentos de cobranças (QR dinâmico) o txid precisa ser correspondente a uma cobrança existente na GN ou ela já poderia ser descartada (independente de qualquer crivo por parte do EC); e
- para recebimentos de QR estático, é perfeitamente compreensível que a GN não tenha ciência prévia dos txid dos recebimentos mas não vislumbro problemas maiores que exijam uma validação do txid com base em critérios definidos pelo EC (somente o problema conhecido de pagamentos entrando sem txid).

então, eu pergunto:

1. já foi implementada a possibilidade de bloqueio de recebimentos de Pix sem txid (seja a nível de chave Pix ou de conta transacional)?
2. se não foi, a evolução dessa funcionalidade para algo baseado em regex (ou outras regras) não está atrasando desnecessariamente a implantação da função de bloqueio de recebimento sem txid?

Lembrando que esse bloqueio é essencial para os EC que precisam de 100% de assertividade na conciliação automática.

e provavelmente daria até menos trab para conciliar tantas regras de "comecaCom", "terminaCom" "E" "OU", etc

Sim. Então algo a documentar, caso seja único, é que pode-se usar a possibilidade de ter chaves distintas para ter regras distintas, caso necessário.

A separação por chaves continua existindo, cada chave pode possuir as suas regras específicas.

Como é um match de txid nulo nessa versão restrita ? Pq os casos de txid com regras de formação que tínhamos pensado se enquadram nas regras mais restritas (ou seja, atendem).

<#💼freelancer>: esse é um lugar para se conectar com desenvolvedores de todos os cantos do mundo que podem ajudar na sua integração. As indicações são livres e feitas pelos usuários, portanto, não passam por seleção da Gerencianet. Ressaltamos a importância de sempre verificar a integridade das partes que firmam um contrato, como maneira de resguardar a segurança de todos.

Fonte: <#📋regras>

E não só o BACEN faz isso, Visa e Mastercard tem regras extensas para proteção do arranjo como um todo, não só de bancos emissores, merchants ou titulares de cartão.

@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