Histórico de mensagens sobre dados

Bom dia @mccartneyba tudo certo?
Você configurou o ramo de atividade da sua conta?
https://sejaefi.com.br/central-de-ajuda/dados-cadastrais/inserir-ramo-de-atividade#conteudo

Para os links prontos são usados os dados de comunicação presentes nas configurações da sua conta

A API retorna os dados e você pode montar seu checkout com os dados de acordo com a necessidade. Este exemplo é um link pronto baseado em uma cobrança PIX, presente na nossa documentação: https://dev.gerencianet.com.br/docs/api-pix-endpoints

Boa noite! Como faz para resolver uma mudança de nome no mesmo cpf porém a api não permite emitir títulos dando essa mensagem Transação não processada por conter incoerência nos dados cadastrais. mas eu preciso alterar o nome pois estava errado?

você pode testar essas requisições no Playground da sua aplicação dentro de sua conta Efí e verificar o schema de dados na documentação de assinaturas

No caso de assinaturas por boletos tem sim, os dados necessários são retornados na rota GET /v1/subscription/:id, sendo o id o identificador da assinatura

acho que nao é tao especifica nao, era mais pra saber se consigo fazer um get na api e trazer uns dados

Ahh okay. E para testar essas transações de cartão, há algum cartão de teste ou algo do tipo? dados placeholder etc

Isso mesmo @meninotrovoada, os dados do cartão sao repassados no momento da geração do payment_token

Lá no json pra fazer um pagamento com cartão de crédito pede diversas informações, só não pede os dados do cartão

Mas ai existem outras verificações q podem ser feitas também:
-Throttle de requisições
-Bloquear requisições subsequentes com o exato mesmo valor
-Pedir a localização(avaliação de área de risco, dá pra fazer isso com uma base de dados relativamente pequena)
-Ter essa verificação "fina" da transação só para valores muito altos como R$3000, R$4000
-Implementar um serviço de Liveness básico(Como o C6 faz para realizar um pix), ee ao terminar o liveness, gerar um token q é enviado junto a requisição da transação do cartão de crédito

Bom dia! Validei os dados e estão corretos.

Bom, então vou comentar da nossa experiência com a API Pix. A gente tem tido disponibilidade quase total nesses anos de operação, só engasgando quando a AWS US-EAST-1 engasga... a API é a mais aderente que encontramos ao padrão do Banco Central, e quando um recurso importante não é adotado pelo Banco Central, eles implementaram como extensão. Por exemplo, para nós era muito importante que transferências por chave e dados bancários e QR-Code estático fossem rejeitadas... isso não tem no padrão, mas tem na Efí.

Caso a resposta vazia esteja acontecendo devido à resposta 500 e verifique que não há quaisquer dados incorretos enviados na emissão pode considerar como uma resposta atípica que não irá ocorrer em ambiente de produção. Para fins de testes pode considerar as cobranças emitidas com sucesso.
A instabilidade na emissão de cobranças em homologação é uma situação que esta sendo mapeada e irá ser tratada pela nossa equipe responsável assim que possível, porém não temos uma previsão para tal.
Reforçamos que não há comportamento semelhante à este em produção.

Bom dia @cleyton9296, tudo bem?
Como o Rubens disse, o endToEndId é gerado no momento do pagamento da cobrança Pix.
Para conferir um pagamento o meio convencional é o webhook, onde você vai ser notificado no momento do pagamento da cobrança ao invés de ter que realizar consultas periódicas para verificar a situação da cobrança, essa pratica de verificação periódica é denominada polling que não recomendados.
Segue uma imagem que demosntra a comparação do polling com o webhook.

no momento o provedor é bem pequeno, estão começando a se estruturar. os clientes atualmente são gerenciados com papel e caneta rsrs. eu imaginei que haveria pontos na api com as mesmas funcionalidades das opções dessa tela aqui, e que poderia usar a própria efi para manter dados dos clientes. isso é possível? se sim, o que devo pesquisar na documentação para encontrar? obrigado e desculpe pelo incômodo

Olá, @gustamedeiros. Bom dia! Como vai?
Neste seu cenário você não precisa utilizar a API de abertura de contas. Pelo que entendi, esse app irá gerenciar as cobranças dos clientes do provedor. Ou seja, nesse app você deve usar as credenciais de acesso a API da conta do provedor.
Uma outra opção que pode ser viável... Imagino que esse provedor já tenha um sistema integrado com nossa API que faça a gestão dos boletos. Então basicamente, você poderia compartilhar ou conectar no banco de dados do sistema para ter as informações atualizadas, como os clientes que estão em dia, ou autras informações.

olá. estou criando um aplicativo para um pequeno provedor que tem como alvo os empregados desse provedor. a ideia é mostrar, no aplicativo, os clientes que não estão em dia, algumas informações cadastrais e gerar pix de pagamento.

consegui implementar a parte do pix, porém fiquei em dúvida se seria a api de abertura de contas que se usa para os dados do cliente. é isso mesmo? e eu teria que liberar o escopo através deste formulário? https://www.cognitoforms.com/GerencianetSA3/EF%C3%8DAPIDeCadastro

ou entendi algo errado e não é por esse caminho?

obrigado!

Boa tarde @caique.mp ! Se for uma transação do tipo cartão de crédito, você deve captar os dados do cartão do cliente e gerar um payment_token pra enviar na requisição de emissão. Não houve mudança, sempre foi dessa forma.

Talvez você utilizava nosso link de pagamento, onde você cria uma cobrança, sem definir a forma de pagamento e o pagador gerando um link. E nesse link, o cliente insere todas as informações necessárias para criar a cobrança de acordo com o método de pagamento escolhido (boleto ou cartão).

Olá @marcelo_efi, entendi entao que agora temos que captar os dados do cartão do Cliente?

Antes eu gerava uma transação, com a forma de pagamento via cartão, e conseguia obter um link de pagamento específico para cartão de crédito.