Bom dia, <@!785181142852698153>.
Entendido. No caso do Pix enviados não é retornado na consulta, ele somente é informado através do webhook, ou pelo extrato financeiro da conta.
Histórico
CALENDÁRIO
Junho 2024
Seg Ter Qua Qui Sex Sab Dom
- Ativo
- Disponível
- Indisponível
CANAIS DE TEXTO
EXIBINDO CONVERSAS RECENTES:
Texto: enviados
Bom dia pessoal. Por gentileza, há um endpoint de comprovantes de pix enviados ou um endpoint para os dados de um pix enviado? Que contenha o código de autenticação
Ele não retorna mesmo, pois, o endpoint GET /v2/pix/{e2eId} só retorna referente a Pix recebidos e não aos enviados. Por isso é necessário um webhook associado a chave, para que esta informação chegue via notificação. No entanto já mapeamos e estamos construindo 2 endpoints semelhantes ao GET /v2/pix/{e2eId} e GET /v2/pix/ para retornar informações referentes a Pix enviados.
Aonde confiro sobre os callbacks enviados em meu webhook, as tentativas de envio e os responses?
Oi pessoal! Estamos integrando a API Pix e estamos com uma dúvida sobre a consulta do status do pix. Os webhooks nos informam os status dos PIX enviados ou apenas dos PIX recebidos?
Mas respondendo a dúvida Renato, não terá custos receber Pix via chave enviados de um PSP para a sua chave na Gerencianet
Boa tarde, <@!305835973474910208>!
Sim, esta propriedade deve ser informada, segue um exemplo do body para atribuir o método de pagamento boleto a uma cobrança:
{
"payment": {
"banking_billet": {
"customer": {
"name": "Gorbadoc Oldbuck",
"cpf": "94271564656",
"email": "[email protected]",
"phone_number": "5144916523",
"address": {
"street": "Avenida Juscelino Kubitschek",
"number": "909",
"neighborhood": "Bauxita",
"zipcode": "35400000",
"city": "Ouro Preto",
"complement": "",
"state": "MG"
}
},
"expire_at": "2018-12-30",
"configurations": {
"fine": 200,
"interest": 33
},
"message": "Usando o atributo message, este conteúdo é exibido no campo OBSERVAÇÃO da cobrança emitida via API \n ... e também no campo OBSERVAÇÃO DO VENDEDOR nos e-mails de cobrança enviados ao cliente \n É possível utilizar até 4 linhas de conteúdo, com no máximo 100 caracteres por linha \n Essa mensagem poderá ser vista nos e-mails relacionados à cobrança, no boleto ou carnê"
}
}
}
"payment": {
"banking_billet": {
"customer": {
"name": "Gorbadoc Oldbuck",
"cpf": "94271564656",
"email": "[email protected]",
"phone_number": "5144916523",
"address": {
"street": "Avenida Juscelino Kubitschek",
"number": "909",
"neighborhood": "Bauxita",
"zipcode": "35400000",
"city": "Ouro Preto",
"complement": "",
"state": "MG"
}
},
"expire_at": "2018-12-30",
"configurations": {
"fine": 200,
"interest": 33
},
"message": "Usando o atributo message, este conteúdo é exibido no campo OBSERVAÇÃO da cobrança emitida via API \n ... e também no campo OBSERVAÇÃO DO VENDEDOR nos e-mails de cobrança enviados ao cliente \n É possível utilizar até 4 linhas de conteúdo, com no máximo 100 caracteres por linha \n Essa mensagem poderá ser vista nos e-mails relacionados à cobrança, no boleto ou carnê"
}
}
}
galera eu to confuso com um ponto da documentação,
> Callbacks
> Esse serviço está protegido por uma camada de autenticação mTLS. Os callbacks são enviados pela Gerencianet via POST {$request.body#/webhookUrl}/pix quando há uma alteração no status do PIX.
>
e do lado de vocês, é possível "exigir o mTLS" pra decidir se os dados devem ser enviados (no momento do callback em si)?
Já foi orientado e as credenciais não estão sendo enviados pela equipe, no entanto, a documentação estava desatualizada. Alterei para que o integrador informe o nome da aplicação e o ambiente para que possamos gerar o certificado.
"Esse serviço está protegido por uma camada de autenticação mTLS. Os callbacks são enviados pela Gerencianet via POST {$request.body#/webhookUrl}/pix quando há uma alteração no status do PIX."
São certificados diferentes enviados , o de produção é um e o de dev é outro , com tokens diferentes. No ticket que você abriu solicitando o certificado eles enviam as informações e a senha por SMS no seu celular.
e eu vou parar de discutir isso pq ter que aceitar que alguém suporta a existência de um "quase mTLS" não é saudável pra mim. a pessoa precisa entender que 2 requests podem ser enviados para o mesmo server {} e um ter mTLS e o outro não. se ela não entende.. paciência.
cara.. não terá mTLS nos requests enviados sem o certificado. será mTLS quando tiver o certificado. se pra vc isso é "quase mTLS", questão de interpretação sua. a documentação diz que é e o request não vai chegar onde tem que chegar pq vc barrou, ainda no Nginx. então.... não vamos chegar a lugar nenhum discutindo uma coisa que tá documentada e provada que é mTLS só pq vc acha que não é. 🙂
O que eu imagino é mais do tipo um pedido com vários produtos. Aí um produto descobrem que não tinha no estoque, dá devolução no valor dele. Aí os outros são enviados, mas um deles não serve e o cliente devolve. Devolve agora essa parte.
Se a pessoa tiver a sua url e tambem tiver todos os dados da cobrança sem você ter o mTLS, ela pode enviar um POST para a url e se seu sistema validar os dados enviados, vai interpretar que foi pago. Ja que em uma cobrança todos os dados são expostos e são abertos. Por isso a importancia do mTLS com o certificado da GN.
Bom dia para chave de produção, proponho que o user crie chave privada e publica rsa 2048. envia a chave publica para a GN. A GN coloca os protocolos que achar e reenvia para o user. O User com esse arquivo junta a chave privada e faz o pfx/p12. Todos os arquivos deverão ser enviados e recebidos no formato PEM.
> Os certificados estão sendo enviados por e-mail? Isso não é considerado inseguro?
<@!693592686338244609> Inicialmente a gente esta disponibilizando o Certificado de desenvolvimento através do ticket, quanto ao certificado de Produção estamos avaliando a melhor maneira de disponibilizar ate que o ambiente definitivo esteja disponível na conta
> Os certificados estão sendo enviados por e-mail? Isso não é considerado inseguro?
<@!693592686338244609> o certificado será enviado na resposta do ticket que voce criou.
Os certificados estão sendo enviados por e-mail? Isso não é considerado inseguro?