tpIntegra na NF-e: pagamento integrado e não integrado

tpIntegra, em /nfeProc/NFe/infNFe/pag/detPag/card/tpIntegra, informa como o processo de pagamento se integra à automação da empresa. Os códigos são 1, integrado, e 2, não integrado. O campo é obrigatório quando o grupo card existe.

O que os códigos 1 e 2 significam

A distinção é o processo, não apenas o nome ou formato da máquina. Um POS pode estar integrado ou operar independentemente. A mera existência de um terminal cadastrado ou de uma integração bancária para consultar saldo não demonstra que a transação de pagamento está integrada à emissão/automação.

Obtenha essa informação da configuração comprovada e do fluxo real da integração, com seu contrato e retorno de pagamento. Uma digitação manual de código no emissor não transforma automaticamente o processo em integrado.

Quais exigências dependem desse dado

O XSD admite apenas 1 ou 2 dentro de card. Não use 0 para “desconhecido” nem omita o elemento quando o grupo existe. A obrigatoriedade de um filho em grupo opcional é condicional ao grupo; não exige card em todo meio.

Para cartão integrado, a YA05-10 do MOC documenta exigência de CNPJ da instituição e código de autorização cAut, aplicação opcional a critério da UF e exceção histórica para emissão anterior a 01/04/2016; dados ausentes podem gerar 392. A YA04a-20 descreve 737 para integração 2 em UF que não aceita esse tipo, aplicação facultativa a critério da UF.

Isso exige conferir modelo, UF, meio e regra do retorno. Não declare 2 para contornar a ausência de dados exigidos em 1, nem declare 1 sem integração real para evitar 737. Uma escolha diferente do fluxo efetivo torna o dado incorreto.

Dois cenários de equipamento

No primeiro cenário, o sistema envia a operação ao TEF/POS integrado, recebe os dados e os associa à venda. O código representa 1. No segundo, a operação é realizada em POS simples independente da automação; o código representa 2. Esses cenários ilustram os conceitos do manual; não comprovam que a UF aceitará qualquer operação com cada alternativa.

Fragmento parcial e sintético do cenário integrado, com identificadores ilustrativos e sem aptidão para transmissão:

<card xmlns="http://www.portalfiscal.inf.br/nfe">
  <tpIntegra>1</tpIntegra>
  <CNPJ>12345678000195</CNPJ>
  <cAut>AUT-100</cAut>
</card>

Não se conclui que o XML inteiro é válido apenas por esses três campos: a compatibilidade de card com tPag, os valores e outras regras continuam aplicáveis.

Roteiro para 392 ou 737

Na 392, confira se a declaração de integração corresponde ao fluxo e se CNPJ/cAut foram recebidos e corretamente serializados no detalhe. Procure retorno não persistido, mapeamento errado ou código de autorização de outra transação.

Na 737, confira o tpIntegra enviado, UF e aplicação da regra. Se a UF exige um fluxo que a empresa não utiliza, a correção pode envolver adequação operacional/integração confirmada, e não uma troca de número no XML. Verifique a exigência estadual atual aplicável antes de orientar essa mudança; o catálogo técnico não substitui uma decisão específica de conformidade.

Depois da correção autorizada na origem do rascunho, confira a representação e valide novamente. Não edite XML assinado, refaça pagamentos ou prometa autorização. Veja card e os meios compatíveis e cAut e a origem da autorização.

Fontes oficiais

• NT 2023.004 — Informações de Pagamentos e Outros, 1.20; p. 3–6, 11–12, 14–15.
• MOC 7.0 — Anexo I, 7.0; Grupo Y/YA, p. 61–62 e 125–126.