idTermPag na NF-e: identificador do terminal de pagamento
<idTermPag>pag › detPag › card › idTermPagRevisão editorial em 26 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
idTermPag, em /nfeProc/NFe/infNFe/pag/detPag/card/idTermPag, identifica o terminal em que o pagamento foi realizado. Ele permite associar a informação eletrônica ao terminal daquela operação; não é o código de autorização da transação nem o número da nota.
O que consultar para obter o identificador
Use o retorno documentado do prestador de pagamento ou a configuração do terminal vinculada à transação. Se a integração retorna um identificador de terminal, confirme seu significado no contrato e preserve a relação com a empresa e o detalhe de pagamento. Não deduza o campo do nome comercial da máquina, do CNPJ da adquirente ou de um pedido interno.
Um terminal pode realizar várias operações. Por isso, idTermPag pode permanecer o mesmo enquanto cAut, que identifica a autorização do pagamento, muda. O terminal também não determina sozinho tpIntegra: um POS integrado e um POS simples podem ter identificação de equipamento, mas tipos de integração diferentes.
Formato e presença dentro de card
A NT 2023.004 descreve o campo como identificador do terminal e o XSD conferido admite texto de 1 a 40 caracteres, zero ou uma vez em card. Preserve zeros iniciais e caracteres significativos; serialização XML deve escapar caracteres reservados, não remover partes do identificador por conveniência.
Se card existir, seu tpIntegra é obrigatório. A presença de um terminal não dispensa dados contextuais da instituição/autorização nem torna o grupo permitido em qualquer tPag; YA04-20 mantém sua lista de meios compatíveis. Não gere card com um terminal arbitrário para um pagamento em dinheiro.
Exemplo: mesmo terminal, duas operações
Suponha que o prestador tenha registrado duas transações no terminal 00042, com autorizações diferentes. Fragmento parcial e sintético de uma delas, sem aptidão para transmissão:
<card xmlns="http://www.portalfiscal.inf.br/nfe">
<tpIntegra>1</tpIntegra>
<CNPJ>12345678000195</CNPJ>
<cAut>AUT-100</cAut>
<idTermPag>00042</idTermPag>
</card>
Na segunda transação da hipótese, cAut poderia ser AUT-101 e idTermPag continuar 00042. Isso evidencia a diferença entre equipamento e operação. Os códigos e o CNPJ são ilustrativos, sem comprovação cadastral ou financeira. Converter 00042 em inteiro resultaria 42 e perderia a representação original.
Como conferir terminal ausente ou trocado
Compare o retorno da transação, o cadastro/configuração do terminal e o XML enviado. Verifique se o identificador foi omitido por um campo não mapeado, truncado para um tamanho antigo ou preenchido com a autorização por confusão. Se o terminal pertence a outro estabelecimento ou outra empresa, investigue o vínculo antes de usar o dado, mesmo que a sintaxe esteja correta.
Uma mensagem sobre card, CNPJ ou cAut não demonstra por si só erro em idTermPag. Localize o campo e a regra mencionados na resposta. Não existe aqui uma regra universal que possa ser “corrigida” colocando qualquer número de máquina. Se o prestador não disponibiliza o identificador, confirme a necessidade contextual e a origem apropriada; não transforme ausência em zero.
Corrija o mapeamento do rascunho, revalide formato e associação com a transação, e confira o XML regenerado. Não edite XML assinado ou refaça pagamento para obter outro terminal. A pertinência e a relação contratual precisam estar confirmadas; o identificador não atesta liquidação nem resolve efeito fiscal. Veja cAut e autorização da operação e tpIntegra e a integração do processo.
Fontes oficiais
- NT 2023.004 — Informações de Pagamentos e Outros, 1.20; p. 3–6, 11–12, 14–15.
Referência técnica para integração
- XPath completo
/nfeProc/NFe/infNFe/pag/detPag/card/idTermPag- Namespace
http://www.portalfiscal.inf.br/nfe- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 0–1 no contexto do elemento pai
- Tipo
- inline:TString · TString
- Preenchimento no catálogo
- Condicional
A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.
- maxLength
40- minLength
1- pattern
[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}- whiteSpace
preserve