Assinaturas

Criar uma assinatura para um comprador, baseada em um plano previamente existente, permitindo que a Barte gere cobranças recorrentes automaticamente.

Atores

• Vendedor (Seller)
• Barte
• Buyer (obrigatório)

---

Pré-condições

• O plano deve estar ativo
• O buyer deve existir
• O método de pagamento deve ser compatível com o plano
• O merchant deve possuir webhook configurado

---

Pós-condições

• A assinatura é criada
• Uma cobrança recorrente é gerada automaticamente
• O status da assinatura passa a refletir o estado do pagamento
• Eventos de pagamento são comunicados via webhook

---

Fluxo Principal

1. O vendedor solicita a criação de uma assinatura informando:

   • Plano
   • Buyer
   • Método de pagamento
   • Data de início
2. A Barte valida:

   • Existência e status do plano
   • Existência do buyer
   • Compatibilidade do método de pagamento
3. A Barte cria a assinatura
4. A Barte gera a primeira cobrança recorrente
5. O pagamento é processado conforme o método escolhido
6. A Barte atualiza o status da cobrança
7. A Barte envia webhook ao vendedor
8. O vendedor confirma o pagamento com base no webhook

---

Fluxos Alternativos

3.a — Plano inativo

• A Barte recusa a criação da assinatura

3.b — Buyer inexistente

• A Barte retorna erro de validação

5.a — Pagamento assíncrono (PIX / boleto)

• A cobrança permanece PENDING
• O webhook é enviado apenas após confirmação do pagamento

5.b — Falha no pagamento

• A cobrança recebe status FAILED
• A assinatura pode permanecer PENDING ou ser SUSPENDED, conforme regra do plano

---

Regras de Negócio

• O buyer é obrigatório para assinaturas
• A assinatura pode gerar múltiplas cobranças ao longo do tempo
• O status da assinatura depende do status das cobranças
• Pagamentos recorrentes sempre devem ser confirmados via webhook
• A resposta da API não confirma pagamento
• Cobranças possuem status independentes da assinatura
• Assinaturas canceladas não podem ser reutilizadas

---

Observações Importantes

• O uuid da assinatura deve ser armazenado
• O uuid de cada cobrança deve ser armazenado
• Webhooks devem ser tratados de forma idempotente
• A liberação de serviços deve ocorrer somente após webhook