Voltar para o blog

NF-e e NFC-e

Rejeição 392: como completar os dados do pagamento integrado

Atualizado em 10 de outubro de 2026

Blog ALRA
Capa ilustrada da ALRA: Rejeição 392: como completar os dados do pagamento integrado.

Atualizado em 10 de outubro de 2026

Na rejeição 392, o XML informa um pagamento integrado ao sistema da empresa, mas deixa de apresentar os dados exigidos para identificar a operação. A regra YA05-10 verifica o grupo card: quando tpIntegra=1, devem ser informados card/CNPJ e card/cAut. A correção consiste em recuperar e transmitir as informações verdadeiras daquela transação.

Esse diagnóstico vale para NF-e modelo 55 e NFC-e modelo 65. Ele exige uma checagem diferente da rejeição 391, que está ligada à ausência do próprio grupo card. Também não significa que o cartão foi recusado: pagamento e autorização fiscal são etapas distintas. Antes de tentar cobrar novamente, confirme o resultado da transação financeira. NT 2025.001 v1.03, página 11.

Saiba qual informação está faltando

O campo tpIntegra informa como o processo de pagamento se relaciona com a automação da empresa. O valor 1 corresponde à integração, incluindo exemplos como TEF, comércio eletrônico e POS integrado. O valor 2 corresponde ao processo não integrado, como um POS simples. Não decida pelo nome comercial do equipamento: verifique como os dados efetivamente chegam ao emissor.

Dentro de card, o CNPJ identifica a instituição de pagamento, adquirente ou subadquirente; o leiaute também trata do intermediador quando ele processa o pagamento. Já cAut identifica a autorização da operação. Esses dados devem ser obtidos da integração ou dos registros fornecidos pela instituição que processou aquela venda. NT 2023.004 v1.20, página 12.

Não confunda esse CNPJ com CNPJReceb, destinado ao beneficiário, nem com CNPJPag, relacionado ao estabelecimento em que o pagamento foi processado quando ele difere do estabelecimento emissor. A bandeira também tem campo próprio, tBand. O nome de uma bandeira não basta para identificar a instituição a informar.

Não preencha cAut com senha, código de segurança do cartão, número completo do cartão ou um identificador escolhido por semelhança. Se o comprovante tiver vários números, confirme com o fornecedor qual deles corresponde ao campo fiscal. Usar a autorização de outra venda elimina a correspondência que o XML precisa preservar.

A regra deixou de ser facultativa na documentação nacional

Muitos tutoriais ainda descrevem a YA05-10 como opcional por UF. Essa era a redação anterior. Na NT 2025.001 v1.03, a indicação “Facult.” e a observação sobre decisão estadual estão riscadas; a classificação apresentada é “Obrig.”.

A distinção importa: não é seguro justificar a falta dos dados com uma tabela antiga de regras facultativas. Por outro lado, a leitura documental não substitui uma confirmação do comportamento do autorizador, do ambiente de homologação ou produção e da versão utilizada pelo emissor.

O cronograma original dessa NT apontava testes até 02/06/2025 e produção até 01/09/2025. A data 03/11/2025, ligada às alterações da versão 1.03, não deve ser transformada em uma nova data genérica para a 392. A exceção documental para notas emitidas antes de 01/04/2016 permanece.

A ressalva de implementação futura para o modelo 55 está na regra 391; não aparece na YA05-10 da 392. Isso vale também para a análise de uma NF-e 55 com DANFE Simplificado Tipo 2, tpImp=6: ela continua sendo modelo 55. A NT 2026.002 v1.11 não cria uma dispensa específica para os campos desta rejeição.

Como resolver na prática

  1. Localize a ocorrência de pagamento no XML rejeitado. Confira card/tpIntegra e a presença de CNPJ e cAut. Em recebimentos divididos, cada operação deve conservar seus próprios dados.

  2. Se a integração existe, investigue o retorno recebido do provedor. Verifique se a autorização chegou ao PDV, se foi persistida e se a rotina fiscal a incluiu no XML. Um cadastro correto não compensa uma falha na geração do arquivo.

  3. Complete o cadastro da instituição efetivamente utilizada. Não use o CNPJ de outra empresa retirado de um exemplo ou de uma lista apenas porque ele passa na validação de formato.

  4. Se tpIntegra foi cadastrado incorretamente, ajuste-o à realidade e verifique as obrigações estaduais de integração. O valor 2 não é um recurso para dispensar dados de uma operação que é integrada.

  5. Gere novamente o XML e confira a situação fiscal antes de retransmitir. Confirme o protocolo ao final; um status local de “enviado” não basta para encerrar a pendência.

A TecnoSpeed identifica os campos de integração correspondentes a tpIntegra, CNPJ e cAut. A Omie orienta revisar o cadastro associado ao pedido e os dados das parcelas. Esses caminhos ajudam a encontrar a origem, mas não substituem o exame do XML nem atualizam automaticamente trechos antigos sobre faculdade estadual.

A TOTVS, na linha Consinco, documenta uma falha de geração ligada principalmente a carteiras digitais, com correção na versão 24.05.006 ou superior. Para esse cenário específico, recomenda atualização e regeneração do XML das notas pendentes antes do reenvio. A versão citada pertence a esse produto, não a todos os emissores.

E quando o pagamento foi por Pix

O grupo card passou a abranger outros pagamentos eletrônicos, e cAut teve sua descrição ampliada e seu tamanho aumentado para até 128 caracteres. Portanto, não descarte o diagnóstico apenas porque o cliente não utilizou um cartão físico.

No Rio Grande do Sul, a orientação oficial para NFC-e com Pix dinâmico determina o uso do endToEndId em cAut desde 01/07/2024. A página distingue tPag=17 do Pix estático, código 20. É uma orientação estadual, que não deve ser extrapolada para qualquer UF ou modalidade.

Além disso, o IT 2024.002 v1.11 acrescentou Pix automático e TEF “Book Transfer” à tabela, com produção prevista para 04/05/2026. Mantenha a classificação atualizada, sem tratar todo Pix como a mesma operação. O novo grupo YC de vinculação financeira, previsto pela NT 2026.006 v1.00, tampouco substitui o grupo YA; a nota técnica mantém ressalvas próprias sobre uso preparatório e ausência de exigência desses campos em produção em 2026.

Exemplo para conferir a solução

Uma loja recebeu um pagamento integrado, e o provedor retornou a autorização. O cadastro da instituição estava correto, mas o conector descartou cAut. Nesse caso, o ajuste é reparar o mapeamento e regenerar o XML com a autorização da mesma venda. Trocar tpIntegra para 2 ou selecionar “Outros” esconderia o defeito.

Ao abrir um chamado, informe código, modelo, UF, ambiente, versão e quais campos faltaram, com dados de teste ou devidamente ocultados. O suporte consegue investigar a estrutura sem receber informações completas do cartão do cliente. A pendência termina quando os dados reais chegam corretamente ao XML e a autorização fiscal é confirmada.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.