Monitoração de meios de pagamento: o que medir em PIX, SiTEF, NFe, gateways e PDV

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado jan/2022Atualizado ago/2026

O cliente escolheu o produto, digitou o cartão, clicou em finalizar e recebeu uma mensagem de erro. A venda não entrou. No painel de infraestrutura, nada piscou: servidor no ar, link estável, banco respondendo. O carrinho não foi abandonado, foi recusado por um elo que ninguém estava medindo.

A cena se repete no PDV da loja física. O SiTEF perde a conexão com a administradora do cartão. A SEFAZ do estado para de autorizar nota. O gateway devolve timeout em uma bandeira só. Cada componente permanece verde. Ainda assim, a cadeia de pagamento está quebrada.

A monitoração de meios de pagamento existe para fechar esse vão. Ela cobre PIX, SiTEF, NFe, APIs de gateway, infraestrutura de PDV e ERP. Cada elo tem métrica e janela de normalidade próprias. Abaixo estão o sinal que chega primeiro em cada um e o limiar que sustenta alerta. Fecha o texto a forma de amarrar tudo ao processo de venda.

Por que o painel fica verde enquanto a venda não fecha

A cadeia de pagamento atravessa domínios com donos diferentes. Rede e servidor pertencem à infraestrutura, o SiTEF pertence ao time de loja. Já o gateway pertence a um fornecedor externo e o autorizador da nota pertence ao estado. Cada um monitora o próprio pedaço. Ninguém monitora a venda.

O efeito aparece no faturamento antes de aparecer no monitoramento. Dez minutos de recusa na autorização de cartão em horário de pico custam mais que duas horas de parada em um servidor secundário. Mesmo assim, o segundo dispara alerta e o primeiro passa despercebido.

Por isso a pergunta que organiza o desenho não é “o que está fora do ar”. É “qual processo de venda está degradado, em quantas lojas e há quanto tempo”. Todo o resto deste artigo serve para responder isso com número, não com suposição.

Como monitorar meios de pagamento, elo por elo

Cada infraestrutura da cadeia exige métrica própria. Os exemplos abaixo saíram de projetos que rodamos com clientes de varejo e de serviços. As telas são as mesmas que a operação usa no dia a dia.

PIX: o que o Banco Central garante e o que fica com você

O regulamento do SPI, aprovado pela Resolução BCB nº 195, fixa um índice de disponibilidade mínimo de 99,90%. Esse índice mede o grau de disponibilidade do SPI para os participantes. A fórmula é id = (hf/hp) x 100, apurada sobre as horas de funcionamento dos últimos três meses. São cerca de duas horas de parada admitidas por trimestre, do lado do Banco Central.

Do seu lado, a obrigação é outra. O regulamento manda o participante direto manter-se conectado ao SPI, apto a emitir e receber ordens de pagamento. São 24 horas por dia, em todos os dias do ano. Não existe janela de manutenção prevista, conforme o texto oficial da autoridade monetária.

Instrumentar o PIX significa separar três camadas. A primeira é a iniciação e a liquidação no SPI. A segunda é a consulta e o registro de chave no DICT. A terceira é a sua própria stack, com filas do RabbitMQ, pods e endpoints do Kubernetes. A armadilha mais cara é confundir degradação do Bacen com degradação própria.

Sem trace distribuído correlacionando as etapas pelo identificador da transação, o time discute em vez de decidir. O detalhamento de golden signals, indicadores de DICT e SLOs derivados está no guia técnico de monitoramento do sistema PIX.

SiTEF: a transação que morre entre o PDV e a administradora

O SiTEF concentra a transferência eletrônica de fundos entre o ponto de venda e as administradoras de cartão. Quando ele para, a loja continua aberta, o caixa continua atendendo e o pagamento simplesmente não passa.

Quatro métricas sustentam o diagnóstico. As duas primeiras são o status geral do serviço e o estado da conexão com cada administradora. As outras duas são o volume de transações por minuto e o tempo de resposta da autorização. A taxa de negadas por motivo fecha o quadro: ela separa falha técnica de recusa legítima do emissor.

O sinal mais rápido raramente é o erro. É a queda de volume: transações por minuto abaixo da linha de base. A comparação certa é com o mesmo dia da semana, na mesma faixa horária. Limiar fixo não funciona aqui, porque terça de manhã e sábado à tarde têm patamares distintos.

Com esse alerta em mãos, a operação ganha margem para acionar o plano B antes da fila crescer no caixa. Algumas redes automatizam desconto para outra forma de pagamento, o PIX entre elas, enquanto o TEF não volta.

NFe: o pedido que não fatura e o que mudou em 2026

Quando o autorizador da SEFAZ para, o pedido não vira nota e a mercadoria não sai. A monitoração sintética resolve a parte de disponibilidade. Um robô emite nota em ambiente de homologação contra cada autorizador, mede o tempo de resposta e registra o status, órgão por órgão.

Esse mesmo teste alimenta o SLA interno e antecipa a decisão de entrar em contingência. A consulta de status por estado, com histórico e leitura de tendência, aparece detalhada no guia de consulta de disponibilidade da NFe.

Em 2026 entrou uma variável nova. A Nota Técnica 2025.002 do projeto NF-e criou os grupos de IBS, CBS e Imposto Seletivo. A obrigatoriedade vale em ambiente de homologação desde 1º de julho e em produção desde 3 de agosto, para empresas do regime normal.

Em 1º de agosto de 2026, porém, o Ato Conjunto RFB/CGIBS nº 1/2026 mudou o jogo. Ele adiou para implementação futura a regra de validação que rejeitaria o documento sem esses grupos. A obrigação de informar, prevista na lei complementar que instituiu o novo modelo, continua valendo.

A consequência operacional é direta. Quem acompanha apenas a taxa de rejeição não enxerga o problema, porque a SEFAZ autoriza a nota mesmo sem os campos preenchidos. O que detecta é a validação do conteúdo do XML emitido, não só o retorno do autorizador.

APIs de gateway: onde a redundância só existe no slide

Quase nenhuma operação desenvolve gateway próprio. Ela se conecta a Cielo, Rede, Stone, PagBank, Mercado Pago ou a um orquestrador que conversa com vários. A vantagem é herdar certificação e prática de segurança. O custo é depender de um incidente que não está na sua mão.

Redundância entre adquirentes só funciona quando a medição vem antes. Teste as camadas separadamente, DNS, TCP, TLS e HTTP, a partir de mais de um ponto de origem. Em seguida, valide o corpo da resposta, JSON ou XML. Olhar só o código de retorno esconde a falha.

O indicador que decide o failover é a taxa de aprovação por adquirente, comparada à própria linha de base. Some o percentil 95 do tempo de autorização. Health check que devolve 200 OK com corpo de erro continua sendo o falso negativo mais comum. O tema aparece inteiro em como monitorar APIs em produção.

PDV: a loja que não tem quem vá até o rack

Cada loja carrega uma infraestrutura pequena e crítica: link de internet, Wi-Fi, firewall, servidor local, impressora fiscal e os terminais de caixa. Poucas têm equipe de TI no local. Todo diagnóstico começa remoto e o tempo de deslocamento entra na conta do MTTR.

Monitorar dispositivo por dispositivo em uma rede com centenas de lojas produz ruído. O agrupamento por unidade resolve: um estado consolidado por loja, com ranking das unidades por tempo sem transação. O gerente regional entende a lista, o técnico entende o item.

Do outro lado do balcão, a operação online carrega a própria cadeia de dependências. O problema de atribuição é o mesmo, detalhado em monitoramento de e-commerce.

ERP: SAP e TOTVS no caminho do pedido

SAP e TOTVS ficam entre o pedido e o faturamento, com dezenas de aplicações integradas na mesma cadeia. Quando uma fila de processamento trava, o sintoma aparece na venda e não no ERP. Três perguntas guiam a instrumentação:

• Qual é o tempo de resposta das transações críticas do ERP, por módulo?
• Onde está a causa-raiz de uma falha originada nas aplicações do ERP?
• Como extrair indicador de negócio do ERP, do CRM e da cadeia de suprimentos?

Responder as três exige métrica de fila, de job e de transação. CPU e memória do servidor não bastam. O recorte por módulo e por processo aparece em monitoramento de ERP.

O sinal que chega primeiro em cada elo

A tabela abaixo resume o que alertar em cada ponto da cadeia. Boa parte desses sinais vem de coleta ativa. O desenho se aproxima da monitoração sintética, com robô executando a transação em vez de esperar o usuário reclamar.

Do elo ao processo: amarrar a cadeia antes do próximo pico

Medir cada elo resolve metade do problema. A outra metade é saber, no minuto do incidente, quais lojas e quais formas de pagamento estão afetadas. Falta ainda definir quem precisa ser acionado. Isso exige o mapa de dependências entre os componentes e o processo de negócio que eles sustentam.

Quando mapeamos a cadeia de pagamento de uma das maiores redes de varejo do Brasil, o gargalo não era ferramenta. Infraestrutura, aplicação e operação viam pedaços diferentes. Estruturamos o monitoramento orientado a processo, com PDV, PIX, self checkout, TOTVS, HUB e orquestrador na mesma visão, além de 42 lojas em painel consolidado. O efeito foi redução de MTTR e o fim das salas de guerra.

O mapa não precisa nascer pronto. Ele começa pelos dois ou três processos que param receita. A partir daí cresce, do jeito descrito em como estruturar um mapa de dependências.

Cinco erros que custam venda

Alertar por elemento e não por processo. O alerta diz que o serviço X caiu. Ele deveria dizer que o pagamento com cartão parou em 12 lojas. A primeira versão vai para o analista, a segunda vai para quem decide desligar a fila do caixa.

Health check que só olha o código de retorno. Gateway e autorizador devolvem 200 com corpo de erro. Sem validação de conteúdo, o painel mente com precisão e a operação demora a acreditar no cliente.

Limiar fixo em métrica sazonal. Volume de transação tem padrão por dia da semana e por faixa horária. Limiar fixo gera alarme na madrugada, quando o movimento cai por natureza. Depois entrega silêncio no pico da tarde.

Alerta sem dono. Notificação em lista compartilhada não é acionamento. Ela vira ruído em duas semanas e o time aprende a ignorar, mecanismo descrito em fadiga de alertas.

Medir apenas o que é seu. SPI, SEFAZ e adquirente pertencem a terceiros, porém a venda perdida é sua. Sem medição própria da fronteira, a conversa com o fornecedor vira troca de percepção em vez de evidência.

Existe uma solução única para monitorar meios de pagamento?

Não existe. A monitoração de meios de pagamento atravessa protocolos, fornecedores e donos diferentes, do SPI ao autorizador estadual. Nenhuma ferramenta cobre a cadeia inteira sozinha. O que resolve é a combinação de duas coisas: coleta adequada a cada elo e um modelo de dependências. Esse modelo traduz componente em processo de venda.

Em mais de duas décadas de monitoração, montamos essas cadeias com o OpMon, desenvolvido por nós. Ao lado dele entram Grafana, Prometheus e o que já existe no ambiente do cliente. A escolha do produto vem depois do desenho: primeiro o processo, em seguida o elo, por fim a ferramenta.

Se a sua operação perde venda por um elo que ninguém mede, comece pelo mapa e não pelo catálogo de produtos. Fale com nossos especialistas para desenhar a cobertura da sua cadeia de pagamento, do caixa da loja ao autorizador da nota.