Rejeição 768, 963 e 391 na NF-e e NFC-e: Regra YA04-20 vs YA04-10 e Grupo <card> em tPag=16 (Depósito) e tPag=19 (Cashback)

Quem mantém frente de caixa (PDV), checkout de e-commerce ou faturamento B2B integrado à SEFAZ sabe que o bloco de pagamentos <pag><detPag> do layout 4.00 da NF-e (Modelo 55) e da NFC-e (Modelo 65) é um campo minado. Basta que o ERP envie uma propriedade residual de integração TEF junto com um pagamento por Depósito Bancário (tPag=16) ou Programa de Fidelidade / Cashback / Crédito Virtual (tPag=19) para o autorizador estadual travar a nota fiscal.

O que mais confunde os desenvolvedores ao depurar esse erro nos logs de produção é a divergência de códigos de retorno entre os estados e os manuais da SEFAZ: enquanto a documentação da NT 2023.004 / NT 2025.001 cataloga a falha na Regra de Validação YA04-20 sob o cStat 768 ("Rejeição: Não deve ser informado o grupo de cartões"), autorizadores estaduais como a SEFAZ-SP e a SVRS devolvem em produção para essa exata mesma regra o cStat 963. Na ponta oposta, quando o meio de pagamento realmente exige dados de credenciadora ou TEF (03, 04 ou 17) e o XML omite <card>, a SEFAZ aplica outra regra completamente distinta: a **YA04-10 (cStat 391 — "Não informados os dados do cartão de crédito / débito nas Formas de Pagamento da Nota Fiscal")**.

Quando analisamos esse comportamento nos logs da release v0.56.138 da Notaas, percebemos que muitos ERPs reutilizavam o mesmo objeto de pagamento no payload JSON — enviando tipoIntegracaoPagamento: "2" (POS não integrado) por padrão em todas as vendas, inclusive quando o cliente pagava com cashback (tPag=19) ou depósito em conta (tPag=16). Neste artigo técnico, vou mostrar a separação exata entre as regras YA04-20 e YA04-10, a tabela de permissividade do grupo <card> por tPag e como blindamos nossos mappers (NfeMapper e NfceMapper) para que sua aplicação nunca mais sofra com essas rejeições.

Se o seu checkout mistura objetos de TEF/POS com meios não-eletrônicos como depósito bancário (tPag=16) ou cashback (tPag=19), a SEFAZ rejeita o XML antes mesmo de validar os itens da venda.

A diferença exata entre a Regra YA04-20 (cStat 768 / 963) e a Regra YA04-10 (cStat 391)

Para diagnosticar rapidamente o problema no seu sistema de emissão de NF-e (Modelo 55) ou na sua integração de API NFC-e (Modelo 65), é fundamental separar as duas regras de validação do grupo YA04 (<card> dentro de <detPag>) definidas pelas Notas Técnicas da SEFAZ:

1. Regra YA04-20 — Quando o grupo <card> é proibido (cStat 768 e cStat 963)

A regra YA04-20 determina que, se o código do meio de pagamento (<tPag>) pertencer à lista de meios não vinculados a cartão ou arranjo eletrônico de pagamento instantâneo dinâmico, a tag <card> não pode existir no XML.

• Código na especificação da NT (YA04-20): cStat 768 — Rejeição: Não deve ser informado o grupo de cartões.
• Código retornado em produção pela SEFAZ-SP e SVRS: cStat 963 — Rejeição: Não deve ser informado o grupo de cartões (acionado pela mesma condição YA04-20).
• Meios de pagamento (tPag) onde <card> é estritamente vedado:
  • 01 — Dinheiro
  • 02 — Cheque
  • 14 — Duplicata Mercantil
  • 16 — Depósito Bancário
  • 19 — Programa de fidelidade, Cashback, Crédito Virtual
  • 20 — Pagamento Instantâneo (PIX) — Estático / Transferência sem integração TEF
  • 90 — Sem pagamento
  • 99 — Outros

Se o seu builder XML serializar <card><tpIntegra>2</tpIntegra></card> dentro de um <detPag> cujo <tPag> seja 16 ou 19, a nota será imediatamente rejeitada com 768 ou 963.

2. Regra YA04-10 — Quando o grupo <card> é obrigatório (cStat 391)

A regra YA04-10 opera no sentido inverso e aplica-se exclusivamente aos meios de pagamento eletrônicos que exigem identificação do tipo de integração (<tpIntegra>):

• Código de rejeição (YA04-10): cStat 391 — Rejeição: Não informados os dados do cartão de crédito / débito nas Formas de Pagamento da Nota Fiscal.
• Meios de pagamento (tPag) que exigem <card> obrigatório:
  • 03 — Cartão de Crédito
  • 04 — Cartão de Débito
  • 17 — Pagamento Instantâneo (PIX) — Dinâmico / TEF
• Importante: A Rejeição 391 (YA04-10) jamais é disparada para tPag=16 ou tPag=19. Ela ocorre quando o PDV envia tPag=03, 04 ou 17 e esquece de informar <card><tpIntegra>...</tpIntegra></card>.

3. Meios que aceitam <card> opcionalmente (TPAG_ELETRONICO)

Existem ainda os meios de pagamento de vales, cartões próprios e carteiras digitais nos quais o schema da SEFAZ permite o envio do grupo <card> quando houver dados de integração (tpIntegra, CNPJ da credenciadora, tBand ou cAut), sem rejeitar por 768/963:

• 10 (Vale Alimentação), 11 (Vale Refeição), 12 (Vale Presente), 13 (Vale Combustível), 15 (Boleto Bancário) e 18 (Transferência bancária, Carteira Digital).

Veja a matriz completa consolidada por tPag:

Como resolvemos isso na arquitetura da Notaas (v0.56.138)

Em sistemas reais de varejo e e-commerce, é extremamente comum uma venda ter pagamento misto (split de pagamento): por exemplo, o comprador abate R$ 30,00 usando saldo de Cashback (tPag=19) e paga os R$ 120,00 restantes no Cartão de Crédito (tPag=03). Quando o desenvolvedor monta o array pagamentos no backend, um helper genérico de checkout muitas vezes injeta tipoIntegracaoPagamento: "2" em todos os itens do array.

Na release v0.56.138, atualizamos a constante TPAG_ELETRONICO tanto no NfeMapper (src/lib/nfe/nfe-mapper.ts) quanto no NfceMapper (src/lib/nfce/nfce-mapper.ts) para restringir a geração de <card> estritamente aos códigos suportados:

// Códigos tPag nos quais a SEFAZ permite a geração do bloco <card>
const TPAG_ELETRONICO = new Set([
  '03', // Cartão de Crédito
  '04', // Cartão de Débito
  '10', // Vale Alimentação
  '11', // Vale Refeição
  '12', // Vale Presente
  '13', // Vale Combustível
  '15', // Boleto Bancário
  '17', // Pagamento Instantâneo (PIX) - Dinâmico
  '18', // Transferência bancária, Carteira Digital
]);

export function shouldBuildCardGroup(pagamento: {
  meioPagamento: string;
  tipoIntegracaoPagamento?: '1' | '2';
  cnpjCredenciadora?: string;
  bandeiraCartao?: string;
  codigoAutorizacao?: string;
}): boolean {
  const tPag = pagamento.meioPagamento.padStart(2, '0');

  // Nunca gera <card> para tPag=16 (Depósito) ou tPag=19 (Cashback/Fidelidade),
  // mesmo que o ERP envie propriedades residuais de cartão no payload JSON
  if (!TPAG_ELETRONICO.has(tPag)) {
    return false;
  }

  return Boolean(
    pagamento.tipoIntegracaoPagamento ||
      pagamento.cnpjCredenciadora ||
      pagamento.bandeiraCartao ||
      pagamento.codigoAutorizacao
  );
}

⚡ Fluxo de Sanitização Automática de <detPag> na Notaas Engine (v0.56.138):

• 1. Recepção do Payload JSON (POST /api/v1/nfe ou POST /api/v1/nfce): O ERP envia o array de pagamentos (ex: um item tPag="19" de cashback e um item tPag="03" de cartão de crédito).
• 2. Filtro TPAG_ELETRONICO: Para tPag="16" (Depósito Bancário) e tPag="19" (Cashback/Fidelidade), o mapper ignora quaisquer campos residuais (tpIntegra, CNPJ, tBand, cAut) e omite completamente a tag <card>.
• 3. Validação de Meios Eletrônicos (03, 04, 17): Para cartão de crédito, débito e PIX dinâmico, preserva <card><tpIntegra>...</tpIntegra></card>, evitando a Rejeição 391 (YA04-10).
• 4. Assinatura e Autorização SEFAZ: O XML <enviNFe> é assinado com Certificado A1 e autorizado de primeira, sem rejeições 768 ou 963.

Exemplo prático: Payload JSON de venda com Cashback (tPag=19) + Cartão de Crédito (tPag=03)

Veja como enviar uma emissão com pagamento combinado na API de Nota Fiscal Gratuita da Notaas:

{
  "naturezaOperacao": "VENDA DE MERCADORIA ADQUIRIDA DE TERCEIROS",
  "ambiente": 1,
  "itens": [
    {
      "codigo": "SKU-FONE-BT",
      "descricao": "Fone de Ouvido Bluetooth ANC Pro",
      "ncm": "85183000",
      "cfop": "5102",
      "unidade": "UN",
      "quantidade": 1,
      "valorUnitario": 250.00
    }
  ],
  "pagamentos": [
    {
      "indicadorPagamento": 0,
      "meioPagamento": "19",
      "valor": 50.00
    },
    {
      "indicadorPagamento": 0,
      "meioPagamento": "03",
      "valor": 200.00,
      "tipoIntegracaoPagamento": "1",
      "cnpjCredenciadora": "01027058000191",
      "bandeiraCartao": "01",
      "codigoAutorizacao": "849201"
    }
  ]
}

O XML gerado pelo motor da Notaas produz dois blocos <detPag> perfeitamente aderentes às regras YA04-20 e YA04-10:

<pag>
  <detPag>
    <indPag>0</indPag>
    <tPag>19</tPag>
    <vPag>50.00</vPag>
  </detPag>
  <detPag>
    <indPag>0</indPag>
    <tPag>03</tPag>
    <vPag>200.00</vPag>
    <card>
      <tpIntegra>1</tpIntegra>
      <CNPJ>01027058000191</CNPJ>
      <tBand>01</tBand>
      <cAut>849201</cAut>
    </card>
  </detPag>
</pag>

Se você está avaliando diferentes fornecedores para unificar NF-e, NFC-e e NFS-e no seu SaaS ou ERP, confira também o nosso Comparativo Completo de APIs de Emissão Fiscal em 2026.

Emita NF-e e NFC-e sem rejeições de schema na Notaas

Não perca vendas no PDV ou no checkout do seu e-commerce por causa de diferenças sutis entre os validadores da SEFAZ-SP, SVRS e demais estados:

• 20 notas fiscais gratuitas por mês em Produção Real (1 CNPJ) + até 5 projetos simultâneos em Homologação via Org API, sem exigir cartão de crédito.
• Mappers sempre atualizados com as últimas Notas Técnicas da SEFAZ e da Reforma Tributária (IBS e CBS).
• API REST JSON unificada para NF-e (Mod 55), NFC-e (Mod 65), NFS-e (4.836 cidades) e CT-e/MDF-e.

👉 Criar Conta Gratuita na Notaas Platform · Acessar a Documentação Oficial da API