Skip to main content

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


image-1762776253666.png

 Projeto/Sistema:
GERENCIAMENTO DE PROJETOS		 Versão do Template:
1.2
Processo:
PROC003 – Registro de Pagamento em Cartão de Crédito		 Versão do Documento:
1.0
Responsável(eis): 
Jalile Cornachioni

Data: 

11/11/2025
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)

 

image-1762891289199.png

 

-- 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.

 

Processo

Envolvidos

Dados de Entrada

Dados de Saída
PROC001 - Aplicar desconto/acréscimo

Frente de caixa / API Pagamento Unificado

Valor total, tipo de ajuste, origem da ação

Valor ajustado, log de alteração
PROC010- Excluir pagamento já lançado Operador do caixa Identificação do pagamento selecionado Pagamento removido e saldo recalculado
PROC011 - Quitar Restante Operador do caixa Saldo pendente e forma de pagamento selecionada Campo preenchido automaticamente com o valor restante
PROC012 - Finalizar Pagamento Operador do caixa Todos os pagamentos registrados e saldo zerado Venda concluída e registros financeiros emitidos
PROC013 - Cancelar Operador do caixa Ação do usuário Modal fechado sem registrar alterações

Processos Relacionados

Especificação Funcional

PROC001 EXEMPLO:

Protótipo de Tela:

image-1762883267585.png

Descrição dos Campos:

Campo

Tipo

Tamanho

Obrig. ?

Máscara

Observações
Forma de Pagamento (personalizado) Texto / Seleção  -  Sim — Renderizado apenas quando “Crédito” é selecionado.
Valor Numérico -  Sim R$ 0.000,00 > 0. Aceita decimal. Pode vir pré-preenchido com saldo.
Parcelas Inteiro - Sim - ≥ 1. Sem limite, a menos que exista política global.
1º Vencimento Data - Sim DD/MM/AAAA Default = hoje. Retroativo conforme configuração global.
Bandeira Seleção - Sim - Lista carregada da tabela bandeira_cartao.
Código de Autorização Texto - Sim (manual) - Obrigatório quando não houver TEF. Identificador da transação.
CNPJ Credenciadora Texto 14 Sim 99.999.999/9999-99 Validação de CNPJ. Usado quando a captura exige conciliação/envio fiscal.
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

 

 

 

 

No Comments
Back to top