Visa e Mastercard: como funcionam as redes de cartões para devs

O que são Visa e Mastercard?

Visa e Mastercard são redes de tecnologia de pagamentos. Elas conectam o cliente, o lojista, o banco que emitiu o cartão, o adquirente e os processadores que participam da transação. Por isso, não são o banco do cliente e também não são o gateway que aparece na tela do checkout.

A história ajuda a separar as peças. A Visa tem raízes no BankAmericard, lançado em 1958, e a marca Visa surgiu em 1976. A Mastercard nasceu em 1966 como Interbank Card Association e adotou o nome Mastercard em 1979. As duas evoluíram para redes globais de autorização, compensação e liquidação.

O assunto interessa cada vez mais a quem desenvolve porque pagamentos digitais misturam produto, infraestrutura e segurança. Um checkout rápido depende de uma cadeia que precisa responder em segundos, lidar com recusas, confirmar eventos e manter os dados do cartão fora da aplicação sempre que possível.

Como funciona uma compra

Imagine o fluxo básico: o cliente confirma o pedido, o checkout encaminha os dados tokenizados para um gateway ou processador, o adquirente envia a solicitação à rede, e a rede consulta o banco emissor. A resposta volta pelo mesmo caminho até a aplicação decidir se mostra pagamento aprovado ou recusado.

Na autorização, o emissor verifica o cartão, o limite ou saldo disponível, as regras de risco e os sinais de fraude. Visa ou Mastercard transportam a mensagem e aplicam regras da rede, mas a decisão de aprovar ou recusar vem da instituição que emitiu o cartão. O gateway e o adquirente fazem a ponte operacional para o comerciante.

Depois da autorização, vêm a captura, a compensação e a liquidação. A captura confirma que o comerciante quer concluir a cobrança. A compensação organiza os valores e as mensagens entre os participantes. A liquidação movimenta os recursos entre as instituições conforme o arranjo contratado, que pode ter prazos e condições diferentes.

Principais recursos no ecossistema

O recurso central é a interoperabilidade. Um lojista não precisa ter uma conexão particular com cada banco emissor. Ele usa um adquirente ou provedor de pagamentos, e a rede ajuda a levar a autorização até a instituição correta e devolver uma resposta padronizada.

Para quem desenvolve, as redes também oferecem produtos e APIs para pagamentos digitais, autenticação, tokenização, prevenção a fraude, pagamentos recorrentes, dados e gestão de disputas. O catálogo exato depende do país, do produto, do contrato e do parceiro que fará a integração.

Na prática, o valor técnico aparece em quatro frentes que precisam ser desenhadas juntas:

• Autorização e captura: receber a decisão do emissor e controlar quando a cobrança deve ser concluída.
• Tokenização: trocar o número do cartão por um identificador que reduz a exposição do dado sensível.
• APIs e integrações: conectar checkout, gateway, adquirente e sistemas internos com contratos claros.
• Risco e disputas: tratar autenticação, antifraude, estorno e chargeback sem esconder o estado real do pedido.

Como começar: acesso e integração

O caminho mais comum para uma empresa pequena ou média é começar por um gateway, adquirente ou provedor de serviços de pagamento. A integração direta com Visa ou Mastercard pode exigir cadastro, certificação, parceria comercial e requisitos técnicos específicos. O Visa Developer Center, por exemplo, separa recursos de sandbox das condições de produção.

Antes de escrever código, defina quem será o responsável por tokenizar o cartão, autorizar a transação, enviar webhooks, conciliar valores e responder a disputas. Essa divisão evita que o time trate o gateway como se fosse o emissor ou a rede como se fosse o dono da conta do cliente.

Um roteiro seguro para sair do zero é:

1. Mapeie o fluxo: pedido criado, pagamento pendente, autorizado, capturado, recusado, estornado e contestado.
2. Escolha o parceiro: compare cobertura, métodos aceitos, suporte a sandbox, webhooks, relatórios e condições comerciais.
3. Crie o projeto de teste: use as credenciais de sandbox e cartões de teste fornecidos pelo parceiro, nunca dados reais.
4. Implemente os eventos: valide assinatura, grave o identificador do evento e torne o processamento idempotente.
5. Prepare a produção: revise PCI DSS, chaves, logs, alertas, conciliação e o procedimento para estornos antes de liberar tráfego.

Exemplo prático de webhook confiável

Considere uma loja virtual que cria o pedido como pendente e só muda para pago quando recebe um evento assinado do provedor. A aplicação não deve confiar apenas no retorno do navegador, porque o cliente pode fechar a página, repetir a requisição ou perder a conexão depois da autorização.

O trecho abaixo mostra a ideia de idempotência sem depender de uma bandeira específica. Em produção, o conjunto em memória deve ser substituído por uma tabela ou coleção com índice único e a assinatura deve ser validada com o segredo do webhook.

type PaymentEvent = {
  id: 'event-id';
  type: 'payment.authorized' | 'payment.declined';
  orderId: 'order-id';
};

export function consumePaymentEvent(
  event: PaymentEvent,
  processedIds: Set<string>
): 'paid' | 'declined' | 'ignored' {
  if (processedIds.has(event.id)) return 'ignored';

  processedIds.add(event.id);
  return event.type === 'payment.authorized' ? 'paid' : 'declined';
}

O ponto importante não é o nome do evento, e sim o comportamento. Se o provedor reenviar o mesmo evento, o pedido não pode ser pago duas vezes. Se chegar uma recusa depois de uma aprovação, a máquina de estados deve aceitar apenas transições válidas e registrar a sequência para auditoria.

Comparação com alternativas

Visa e Mastercard são redes de cartões. Elas não substituem um gateway, um adquirente, um processador ou um sistema de cobrança. Essa diferença é essencial para o dev, porque o contrato de integração e o formato das APIs normalmente vêm do parceiro que expõe o serviço ao seu produto.

A escolha depende do problema que você está resolvendo:

• Visa: faz sentido quando o parceiro oferece acesso aos produtos Visa, à rede VisaNet ou a APIs do Visa Developer Center.
• Mastercard: faz sentido quando a solução depende dos produtos, APIs e serviços do Mastercard Developers.
• Gateway ou PSP: costuma ser o caminho mais simples para aceitar vários métodos e delegar partes da conexão com adquirentes e redes.
• Pix: é uma alternativa de pagamento instantâneo que não usa a mesma rede de cartões e pode complementar o checkout no Brasil.

O ponto forte de Visa e Mastercard é a escala da rede e a interoperabilidade entre muitos participantes. O ponto forte de um provedor de pagamentos é esconder parte dessa complexidade em uma integração única. Um produto pode usar os dois níveis ao mesmo tempo, desde que saiba qual sistema é a fonte de cada estado.

Pontos positivos e limitações

As redes oferecem alcance, padrões operacionais e uma infraestrutura madura para autorizar transações em diferentes canais. Para o comerciante, isso reduz a necessidade de negociar uma conexão técnica com cada emissor. Para o dev, significa trabalhar com fluxos conhecidos de autorização, captura, estorno e disputa.

Existe uma limitação importante: a rede não elimina a complexidade comercial nem a responsabilidade de segurança. Taxas, prazos de liquidação, cobertura geográfica, regras de chargeback, produtos disponíveis e suporte variam conforme o país, o adquirente, o emissor e o contrato.

Também há dependências operacionais. Um provedor pode ficar indisponível, um emissor pode recusar uma compra legítima e um webhook pode chegar atrasado. O sistema precisa mostrar estados intermediários, permitir reconciliação e evitar que uma falha de comunicação vire cobrança duplicada ou pedido marcado como pago sem confirmação.

Casos de uso reais

Em um e-commerce, o fluxo costuma começar no checkout e terminar na confirmação do pedido. O time precisa lidar com autorização, captura, expiração de sessão, estorno e atualização por webhook. O cliente deve receber uma mensagem útil sem que a aplicação revele detalhes desnecessários do motivo da recusa.

Em um SaaS, a cobrança recorrente exige mais do que autorizar o primeiro pagamento. O produto precisa acompanhar renovação, cartão atualizado, falha temporária, cancelamento e reembolso. Tokenização e eventos assíncronos ajudam a manter o número do cartão fora da base principal.

Em um marketplace ou aplicativo, o desafio inclui separar comprador, vendedor, plataforma, repasse e conciliação. O parceiro de pagamentos pode oferecer produtos próprios para esse cenário, mas as regras de responsabilidade, cadastro e liquidação precisam ser confirmadas antes de prometer uma experiência na interface.

Dicas e boas práticas

O melhor desenho trata pagamento como uma máquina de estados auditável. Cada transição deve ter origem, horário, identificador externo e resultado. Em vez de assumir que uma resposta positiva encerra o fluxo, aguarde o evento definitivo do parceiro e concilie com o relatório financeiro.

Vale a pena?

Vale a pena entender Visa e Mastercard mesmo quando a integração será feita por um provedor. Essa visão permite identificar onde ocorre a autorização, quem decide a recusa, qual sistema envia o webhook e onde os valores aparecem na conciliação.

Para a maioria dos produtos, começar com um gateway ou PSP bem documentado é mais simples do que tentar construir uma conexão direta com uma rede global. A integração direta pode fazer sentido em cenários regulados, de grande escala ou com requisitos específicos de parceria, mas exige mais certificação e operação.

O próximo passo é desenhar o fluxo completo em um quadro, escolher um ambiente de sandbox e implementar primeiro a máquina de estados com idempotência. Quando o checkout sobreviver a retries, recusas, estornos e webhooks atrasados no teste, aí sim ele estará pronto para uma revisão de produção.