Histórico de mensagens sobre PIX

https://sejaefi.com.br/tarifas?targetid=kwd-968216101418&network=g&device=c&keyword=api+pix&ad=728265693761&utm_source=google&utm_medium=cpc&utm_campaign=22093548949&utm_term=api+pix&campaignid=22093548949&adgroupid=174487648313&gad_source=1&gbraid=0AAAAADlmt4AElevf_xvpTz3KXw4TZwd3Y&gclid=CjwKCAiAp4O8BhAkEiwAqv2UqEUg3qvKHVe98RQhwaQckjKYrU_oV_RuHL1lGBAf7bKfM00TXIDDnBoCcR8QAvD_BwE

Boa tarde pessoal, vcs ja foram cobrados tarifa para enviar pix?

___
Um outro workaround rápido possível é usar duas instâncias de nossa SDK, adaptando em seu sistema para chamar uma só para o link de pagamento e outra somente para o PIX

Exactly. This attribute provides for the blocking of receipts from Pix charges, whose debtor's document, registered at the time of creating the charge, does not match the payer's document.

pagando um bolix por pix ele automaticamente passa para o status de paid no ato do pagamento

ou independente se é pix ou nao irá demorar o tempo de boleto (aprox 72h)

uma duvida, o bolix se pago com pix

Good afternoon @.steelfenix !
To activate the payer information, simply consume the account configuration endpoint, passing the attribute "pagador": true

Mas agora entendi, entao eu teria que criar duas aplicacoes é isso?

Uma para pix outra para pagamentos

Se ele gerar um pix e outro gerar um pix vai dar certo pois ainda está no token da api pix, porem quando alguem escolher cartao, vai dar nao autorizado

nao, o cliente escolhe.

No meu frontend ele pode escolher pix ou cartao/boleto.

porem se ele gerar um pix, e outro usuario por exemplo gerar um cartao nao dá certo, pois vai dar erro de nao autorizado

Olá, @allefrodrigo! Boa tarde!
Sua aplicação vai sempre gerar os 3 métodos para cada cobrança (2 do link e 1 do pix)?

Pois o ideal seria possibilitar ao cliente a escolha de um método antes de emitir por ele 😀

Mas seguindo, cada API precisa do access token atualizado da sua própria rota base. Além disso, a API Pix exige o uso do certificado que você pode obter diretamente pela área do integrador da conta Efí (menu API > Meus certificados).

exemplo:
para pix
const chargeResponse = await efipayPix.pixCreateImmediateCharge({}, chargeInput);

E aqui para link
const response = await efipayLink.createOneStepLink({ id: 0 }, chargeInput);

criei duas instancias mas nao resolveu.

As duas funcoes funcionam e criam o a cobrança, porém ou é um ou é outro.

Pessoal, boa tarde, alguém poderia me dar uma luz no seguinte?

Tenho uma aplicacao que tá habilitado pix e cobranças. Na minha api eu uso o sdk do node para criar um link de pagamento e cobrança pix.

O que acontece é que eu nao consigo fazer uma cobrança no pix e outra cobrança no cartao, eu recebo nao autorizado. O motivo eu creio que é porque cada um tem uma e logo um token.

Pelo menos quando eu testo no postman eu preciso fazer login separadamente para conseguir usar os endpoints.

Existe alguma luz para utilizacao dos dois ao mesmo tempo no node?

"fiz" 4 pix e nd de vir o webhook

Pessoal quanto tempo geralmente demora pra um pix de teste (Homologação) enviar a notificação pro webhook?

Eu não sou da Efí e eles vão poder te dizer se o atributo ainda é obrigatório... o que eu queria comentar é que a expectativa do cartão ter experiência similar a Pix e boleto é irreal, devido a natureza não autenticada das transações de cartão de crédito. Essa operação com um segredo compartilhado que não está associado à transação específico torna o cartão intrinsecamente inseguro, e sempre haverão controles para endereçar essa insegurança. A experiência de cartão só tende a ficar igual quando houver autenticação; já existe o padrão para isso, chamado 3D Secure, mas ainda é pouco implementado por bancos emissores e por processadores (a Efí por exemplo ainda não tem). Se você já fez alguma compra via cartão em que teve que continuar no site do banco emissor e fornecer um token, essa é uma das maneiras de operação do 3DS.

Bom dia equipe Efí, espero que estejam bem.
Utilizamos a integração com a "sdk-node-apis-efi" de vocês e notamos que na nova versão não é mais obrigatório envio do endereço do cliente para checkout com cartão de crédito 🙏
Vemos com bons olhos essa mudança, entretanto a exigência do número do telefone persiste, é isso mesmo? Porque essa exigência apenas para o cartão? Gostaríamos muito de deixar a experiência do checkout com cartão para nossos clientes bem similar ao PIX e ao Boleto (que não exigem telefone).

If you turn on the "pagador" information, the webhook will look like this:
{
"pix": [
{
"endToEndId": "E1803615022211340s08793XPJ",
"txid": "fc9a43k6ff384ryP5f41719",
"chave": "2c3c7441-b91e-4982-3c25-6105581e18ae",
"valor": "0.01",
"horario": "2020-12-21T13:40:34.000Z",
"infoPagador": "pagando o pix",
"gnExtras": {
"pagador": {
"nome": "GORBADOCK OLDBUCK",
"cpf": ".123.456-",
"codigoBanco":"00416968"
}
}
}
]
}

Note that you would still have to compare it to "devedor" to assess whether it's the same person or not. But if it's an issue pagador and devedor being different, you could set the account to deny such payments.

Good Night,

I'm currently helping a company to integrate Pix. Do you have an example of the webhook response when a "pagador" diferent from the informed on the PUT /v2/cob/:txid payed the QR code?