Pagamentos e estados

O banco é a autoridade para o estado da sessão. Eventos de interface não confirmam dinheiro recebido.

Fluxo disponível

1. O backend cria a sessão de checkout.
2. O pagador revisa valor, rede e dados.
3. O navegador cria uma operação sandbox, com chave de idempotência.
4. A API retorna sandbox_pending e um código explicitamente não pagável.
5. A simulação conclui como sandbox_completed e grava um evento persistente.

Só existe um pagamento por sessão. Trocar a chave de idempotência não cria um segundo pagamento.

Consulta

GET /v1/payments exige payments:read. Retorna até 100 pagamentos da organização, sem documento, e-mail ou dados brutos da operadora.

GET /v1/metrics exige metrics:read. Totais financeiros contam somente pagamentos live com estado completed. Sandbox é contado separadamente e nunca entra no volume liquidado.

Estados reservados para produção

created, processing, paid, completed, expired e failed fazem parte do planejamento operacional. paid (Pix recebido) e completed (cripto liquidada) não podem ser tratados como equivalentes. A máquina de estados live e sua conciliação precisam de validação com a operadora antes de serem expostas.

Valores

BRL é persistido em centavos inteiros. Ativos digitais exigirão unidades inteiras com precisão por ativo. Não mantenha um saldo financeiro baseado em números de ponto flutuante ou em cotação da interface.