Como funcionam os pagamentos com cartão: modelo de quatro partes, autorização e PCI DSS

Pagar aproximando o cartão é uma das poucas experiências de consumo que escondem uma indústria inteira atrás de um segundo de latência. Nesse segundo, uma requisição sai do terminal rumo a um banco adquirente, atravessa a rede de uma bandeira, chega ao sistema de autorização de um banco emissor e volta com um código de aprovação. Depois, ao longo dos dias seguintes, um conjunto de arquivos totalmente separado movimenta o dinheiro, aplica as tarifas e, de vez em quando, desfaz tudo.

Engenheiros costumam enxergar só uma fatia disso — um formulário de checkout ou o SDK de um terminal — e herdam um vocabulário que parece arbitrário até que o quadro completo fique visível. Este guia entrega esse quadro. Ele parte dos conceitos de livro-razão e liquidação vistos em fundamentos de sistemas de pagamento; o cartão é apenas um instrumento que roda sobre eles.

O modelo de quatro partes

A transação clássica com cartão envolve quatro instituições e uma assimetria muito útil.

• O portador tem um cartão emitido em seu nome.
• O emissor é o banco do portador. Ele é dono da conta, decide se aprova uma transação e arca com a maior parte das perdas por fraude nas transações autenticadas.
• O lojista vende algo e quer receber.
• O adquirente é o banco do lojista. Ele credencia o lojista, recebe suas transações e paga o lojista já com as tarifas descontadas.
• A bandeira — a rede de cartões — fica entre emissor e adquirente e fornece a rede de roteamento, o regulamento, a arbitragem de disputas e o cálculo da liquidação. Ela não é parte da venda.

A assimetria é que o portador e o lojista não têm nenhuma relação com o banco um do outro, e mesmo assim a transação funciona porque os dois bancos seguem o mesmo regulamento. É esse regulamento, e não algum contrato bilateral, que torna um cartão utilizável em um país que você nunca visitou.

Um modelo de três partes junta emissor, adquirente e bandeira em uma única empresa, com relação direta tanto com o portador quanto com o lojista. Isso dá a essa empresa um controle maior sobre preços e aceitação, ao custo de uma rede de lojistas que cresce bem mais devagar. Na prática, as grandes bandeiras hoje misturam os dois modelos.

Entre o lojista e o adquirente, a maioria das empresas modernas coloca um provedor de serviços de pagamento (PSP) ou gateway, que fornece as APIs, o checkout hospedado, os tokens e muitas vezes o motor de risco. Alguns provedores também têm a própria licença de adquirência.

O cartão, o número e o chip

O número da conta principal (PAN) normalmente tem 16 dígitos, embora o padrão permita até 19. Os primeiros dígitos formam o issuer identification number (historicamente o BIN), que identifica a instituição emissora, a bandeira e o tipo de produto, e é a base das decisões de roteamento e aceitação antes de qualquer chamada à rede. O último dígito é um dígito verificador calculado com o algoritmo de Luhn.

Validate 4111 1111 1111 1111

Starting from the rightmost digit, double every second digit
(the check digit itself is never doubled). If a doubled value
exceeds 9, subtract 9.

  digits   4  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
  double   x     x     x     x     x     x     x     x
  becomes  8  1  2  1  2  1  2  1  2  1  2  1  2  1  2  1

  sum = 8 + (7 x 2) + (8 x 1) = 8 + 14 + 8 = 30
  30 mod 10 == 0  ->  the number is internally consistent

Para gerar um dígito verificador em vez de validá-lo, aplique a mesma ponderação ao número com um zero na última posição e calcule (10 - sum mod 10) mod 10.

function luhnValid(pan) {
  let sum = 0;
  for (let i = 0; i < pan.length; i++) {
    let d = pan.charCodeAt(pan.length - 1 - i) - 48;
    if (d < 0 || d > 9) return false;
    if (i % 2 === 1) { d *= 2; if (d > 9) d -= 9; }
    sum += d;
  }
  return pan.length >= 12 && sum % 10 === 0;
}

Fisicamente, o cartão evoluiu muito desde a tarja magnética, que guardava uma cópia estática dos dados e, por isso, podia ser clonada por qualquer um que a lesse uma única vez. Os cartões com chip EMV a substituem por um pequeno computador que assina um criptograma sobre os dados da transação com uma chave que nunca sai do chip, de modo que um tráfego interceptado não pode ser reproduzido. O pagamento por aproximação usa a mesma criptografia sobre uma interface de rádio, com limites offline e pedidos periódicos de PIN para limitar o risco de um cartão perdido.

Em uma carteira digital no celular ou no relógio, o cartão é tokenizado pela rede: a carteira não guarda o número real, e sim um token PAN específico do dispositivo, emitido pelo serviço de tokens da bandeira, com um criptograma próprio a cada transação. Se o token vazar, ele não serve em outro dispositivo, e o cartão subjacente não precisa ser reemitido. A tokenização de cartões salvos (card-on-file) aplica a mesma ideia às assinaturas, com um efeito colateral agradável: as atualizações de data de validade se propagam sem que o cliente precise fazer nada.

Os três ou quatro dígitos impressos no cartão (o código de segurança) existem apenas para provar a posse do cartão em transações remotas. Armazená-los depois da autorização é terminantemente proibido: não existe nenhuma configuração em conformidade em que você possa guardá-los.

Autorização, captura, compensação e liquidação

Quatro palavras que iniciantes usam como sinônimos e que significam quatro coisas diferentes.

A autorização pede ao emissor, em tempo real, que verifique a conta e reserve o valor. A resposta é um código de aprovação ou um motivo de recusa. Nenhum dinheiro se move; a reserva reduz o saldo disponível do portador e expira após um prazo definido pela bandeira se não for usada.

A captura (ou confirmação) avisa o adquirente que a mercadoria foi despachada e que o lojista agora cobra o valor. Muitas empresas autorizam no checkout e capturam no envio; hotéis e bombas de combustível autorizam uma estimativa e capturam um valor final diferente, dentro de certos limites.

A compensação (clearing) é a troca, via bandeira, dos registros de transações capturadas entre adquirente e emissor, normalmente em lotes diários, aplicando no caminho a tarifa de intercâmbio e as tarifas da bandeira.

A liquidação (settlement) é a movimentação efetiva de fundos entre os bancos, com os valores compensados em termos líquidos pela bandeira, seguida do pagamento do adquirente ao lojista conforme o seu próprio calendário.

Day 0  10:32  Authorization request  (terminal -> acquirer -> scheme -> issuer)
       10:32  Approval, funds reserved on the cardholder account
Day 1  09:00  Capture / presentment batch sent by the acquirer
Day 1  22:00  Clearing: scheme computes net positions, applies fees
Day 2  08:00  Interbank settlement
Day 3        Merchant credited, net of the merchant service charge
Day 40       Cardholder disputes -> chargeback -> possible representment

As tarifas correm no sentido contrário ao do dinheiro. O lojista paga ao adquirente uma taxa de desconto (MDR), da qual o adquirente repassa a tarifa de intercâmbio ao emissor e uma tarifa à bandeira. O intercâmbio é o que permite aos emissores oferecer cartões sem anuidade e programas de pontos, e também o motivo pelo qual reguladores de várias regiões o limitaram para cartões de pessoa física. Trate a mecânica aqui como conceitual: as taxas mudam e dependem de cada jurisdição.

Os chargebacks são o mecanismo de disputa. O portador reclama com o emissor, o emissor recupera os fundos do adquirente com um código de motivo (fraude, produto não entregue, valor incorreto, cobrança em duplicidade), e o lojista pode responder com provas em uma reapresentação. As bandeiras monitoram os índices de chargeback, e um índice alto de forma persistente custa ao lojista o direito de aceitar cartões. Na prática, isso significa que os seus sistemas precisam conseguir apresentar, meses depois, a prova do que foi pedido, autenticado, enviado e entregue — um bom argumento para manter logs imutáveis de pedidos e de autenticação.

Autenticação: 3-D Secure e SCA

Transações remotas não têm um chip para provar que o cartão está presente, então as bandeiras criaram o 3-D Secure: uma etapa de autenticação entre o lojista, o servidor de diretório (directory server) da bandeira e o servidor de controle de acesso (ACS) do emissor. A primeira geração era a famosa janela pop-up de senha. A geração atual é baseada em risco: o lojista envia um conjunto rico de dados do dispositivo, da transação e de comportamento, e o emissor decide entre uma aprovação frictionless e um challenge (normalmente uma notificação push no app do banco).

Pelas regras europeias, a autenticação forte do cliente (SCA) exige dois fatores independentes, entre conhecimento, posse e inerência, na maioria dos pagamentos eletrônicos, com isenções definidas: transações de baixo valor, pagamentos recorrentes de valor fixo após o primeiro, lojistas que o portador colocou em uma lista de confiança e análise de risco da transação abaixo de um limite de taxa de fraude. O contexto regulatório é o mesmo descrito em PSD2 e open banking.

Daí decorrem duas consequências de engenharia. Primeiro, a autenticação é assíncrona e pode redirecionar ou abrir um app, então o seu checkout precisa ser retomável: um cliente que se autentica no celular e volta dois minutos depois não pode perder o carrinho. Segundo, uma autenticação bem-sucedida em geral transfere a responsabilidade pela fraude para o emissor; portanto, a justificativa para um challenge não é só conformidade — ela muda quem paga quando a transação se revela fraudulenta.

{
  "amount": { "currency": "EUR", "value": 4990 },
  "paymentMethod": { "type": "scheme", "token": "tok_9f3c1a7b" },
  "authentication": {
    "threeDSRequestorChallengeIndicator": "no-preference",
    "exemption": "transaction-risk-analysis"
  },
  "merchantOrderReference": "ORD-2026-114522",
  "shopperInteraction": "Ecommerce"
}

PCI DSS e como manter o escopo pequeno

O Payment Card Industry Data Security Standard se aplica a qualquer organização que armazene, processe ou transmita dados de portadores de cartão. Seus requisitos cobrem segmentação de rede, criptografia em trânsito e em repouso, controle de acesso, registro de eventos, gestão de vulnerabilidades e testes regulares; o esforço de validação vai de um questionário curto de autoavaliação até uma auditoria presencial, conforme o volume e o tipo de integração.

A decisão de arquitetura mais valiosa, de longe, é ficar totalmente fora do ambiente de dados do portador. Da menos à mais trabalhosa:

1. Redirecionamento ou página de pagamento hospedada. O cliente digita o cartão na página do provedor. Os seus servidores nunca veem um PAN.
2. Campos hospedados / iframe. Os campos do cartão são renderizados pelo provedor dentro do seu checkout: a aparência é sua, os dados são dele. Costuma ser o ponto ideal.
3. Criptografia no cliente ou API direta para o provedor. O navegador criptografa os dados do cartão ou os envia direto ao provedor; o seu backend recebe apenas um token.
4. Coleta no servidor. A sua aplicação recebe PANs em claro. Escopo de auditoria completo, testes de intrusão, segmentação, gestão de chaves — só vale a pena com um motivo muito forte.

Seja qual for a escolha, as defesas de sempre continuam valendo: nunca registre em log um PAN ou código de segurança (filtre no framework de logging, não em cada ponto de chamada), mascare deixando os seis primeiros e os quatro últimos dígitos quando for realmente necessário exibir, guarde tokens em vez de números no banco de dados e trate a página de checkout como crítica para a segurança, porque um script injetado ali derruba qualquer iframe. Os guias de OWASP Top 10 e de arquitetura de segurança de aplicações cobrem a higiene ao redor.

Integração com um provedor

Um checklist de integração que funciona, aprendido a duras penas por muitas equipes:

• Idempotência em toda chamada que altera estado. Uma captura repetida não pode capturar duas vezes; envie uma chave estável derivada do identificador do seu pedido.
• A fonte da verdade são os webhooks, não a resposta HTTP. Resultados de autorização, chargebacks e notificações de liquidação chegam de forma assíncrona, às vezes fora de ordem e mais de uma vez. Verifique as assinaturas, deduplique pelo id do evento e torne os handlers idempotentes.
• Guarde as referências do provedor — código de autorização, id da transação, token, referência da bandeira — junto ao seu pedido. Todo atendimento de suporte e toda disputa vão precisar delas.
• Concilie diariamente o relatório de liquidação com os seus próprios registros, cruzando pela referência do provedor, e gere alertas para itens sem correspondência nas duas direções.
• Modele explicitamente capturas parciais, estornos parciais e expirações. Não são casos extremos; são o dia a dia.
• Teste recusas, não só aprovações. Os provedores publicam cartões de teste para saldo insuficiente, cartão vencido, “do not honour”, challenge do 3-D Secure e timeouts. Um checkout que só trata o sucesso está pela metade.
• Nunca crie o seu próprio loop de novas tentativas sobre uma recusa. Tentativas repetidas em um cartão recusado são penalizadas pelas bandeiras, e é assim que um lojista acaba em um programa de monitoramento.

Projete a fronteira da API de modo que o provedor possa ser substituído: uma pequena abstração interna de pagamentos, com o seu próprio vocabulário de status e mapeada na borda, poupa uma reescrita quando as condições comerciais mudam. Os princípios gerais de design de APIs REST se aplicam diretamente.

Principais pontos

• Quatro instituições — emissor, adquirente, bandeira e lojista, geralmente com um PSP no meio — cooperam sob o regulamento de uma bandeira que nem o portador nem o lojista assinam.
• O PAN codifica o emissor nos primeiros dígitos e termina com um dígito verificador de Luhn que detecta erros de digitação e nada mais.
• Criptogramas EMV e tokens de rede substituem dados de cartão estáticos e clonáveis por uma prova única por transação, e é por isso que as carteiras digitais são mais seguras do que os números por trás delas.
• A autorização reserva, a captura cobra, a compensação troca registros e a liquidação movimenta o dinheiro — com dias de intervalo e disputas que podem voltar meses depois.
• O 3-D Secure e a autenticação forte acrescentam atrito, mas transferem a responsabilidade pela fraude; construa um checkout que possa ser interrompido e retomado.
• Escolha uma integração que mantenha os dados de cartão fora dos seus servidores: o escopo PCI DSS é decidido pela arquitetura muito antes de ser decidido pela papelada.