Visão Geral
O Pix Recorrente permite que você configure cobranças periódicas automáticas usando Pix como meio de pagamento. Seus clientes autorizam a recorrência uma única vez e os pagamentos subsequentes são processados automaticamente.Autorização Única
Cliente autoriza uma vez via QR Code
Cobranças Automáticas
Pagamentos processados automaticamente
Gestão Simplificada
Sem necessidade de novo QR Code a cada cobrança
Benefícios
- ✅ Redução de inadimplência - Cobranças automáticas sem ação do cliente
- ✅ Melhor experiência - Cliente autoriza apenas uma vez
- ✅ Flexibilidade - Suporte para trial, cobranças mensais, anuais, etc.
- ✅ Menor custo - Taxas Pix geralmente menores que cartão de crédito
Como Funciona
Fluxo de Autorização Inicial:- Você cria uma assinatura via API com
payment_method: pix_recurring - API retorna um QR Code Pix para autorização
- Cliente escaneia o QR Code com app bancário
- Cliente autoriza a recorrência (e paga primeira cobrança se sem trial)
- Sistema processa e armazena token de recorrência
- Pronto! Cobranças futuras serão automáticas
- Sistema agenda cobrança 3 dias antes da data
- Sistema processa a cobrança 2 dias antes da data
- Gateway processa cobrança na data agendada
- Webhook notifica sucesso ou falha da cobrança
A Autorizou gerencia automaticamente todo o ciclo de vida das cobranças: agendamento, processamento, retentativas e notificações via webhook.
Jornadas de Pagamento
O Pix Recorrente suporta duas jornadas distintas:Journey 2 (J2) - Com Período de Trial
Para assinaturas que oferecem período de teste gratuito:
Exemplo: Assinatura com 7 dias de trial
Journey 3 (J3) - Sem Trial (Pagamento Imediato)
Para assinaturas que cobram imediatamente:
Exemplo: Assinatura mensal sem trial
Status do Ciclo de Vida
Status da Subscription
| Status | Significado | Quando Ocorre |
|---|---|---|
PAYMENT_PENDING | Aguardando autorização do cliente | Após criação, antes do cliente escanear QR Code |
TRIAL_STARTED | Período de trial ativo | Após autorização em J2 (com trial) |
PAYMENT_APPROVED | Assinatura ativa e em dia | Após confirmação de pagamento |
PAYMENT_REFUSED | Última cobrança falhou | Após falha em cobrança recorrente |
TRIAL_ENDED | Trial finalizado | Ao fim do período de trial |
CANCELED | Assinatura cancelada | Após chamada ao endpoint de cancelamento |
Status do Payment
| Status | Significado | Quando Ocorre |
|---|---|---|
SCHEDULED | Pagamento agendado, ainda não enviado | Criado pelo sistema inicialmente na J2 e 3 dias antes da cobrança na J3 |
WAITING_PAYMENT | Aguardando confirmação do gateway | Após envio para gateway (2 dias antes) ou QR Code J3 |
AUTHORIZED | Pagamento confirmado e concluído | Após confirmação via webhook |
REFUSED | Pagamento recusado | Após falha na cobrança |
Fluxo de Status - Journey 2 (Com Trial)
Pagamentos J2:Fluxo de Status - Journey 3 (Sem Trial)
Pagamentos J3:Criando Assinatura com Pix Recorrente
Endpoint
POST /api/v1/subscriptions
Parâmetros Principais
Merchant Category Code - Código de categoria do estabelecimento
Código identificador único da assinatura (gerado pelo seu sistema)
Descrição da assinatura
URL para recebimento de webhooks
ID do plano (opcional - use
null se não usar planos)Intervalo de cobrançaValores:
weekly, monthly, yearlyNota: Autorizou suporta apenas esses três intervalos. Não há suporte para interval_count ou intervalos customizados.Dias de trial gratuito (0 = sem trial, J3)Journey 2:
trial_days > 0Journey 3: trial_days = 0Objeto com dados do cliente
Objeto com dados do pagamento
Exemplo: Assinatura Mensal com 7 dias de Trial (J2)
cURL
Exemplo: Assinatura Mensal sem Trial (J3)
cURL
QR Code: O QR Code para autorização inicial está disponível em
payment.pix_recurring.qr_code. Cliente deve escanear para autorizar a recorrência.Diferenças entre J2 e J3
| Campo | Journey 2 (Trial) | Journey 3 (Sem Trial) |
|---|---|---|
trial_days | 7 (ou > 0) | 0 |
current_cycle | 0 | 1 |
payment.status | scheduled | waiting_payment |
payment.amount | 0 | 2890 (valor real) |
fee.platform_fee_amount | 0 (sem cobrança no trial) | 87 (taxa sobre valor) |
id- ID da assinatura (UUID)status- Status atual (payment_pending,trial_started,payment_approved, etc.)trial_days- Dias de trial (0 = J3, >0 = J2)current_cycle- Ciclo atual (0 = ainda não cobrou, 1+ = já cobrou)next_charge_at- Data/hora da próxima cobrançapayment.status-scheduled(J2) ouwaiting_payment(J3)payment.amount-0(J2) ou valor real (J3)payment.pix_recurring.qr_code- QR Code para o cliente escanearpayment.pix_recurring.charge_code- Token de recorrência (preenchido após autorização)payment.pix_recurring.acquirer_reference- Referência do gateway de pagamentofee- Informações de taxas da plataforma
Timing de Processamento
A Autorizou processa cobranças Pix Recorrente seguindo janelas específicas para garantir conformidade com requisitos do gateway de pagamento:Constantes de Timing
Linha do Tempo de Processamento
Exemplo para cobrança agendada para 10 de Novembro:Processamento Automatizado
A Autorizou executa três processos automatizados diariamente:Agendamento de Pagamentos - 02:00 AM
Agendamento de Pagamentos - 02:00 AM
Responsabilidade: Criar pagamentos
SCHEDULED 3 dias antes da cobrançaO que faz:- Busca assinaturas com
next_charge_atem 3 dias - Verifica se já existe payment
SCHEDULEDpara aquela data - Se não existe, cria novo payment com status
SCHEDULED - Se já existe, não faz nada (rede de segurança)
Processamento de Pagamentos - 04:00 AM
Processamento de Pagamentos - 04:00 AM
Responsabilidade: Enviar payments
SCHEDULED para gateway 2 dias antesO que faz:- Busca payments com status
SCHEDULEDebilling_dateem 2 dias - Valida que subscription ainda está ativa
- Muda status:
SCHEDULED→WAITING_PAYMENT - Envia requisição para o gateway de pagamento
- Aguarda confirmação via webhook
Processamento de Pagamentos Atrasados - 06:00 AM
Processamento de Pagamentos Atrasados - 06:00 AM
Responsabilidade: Retentar payments com status
REFUSEDO que faz:- Busca payments
REFUSEDde Pix Recorrente - Verifica se
retry_attempts < 3 - Cria novo payment
SCHEDULEDcom nova data - Aguarda processamento pelos outros processos automatizados
- Máximo de 3 tentativas em 7 dias
Webhooks
A Autorizou envia webhooks para notificar eventos importantes do ciclo de vida das assinaturas:Eventos de Subscription
| Evento | Quando Ocorre | Dados Incluídos |
|---|---|---|
subscription.created | Assinatura criada | subscription completa |
subscription.updated | Assinatura atualizada | subscription + campos alterados |
subscription.inactivated | Assinatura inativada | subscription + motivo |
subscription.deleted | Assinatura deletada | subscription + deleted_at |
Eventos de Payment
| Evento | Quando Ocorre | Dados Incluídos |
|---|---|---|
payment.scheduled | Payment agendado | payment + scheduled_for |
payment.authorized | Pagamento confirmado | payment + paid_at |
payment.refused | Pagamento recusado | payment + refusal_reason |
payment.retry_scheduled | Retry agendado após falha | payment + retry_attempt |
Exemplo de Payload
Para configurar e testar webhooks, consulte a documentação completa de webhooks.
Gerenciando Assinaturas
Cancelar Assinatura
Para cancelar uma assinatura ativa: Endpoint:POST /api/v1/subscriptions/cancel
cURL
- Define
canceled_atcom timestamp atual - Interrompe processamento de cobranças futuras
- Payments
SCHEDULEDnão são mais processados - Envia webhook
subscription.deleted
Consultar Assinatura
Endpoint:GET /api/v1/subscriptions/{subscription_id}
cURL
Listar Pagamentos de uma Assinatura
Endpoint:GET /api/v1/subscriptions/{subscription_id}/payments
cURL
Tratamento de Falhas
Política de Retry
Quando uma cobrança falha:- Payment muda para status
REFUSED - Subscription muda para
PAYMENT_REFUSED - Sistema agenda retry automático
- Máximo 3 tentativas em janela de 7 dias
- Após 3 falhas, assinatura permanece
PAYMENT_REFUSED
Motivos Comuns de Falha
| Motivo | Causa | Ação Recomendada |
|---|---|---|
INSUFFICIENT_FUNDS | Saldo insuficiente | Aguardar retry automático |
EXPIRED_TOKEN | Token de recorrência expirou | Cliente deve criar nova assinatura |
ACCOUNT_BLOCKED | Conta bloqueada | Cliente deve verificar com banco |
DAILY_LIMIT_EXCEEDED | Limite diário excedido | Retry no dia seguinte |
Verificando Falhas via Webhook
Ambiente de Testes
Sandbox
Use o ambiente sandbox para testar todo o fluxo: Base URL:https://zeus-sandbox.autorizou.dev/api/v1
Como testar:
- Use o endpoint
POST /api/v1/subscriptionsconforme documentado acima - No campo
payment.payment_method, use o valor"pix_recurring" - A API retornará o QR Code em
payment.pix_recurring.qr_code
QR Code de Teste
Em sandbox, o QR Code retornado aponta para ambiente de testes. Portanto, ele não vai funcionar no seu aplicativo bancário.Dica de Teste: Para simular falhas, você pode usar metadados específicos na criação da assinatura. Entre em contato com o suporte para detalhes.
Troubleshooting
QR Code não gera pagamento
Causa: Cliente pode ter escaneado mas não confirmou no app bancário Solução:- Verifique se QR Code ainda está válido (30 minutos)
- Peça ao cliente para confirmar autorização no app
- Aguarde webhook de confirmação (pode levar alguns segundos)
Subscription fica em PAYMENT_PENDING
Causa: Cliente não escaneou o QR Code ou autorização não foi processada Solução:- Verifique se cliente escaneou o QR Code
- Confirme que QR Code não expirou
- Se expirou, crie nova assinatura
- Verifique logs de webhook para erros
Payment fica em WAITING_PAYMENT
Causa: Aguardando confirmação do gateway via webhook Solução:- Normalmente resolve em alguns segundos
- Verifique se webhooks estão configurados corretamente
- Consulte status via
GET /api/v1/payments/{payment_id} - Se persistir por mais de 5 minutos, contate suporte
Cobranças não processam automaticamente
Causa: Processos automatizados não estão executando Solução:- Isso é gerenciado pela Autorizou (SaaS)
- Se detectar atrasos, contate suporte imediatamente
- Verifique se subscription está ativa (
canceled_atdeve ser null)
Campos Importantes
Campos principais retornados pela API:| Campo | Descrição |
|---|---|
payment.acquirer_reference | ID único do pagamento no gateway |
subscription.charge_code | Token de recorrência armazenado |
customer.uuid | Identificador único do cliente |
payment.pix_recurring.qr_code | QR Code para autorização inicial |
Recursos Adicionais
Criar Assinatura
Documentação completa do endpoint
Cancelar Assinatura
Como cancelar assinaturas
Webhooks
Configurar notificações em tempo real
Consultar Pagamento
Verificar status de pagamentos
Checklist de Implementação
Configuração Inicial
- Conta Autorizou configurada para Pix Recorrente
- Credenciais de API obtidas (sandbox e produção)
- Webhooks configurados para receber notificações
Integração Backend
- Endpoint de criação de assinatura implementado
- Endpoint de cancelamento implementado
- Recebimento de webhooks configurado
- Tratamento de eventos de pagamento implementado
- Logs e monitoramento configurados
Testes
- Testado criação de assinatura J2 (com trial)
- Testado criação de assinatura J3 (sem trial)
- Testado fluxo de autorização via QR Code
- Testado recebimento de webhooks
- Testado cancelamento de assinatura
- Testado falhas e retries
Produção
- Testado com transações reais em produção
- Monitoramento de falhas configurado
- Processo de suporte ao cliente definido
- Documentação interna criada
Próximos Passos
Após implementar Pix Recorrente:- Configurar webhooks para notificações
- Monitorar pagamentos em tempo real
- Implementar dashboard para gestão de assinaturas
- Processar reembolsos quando necessário