Histórico de mensagens sobre regras em pix

As regras se aplicam usando nossas SDKs também @wesleyalmont 🙂

Boa tarde @wesleyalmont tudo certo?
Basta criar as cobranças seguindo as seguintes regras:

Para o Envio de Pix, endpoint PUT /v2/gn/pix/:idEnvio :

Se o valor do Pix está entre R$ 0.01 à R$ 10.00:
Pix é confirmado, informação virá via Webhook.
Se o valor do Pix está entre R$ 10.01 à R$ 20.00:
Pix é rejeitado, informação virá via Webhook.
Se o valor do Pix é acima de R$ 20.00:
Pix é rejeitado já na requisição, informação não virá via Webhook.

Para COB e COBV:

Se o valor da cobrança está entre R$ 0.01 à R$ 10.00:
A cobrança é confirmada, informação virá via Webhook.
Se o valor da cobrança é maior que R$ 10.00:
A cobrança permanece ativa, sem confirmação. Como não há webhook nesses casos, nada é feito.

Mensagem removida por não respeitar as regras da comunidade.

Lembrando que não necessariamente você queira remover a cobrança expirada... aí é regra de negócio, você pode querer extender a expiração sem o pagador pedir, você pode querer extender a expiração se o pagador pedir. A Efí só cobra por efetivo recebimento então na conta vai dar igual, mas a sua arquitetura e regras de negócio vão indicar uma alternativa preferida. Senão, jogue um d20 e deixe ele escolher...

Na verdade não é a Efí que precisa validar mTLS, é você. o skip-mTLS só desliga um teste que a Efí de se você está validando... mas você tem que validar de qualquer forma para estar de acordo com as regras do Banco Central.

Boa tarde @alexandrecosta1735 tudo certo?
O skip-mtls seguem as seguintes regras:

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;

Não, me refiro em montar offline o qr code de acordo com a especificações técnicas e de negócio do ecossistema do pix no
Anexo I –Padrões para Iniciação do PIX seguindo as regras de formação da URL que são definidas na seção 1.2.3.1

Isso. Gerada em homologação não dá para pagar.

Mas você tem um webhook registrado em homologação, seguindo as regras você recebe a notificação do "pagamento".
Se o valor da cobrança está entre R$ 0.01 à R$ 10.00: A cobrança é confirmada, informação virá via Webhook.
Se o valor da cobrança é maior que R$ 10.00: A cobrança permanece ativa, sem confirmação. Como não há webhook nesses casos, nada é feito.

Operar sem supervisão do Banco Central, as tarifas que ele cobra, dar a entender que atende todos os meios de pagamento... mas os arranjos como boleto e cartão tem regras diferentes, com regras que permitem e disciplinam como operar. Mas ainda assim muitos mesmo em boleto e cartão violam um dispositivo geral do sistema de pagamentos brasileiro que é deixar claro quem é a instituição regulada responsável. Então a Efí poderia por exemplo autorizar operadores desse tipo, mas dando a cara para bater e sem os controles de compliance que internamente ela tem e enforça.

A checagem que a Efí é só um conforto para você saber que está tudo certo. Mas a responsabilidade é sua de seguir as regras... o que o parâmetro faz é desabilitar a checagem, mas você precisaria fazer a checagem mTLS de outro jeito. Por exemplo com seu provedor de hospedagem passando via headers qual o certificado cliente que foi apresentado.

Bom dia, @nckex!
Você pode utilizar o endpoint PUT /v2/gn/config para definir que a recusa de QR Code estáticos. Mas não é possível recusar de um txid específico.

Para recusar QR Code estático, informe true no parâmetro qrCodeEstatico->recusarTodos

As regras banindo certificados wildcards estão desde a primeira edição do manual de iniciação que continha a API Pix.

Segui o tutorial do Daniel Cioffi, mas pelo visto ele já está desatualizado e não funciona mais com as novas regras do gerenciaNet. Um novo tutorial de como criar esse novo certificado via AWS e como integra-lo ao WebHook seria muito bem vindo.

Aproveitando para explicar um pouco sobre algumas regras dos webhooks da API Pix.
@rubenskuhl @quirino_diogo6784 @diton89

As notificações são disparadas, geralmente, até 6 vezes.

Caso a primeira tentativa falhe, nós tentaremos novamente após 5 minutos. Caso a segunda também falhe, tentaremos novamente após 10. E por aí vai até a 6ª tentativa, numa PG de 2.

Se em algum momento dessas tentativas o servidor do outro lado retornar 429, nós vamos tentar 10 vezes, ao invés de 6.

Assim como as regras de cartão são estabelecidas pelas bandeiras (Visa, MasterCard etc.)

Receber isso em HTTP violaria regras de segurança do Pix...

E se a instituição não respeita o regulamento, ela também pode decidir que regras e leis mais ela quer seguir ou não.

Boa noite <@!764685636384456755> tudo bem? 🙂
Uma vez que o mTLS estiver configurado, ele previne que qualquer outra requisição que não seja da Gerencianet envie uma requisição contendo uma confirmação de pagamento falsa para seu sistema.
O parâmetro x-skip-mtls-checking segue as regras:

A Gerencianet, assim como outros PSPs, tem acesso limitado ao DICT, que é o serviço do Banco Central que é como um DNS das contas que relaciona chaves Pix com dados bancários. Eles só podem fazer consultas que em sua maioria resultem em transações, senão são penalizados com rate-limit. Se você precisa de acesso direto ao DICT, você pode aderir diretamente ao Open Banking como Iniciador de Pagamento e depois ao Pix como Iniciador de Pagamento. Aí você acessa o DICT na sua própria credencial e passa a responder diretamente pela obediência às regras de uso do DICT.

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