PROC003 – Registro de Pagamento em Cartão de Crédito

1. Introdução

Este documento tem como objetivo detalhar o comportamento da interface e as regras de negócio referentes ao processo de Recebimento via Cartão de Crédito dentro do fluxo de Pagamento Unificado detalhando, confirmação da transação e registro do recebimento.

2. Processo (adicionar fluxograma exemplo)

-- Fluxograma PROC003 – Registro de Pagamento em Cartão de Crédito --

1. Usuário acessa a tela Registrar Pagamento.

2. Seleciona Crédito como forma de pagamento.

3. O sistema renderiza os campos condicionais de Crédito.

4. Usuário preenche valor, parcelas, vencimento, bandeira, código de autorização (quando manual) e CNPJ da credenciadora.

5. Se o ambiente estiver integrado ao TEF:

   • O sistema envia a solicitação ao terminal.

   • Se aprovado, retorna dados da transação e pré-preenche o código de autorização.

   • Se recusado, o sistema bloqueia a inclusão.

   • Se falhar a comunicação, o sistema exibe o modal:
     “Falha na comunicação com o terminal. Deseja registrar manualmente?”

   • Se o usuário optar por registro manual, segue para o passo 6.

6. Usuário confirma Adicionar Pagamento.

7. O sistema valida regras de negócio e gera uma linha por parcela em “Pagamentos Adicionados”.

8. Usuário pode editar ou excluir parcelas individualmente.

9. Se houver pagamento em Dinheiro, o sistema renderiza o campo Troco, permitindo sua edição e atualização conforme diferença.

10. Usuário pode repetir o processo para adicionar outros cartões ou demais formas de pagamento.

11. Ao finalizar, o sistema valida soma total e libera a conclusão da operação.

Processos Relacionados

• • Pagamento Unificado

  • PROC001 – Aplicar desconto/acréscimo

  • PROC002 – Registro de Pagamento em Dinheiro

  • PROC003 – Registro de Pagamento em Cartão de Crédito

  • PROC004 – Registro de Pagamento em Cartão de Débito

  • PROC005 – Registro de Pagamento em Boleto

  • PROC006 – Registro de Pagamento via PIX

  • PROC007 – Registro de Pagamento em Outros Métodos

  • PROC008 – Adicionar múltiplas formas de pagamento

  • PROC012 – Finalizar Pagamento

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

Descrição dos Campos:

Regras de Interface:

O sistema deve:

• Renderizar todos os campos condicionais ao selecionar Crédito, ou seja, parcelas, primeiro vencimento, bandeira, cod. autorização e CNPJ da credenciadora.

• O campo bandeira deve oferecer uma lista das bandeiras mais utilizadas no país.

• Habilitar o botão Adicionar Pagamento somente quando todos os campos obrigatórios estiverem preenchidos.

• Criar uma linha por parcela na seção “Pagamentos Adicionados”.

• Permitir edição e exclusão individual de cada parcela.

• Renderizar o campo Troco somente quando existir pelo menos um pagamento em Dinheiro adicionado.

• Permitir edição do valor de Troco apenas quando houver pagamento em Dinheiro.

• Atualizar o Troco conforme a diferença entre o valor pago em Dinheiro e o saldo da venda.

• Permitir inclusão de múltiplos cartões na mesma venda (multi-cartão).

• Aplicar máscaras de valor, data e CNPJ conforme o padrão da aplicação.

• Exibir aviso de duplicidade quando detectar combinação idêntica de valor + parcelas + vencimento + bandeira.

• Exibir modal de contingência em caso de falha TEF:
  “Falha na comunicação com o terminal. Deseja registrar manualmente?”.

O sistema não deve:

• Permitir clique em Adicionar Pagamento com campos obrigatórios vazios.

• Exibir o campo Troco quando não existir pagamento em Dinheiro.

• Bloquear inclusão de múltiplos cartões em uma mesma venda.

• Permitir finalização caso a soma dos pagamentos ultrapasse o valor total da venda.

.

Regras de Negócio:

• O sistema deve validar que o Valor informado seja numérico e maior que zero.

• Validar que Parcelas seja inteiro ≥ 1, respeitando limite configurado (se existir).

• Definir 1º Vencimento como a data atual por padrão.

• Permitir vencimento retroativo apenas se a configuração e permissões de usuário correspondente estiver ativa.

• Garantir que o somatório das parcelas feche exatamente o valor total calculado.
• O sistema deve recuperar o código da autorização da transação do TEF e vincular ao pedido quando o TEF retornar status Aprovado. 
• Exigir Código de Autorização quando o pagamento for registrado manualmente (sem TEF).
• O sistema não deve aceitar pagamento manual sem Código de Autorização.
• Em caso de Recusado, o sistema não deve permitir o fechamento do caixa com aquele lançamento.
• Após confirmação, o botão Finalizar Pagamento deve ser exibido para conclusão do fluxo de pagamento.

• Validar formato do CNPJ da Credenciadora.

• O sistema não deve finalizar a venda quando houver inconsistências de soma, bandeira inválida ou CNPJ inválido

• Permitir múltiplas inclusões de pagamentos em crédito (multi-cartão).

• Bloquear finalização caso a soma dos pagamentos ultrapasse o valor da venda..

Questões Técnicas:

1. Integração com módulo TEF (API externa).

2. Logar toda tentativa, inclusive timeouts de comunicação TEF.

3. Em ambiente offline, bloquear operação com TEF.

4. O sistema deve criar uma tabela para armazenar as bandeiras de cartão, contendo apenas os campos id e descricao, seguindo o modelo abaixo: 

CREATE TABLE bandeira_cartao (
id INT PRIMARY KEY,
descricao VARCHAR(60) NOT NULL
);

INSERT INTO bandeira_cartao (id, descricao) VALUES
(1, 'Visa'),
(2, 'Mastercard'),
(3, 'American Express'),
(4, 'Hipercard'),
(5, 'Elo');

©SOFTEN SISTEMAS 2025