Histórico de mensagens sobre integrador

Boa tarde, <@!676542738455330828>. Sempre bom ter esses feedbacks de clientes como você, com certeza vai auxiliar outros integradores no futuro.

<@!616074678296903690> Houve um relato similar ao descrito por você, resolvido por um de nossos integradores. A solução encontrada por ele está descrita nessa mensagem: https://discordapp.com/channels/775322853884821504/775328670784159744/866698052123099167. Pode ser que te ajude! 😃

{
"created_at": "2018-04-03 07:33:30", // data da alteração do status do array "id 4"
"custom_id": null, // identificador da cobrança definido pelo integrador, se existir
"id": 4,
"identifiers": { // identificadores que representam a cobrança
"charge_id": 24342333
},
"received_by_bank_at": "2018-04-02", // data do pagamento da cobrança
"status": {
"current": "paid", // status ATUAL da transação: paid ("pago")
"previous": "unpaid" // status ANTERIOR da transação: unpaid ("não pago")
},
"type": "charge", // tipo da cobrança que sofreu a alteração (neste caso, "charge" quer dizer que a alteração ocorreu em uma transação)
"value": 6990 // valor que acompanha a alteração. Esta tag existirá quando a alteração for uma confirmação de pagamento, informando o valor pago que foi confirmado
}

E como saber o motivo de um banco estar recusando se o integrador conversa com o Bacen e não com os bancos?

nós geramos nosso EMV já, nosso integrador primário não gera então mesmo GN fornecendo, não podemos considerar no fluxo.

<@!671762828046106646> esse cenário existe? (os integradores diretos enviarem webhook de pix não pago)

Boa Tarde, estou avaliando integradores e gostaria de saber se é possivel fazer o split de pagamentos em cobranças recorrentes (Assinaturas)?

Bom dia, <@!330055572483473409>. Agradecemos pela dica!! 👏 Com certeza poderá auxiliar muitos integradores.

Boa tarde <@!89083132287938560>, o funcionamento do webhook está normal, não tivemos reporte de mais nenhum integrador e inclusive fiz um teste agora com 3 PSPs diferentes e em todos foi notificado com sucesso.

Pessoal, vejo que tanto no SDK PHP e como no Postman há o campo de "solicitacaoPagador" preenchido como uma informação que parece ser uma descrição do serviço. Por um erro de alguns PSPs houve uma tratativa errado do campo e alguns somente mostram ele sem requerer nenhum dado do usuário. A GN em sua documentação leva a acreditar também que o campo também serve para isso quando coloca "solicitacaoPagador" => "Cobrança dos serviços prestados."
Sugiro a modificação para algo como "solicitacaoPagador" => "Informe o id do produto", assim o integrador poderá entender com mais facilidade (mesmo que o campo em si já descreva a funcionalidade).

Muito bacana <@!89083132287938560> , com certeza seu vídeo vai ser de grande valia pra outros integradores! Muito obrigado por compartilhar com a comunidade de forma tão didática!!

Acredito que em seu caso esteja faltando tratar o /pix que incluímos no envio da notificação.
Exemplo:
Integrador cadastrou a url base https://gerencianet.com.br/, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.

Por exemplo:
Integrador cadastrou a url base https://gerencianet.com.br/, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix.
Integrador cadastrou a url base https://gerencianet.com.br/pix, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/pix/pix.
Integrador cadastrou a url base https://gerencianet.com.br/?id=0000x22, ao acionar o webhook uma requisição do tipo POST será enviada para https://gerencianet.com.br/?id=0000x22/pix.

Boam dia, <@!809817630856445982>
A data de nascimento é um parâmetro obrigatório somente nas cobranças via cartão de crédito. Isto para auxiliar no rastreamento de transações indevidas e proporcionar maior segurança ao integrador.
Mas levarei a demanda apresentada e reportamos a vocês qualquer novidade.

Não tem, mas vamos adicionar para que os integradores fiquem cientes. Obrigado pela sugestão.

Bom dia, pessoal! Como vão?
<@!689656729314656316> até o momento a rota POST /v2/gn/evp gera apenas chaves em produção, em vista de disponibilizar mais rápido as funcionalidades para os integradores. Na medida que formos caminhando com as soluções nos manteremos os ambientes similares.
No entanto, reportamos a vocês qualquer novidade.

Um processo de autorização pelo integrador, interessante <@!440035527127990273> , atende a nossa proposta e abre possibilidade para outros casos de uso

Aí é que tá. Vamos pensar mais um pouco, mas é algo que começa a ficar muito complexo, até para o integrador, ficará a dúvida:
- Será que minha regex tá ok?

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

Encontrei este tutorial aqui da AWS que ensina passo a passo a configuração com mTLS, outros integradores utilizarem ele, pode ser útil https://aws.amazon.com/pt/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/ . Vou buscar mais informações e retorno para você caso não consiga configurar.