Histórico de mensagens em assinaturas

Boa tarde ta dando erro: 3500000
server_error
Erro interno do servidor.

ok obrigado

Oi, @dev_victorhugo. Pode executar o comando composer update para atualizar para última versão da SDK, e usar o exemplo seguinte exemplo para consumir o endpoint: https://github.com/efipay/sdk-php-apis-efi/blob/main/examples/charges/subscription/updateSubscription.php

ok obrigado

Olá, @dev_victorhugo. Como vai?
Esse endpoint ainda não foi disponibilizado na SDK. Mas aguarde um instante que já lançamos uma atualizado com inclusão destes endpoint.

Tenho outra dúvida e possível usar : https://dev.efipay.com.br/docs/api-cobrancas/assinatura/#alterar-dados-de-uma-assinatura pelo SDK php não estou achando poderia me auxiliar ?

Ok muito obrigado

E consegue alterar os dados do cartão caso ele tenha sido recusado por algum motivo operacional, como falta de limite, dados incorretos e problemas temporários com o cartão utilizando este endpoint: https://dev.efipay.com.br/docs/api-cobrancas/cartao#retentativa-de-pagamento-via-cart%C3%A3o-de-cr%C3%A9dito

Olá, @dev_victorhugo! Tudo bem? Caso for uma assinatura do tipo cartão de crédito utilizando nossa Api de Cobranças, você consegue alterar o valor da cobrança de assinatura utilizando este endpoint: https://dev.efipay.com.br/docs/api-cobrancas/assinatura#alterar-dados-de-uma-assinatura

Ok obrigado

Olá @dev_victorhugo, Boa tarde!
Tudo bem?
Atualmente não é possível alterar o valor e o cartão vinculado a uma assinatura recorrente.
Neste caso seria necessário emitir uma nova assinatura com o valor reajustado e para que seu cliente realize o pagamento com outro cartão.

Olá bom dia queria tirar uma dúvida e possível eu editar uma assinatura como o valor eo cartão o valor no caso de reajuste e o cartão caso venha a vencer

Mas já coloquei o ramo de atividade, já está tudo certo.

O ramo de atividade é o único detalhe que comumente causa isso... 😦

Preciso de ajuda, estou com problema: {
"code": 3500072,
"error": "request_not_allowed",
"error_description": "Não foi possível finalizar sua solicitação. Por favor, entre em contato com o suporte Gerencianet."
}, OBS JÁ CADASTREI RAMO DE ATIVIDADE

Entendi
Muito obrigado @hiagosilvas

Quando há um bloqueio e o cliente faz uma "promessa de pagamento". Eu basicamente atualizo a dt_bloqueio tbm, ai facilitou

Exatamente, no meu caso de uso ficou muito bom.

Bom dia @hiagosilvas
Entendi, então vc msm controla o processo de assinatura? E usa somente a parte de cobrança da efi
É isso?

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