Vem no webhook, tem no GET de /cob também um objeto pix com ele, após o pagamento acontecer.
quais desses campos se referem a e2eId para solicitar a devolução do pix? desculpa mas pra mim nao está claro[
Opção 1: pega o pixCopiaeCola que já vem no retorno do /cob e usa um biblioteca para gerar o QR-Code (muitas linguagens tem). Esta opção é portável entre PSPs.
Opção 2: pega o loc.id que vem no retorno do /cob e faz em GET em /location aonde vem já a imagem do QR-Code. Esta opção não é portável.
Bom dia, estou realizando uma cobrança PIX, como eu consigo gerar o QR na minha tela?
Estou rodando o pix_received_list mas não estou obtendo os pixs pagos
Boa tarde pessoal, o campo devedor dentro do body é necessário na hora de gerar o pix ?
Eles fazem reenvio automático caso você não confirme com HTTP 2xx que recebeu. Acho que tem na doc os intervalos entre reenvios.
Se você estiver desconfiado de que o webhook era para ter vindo e não veio, GET de /pix com filtro por inicio/fim/txid já te o mesmo conteúdo que o webhook daria.
Então se você passar https://exemplo.com.br" class="link-msg" >https://exemplo.com.br , o teste durante a ativação vai ser feito para https://exemplo.com.br, e os Pix efetivamente virão para https://exemplo.com.br/pix .
E isso você pode ver em homologação também, criando cobranças de até R$ 10 que depois de alguns segundos geram requisições no webhook como se tivessem sido pagas.
Mas se quiser spoiler do que você vai ver, é uma requisição POST feita para a URL do webhook sem apresentar o certificado, seguida de uma com o certificado, na hora em que você ativa.
E depois, quando vem o Pix, eles fazem POST em URL+"/pix" com um array de objetos Pix.
entendi. pra mim, o asaas tem atendido na parte tecnica. uso em outro sistema tambem com um ticket maior a taxa fica funciona bem, mas para esse meu saas, a taxa fixa nao é legal.
tecnicamente eu gosto do asaas. é bem simples.
essa camada da api nativa do pix, eu tenho que me familiarizar mais.
Não obediência ao padrão da API Pix. Se você olhar a doc da Efí e comparar com https://github.com/bacen/pix-api/ , vai ver que é basicamente a mesma coisa, com alguns recursos específicos da Efí em adição. E o regulamento diz que a API Pix precisa ser assim para os métodos que ela suporta.
Métodos que ela não tem como de envio de Pix podem existir e aí não precisam seguir padrão específico.
sou usuario do Stripe para CC tambem mas eles nao estao com Pix para todos os clientes ainda.
Na parte de Pix a plataforma da Efí é muito funcional. Uma das poucas, aliás... AsaaS estou neste momento com reclamação aberta no Banco Central e eles estão dando respostas ensaboadas de pq não seguem o regulamento corretamente.
Na parte de taxas a Efí não costuma ser a menor...
E nesse caso, cada conta vai ter uma única chave Pix, e aí está dentro do limite de 20 chaves Pix por conta de PJ.
E sim, para uso com a API de abertura de contas, o endpoint de criação de chave Pix faz sentido.
nao. eu vou cadastrar cada cliente meu programaticamente, e cada um vai ter uma chave pix.
meu negocio eh um saas na area de restaurante.
acredito que seja esse endpoint https://dev.efipay.com.br/docs/api-abertura-de-contas/cadastro-simplificado
No Asaas, isso eh chamado de sub contas. Nao sei exatamente ainda no Efi como isso deve ser feito pra ser sincero
Mesmo conta CNPJ pode ter no máximo 20 chaves Pix
Mas criação de chave Pix é algo que se faz normalmente uma única vez, e em geral nem é via API, e sim via site ou app... então esse endpoint não faz muita falta. Eu sinto mais falta da quitação em homologação acontecer sem colocar um objeto pix na cobrança, que é uma diferença significativa entre produção e homologação.
Sim, o webhook é cadastrado para a chave Pix