a API permite consultar pix recebidos sem txid (pelo menos deveria, segundo documentação oficial da API do BACEN). usando parâmetros como data de início/fim, cpf/cnpj do pagador, etc.
Termos mais procurados:
Histórico de mensagens sobre Cpf
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Conceito de Payload Locations no PIX
- Consulta de Chave PIX na API de Envio
- Repetição do Processo de Criação com txid
- Endpoint para Recuperar Saldo
- Recebimento de Pagamentos via QR Code e Arduino
- Teste de Status de Pagamento em Ambiente de Homologação
- Implementação da SDK do Pix em Next.js ou React
- Autenticação com Certificado em NextJS
- Implementação do Módulo Gerencianet no Perfex CRM
- Configuração de URLs para Recebimento de Status
- Problemas com Token em Ambiente de Homologação
- Integrações com o Laravel e SDK de PHP da EFI
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Geração de payment_token pelo Postman e teste em homologação
- Cobrança em Período de Teste Grátis de 7 dias
- Interpretação do Campo 'Solicitação ao Pagador' no Webhook GN
- Especificação da URL do Webhook no Exemplo Pix
- Atualização de informações no Retentiva de Cobrança
- Utilização de Endpoints e Payload no Pix
- Retenção de Pagamento no PIX em Marketplace
- Resolução de Delay nas Chamadas de Geração de QR Code e Pix em Node
- Acionamento de Webhooks em Pagamentos e Devoluções
- Funcionamento do Webhook em Ambiente de Homologação
- Cancelamento de Boleto e Remoção do DDA
EXIBINDO CONVERSAS RECENTES:
Texto: Cpf
https://api-pix.gerencianet.com.br/v2/cob PUT
{
"calendario": {
"criacao": "2021-02-08T13:24:57.508Z",
"expiracao": 3600
},
"txid": "7978c0c97ea847e78e884963a4473c1f2",
"revisao": 0,
"loc": {
"id": 2,
"location": "qrcodes-pix.gerencianet.com.br/v2/bba3f7429ab34da6bfcd6a47b216dfd0",
"tipoCob": "cob",
"criacao": "2021-02-08T13:24:57.532Z"
},
"location": "qrcodes-pix.gerencianet.com.br/v2/bba3f7429ab34da6bfcd6a47b216dfd0",
"status": "ATIVA",
"devedor": {
"cpf": "00586549250",
"nome": "Matheus Torrente"
},
"valor": {
"original": "0.01"
},
"chave": "94fa0387-e550-4383-be40-622c2f58ac06",
"solicitacaoPagador": "Cobrança dos serviços prestados."
}
Bom dia, estou testando o pagamento com cartão de crédito no modo sandbox, estou gerando o payment_token e installments e ao utilizar o metódo
payCharge
com o body var body = {
payment: {
credit_card: {
installments: installments,
payment_token: paymentToken,
billing_address: address,
customer: {
name: client.name,
email: client.email,
cpf: client.cpf.replace(/\D/g, ''),
birth: birth,
phone_number: client.whatsapp.replace(/\D/g, ''), // Only number
},
},
},
};
payment: {
credit_card: {
installments: installments,
payment_token: paymentToken,
billing_address: address,
customer: {
name: client.name,
email: client.email,
cpf: client.cpf.replace(/\D/g, ''),
birth: birth,
phone_number: client.whatsapp.replace(/\D/g, ''), // Only number
},
},
},
};
{
"txid": "d84e95ed10274fdca3ce81a15bebb48c",
"revisao": 0,
"calendario": {
"criacao": "2021-02-05T18:11:02.000Z",
"apresentacao": "2021-02-05T18:51:52.626Z",
"expiracao": 3833340
},
"status": "ATIVA",
"valor": {
"original": "1.00"
},
"chave": "0a4313be-2d49-4c01-a2ac-8ff2cffd94bc",
"devedor": {
"nome": "FABRICIO MOTA CAMARGO",
"cpf": "01257398695"
},
"solicitacaoPagador": "Mensalidade de internet referente ao vencimento 22/03/2021 cod:911504."
}
Sobre o pagamento/transferência via POST em /pix, eu acho que ele devia ser mudado para PUT. O POST hoje não tem idempotência, e está sujeita a duplicações... a idempotência seria garantida com um parâmetro id (similar ao id de devolução), diferente do eventual txid (que é do recebedor). Para não ter que criar muitos métodos distintos, acho que poderia ser um único... se não tiver txid ou código, a ação é de transferência. Se tiver txid ou código, é pagamento... mas são mutuamente exclusivos. Ou tem o txid, ou tem o código do Pix Copia e Cola.
No geral fica:
chave mutuamente exclusivo com banco/tipo/agência/conta/cpf , mas um deles é requerido
txid mutuamente exclusivo com código, mas é opcional.
idenvio obrigatório, e garante idempotência. Se receber duplicado, só dá erro se for diferente. <@!793123559874494465>
@35011180824 seu nome de usuário é um CPF? 🤔
Eu tinha pensado em algo para confirmar existência de chave em situações de split e envio de Pix, mas aí não funcionaria para CPF/CNPJ/chave aleatória. 😦
E o seguinte exemplo seria para cartão:
{
"payment": {
"credit_card": {
"customer": {
"name": "Gorbadoc Oldbuck",
"cpf": "94271564656",
"email": "[email protected]",
"birth": "1990-08-29",
"phone_number": "5144916523"
},
"installments": 1,
"payment_token": "",
"billing_address": {
"street": "Avenida Juscelino Kubitschek",
"number": "909",
"neighborhood": "Bauxita",
"zipcode": "35400000",
"city": "Ouro Preto",
"complement": "",
"state": "MG"
}
}
}
}
"payment": {
"credit_card": {
"customer": {
"name": "Gorbadoc Oldbuck",
"cpf": "94271564656",
"email": "[email protected]",
"birth": "1990-08-29",
"phone_number": "5144916523"
},
"installments": 1,
"payment_token": "",
"billing_address": {
"street": "Avenida Juscelino Kubitschek",
"number": "909",
"neighborhood": "Bauxita",
"zipcode": "35400000",
"city": "Ouro Preto",
"complement": "",
"state": "MG"
}
}
}
}
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ê"
}
}
}
Pessoal, a interface CheckKeys que o BACEN está considerando aceita apenas chave telefone ou também e-mail, CPF/CNPJ, aleatória ?
parâmetro GET /pix/e2eid e aí no JSON inicio=emissao-da-cobranca fim=agora cpf=111.111.111-11
Você intermediário não precisa, mas o seu cliente, o recebedor, precisa sim do CPF. Então pedir essa informação já é parte normal de qualquer processo econômico no país.
Não é bem assim, Rubens. Não precisavamos do CPF de cada pagador individualmente.
No caso de intermediações existe um obrigação tributária do recebedor de qualquer forma. E para cumprir essa obrigação ele precisa do CPF.
no caso o CPF é passado como parametro ou no path? nao achei no manual esse método
Não existe no ramo de intermediações, portanto nunca precisamos pedir o CPF do comprador. O tributo é arrecadado de forma diferente da maioria das empresas
Isso já tem, você faz um GET /pix com o e2eid do pagamento e o CPF esperado. Se vier o Pix, veio desse mesmo.
Você já tinha que pedir CPF dos clientes para gerar nota fiscal ou fatura. Já existia uma obrigação tributária.
existe já alguma chamada para informar o CPF esperado ou ainda não foi implementado?
O problema neste caso é ter que pedir o CPF de todos os clientes, quando no momento podemos apenas conferir o nome do pagador com o nome do cliente cadastrado no site