Operações no console e rotinas agendadas

TLDR: runbook das operações manuais do checkout-api — criar admins, unificar clientes, restaurar pagamento apagado — e o que os cronjobs fazem sozinhos.

Pré-requisitos

• Acesso ao console da aplicação (make console.staging ou make console.production, conforme o ambiente)
• Permissão de System Manager para as operações que passam pelo ActiveAdmin — ver ../reference/admin/access_permissions.md

Todas as operações abaixo alteram dados de produção. Confirme o ambiente antes de executar.

Passos

Criar um usuário admin

```ruby uu = User.new( admin: true, email: ‘pessoa@example.com’, password: ‘senha-forte’, password_confirmation: ‘senha-forte’, roles: ‘customer_support’ )

uu.valid? uu.save ```

Os valores válidos de roles e o que cada um enxerga estão em ../reference/admin/access_permissions.md.

Unificar dois clientes (merge total)

O primeiro parâmetro é o cadastro errado, o segundo é o correto:

ruby IbftMergeCustomersJob.set(wait: 1.seconds).perform_later(39435, 39407)

Para mover apenas algumas organizações entre dois cadastros, sem unificar nem desativar ninguém, use a transferência por organização no ActiveAdmin — ver ../specs/20260407150300_organization_transfer.md.

Restaurar um pagamento apagado

Às vezes pagamentos são apagados e fica difícil rastrear. Dá para restaurar a partir dos logs do Asaas, em https://www.asaas.com/customerConfigIntegrations/logs?category=PAYMENTS&status=200:

ruby restore = PaymentRestoreService.new(req_json: '{}', resp_json: '{}', checkout_id: 75) restore.process

O checkout_id é parâmetro obrigatório: não é possível inferi-lo a partir do log sem trabalho demais.

Rotinas agendadas

Auto-cancelamento de pagamentos não pagos

O rake asaas:remove_pending_non_paid_payments cancela todos os pagamentos criados há 7 dias que não foram pagos. O script também remove as parcelas no gateway, para evitar notificações ao usuário.

O modelo Payment tem a flag auto_cancel_non_paid_period: quando ela é false, o pagamento escapa do auto-cancelamento.

Reparcelamentos e quitações têm a flag em false, porque o usuário precisa ter um pagamento ativo no gateway para ser enviado ao SERASA, se necessário.

Provedores de PlatformService

Provedores atuais:

• APOLO
• CITRG
• NotificationEmail (em progresso)
• NotificationWhatsapp (em progresso)
• NotificationEmailWhatsapp (em progresso)

Como adicionar um provedor novo está detalhado em ../plans/20260318144411_onion_integration.md, que percorre o caso do Onion ponta a ponta. O mecanismo genérico está em ../reference/payments/payment_integration_flow.md.

Opções de provedor por checkout

O módulo CheckoutIntegrationOption guarda, para cada checkout criado, os valores necessários — de forma genérica entre integrações diferentes.

Tabela checkout_integration_options:

Troubleshooting