Tokenização própria no Asaas e o liga-desliga de meios de pagamento no admin

Ontem à noite a decisão do checkout tinha ficado em aberto — tokenizar cartão aqui dentro ou empurrar o usuário pro checkout hospedado do Asaas. Hoje o dia no kmaroteApp foi resolver essa bifurcação e já sair construindo o que ela destrava.

A escolha: tokenização própria, e agora o pedido de liberação ao Asaas

O rumo ficou definido pelo lado da tokenização — usar o método que já está construído aqui dentro, em vez de terceirizar o pagamento no checkout do Asaas. Só que tokenizar cartão não é uma chave que eu ligo sozinho: o Asaas precisa liberar a conta pra isso.

Então pedi ao Claude Code pra verificar na documentação do Asaas como solicitar essa liberação e, na sequência, redigir o texto pra enviar a eles. O Claude Code foi buscar na documentação (quatro consultas ao material do Asaas) e montou o texto do pedido. É a parte chata mas necessária: pra ter mais controle sobre a experiência de pagamento, tenho que passar pelo processo de aprovação deles antes.

Liga-desliga de meios de pagamento no admin

Com o caminho do cartão encaminhado, abri a segunda frente: dar ao admin o controle de quais meios de pagamento ficam ativos. Pedi pra criar, na área administrativa, a possibilidade de ativar e desativar Cartão, Pix e Boleto — e, mais importante, fazer as telas dos usuários comuns respeitarem essa configuração. De nada adianta desligar o Boleto no admin se ele continua aparecendo pro cliente.

O Claude Code estruturou isso em duas peças: uma camada de configuração do gateway (funcs/db.gateway_config.inc.php) e a página de admin em si (admin/paginas/admin/config_pagamentos/config_pagamentos.php). Foi a parte mais densa do dia — dez edições de arquivo, a lógica de config nova, e as telas de usuário lendo esse estado.

Decisão persistente: tokenização própria como caminho do checkout

Vale registrar essa decisão porque ela muda o desenho do checkout do kmaroteApp daqui pra frente: em vez de redirecionar o cliente pro ambiente do Asaas, o pagamento vai continuar sendo capturado dentro da própria aplicação, tokenizado e enviado ao Asaas por trás. Isso dá mais controle sobre a experiência, mas deixa a liberação da tokenização nas mãos do processo de aprovação do Asaas — não é algo que eu resolvo só com código.

Fechamento

Antes de considerar fechado, passei o código pelo lint de PHP do projeto (lint_php.sh, phpcs, verify-php.sh). O trabalho ficou construído na sessão, mas não fechei em commit dentro da janela — fica como próximo passo materializar o que foi escrito hoje, além de aguardar a resposta do Asaas sobre a liberação da tokenização.

Estatísticas do dia (geradas automaticamente):

Fontes desta execução:

claude.ai: 0 conversas (sem export novo desde 19/05)
Claude Code Windows: 3 sessões (1 em kmaroteApp com o trabalho real; 2 em elquercarlos são a própria geração do devlog)
Codex Windows: 0 sessões
Claude Code Larissa: indisponível (SSH não resolveu o host)
Larissa drops: 0 arquivos
Git kmaroteApp: 0 commits (trabalho ficou em WIP na sessão)
Git Larissa: indisponível (SSH não resolveu o host)
Git elquercarlos: 1 commit (devlog da execução anterior)

Atividade no PC:

Tempo ativo: 5h29min na janela de 24h

Por categoria:

Uncategorized: 2h33min
AI Chat: 1h29min
Communication: 43min
Browsing: 23min
Coding: 15min
Larissa Project: 6min

Top apps: TaskBarHero (1h54min) · Chrome (1h50min) · WhatsApp (43min) · OBS (35min) · Antigravity IDE (15min)

Top sites navegados: chatgpt.com (23min) · claude.ai (5min) · <PRIVATE-HOST> (5min)