Pagamentos com cartão
Pagamentos com cartão: do terminal ao adquirente e de volta ao razão
Terminais EMV e gateways de pagamento conectados a adquirentes por ISO 8583 ou APIs, com arquivos de liquidação conciliados no ERP.
Blueprint
Role para o lado para ver o desenho completo.
Pagamentos com cartão: autorizados no caixa, liquidados depois, conciliados no ERP
O terminal ou o checkout consulta o gateway, o gateway consulta o adquirente, e o adquirente encaminha para a bandeira do cartão e o emissor. Os arquivos de liquidação chegam depois e são conciliados com vendas e tarifas no ERP. A ausência de resposta a tempo dispara um estorno para que o cliente nunca seja cobrado duas vezes.
- Fluxo principal
- Assíncrono
- Caminho de exceção
O fluxo em 8 etapas
O fluxo, etapa a etapa
- De Terminal EMV ou checkout on-line para Gateway de pagamento: Solicitação de autorização, por EMV · REST/JSON (fluxo principal).
- De Gateway de pagamento para Adquirente: Autorização, por ISO 8583 (fluxo principal).
- De Adquirente para Bandeira do cartão e emissor: Encaminhada ao emissor, por ISO 8583 (fluxo principal).
- De Adquirente para Gateway de pagamento: Aprovada ou recusada, por ISO 8583 (assíncrono).
- De Adquirente para Camada de integração: Arquivos de liquidação e tarifas, por SFTP (assíncrono).
- De Camada de integração para ERP: Vendas liquidadas, tarifas e repasses, por REST/JSON (fluxo principal).
- De Gateway de pagamento para Terminal EMV ou checkout on-line: Sem resposta a tempo: estorno automático, por ISO 8583 0400 (caminho de exceção).
- De Camada de integração para Equipe de operações de pagamentos: Divergência de liquidação ou chargeback (caminho de exceção).
Visão geral
Este é o caminho de um pagamento com cartão, do terminal ou do checkout on-line ao adquirente, à bandeira do cartão e ao emissor, e de volta. O cliente espera a resposta no caixa. O dinheiro, menos as tarifas, chega depois em um arquivo de liquidação que precisa ser conciliado com as vendas no seu ERP.
O desenho de referência envia as autorizações por um gateway de pagamento que tokeniza o cartão e encaminha a requisição ao adquirente, por ISO 8583 ou pela API do adquirente. Os arquivos de liquidação e de tarifas são recolhidos pela camada de integração, conciliados com as vendas originais e registrados no ERP como vendas, tarifas e repasses.
O desenho também cobre o que dá errado. Uma requisição que não recebe resposta a tempo é estornada, para que o cliente não seja cobrado duas vezes. Uma liquidação que não corresponde, ou um chargeback, vai para a sua equipe de operações de pagamentos com a venda original anexada.
Como o fluxo funciona
Começar no terminal ou no checkout
O terminal EMV lê o chip ou o cartão por aproximação, ou o checkout on-line recolhe os dados do cartão por uma página hospedada, e envia uma requisição de autorização ao gateway.
Autorizar pelo gateway
O gateway substitui o número do cartão por um token e envia a autorização ao adquirente, por ISO 8583 ou pela API do adquirente.
Encaminhar ao emissor
O adquirente encaminha a requisição pela bandeira do cartão ao emissor, que a aprova ou recusa.
Devolver a resposta
A aprovação ou recusa volta pelo mesmo caminho até o terminal ou checkout, com o seu código de resposta.
Receber a liquidação
O adquirente envia depois os arquivos de liquidação e de tarifas, que a camada de integração recolhe e valida.
Conciliar e lançar
A camada concilia as transações liquidadas com as vendas originais e registra vendas, tarifas e repasses no ERP.
Quando algo falha
Sem resposta a tempo
Se o gateway não recebe resposta dentro do limite de tempo do adquirente, envia um estorno, uma mensagem ISO 8583 0400 ou o equivalente na sua API, para que o cliente nunca seja cobrado por uma venda que não se completou.
Um pagamento é recusado
O código de resposta chega ao caixa ou checkout com uma mensagem clara. As taxas de recusa são monitoradas, para que um salto que indique falha técnica gere um alerta.
A liquidação não corresponde
Um valor liquidado diferente da venda, ou uma venda sem liquidação, vai para uma lista de revisão da sua equipe de operações de pagamentos, com os dois registros lado a lado.
Um portador contesta um pagamento
O relatório de disputas do adquirente é importado e vinculado à venda e à liquidação originais, para que a sua equipe possa responder com as evidências em um só lugar.
Normas e sistemas
- Normas e canais bancários
- SFTP (H2H)
- Pagamentos
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integração
- REST
- Webhooks
Perguntas e respostas
Qual é a diferença entre um gateway e um adquirente?
O adquirente é o banco ou a instituição licenciada que processa pagamentos com cartão para você e repassa o dinheiro. O gateway é o serviço técnico à frente dele que recebe requisições de terminais e checkouts, tokeniza cartões e encaminha essas requisições. Alguns provedores fazem as duas coisas. O desenho funciona de qualquer forma e mantém os dois papéis claros.
Isso mantém os dados de cartão fora dos nossos sistemas?
Esse é o objetivo do desenho. Os números de cartão são capturados pelo terminal certificado ou por uma página de pagamento hospedada e substituídos por tokens no gateway, então o seu POS, o seu ERP e os seus repositórios de dados só veem tokens. Isso reduz a parte do seu parque à qual o PCI DSS se aplica. O seu avaliador confirma o escopo final.
O ISO 8583 é igual para todo adquirente?
Não. O ISO 8583 define uma estrutura, e cada adquirente ou rede publica a sua própria especificação de campos, tipos de mensagem e códigos. É por isso que construímos a partir da especificação do adquirente e executamos os seus testes de certificação. Uma API de gateway à frente do adquirente esconde essas diferenças, o que costuma ser mais simples para o varejo.
Por que a liquidação chega depois da venda?
A autorização apenas reserva os fundos. O adquirente liquida em lotes, depois de deduzir as suas tarifas e quaisquer encargos da bandeira, e repassa no seu próprio cronograma. É por isso que o desenho trata autorização e liquidação como eventos separados e os concilia, para que as finanças vejam o que foi vendido, o que foi liquidado e o que ainda está por vir.
Vocês suportam EMV 3-D Secure para pagamentos on-line?
Sim. Para pagamentos on-line com cartão, integramos o EMV 3-D Secure pelo gateway, para que o emissor possa autenticar o portador onde a regulação ou o risco exigir. Tratamos os fluxos com desafio e sem atrito no checkout e testamos os dois com os cartões de teste do provedor.
Podemos usar mais de um provedor de pagamentos?
Sim. A camada de integração mantém um modelo interno único de pagamento e o mapeia para cada provedor, para que você possa rotear por canal, país ou tipo de cartão, ou mover volume entre provedores. Cada provedor ainda precisa da sua própria integração e certificação, que planejamos provedor por provedor.
Comece com uma conversa, não com um contrato.
Conte o que você precisa construir, conectar ou proteger. Um arquiteto analisa com você e recomenda por onde começar.
O que acontece a seguir
Definição do horário
Nossa equipe envia um e-mail para combinar o horário da sessão.
Sessão de pré-consultoria
Uma sessão on-line gratuita de pré-consultoria de 30 minutos: analisamos os seus objetivos, sistemas e restrições.
Avaliação de prontidão
Em uma avaliação de prontidão gratuita de 48 horas, um arquiteto principal verifica o seu projeto com a Definição de Prontidão em 6 pontos e recomenda a trilha adequada.
Escolha da trilha
Projetos com escopo pronto recebem uma proposta vinculante em 3 a 5 dias úteis. Projetos em estágio de conceito começam no Blueprint Studio. Um sistema em produção com falhas, não documentado ou que precisa de integração começa com um diagnóstico de 1 a 2 semanas. O Blueprint Studio e o diagnóstico têm cada um uma taxa fixa, cotada na proposta.