Histórico de mensagens sobre dados

é como se fosse um id que vem do banco de dados?

Boletos emitidos e pagos presencialmente, quando dado baixa no mkauth manualmente, serão dados baixa no api?

Em nossa API, você consegue consultar informações de boleto através deste endpoint: GET /v1/codBarras/:codBarras
Um dos atributos retornado é a linha digitavel.
Você pode consultar o boleto e armazenar a linha digitavel em seu banco de dados.

sempre gera um tanto de dados

Deixa eu ver se entendi, no caso eu vou estar gerando o txid, então o cpf ou cnpj em questão vai ser o meu, logo não importa se foi gerado um qr code para qualquer cpf pagador, vai sempre levar em consideração meus dados pra geração do txid, seria isso né?

Bom dia, @tacsistemas. Como vai?
Essa falha ocorre quando excede o número total de duas cobranças idênticas emitidas paro o mesmo cliente.

Exemplo: ao gerar duas cobranças com mesmo vencimento, mesmo valor R$54,90 para um determinado cliente, na terceira cobrança para o cliente com o mesmo valor e vencimento irá apresentar a falha.

Vale frisar que a API Efí utiliza identificadores únicos de cliente, sendo pelos dados CPF, número de telefone e e-mail.

Bom dia @elicast5242! Complementando o que o @rubenskuhl trouxe:
Eu estou envolvido com projetos de criptoativos, blockchain e DLT desde de 2018. Quando surgiu a notícia da CBDC do Brasil eu tammbém fiquei com muito receio porque as possibilidades de controle são infinitas.
Mas depois que a Efí entrou no piloto do Drex eu confesso que fiquei positivamente surpreso com a maturidade com que o tema está sendo tratado pelo BC. Da forma que está desenhado hoje, o Drex simplesmente impossibilita que o BC ou outra instituição de governo qualquer tenha acesso à nossos dados ou controle nossas atividades. O Drex, da forma como está desenhado, não dá ao BC nenhum tipo de controle à mais do a instituição já possui hoje.
Se for do interesse de vocês, posso gravar um vídeo mais técnico explicando os detalhes do Projeto.
Muito obrigado pessoal pela discussão, os pontos que vocês estão trazendo são excelentes!

Mas eu não sei que caso de uso precisaria de confirmação imediata de que a chave Pix exista ou não e é detida pelo CPF/CNPJ em questão... talvez seja mais fácil checar apenas a sintaxe da chave, e depois quando precisar enviar dinheiro para a chave, você dá feedback para o usuário de que os dados estavam corretos ou não.

Oi, @elicast5242 , @jeanmatos. e @rubenskuhl ! Agradecemos as contribuições.

Essa questão é um dos pontos mais interessantes abordados pelos nossos especialistas no podcast Efícientes. A ideia não é exatamente que o Drex substitua o saldo em conta ou o uso Pix. Como o Rubens bem pontuou, o Drex será utilizado, principalmente, para smart contracts.

Dessa forma, o dinheiro do pagador poderá ser liberado ao vendedor somente quando uma condição for atendida, como a entrega de um produto ou transferência de propriedade de um imóvel, por exemplo. Confira no exemplo:

Boa tarde, @tudocatolico! Tudo bem?
O Identificador da Conta (payee_code), é uma informação presente dentro da sua conta Efí.
Atualmente, o marketplace nativo da Efí permite a divisão de valores entre contas Efí.
Sendo assim, você precisará inserir nas requisições os Identificadores de Conta Efi para que seja realizado o split de forma automática.

O que temos em nossa API Pix, é um endpoint que permite você realizar uma transferencia Pix para qualquer instituição, por meio da chave Pix ou dados bancários.
Com essa solução, você poderia receber todo o valor em sua conta e utilizar este endpoint para transferir os valores para os vendedores.

Estou recebendo esse erro de retorno, no entanto o payment_token está sendo recebido em Dados de entrada

Sim @rubenskuhl, mas a Efí pode manter o padrão da API Pix do jeito que é hoje. Porém ao invés deu utilizar uma UI para criar os certificados, eu utilizaria uma API para isso. A API cria as credenciais, as chaves, isso funcionando seria como se fosse a UI da Efí hoje só que permitindo que eu parametrizasse a conta do cliente e obtesse os dados necessários para utilizar a API Pix. Entendeu?

Boa tarde, @stanleyjones_31137! Atualmente você tem duas possibilidades para realizar esse objetivo:

1. Utilizar nosso Bolix, um recurso próprio da Efí que você ativa em sua conta e toda criação de boleto já conta com um QR Code PIX vinculado à cobrança;
2. Usar a API Pix para gerar o QR Code, manter um gerenciamento interno para cancelar o boleto em caso de pagamento via PIX, configurar um webhook para acompanhar as movimentações PIX, montar o próprio Layout com os dados vindos da API para juntar o Boleto com o QR Code PIX.

Lembrando que a API nunca faz modificações no seu sistema, ela opera apenas recebendo requisições (com retorno de dados) e enviando notificações, toda alteração extra deve ser implementada pelo seu sistema.

Estou enviando os dados de options... let options = {
sandbox: (process.env.API_MODE !== 'PROD') ? true : false,
client_id: (process.env.API_MODE === 'PROD') ? process.env.EFI_PROD_CLIENT_ID : process.env.EFI_HOMOL_CLIENT_ID,
client_secret: (process.env.API_MODE === 'PROD') ? process.env.EFI_PROD_SECRET : process.env.EFI_HOMOL_SECRET,
certificate: certificado,
validateMtls: false,
};

Tava vendo aqui e no link de visulização da api pix mostra alguns dados como email, endereço e telefone. Tem como ocultar isso?

Nela você encontra a lista de dados necessários para cada endpoint e como utilizá-los

Mas o @apoloislaio_75951 quer o usuário e senha para salvar em uma base de dados própria.

Aí são duas questões: percepção e realidade. A realidade é que os dados de cartão são criptografados pelo componente Javascript da Efí e você não tem acesso. A percepção, de fato, é de passar os dados para você. Para clientes paranóicos, nada como Pix... o cliente sabe que pagar um QR-Code não revela nada para o recebedor.

Acho que entendi. Pensei que pela api seria gerado um link de pagamento, mas acho que entendi que o processo vai ter que ser no meu site e requisitado o pagamento com os dados do cartão pela API. Acho que assim fica mais "inseguro" pra pessoa confiar em pagar inserindo os dados no site e não no gateway