A Jornada de uma Transação: da Autorização à Liquidação

Resumo (dek): O “pagamento aprovado” que aparece no checkout é apenas uma etapa. Autorização e captura pertencem ao ciclo do pagamento; liquidação, repasse, reembolso e disputa exigem registros relacionados, com estados e riscos próprios.

Introdução

O cliente clica em pagar e recebe uma resposta em segundos. Para quem olha apenas o checkout, a transação parece concluída. Nos bastidores, porém, aquela resposta inicia uma sequência que pode durar dias e envolver lojista, gateway, adquirente, bandeira, emissor e instituições de liquidação.

Entender essa jornada evita erros concretos. Um e-commerce pode despachar um item depois de uma autorização que nunca foi capturada. O atendimento pode prometer que um estorno já apareceu na fatura quando apenas enviou a solicitação. O financeiro pode comparar vendas brutas com depósitos líquidos e concluir que há dinheiro faltando, sem separar tarifas, antecipações e ajustes.

Este artigo usa o cartão online como fio condutor, pois ele expõe bem a diferença entre as etapas. PIX e outros meios têm estados e participantes diferentes, mas a disciplina permanece: tratar o ciclo do pagamento como uma máquina de estados, registrar operações relacionadas e conciliar o que o sistema esperava com o que realmente aconteceu.

Antes da autorização: intenção, dados e autenticação

A jornada começa antes de qualquer mensagem chegar ao banco emissor. O sistema cria uma intenção de pagamento vinculada ao pedido. Ela deve conter valor, moeda, referência do negócio, cliente e uma chave idempotente. Se a conexão cair, a mesma operação pode ser reenviada sem gerar uma cobrança nova.

No checkout, os dados do cartão são capturados. Uma integração bem desenhada usa tokenização ou componentes seguros para reduzir a circulação do número principal do cartão, o PAN. O PCI DSS se aplica às entidades que armazenam, processam ou transmitem dados de conta, ou que podem afetar a segurança do ambiente. Tokenizar ajuda a reduzir exposição, mas o desenho completo determina o escopo de conformidade.

Em transações online, pode haver uma etapa de autenticação do portador, como o EMV 3-D Secure. O protocolo troca dados sobre compra, dispositivo e meio de pagamento entre participantes para que o emissor avalie se quem está comprando é o usuário legítimo. Operações de menor risco podem seguir sem interação adicional. Em outras, o banco pede um desafio, como biometria ou código de uso único.

Autenticar não é autorizar. A autenticação procura confirmar a identidade do portador. A autorização verifica se a transação pode ser aceita naquele momento, conforme saldo ou limite, situação do cartão, controles de risco e regras do emissor.

Autorização: uma promessa condicionada

O gateway envia a solicitação ao adquirente, que a encaminha pela bandeira até o emissor. O emissor responde com aprovação ou recusa. Quando aprova, normalmente reserva o valor na conta ou no limite do portador. Essa reserva ainda não é a transferência final ao lojista.

Uma recusa também exige interpretação. Falta de saldo, cartão expirado e autenticação necessária pedem ações diferentes. Indisponibilidade do emissor pode justificar nova tentativa controlada. Cartão perdido, suspeita de fraude ou transação não permitida não devem entrar em uma cascata cega. Códigos variam entre participantes, portanto o gateway costuma normalizá-los em categorias úteis sem expor ao comprador detalhes sensíveis.

O produto deve registrar pelo menos a referência interna, a referência do provedor, o horário, o valor, o resultado e a categoria da resposta. Guarde também o histórico das tentativas. Substituir o estado anterior apaga evidências essenciais para suporte e conciliação.

Há ainda uma pergunta de negócio: quando cumprir o pedido? Para bens digitais de entrega imediata, muitas operações avançam após autorização e controles de risco. Em mercadorias físicas, a captura pode ocorrer na expedição. O ponto seguro depende do produto, do contrato e do risco aceito. A própria documentação de provedores recomenda acompanhar a captura antes de tratar o fluxo financeiro como concluído.

Captura: confirmar que a cobrança deve seguir

Captura é a confirmação de que o lojista quer efetivar um pagamento autorizado. Ela pode acontecer automaticamente logo após a autorização ou ser enviada depois. A captura separada é útil quando existe intervalo entre pedido e cumprimento, como reserva de hotel, aluguel de veículo ou e-commerce que precisa verificar estoque antes de despachar.

Se o item não puder ser entregue, a autorização pode ser cancelada em vez de capturada. Se apenas parte do pedido for enviada, alguns arranjos e integrações aceitam captura parcial. Em entregas divididas, pode haver múltiplas capturas, desde que o parceiro e a modalidade suportem o fluxo.

A autorização tem validade. Se a plataforma esperar além da janela permitida, a captura pode falhar e uma nova autorização pode ser necessária. Não existe prazo universal para todos os cartões e casos de uso. Bandeira, categoria, adquirente e tipo de autorização influenciam a regra. Por isso, a validade deve vir da documentação e do contrato do processador, não de uma constante assumida no código.

Também aqui a resposta pode ser assíncrona. Uma API aceitar a solicitação de captura significa que ela entrou em processamento, não que todas as etapas posteriores terminaram. O sistema precisa consumir o webhook correspondente e prever falha de captura, inclusive depois de uma aceitação inicial.

Compensação, liquidação e repasse não são sinônimos

Depois da captura, as informações financeiras seguem para compensação, também chamada de clearing. Nessa etapa, os participantes apuram obrigações, tarifas e valores líquidos. A liquidação é o cumprimento dessas obrigações entre os participantes do arranjo. Só depois o valor segue o calendário contratado para ficar disponível ao recebedor.

É comum usar “liquidado” e “pago ao lojista” como se fossem o mesmo evento. Nem sempre são. A documentação de ciclo de pagamentos da Adyen, por exemplo, distingue o recebimento dos fundos pelo provedor do pagamento efetivo ao estabelecimento, que depende do modelo e da agenda de repasse. Em uma plataforma com split, cada recebedor ainda pode ter agenda, retenção ou saldo próprios.

No cartão parcelado brasileiro, há outra camada: o comprador paga parcelas, enquanto as condições comerciais definem como o recebedor recebe e se existe antecipação de recebíveis. Antecipar não acelera magicamente a liquidação original. Trata-se de uma operação financeira sobre recebíveis, com custo e regras próprios.

O depósito tende a ser líquido, não igual ao valor exibido no checkout. Podem aparecer MDR, tarifa fixa, aluguel de serviço, antecipação, reserva, estorno, chargeback e ajustes. A conciliação precisa decompor essas parcelas.

Operações posteriores não substituem o pagamento

O pagamento pode receber operações relacionadas depois da venda. O lojista pode cancelar uma autorização antes da captura, solicitar a devolução de parte ou de todo o valor capturado, ou receber uma contestação do portador. O cancelamento encerra uma autorização não capturada. O reembolso cria um fluxo financeiro de retorno. A disputa segue as regras do arranjo e pode resultar em chargeback, inclusive sobre valores já repassados.

Esses eventos não devem reescrever o estado principal como se autorização e captura nunca tivessem ocorrido. O modelo preserva o pagamento e registra cada reembolso ou disputa como recurso relacionado, com valor, estado e histórico próprios. Uma transação de R$ 300 com reembolso parcial de R$ 80 continua capturada em R$ 300 e passa a ter um reembolso concluído de R$ 80. O saldo econômico é R$ 220, mas o histórico mostra como se chegou a ele.

Essa abordagem facilita auditoria e evita bugs em relatórios. Também prepara a plataforma para receber eventos fora de ordem. Um webhook pode ser repetido, atrasar ou chegar quando a tela do usuário já fechou. O consumidor do evento deve validar assinatura, persistir antes de processar, deduplicar pelo identificador e aceitar reprocessamento.

Aplicação prática: separe estados e operações

Em vez de um campo booleano pago, adote dimensões com significado operacional. No ciclo principal, os nomes exatos variam por provedor, mas um pagamento pode incluir:

• criado: intenção registrada, ainda sem resultado;
• autenticacao_pendente: cliente precisa concluir uma etapa;
• autorizado: emissor aprovou e reservou o valor;
• captura_pendente: captura solicitada e ainda sem resultado final;
• parcialmente_capturado ou capturado: cobrança confirmada para seguir ao fluxo financeiro;
• cancelado: autorização encerrada sem captura;
• recusado: tentativa de autorização negada.

Compensação, liquidação e repasse devem ficar em registros financeiros associados, cada qual com referência, valor e estado. Da mesma forma, um reembolso pode estar solicitado, concluido ou falhou, enquanto uma disputa pode estar aberta, ganha ou perdida. Assim, um pagamento capturado não vira estornado ou contestado: ele mantém seu histórico e passa a expor valores reembolsados, contestados e líquidos calculados a partir das operações relacionadas.

Defina quais transições são válidas em cada recurso e qual evento de negócio cada uma dispara. Estoque não deve baixar duas vezes porque o webhook foi repetido. Um timeout não deve transformar estado desconhecido em recusa. Se a API não respondeu, consulte a transação pela referência ou repita com a mesma chave idempotente, conforme o contrato da API.

Para conciliar, mantenha três visões ligadas pela mesma referência: pedido, transação e lançamento financeiro. Todos os dias, compare o livro-razão interno com os relatórios do provedor e o extrato bancário. Separe divergências por motivo e idade. Uma diferença recente pode ser calendário; uma diferença antiga pede investigação.

No sandbox, teste mais que aprovação e recusa. Simule captura parcial, captura expirada, webhook duplicado, evento fora de ordem, estorno após repasse e falha entre a resposta da API e a gravação local. Esse conjunto revela se a integração é confiável.

Próximos Passos

Com o ciclo compreendido, documente quem assume cada saldo e cada risco. Em uma venda simples há um recebedor. Em marketplaces, a mesma captura pode originar comissão da plataforma, valor do vendedor e remuneração de outro participante. Reembolso e chargeback precisam percorrer esse desenho no sentido inverso.

O próximo artigo explica essa camada: Split de Pagamentos para Marketplaces. Para rever o ponto de entrada da jornada dentro do software, leia Pagamentos Embarcados.

Conclusão / CTA

Uma operação confiável não chama tudo de “aprovado”. Ela sabe em qual etapa cada valor está, reage a eventos assíncronos e fecha o financeiro até o repasse. A Plutech oferece infraestrutura white label com multi-acquiring, split, conformidade PCI DSS e suporte a PIX. Fale com nosso time para avaliar o desenho adequado à sua operação.

Fontes

• Payments lifecycle. Adyen Docs, estados de autorização, captura, liquidação, reembolso e disputa.
• Capture. Adyen Docs, captura automática, manual e parcial.
• API idempotency. Adyen Docs, repetição segura de requisições.
• EMV 3-D Secure. EMVCo, autenticação em pagamentos de cartão não presente.
• PCI Data Security Standard. PCI Security Standards Council, proteção de dados de conta.
• Sistema de Pagamentos Brasileiro. Banco Central do Brasil, infraestrutura e liquidação no SPB.