Histórico de mensagens sobre PSP

O txid e o e2eid são coisas diferentes. O txid você definiu na criação da cobrança, o e2eid o PSP do pagador definiu para o Pix que liquidou a cobrança.

Lembrando que mesmo usando um outro PSP recebedor, ainda assim o PSP pagador pode abrir MEDs... mas o MP gera um ou outro MED mas nada fora de proporção. Itaú e Nubank sim, mais % de MEDs do que de Pix.

Mayron, eu controlo a assinatura diretamente pelo meu backoffice também. O que eu fiz foi basicamente na assinatura criar um dt_vencimento e um dt_bloqueio.

Para cartão eu crio o token com o reuse: true na API deles e armazeno essa informação.

Dito isso, eu tenho a seguinte regra:

Caso boleto, eu emito o boleto em D-3 sobre a data de vencimento. Então o cliente tem 3 dias pós emissão para pagar. E o bloqueio eu coloco em dt_vencimento + INTERVAL 7 DAY, ou seja meu sistema só irá bloquear de fato sete dias após o último vencimento.

Caso cartão eu solicito a captura do valor no dia do vencimento às 4h da manhã, caso não consiga cobrar deixo um botão para o cliente tentar mais duas vezes. Após isso ele é obrigado a cadastrar novamente o cartão de crédito.

Sobre os webhooks, sempre que obtenho um status de sucesso eu calculo a nova data de vencimento e a nova data de bloqueio no banco de dados. Apenas para boleto existe um negócio bem interessante que é o status identified que basicamente significa que foi identificado o pagamento, porém ele ainda não foi liquidado de fato em sua conta. Como existe o risco do cliente entrar no atendimento do banco dele e cancelar esse pagamento a tratativa que faço sempre é: caso o status seja identified coloca o dt_bloqueio para daqui 3 dias úteis. Porém como a Efí geralmente deposita no próximo dia útil o webhook com a identificação do pagamento já virá no próximo dia útil e a rotina para recalcular as novas datas entrará em ação.

Dessa forma ficou bacana, pois consigo criar planos com flexibilidade. Adicionar valores novos ou variáveis que foram contratados durante o mês e caso precise de fazer qualquer migração não precisaria necessariamente usar uma API de assinaturas do novo fornecedor (visto que pode levar um tempo para seguir a lógica de um possível novo fornecedor). A lógica fica toda na minha aplicação e o PSP faz apenas a parte dele que é gerir o fluxo de cobrança na forma de pagamento que eu escolher

Esse campo depende do preenchimento do pagador no app do PSP pagador

É que outros PSPs sem API não cobram no recebimento por chave independente da quantidade ...

Isso tem no Pix indepente da Efí. Dá para fazer com chave Pix de qualquer PSP, inclusive da Efí. Mas não tem um endpoint para isso, você pode usar uma biblioteca de BR-Code + QR-Code, ou usar sites que já façam isso como o https://pix.ae

Vai depender do PSP. SEPA é o arranjo. E além da API de pagamento, você vai precisar de API de ForEx pra calcular câmbio.

uso o componente acbr para transitar pagamentos pix via psps

Para Pix eu sugiro se ater aos gateways que sejam PSPs autorizados do BACEN, o que não é o caso desse que você citou.

Um ponto que ainda não ficou claro é como o PSP pagador deve validar a frequência autorizada. Pq a cobrança não precisa ser sempre no dia X... mas se em um mês atrasar, qual a janela de tolerância para depois no mês seguinte cobrar no dia regular ? Acho que vai ser tolerância de +/- 1 semana para os períodos exceto semanal, mas vamos ver.

Isso dá. Inclusive você pode colocar um piso mínimo de autorização, que é a mensalidade... se o cara tentar aceitar mas com teto menor do que o piso, o próprio app do PSP pagador já recusa.

O desacordo comercial não foi abordado, pelo que eu entendi. Isso significa que o PSP não iria intervir caso ocorra. É isso? Caso o cliente queira o valor de volta ele terá que solicitar ao recebedor, e não utilizará o MED para isso.

O ideal seria pegar o location e gerar o QR-Code a partir de bibliotecas suas, pq isso é mais portável para outros PSPs. Mas a Efí tem umas chamadas de location que permitem obter isso da API.

Sugiro uma pesquisa mais abrangente antes de afirmar algo do mercado como um todo... se você procurar no GitHub do BACEN, eu mantenho uma lista de PSPs com API Pix e você pode pesquisar esse ponto em particular.

Tem tanto PSPs que devolvem a tarifa no caso de devolução, os que não cobram e não devolvem (Efí), e os que cobram a devolução como se fosse um novo envio de Pix... o importante é que a condição comercial esteja clara, e você fatore isso na sua escolha de PSP.

A taxa do recebimento original, já paga, não é devolvida. A Efí não cobra pela devolução (o que alguns PSPs fazem).

O que você pode fazer é devolução parcial, tudo menos a taxa...

O que significa isso aqui: REMOVIDA_PELO_PSP? Quando isso acontece?

Você pode utilizar o endpoint de Consultar Cobrança(GET /v2/cob/:txid), passando o txid da cobrança, que vai te retornar todas as informações. Por exemplo, de uma cobrança Paga, vai te retornar o seguinte:

Bom dia @arig4m3r ! O body da sua requisição esta incorreto. A chave você passou dentro do Objeto pagador e não existe o atributo infoPagador. Você deve seguir à seguinte estrutura:

de acordo com a documentacao, o pix retorna REMOVIDA_PELO_PSP apos o vencimento, correto?