E isso também levanta uma outra questão sobre as assinaturas e o plano, no caso, será que não é mais adequado atribuir para a assinatura a responsabilidade de definir a recorrência da cobrança ao invés do plano?
Termos mais procurados:
Histórico de mensagens em assinaturas
PROCURE NO HISTÓRICO
CANAIS DE TEXTO
DISCUSSÕES
- Inserção automática do formato do Pix copia e cola pelo WhatsApp
- Conceito de Payload Locations no PIX
- Alternativas para Detalhar QR Code Pix
- Implementação do Módulo Gerencianet no Perfex CRM
- Integração de API Pix em Bot no Telegram
- Cancelamento de Boleto e Remoção do DDA
- Tempo Médio de Análise de Documentos na Abertura de Conta
- Endpoint para Recuperar Saldo
- Lista de ISPB e Códigos dos Bancos
- Repetição do Processo de Criação com txid
- Recebimento de Pagamentos via QR Code e Arduino
- Integração da API do Pix em Sistema Próprio
- Cobrança em Período de Teste Grátis de 7 dias
- Consulta de Chave PIX na API de Envio
- Cálculo da CRC 16 do QR Code do PIX
- Implementação da SDK do Pix em Next.js ou React
- Problemas com Token em Ambiente de Homologação
- Configuração de URLs para Recebimento de Status
- Utilização de Endpoints e Payload no Pix
- Autenticação com Certificado em NextJS
- Integrações com o Laravel e SDK de PHP da EFI
- Teste de Status de Pagamento em Ambiente de Homologação
- Atualização de informações no Retentiva de Cobrança
- Exemplos de Cartão de Crédito para Testes
- Retenção de Pagamento no PIX em Marketplace
EXIBINDO CONVERSAS RECENTES:
Data: 27/03/2025
Canal: assinaturas
Olá, podem me confirmar uma informação?
Olhando a documentação, aparentemente não é possível flexibilizar na hora da atribuição de uma assinatura a um pagador o tempo de duração da assinatura, pois é definido no plano (com interval e repeats) e não na execução do pagamento.
Dessa maneira, parece impossível com um plano já criado, atribuir códigos promocionais que aumentam o tempo daquele plano, sendo necessário criar um novo plano para atender as regras específicas do código promocional criado.
É isso mesmo ou é possível alterar a duração de uma assinatura de forma arbitrária?
Boa tarde @dilanln_ tudo certo?
Será recebido o status unpaid relacionado a cobrança daquele mês.
Por exemplo:
js
{
"id": 8,
"type": "subscription_charge",
"custom_id": null,
"status": {
"current": "unpaid",
"previous": "waiting"
},
"identifiers": {
"subscription_id": 11976,
"charge_id": 2688053
},
"created_at": "2021-08-25 01:32:38"
},
Na nossa documentação você encontra o exemplo completo: https://dev.efipay.com.br/docs/api-cobrancas/notificacoes#exemplos-de-respostas{
"id": 8,
"type": "subscription_charge",
"custom_id": null,
"status": {
"current": "unpaid",
"previous": "waiting"
},
"identifiers": {
"subscription_id": 11976,
"charge_id": 2688053
},
"created_at": "2021-08-25 01:32:38"
},
Bom dia, alguém poderia me informar que status a EFI envia pra caso uma assinatura não tenha sido paga no mês, por exemplo meu cliente teve 3 descontos com sucesso porém o 4 falhou, que status vou receber no webhook ?
O plano que você criar pode ser reutilizado, mas será necessário criar uma assinatura para cada cliente.
@guilherme_efi Tenho uma última que não ficou muito claro para mim. Para cada pagador novo eu preciso criar uma assinatura? E para cada assinatura, também deve ser criado um novo plano? Ou tanto o plano quanto a assinatura podem ser reutilizados?
Perdão, minha pergunta já está respondida, o payment não precisa dos dados do cartão do pagador, está implicito com paymentToken.
Entendi, então remove a necessidade de criptografar os dados antes de enviar para o backend. Que bom!
Então quer dizer que na req de criar um pagamento não é necessário enviar os dados de pagamento payment por já ter o paymentToken que representa os dados do pagador?
@.antony, a biblioteca do payment token foi criada para gerar um token único que representa os dados do cartão de crédito de forma segura. Assim as informações do cartão não precisam ser enviadas diretamente para o backend, evitando o risco de interceptação. Além disso, evita que o backend armazene dados sensíveis, como os números dos cartões.
Então o processo acontece no frontend, onde os dados do cartão são criptografados e transformados nesse token. E esse token é o que será enviado para o backend para processar o pagamento.
Beleza Gui, obrigado! Pode só me explicar o que faz essa lib do payment token e qual é a necessidade dela?
Achei interessante que o token é criado no frontend e não no back, tirando de certa forma a responsabilidade de quem implementou o sistema de cuidar de alguma etapa do processo de envio dos dados.
O payment_token é obrigatório. Ele é um token que representa os dados do cartão de crédito, que deve ser gerado no front-end da sua aplicação.
Em nossa documentação você encontra mais detalhes: https://dev.efipay.com.br/docs/api-cobrancas/cartao#obten%C3%A7%C3%A3o-do-payment_token
Bom dia, @.antony! Tudo bem?
Pode ignorar esse comentário. Ele seria do exemplo de como consultar uma cobrança. Dá uma olhada aqui: Exemplo de consulta de cobrança.
Vamos remover esse comentário do arquivo createOneStepCard.go, pois ele não é necessário.
Bom dia devs! Pergunta para o pessoal técnico:
No código de exemplo de vocês da assinatura one step, tem um comentário que me deixou confuso que diz no lugar do 1 coloque o charge_id certo.
Podem me explicar o que isso quer dizer?
https://github.com/efipay/sdk-go-apis-efi/blob/main/examples/charges/card/createOneStepCard.go
go
package main
import (
"fmt"
"github.com/efipay/sdk-go-apis-efi/src/efipay"
"github.com/efipay/sdk-go-apis-efi/examples/configs"
)
func main(){
credentials := configs.Credentials
efi := efipay.NewEfiPay(credentials)
paymentToken := "428d7f3b2dc49117552ace464078557832c4ae4f";
customer := map[string]interface{}{
"name": "Gorbadoc Oldbuck",
"cpf": "04267484171",
"phone_number": "51944916523",
"email": "gorb.oldbuck@gerencianet.com.br",
"birth": "1977-01-15",
}
billingAddress := map[string]interface{} {
"street": "Av JK",
"number": 909,
"neighborhood": "Bauxita",
"zipcode": "35400000",
"city": "Ouro Preto",
"state": "MG",
}
body := map[string]interface{} {
"payment": map[string]interface{} {
"credit_card": map[string]interface{} {
"installments": 1,
"billing_address": billingAddress,
"payment_token": paymentToken,
"customer": customer,
},
},
"items": []map[string]interface{}{
{
"name": "Product 1",
"value": 1000,
"amount": 2,
},
},
"shippings": []map[string]interface{} {
{
"name": "Default Shipping Cost",
"value": 100,
},
},
}
res, err := efi.CreateOneStepCharge(body) // no lugar do 1 coloque o charge_id certo
if err != nil {
fmt.Println(err)
} else {
fmt.Println(res)
}
}
package main
import (
"fmt"
"github.com/efipay/sdk-go-apis-efi/src/efipay"
"github.com/efipay/sdk-go-apis-efi/examples/configs"
)
func main(){
credentials := configs.Credentials
efi := efipay.NewEfiPay(credentials)
paymentToken := "428d7f3b2dc49117552ace464078557832c4ae4f";
customer := map[string]interface{}{
"name": "Gorbadoc Oldbuck",
"cpf": "04267484171",
"phone_number": "51944916523",
"email": "gorb.oldbuck@gerencianet.com.br",
"birth": "1977-01-15",
}
billingAddress := map[string]interface{} {
"street": "Av JK",
"number": 909,
"neighborhood": "Bauxita",
"zipcode": "35400000",
"city": "Ouro Preto",
"state": "MG",
}
body := map[string]interface{} {
"payment": map[string]interface{} {
"credit_card": map[string]interface{} {
"installments": 1,
"billing_address": billingAddress,
"payment_token": paymentToken,
"customer": customer,
},
},
"items": []map[string]interface{}{
{
"name": "Product 1",
"value": 1000,
"amount": 2,
},
},
"shippings": []map[string]interface{} {
{
"name": "Default Shipping Cost",
"value": 100,
},
},
}
res, err := efi.CreateOneStepCharge(body) // no lugar do 1 coloque o charge_id certo
if err != nil {
fmt.Println(err)
} else {
fmt.Println(res)
}
}
Entendi amigo, em prod o cenário funcionária como descrevi?
Em prod teríamos uma parcela a mais esse mês?
Bom dia, @williansoncini! Tudo bem?
A assinatura em homologação emite apenas a primeira parcela mesmo.
Olá pessoal, tudo bem? 🙂
Podem me ajudar com uma dúvida por favor?
Tenho essa assinatura em anexo e minha dúvida é se não deveria ter mais uma cobrança realizada automaticamente no histórico tendo em vista que a data de próxima execução já passou (23/03/2025)
O intervalo é mensal é a recorrência é nula, sendo assim "infinita"
Essa assinatura só está só com uma cobrança, acho que o correto seria estar com duas tendo em vista que a data de criação foi 24/02/2025
Estou no ambiente de homologação