Histórico de mensagens sobre an

Certo, criamos um # atendimento privado para pegar mais detalhes com você, @rommel.santhiago

Olá, @rommel.santhiago

@hjjunior entendemos que este email é a confirmação de nossa parte para o cliente final, da cobrança efetuada. Além disso, ele também entra em algumas analises de nosso antifraude.

desculpa a pergunta, mais pq é obrigatorio? alguns outros payment gateway nao fazem envio, tem checkout mais transparente

Se forem cobranças de cartão de crédito sim @hjjunior

Estou criando um marketplace e utilizando a minha conta efi para gerar um repasse para o vendedor, mas ao pagar, o nome exibido é o meu. Gostaria de saber se há a possibilidade de exibir o nome do vendedor quando os usuários forem realizar o pagamento.

Uma outra dúvida, é necessário que a porta do servidor esteja na 443 para configurar os webhooks? Como estou tentando implementar através do servidor compartilhado da digital ocean não tenho acesso para alterar e ele só abre na 8080.

No caso as cobranças tbm por fora da assinatura também terão esse email?

Em casos de cobranças que possuem o pagamento via cartão de crédito, o envio do email é obrigatório :/

Tem como evitar o envio de emails de assinaturas para o cliente? Achei estranho de receber ate mesmo em ambiente de homologacao

Além do custo de cobranças (mas apenas se liquidadas), há custos para envio de TED pelo app e para envio de Pix via API (se você for liberado a usar). Mas não há custos fixos ou recorrentes.

Não estamos conseguindo cancelar boletos via integração com o IXC.

Boa tarde @neurizin ! Você não tem nenhum custo de mensalidade ou tarifa de manutenção para utilizar nossa API. O único custo será por cobranças liquidadas.

Não há custos associados à utilização da API, @neurizin
As tarifas são cobradas apenas quando ocorre o pagamento de uma cobrança.
Ou seja, você pode utilizar a API livremente, mas uma tarifa será deduzida somente quando uma cobrança emitida por ela for paga.

Catálogo de possíveis estratégias:
1) Obter um token, anotar a validade. Se tem que fazer nova requisição e já passou da validade, pedir outro token.
2) Obter um token e renovar forçadamente para sempre ter um token válido
3) Para cada requisição, obter um token, usar, e não guardar.

A sim, são válidas sim...

Mas não é uma obrigatoriedade manter o token válido, fazendo autenticação só para deixar ele válido...

Isso q quis falar, não é uma obrigatoriedade...

Não digo ignorar q ele tenha validade... Um exemplo...

As 8hrs faço a autenticação e uma transação, as 8:40 faço outra transação sem necessidade de nova autenticação...

Agr, as 8hrs faço autenticação e transação, aí só vou fazer outra transação as 13hrs... Não tem pq as 9, 10, 11, 12, ficar fazendo autenticação... As 13hrs quando for fazer a transação, vejo q o token expirou, faço a autenticação, e a transação.

Eu trabalho assim....

Depende, é válida também uma estratégia de manter o token em prontidão. Assim como também pedir um novo token a cada transação e ignorar que ele tenha validade de 1h...

Vc precisa fazer a autenticação quando vai fazer uma request depois de ter passado 1hr da última autenticação...

Agr, se vc não vai fazer nenhuma request, não tem pq fazer a autenticação só por fazer....

Mesmo depois da mudança de 15.03 na plataforma de boletos ?