Histórico de mensagens sobre cursos

ainda que não gere prejuízo financeiro, pode gerar aumento de consumo de recursos (tecnológicos e humanos)

Acredito, apesar de ser uma possibilidade, que essa não é a melhor prática. O webhook otimiza o uso de recursos tanto do seu quanto do lado da GN, além de garantir a instantaneidade que o Pix traz como proposta.

Sobre este serviço de mTLS proxy: era planejado cobrar, mas o consumo de recursos é tão irrisório que o serviço continuará sendo oferecido de forma gratuita, indefinidamente.

Joel, muito obrigado pela atenção. No momento, estou tentando me familiarizar com os recursos do Gerencianet ainda. Num primeiro momento, apenas tentar gerar um QR CODE para permitir o pix e/ou fazer um pix direto para uma conta de dentro do meu site em php

Boa tarde. Estou tentando subir um teste em php para ver o funcionamento dos recursos do PIX do gerencianet

Bom dia <@!812297338605273098>, respondendo ao questionamento que você fez no 2, sim é possível fazer o envio de Pix de sua conta Gerencianet para uma outra chave/conta via API. Para isto temos o endpoint POST /v2/pix (https://dev.gerencianet.com.br/docs#section-requisitar-envio-de-pix-) que permite o envio para uma outra conta via chave ou dados bancários.
Além disso via API você pode adicionar diversos recursos em seu site como cobranças estáticas e dinâmicas e fazer o controle via endpoints da API. Outro recurso interessante é o webhook que automatiza o seu sistema com os Pix recebidos, sem a necessidade de ter que construir uma rotina que fica realizando consultas na API. Você encontra tudo isso e mais na documentação e caso tenha dúvidas pode mandar aqui canal que te auxiliamos.

Pode ser que a GN venha a ter boleto híbrido, um boleto liquidável pelo código de barras CIP/COMPE e pelo QRCode Pix, depois que o Pix tiver recursos de vencimento/multa/juros para equiparação com o boleto. Precisa ver o que se adequa melhor ao seu caso de uso, mas hoje só está disponível a cobrança imediata Pix.

Não, é a Chave Pix da conta que receberá os recursos. O mais usual é criar uma chave aleatória para os recebimentos, mas pode ser qualquer dos tipos de chave Pix existentes.

Veja, mas quando o boleto é emitido pela GN e pago pela GN, poderia quebrar o fluxo bancário e funcionar somente como uma transferência de recursos, não?

aí você pode configurar seu nginx pra validar (e re-cadastrar a URL sem o x-skip-mtls-checking) ou fazer uma consulta à API pra verificar se o Pix foi mesmo recebido; o que vc achar melhor (a primeira opção exige menos recursos do seu servidor e da GN, além de ser marginalmente mais segura)

Sugestão: alinhar melhor com a equipe as informações a respeito dos [novos] recursos e exigências [removidas] para consumo da API Pix. Por ex: as informações a respeito da necessidade ou não de mTLS no PUT /webhook, bem como no recebimento dos callbacks, estão desencontradas lá no canal <#❖pix>. Tem membros da equipe GN dizendo A e outros membros dizendo B.

Boa tarde Diego, a nossa SDK em PHP em que o download é realizado por meio do composer não tem as funcionalidades da API-Pix. A SDK que disponibilizamos em PHP tem os recursos necessários desde gerar uma cobrança a emitir o QRCode(https://github.com/gerencianet/gn-pix-sdk-php-exemplo).

O Renato mostrou alguns conteúdos bacanas de desenvolvedores que podem te auxiliar. Vamos atualizar as nossas SDKs e em breve vai ser possível emitir um boleto, cobrança de cartão e Pix utilizando a mesma SDK.

Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.

E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.

É necessário que o Pix se comporte de forma alinhada aos recursos que temos no boleto, para que o modelo hibrido seja coeso, como; desconto por pagamento antecipado, vencimento (considerando feriados locais), juros e multas...

Essa coesão já está desenhada pelo Bacen, a questão que precisamos que todos os PSP's leiam as informações corretamente. A Experiência do Pix mostrou que muitos PSP's levam algum tempo para fazerem suas partes. O Bacen sinalizou que em março todos os PSP's devem ter feito seus deveres de casa, momento que a Gerencianet sentirá confortável em disponibilizar a opção de pagamento por Pix em seus boletos.

<@!788406836813365248> O que eu posso concordar com você é que há, de fato, algumas inconsistências entre os exemplos que a GN mostra (como o que você apontou: não existe status "EM_PROCESSAMENTO"). E haviam alguns outros, mas estamos todos no mesmo barco e, conforme apontamos pra GN, eles logo corrigem. E, de todo modo, tem a documentação oficial do BACEN para ser o seu norte. Nada que está lá pode ser diferente na implementação da GN (exceto recursos que sejam adicionais na GN, como o envio de Pix a terceiros, que ainda não está regulamentado pelo BACEN).

Como é do BACEN sempre precisa de $. Mas ele tem mais recursos do que só $ que vão depender da criatividade.

exato, aqui faço validação do tempo, ai economizamos em tudo, principalmente recursos das maquinas nossas.

No caso do certificado, para facilitar a emissão e manutenção, uma vez que nem todos dispõem de recursos para tal, optamos pela geração dos certificados

estou concentrado nesses recursos da minha ferramenta https://pix.ae primeiro, que serão "Freemium". depois vou partir pra minha própria camada de consumo da API

Eu acho que não.. a última resposta que vi os recursos /pix ainda seriam implementados