Rejeição 391: grupo card ausente no pagamento por cartão ou PIX
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 391, regra YA04-10, identifica a falta do grupo card no pagamento por cartão de crédito, débito ou PIX, código 17. A NT 2025.001 v1.03 corrigida torna a regra obrigatória, lista 55/65 e mantém implementação futura para 55; não presuma essa extensão já implantada a partir da tabela.
Condição atual e alcance
No modelo 65, confira cada pag/detPag/tPag: 03 representa cartão de crédito, 04 representa cartão de débito e 17 representa PIX. Para esses meios, a YA04-10 exige o grupo card no detalhe correspondente. A aplicação obrigatória substitui a antiga observação de escolha da UF, rasurada na NT 2025.001, p. 11. A tabela lista 55/65, mas registra implementação futura para 55; no diagnóstico da NFC-e 65, essa observação não é uma dispensa. A exceção histórica não a aplica, em produção, a documento com emissão anterior a 01/04/2016.
O nome da tag não limita seu conteúdo atual a cartões. A NT 2023.004, p. 12, denomina card grupo de cartões, PIX, boletos e outros pagamentos eletrônicos, com tpIntegra, CNPJ da instituição, autorização e campos complementares. A ampliação estrutural não torna todos esses meios obrigatórios pela 391: sua condição expressa é 03, 04 ou 17.
Como localizar a perda de dados
Um cenário sintético tem dois detalhes: dinheiro e PIX. O emissor associa card apenas ao dinheiro ou deixa o grupo fora do detPag do PIX. O grupo existir em outro ponto não atende ao detalhe de pagamento eletrônico. Compare o comprovante e os dados retornados pela integração com a associação entre tPag e card no XML.
Em outro cenário, o software usa uma regra antiga que só gera card para 03 e 04. O retorno 391 em um PIX pode indicar ausência de atualização do gerador. Não recadastre o PIX como dinheiro nem invente dados bancários para produzir um grupo.
Um XML sintético não comprova a instituição, a integração ou a autorização do pagamento real. O exemplo é textual, sem CNPJ ou autorização inventados; o diagnóstico exige o XML original protegido e o registro do processador do pagamento.
Verificação depois da correção
Confirme modelo, ambiente, meio real e ocorrência indicada no retorno. Verifique se o gerador omitiu o grupo ou se os dados da integração nunca foram disponibilizados. Restaure a informação a partir do processador e gere novamente o documento rejeitado, preservando a associação ao pagamento correto.
A ausência de card é diferente de falta de dados dentro dele: a 392 trata do pagamento com cartão integrado, tpIntegra=1, e campos específicos. A 737 trata de integração não aceita pela UF. A 963, na NT 2023.004, restringe card conforme o meio. Não replique o grupo indiscriminadamente em todos os pagamentos.
A NT 2023.004 v1.20, pp. 3–5 e 14, documenta a inclusão do PIX, com regras da versão 1.11 previstas em 01/07/2024. A NT 2025.001 v1.03 corrigida, pp. 2–3 e 11, atualiza obrigatoriedade e alcance, com produção geral até 01/09/2025 e implementação futura específica do 55. Datas de schema, versões e regras são distintas. Confira o retorno individual e eventual autorização, preserve documento autorizado e esclareça tentativa incerta antes de um novo envio.
Fontes oficiais
- MOC 7.0 — Anexo I: p. 126 YA04-10 base e regras vizinhas.
- NT 2023.004 v1.20: pp. 3–5 cronograma/histórico; p. 12 grupo card; p. 14 YA04-10/20.
- NT 2025.001 v1.03 corrigida: pp. 2–3 cronograma; pp. 7,10–11 atualização pagamentos, condições, obrigatoriedade e rasuras.