Pagamentos com cartão
Pagamentos com cartão: do terminal ao adquirente e de volta ao razão
Terminais EMV e gateways de pagamento ligados a adquirentes por ISO 8583 ou APIs, com ficheiros de liquidação reconciliados no ERP.
Blueprint
Role para o lado para ver o desenho completo.
Pagamentos com cartão: autorizados no caixa, liquidados depois, reconciliados no ERP
O terminal ou o checkout consulta o gateway, o gateway consulta o adquirente, e o adquirente encaminha para a rede do cartão e o emissor. Os ficheiros de liquidação chegam depois e são reconciliados com vendas e tarifas no ERP. Um timeout 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 em linha para Gateway de pagamento: Pedido 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 Rede 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: Ficheiros de liquidação e tarifas, por SFTP (assíncrono).
- De Camada de integração para ERP: Vendas liquidadas, tarifas e pagamentos, por REST/JSON (fluxo principal).
- De Gateway de pagamento para Terminal EMV ou checkout em linha: Sem resposta a tempo: estorno automático, por ISO 8583 0400 (caminho de exceção).
- De Camada de integração para Equipa 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 em linha ao adquirente, à rede do cartão e ao emissor, e de volta. O cliente espera a resposta no caixa. O dinheiro, menos as tarifas, chega depois num ficheiro de liquidação que precisa ser reconciliado 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 o pedido ao adquirente, por ISO 8583 ou pela API do adquirente. Os ficheiros de liquidação e de tarifas são recolhidos pela camada de integração, reconciliados com as vendas originais e registados no ERP como vendas, tarifas e repasses.
O desenho também cobre o que dá errado. Um pedido que não recebe resposta a tempo é estornado, para que o cliente não seja cobrado duas vezes. Uma liquidação que não corresponde, ou um chargeback, vai para a sua equipa 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 em linha recolhe os dados do cartão por uma página hospedada, e envia um pedido 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 o pedido pela rede 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 ficheiros de liquidação e de tarifas, que a camada de integração recolhe e valida.
Reconciliar e lançar
A camada reconcilia as transações liquidadas com as vendas originais e regista vendas, tarifas e pagamentos 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 monitorizadas, 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 equipa de operações de pagamentos, com os dois registos 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 equipa possa responder com as evidências num 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 si e paga o dinheiro. O gateway é o serviço técnico à frente dele que recebe pedidos de terminais e checkouts, tokeniza cartões e as encaminha. Alguns fornecedores 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, por isso 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 aplica-se. O seu avaliador confirma o âmbito 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 retalho.
Por que razão 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 rede do cartão, e paga segundo o seu próprio calendário. É por isso que o desenho trata autorização e liquidação como eventos separados e os reconcilia, para que as finanças vejam o que foi vendido, o que foi liquidado e o que ainda está por vir.
Suportam EMV 3-D Secure para pagamentos em linha?
Sim. Para pagamentos em linha 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 fornecedor.
Podemos usar mais de um fornecedor de pagamentos?
Sim. A camada de integração mantém um modelo interno único de pagamento e o mapeia para cada fornecedor, para que possa rotear por canal, país ou tipo de cartão, ou mover volume entre fornecedores. Cada fornecedor ainda precisa da sua própria integração e certificação, que planeamos fornecedor por fornecedor.
Comece com uma conversa, não com um contrato.
Conte o que precisa construir, ligar ou proteger. Um arquiteto analisa consigo e recomenda por onde começar.
O que acontece a seguir
Definição do horário
A nossa equipa envia um e-mail para combinar o horário da sessão.
Sessão de pré-consultoria
Uma sessão em linha gratuita de pré-consultoria de 30 minutos: analisamos os seus objetivos, sistemas e restrições.
Avaliação de prontidão
Numa 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 o percurso adequado.
Escolha do percurso
Projetos com âmbito pronto recebem uma proposta vinculante em 3–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–2 semanas. O Blueprint Studio e o diagnóstico têm cada um uma taxa fixa, cotada na proposta.