> Melhoria Contínua de Processos > Pagamentos em Processamento > Fiserv > Modelo de Dados

Seu template de dados de processamento de pagamentos

Name: Pagamentos em Processamento Process Mining Data Template
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

Seu template de dados de processamento de pagamentos

← Voltar ao Guia de Melhoria

Atributos de Processamento de Pagamentos (20) Atividades de Processamento de Pagamentos (13) Guias de Extração (1)

Seu template de dados de processamento de pagamentos

Este template fornece uma estrutura organizada para ajudar você a mapear seus dados do Fiserv para um formato adequado para process mining e análise. Ele descreve os atributos e atividades essenciais necessários para obter visibilidade clara dos seus ciclos de liquidação e conciliação. Seguindo este guia, você poderá criar um log de eventos robusto que destaca ineficiências e riscos de conformidade em suas operações financeiras.

Atributos recomendados para análise de pagamentos
Marcos principais do processo para monitorar
Orientação técnica para extração de dados do Fiserv

É novo em event logs? Saiba como criar um event log para Process Mining.

Baixar Modelo

Atributos de Processamento de Pagamentos

Estes campos de dados recomendados fornecem o contexto necessário para que seu log de eventos suporte uma análise abrangente de todo o ciclo de vida dos seus pagamentos.

5 Obrigatório 10 Recomendado 5 Opcional

	Nome	Descrição
	Event Timestamp EventTimestamp	A data e hora exatas em que a atividade ocorreu.
Descrição Este atributo registra o momento exato em que um evento ocorreu. É a base para toda a análise temporal, incluindo tempos de ciclo, lead times e identificação de gargalos. Nos dashboards, esses dados alimentam o cálculo da duração entre as etapas, como o tempo desde `Solicitação de Pagamento Criada` até `Pagamento Autorizado`. Timestamps de alta precisão são necessários para ordenar corretamente os eventos que acontecem em sucessão rápida. Por que é importante Necessário para ordenar eventos e calcular as durações de desempenho do processo. Onde obter Logs de auditoria ou colunas de timestamp de atualização de transação. Exemplos 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	ID da Transação de Pagamento PaymentTransactionId	O identificador único para a instrução de pagamento ou caso de transação específica.
Descrição Este atributo serve como a chave central para vincular todas as atividades dentro de um único ciclo de vida de pagamento. Ele permite que os analistas rastreiem a jornada desde a solicitação inicial até a validação, aprovação e liquidação final ou cancelamento. Em ambientes Fiserv, esta é geralmente a chave primária nas tabelas de histórico de transações. É essencial para reconstruir o fluxo do processo e garantir que eventos isolados (como a liquidação ocorrendo dias após a autorização) sejam associados corretamente ao mesmo objeto de negócio. Por que é importante É o Case ID fundamental necessário para agrupar eventos em instâncias de processo. Onde obter Consulte a documentação da Fiserv para tabelas de Transação ou Cabeçalho de Pagamento. Exemplos TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Nome da Atividade ActivityName	O evento específico ou mudança de status ocorrida no processo de pagamento.
Descrição Este atributo descreve a etapa realizada, como `Solicitação de Pagamento Criada` ou `Pagamento Liquidado`. Ele define os nós no mapa do processo e é fundamental para entender a sequência de operações. Ao analisar as `Atividade` distintas, as empresas podem visualizar o fluxo de trabalho, identificar etapas ignoradas e detectar caminhos não conformes onde validações ou aprovações obrigatórias foram contornadas. Por que é importante Define os eventos que compõem a linha do tempo do processo. Onde obter Log de histórico de transações ou tabelas de auditoria de mudança de status. Exemplos Solicitação de Pagamento CriadaPagamento AutorizadoErro de Pagamento IdentificadoPagamento LiquidadoPagamento Cancelado
	Sistema de Origem SourceSystem	O nome do sistema de onde os dados se originaram.
Descrição Identifica o módulo específico da Fiserv ou sistema externo que gerou o evento. Muito útil em ecossistemas complexos onde o pagamento nasce em um canal de front-end e é liquidado em um core banking de back-end. Permite que analistas filtrem a visão do processo pelo sistema de origem, garantindo que a análise foque em ambientes técnicos ou pontos de integração específicos. Por que é importante Fornece contexto técnico e linhagem de dados. Onde obter Definido no código durante a extração ou via metadados do sistema. Exemplos Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Última Atualização de Dados LastDataUpdate	O registro de data e hora de quando o registro foi extraído ou atualizado pela última vez.
Descrição Indica o quão atualizados estão os dados usados na análise. Crucial para saber se os dashboards refletem a operação em tempo real ou snapshots históricos. Isso gera confiança nas métricas exibidas, garantindo que decisões não sejam tomadas com base em dados obsoletos, especialmente ao monitorar conformidade de cutoff ou gargalos ativos. Por que é importante Garante a atualidade e a confiabilidade dos dados. Onde obter Hora do sistema no momento da execução do ETL. Exemplos 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Código da Moeda CurrencyCode	O código de moeda ISO para o valor do pagamento.
Descrição Especifica a moeda na qual o pagamento é denominado (ex: USD, BRL). Este atributo é vital para o dashboard de Tendências de Volume por Moeda e Método, permitindo que a organização monitore a exposição a diferentes câmbios. Também é usado para normalizar valores para relatórios globais e para garantir que as verificações de duplicidade não sinalizem erroneamente transações com o mesmo valor numérico, mas moedas diferentes. Por que é importante Necessário para análise de processamento multimoeda. Onde obter Tabela de cabeçalho da transação, coluna Moeda. Exemplos USDEURGBPCADJPY
	Código de Erro ErrorCode	O código específico gerado quando um pagamento falha na validação.
Descrição Captura o código de erro técnico ou de negócio associado às atividades de 'Erro de Pagamento Identificado'. Este atributo é a base para o dashboard de Rastreador de Erros e Retrabalho. Ao agregar as frequências de códigos de erro específicos, a organização pode identificar problemas sistêmicos de qualidade de dados (ex: 'Número de Roteamento Inválido') e aplicar correções na lógica de validação ou treinamentos específicos. Por que é importante Identifica as causas raiz do retrabalho. Onde obter Logs de erro ou detalhes do status da transação. Exemplos E-101INV_ACCNSF_ERRAUTH_FAIL
	Data de Vencimento do Pagamento PaymentDueDate	A data limite para o processamento do pagamento.
Descrição A data prevista para a conclusão do pagamento. Isso é usado no `Monitor de Conformidade de Horário de Corte` para sinalizar transações que correm o risco de atraso. A comparação do timestamp `Pagamento Liquidado` com este atributo permite o cálculo de métricas de entrega no prazo e ajuda a organização a manter a confiança dos beneficiários. Por que é importante Ponto de referência para medir a adesão ao SLA. Onde obter Detalhes da instrução de pagamento. Exemplos 2023-11-012023-11-15
	Duração do Processamento ProcessingDuration	O tempo levado para concluir a atividade específica.
Descrição Representa a duração da própria atividade ou o tempo desde a atividade anterior. Isso permite uma análise granular de onde o tempo está sendo gasto no processo. É usado para preencher o mapeamento genérico de Tempo de Processamento e ajuda a identificar etapas específicas que são consistentemente mais lentas do que o esperado. Por que é importante Mede a eficiência de etapas individuais do processo. Onde obter Calculado a partir das diferenças de timestamp. Exemplos 00:05:0024:00:0000:00:30
	É STP? IsStraightThroughProcessing	Sinaliza se o pagamento não exigiu nenhuma intervenção manual.
Descrição Um atributo booleano calculado que é verdadeiro se o caso não contiver as etapas 'Erro de Pagamento Identificado', 'Erro de Pagamento Resolvido' ou 'Pagamento Aprovado' manualmente (dependendo da definição). Isso suporta diretamente o KPI de Taxa de Processamento Direto (STP). Ele permite a segmentação binária do processo: fluxos puramente automatizados versus aqueles que exigem intervenção humana, facilitando a visualização do potencial de automação. Por que é importante Métrica central para eficiência do processo e sucesso da automação. Onde obter Calculado durante a transformação dos dados. Exemplos verdadeirofalse
	Meio de Pagamento PaymentMethod	O mecanismo utilizado para executar o pagamento (ex: Wire, ACH).
Descrição Classifica a transação pelo seu canal de processamento (rail). Este atributo é fundamental para a Análise de Tempo de Ciclo de Autorização, já que diferentes métodos possuem procedimentos operacionais e SLAs muito distintos. Analisar as variantes do processo por método de pagamento ajuda a isolar se os atrasos são sistêmicos em um canal específico (como transferências internacionais) ou gerais na organização. Por que é importante Segmenta os fluxos de processo pela infraestrutura utilizada. Onde obter Coluna de tipo de transação ou código de instrumento. Exemplos WireACHChequeRTPTransferência Interna
	Número da Conta do Beneficiário PayeeAccountNumber	O número da conta na qual os fundos são creditados.
Descrição Identifica a conta de destino. Assim como a conta do pagador, este dado é crucial para a Detecção de Pagamentos Duplicados, garantindo que a análise foque corretamente em relacionamentos específicos com beneficiários. No monitoramento de conformidade de cutoff, conhecer o favorecido ajuda a priorizar fornecedores estratégicos ou liquidações críticas que não podem sofrer atrasos. Por que é importante Essencial para detecção de duplicidade e análise de beneficiários. Onde obter Detalhes da transação, coluna Conta de Crédito ou Beneficiário. Exemplos 555000111222333444BEN-882-11
	Número da Conta do Pagador PayerAccountNumber	O número da conta da qual os fundos são debitados.
Descrição Identifica a conta de origem do pagamento. É um componente essencial para a Detecção de Pagamentos Duplicados. Quando combinado com Beneficiário, Valor e Hora, forma a 'digital' exclusiva para identificar pagamentos feitos duas vezes por engano. Também permite analisar o volume de pagamentos por conta de origem para identificar as carteiras internas mais ativas. Por que é importante Essencial para detecção de duplicidade e análise de fraude. Onde obter Detalhes da transação, coluna Conta de Débito. Exemplos 123456789987654321ACC-001-992
	Usuário de Processamento ProcessingUser	O ID do usuário ou agente do sistema responsável pela atividade.
Descrição Identifica quem realizou a ação, seja um aprovador humano ou um bot de automação. Estes dados alimentam os dashboards de Eficiência de Resolução de Erros e Produtividade de Alçadas. Ao rastrear os usuários, analistas podem identificar necessidades de treinamento para pessoas com altas taxas de erro ou localizar gargalos onde aprovadores específicos estão sobrecarregados. Por que é importante Permite análise de recursos e identificação de gargalos. Onde obter Logs de auditoria, coluna de ID de usuário. Exemplos jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Valor do Pagamento PaymentAmount	O valor monetário da transação de pagamento.
Descrição Este atributo representa o valor financeiro associado ao pagamento. É uma dimensão primária para segmentar a análise, permitindo que os usuários diferenciem entre pagamentos estratégicos de alto valor e transações rotineiras de baixo valor. É essencial para a `Visualização de Detecção de Pagamentos Duplicados`, onde valores idênticos combinados com detalhes do pagador/beneficiário sinalizam possíveis erros. Também dá suporte à análise de autoridade de aprovação, já que valores mais altos geralmente ativam diferentes caminhos de workflow. Por que é importante Crítico para análise de risco financeiro e detecção de duplicidade. Onde obter Tabela de cabeçalho da transação, coluna Valor. Exemplos 150.0025000.5010.991000000.00
	Banco Beneficiário BeneficiaryBank	O nome ou identificador do banco recebedor.
Descrição Identifica a instituição financeira que recebe o pagamento. Útil para analisar atrasos na liquidação, pois bancos específicos podem ter velocidades de processamento ou problemas de integração diferentes. Adiciona uma dimensão extra ao dashboard de Gap entre Liquidação e Conciliação, ajudando a distinguir se o atraso é externo (específico do banco) ou interno. Por que é importante Análise de dependências externas. Onde obter Detalhes da transação, coluna ID do Banco ou Nome. Exemplos ChaseBank of AmericaWells FargoCitibank
	Cutoff Atrasado? IsCutoffMissed	Sinaliza se o pagamento foi enviado após o horário de corte bancário.
Descrição Um booleano calculado que compara o horário da atividade 'Instrução de Pagamento Enviada' com o horário de corte (cutoff) diário para a moeda ou método específico. Isso alimenta o KPI de Taxa de Aderência ao Cutoff. Identificar falhas no cutoff ajuda a investigar as causas raiz dos atrasos, permitindo descobrir se eles surgem de uma iniciação tardia ou de um processamento interno lento. Por que é importante Essencial para conformidade operacional e gestão de liquidez. Onde obter Calculado comparando o EventTimestamp com a tabela de referência de Cutoff. Exemplos verdadeirofalse
	É Retrabalho IsRework	Sinaliza se esta atividade específica faz parte de um loop de retrabalho.
Descrição Uma flag booleana que marca atividades que ocorrem após a identificação de um erro, mas antes de sua resolução, ou atividades repetidas. Este campo alimenta o KPI de Taxa de Retrabalho na Validação de Pagamentos. Ele permite que analistas filtrem o mapa do processo para visualizar apenas o fluxo ideal (happy path) ou, inversamente, foquem inteiramente no caminho do retrabalho para entender os modos de falha. Por que é importante Isola o trabalho que gera valor do trabalho de correção. Onde obter Calculado com base em loops no processo. Exemplos verdadeirofalse
	Nível de Aprovação ApprovalLevel	O nível hierárquico necessário ou utilizado para autorizar o pagamento.
Descrição Indica a senioridade ou o nível de alçada associado à atividade 'Pagamento Aprovado'. Usado no dashboard de Produtividade de Alçadas para analisar se aprovadores de alto nível estão se tornando gargalos. Entender a distribuição de pagamentos entre os níveis (ex: Nível 1 vs. Nível 3) ajuda a otimizar as políticas de delegação de autoridade. Por que é importante Segmenta gargalos de aprovação por hierarquia. Onde obter Papel do usuário ou tabelas de workflow de aprovação. Exemplos Nível 1GestorDiretorCFO
	Unidade de Negócio BusinessUnit	O departamento ou divisão que iniciou o pagamento.
Descrição Categoriza o pagamento pela unidade organizacional responsável pela despesa. Ajuda na alocação de custos e no entendimento de quais áreas da empresa geram mais retrabalho manual ou erros. Suporta a Auditoria de Conformidade de Pagamentos, garantindo que diferentes unidades estejam aderindo aos seus requisitos regulatórios ou de controle interno específicos. Por que é importante Fornece contexto organizacional para o desempenho. Onde obter Mapeamento de centro de custo ou código de departamento. Exemplos Banco de varejoEmpréstimos ComerciaisGestão de PatrimônioOperações

Obrigatório Recomendado Opcional

Atividades de Processamento de Pagamentos

Capture estas etapas e marcos essenciais do processo em seu event log para permitir a descoberta precisa e a otimização de seus fluxos de pagamento.

5 Recomendado 8 Opcional

	Atividade	Descrição
	Instrução de Pagamento Enviada	A transmissão do arquivo de pagamento (ex: lote ACH, mensagem Wire) para a rede externa ou câmara de compensação. Este é um ponto de entrega crítico.
Por que é importante Essencial para o 'Monitor de Conformidade de Cutoff'. Garante que a empresa cumpra os horários de corte bancários. Onde obter Logs de processamento em lote ou timestamps de geração de arquivo. Frequentemente registrados como 'Lote Criado' ou 'Arquivo Transmitido'. Captura Registrado ao gerar o arquivo de lote Tipo de evento explicit
	Pagamento Aprovado	Uma decisão manual ou automatizada para permitir que o pagamento prossiga com base em limites de alçada. Isso é capturado quando um usuário autorizado ou uma regra do sistema atualiza o status de aprovação.
Por que é importante Chave para a 'Análise de Tempo de Ciclo de Autorização'. Atrasos aqui indicam gargalos na cadeia de aprovação humana. Onde obter Logs de auditoria que mostram a ação de um usuário alterando o status de 'Pendente de Aprovação' para 'Aprovado'. Captura Registrado quando a ação de aprovação ocorre Tipo de evento explicit
	Pagamento Conciliado	A correspondência interna da transação com extratos bancários ou arquivos de liquidação. Isso fecha o ciclo para a contabilidade.
Por que é importante Necessário para o 'Intervalo entre Liquidação e Conciliação'. Garante que os registros contábeis sejam fechados com precisão. Onde obter Logs do módulo de conciliação onde o status é atualizado para 'Matched' ou 'Reconciled'. Captura Registrado ao ocorrer a conciliação Tipo de evento explicit
	Pagamento Liquidado	A movimentação de fundos é finalizada e lançada no livro razão. Isso marca a conclusão financeira da transação sob a perspectiva do banco.
Por que é importante O ponto final principal para a 'Taxa de Straight Through Processing'. Indica que o dinheiro realmente foi movimentado. Onde obter Status da transação 'Posted' ou presença de um timestamp de 'Post Date' no livro razão. Captura Registrado ao ocorrer o lançamento no razão (GL) Tipo de evento explicit
	Solicitação de Pagamento Criada	A entrada inicial da instrução de pagamento no sistema Fiserv. Isso é registrado explicitamente quando um usuário ou sistema externo inicia uma transação via API ou interface.
Por que é importante Indica o início da linha do tempo do processo. Essencial para o cálculo do tempo total de ciclo e para a identificação de gargalos na entrada. Onde obter Timestamp de criação da tabela de histórico de transações. Procure o registro mais antigo com o `ID da Transação de Pagamento` específico. Captura Registrado ao inserir o registro da transação Tipo de evento explicit
	Detalhes do Pagamento Validados	O sistema verifica números de conta, códigos de roteamento e conformidade de formato. Isso geralmente é inferido quando uma transação passa com sucesso de um status de recebido para um status pendente ou aprovado sem gerar erro.
Por que é importante Indica que o primeiro portal automático foi superado. Falhas nesta etapa representam problemas de qualidade de dados, não de liquidez ou aprovação. Onde obter Inferido a partir de uma mudança de status de 'Recebido' para 'Pendente' ou 'Pronto' em um curto intervalo de tempo. Captura Comparar campo de status antes/depois Tipo de evento inferred
	Erro de Pagamento Identificado	Captura o momento em que uma transação é sinalizada com status de falha ou código de exceção. Ocorre quando regras de validação falham ou verificações externas retornam uma resposta negativa.
Por que é importante Fundamental para o dashboard de 'Erros de Validação e Retrabalho'. Altos volumes aqui indicam problemas de qualidade de dados na origem. Onde obter O campo de status da transação muda para um código de exceção (ex: 'Inválido', 'Retenção', 'Erro'). Captura Registrado quando o status muda para Erro Tipo de evento explicit
	Erro de Pagamento Resolvido	Representa a correção de uma transação que anteriormente apresentou erro. Isso é inferido quando uma transação muda de um status de erro de volta para um status de processamento ou válido.
Por que é importante Essencial para calcular o 'Tempo Médio para Resolver Erros de Pagamento'. Ajuda a medir a eficiência da equipe de operações. Onde obter Inferido quando o status da transação muda de um código de erro para um código de processamento normal. Captura Comparar campo de status antes/depois Tipo de evento inferred
	Notificação de Pagamento Enviada	O sistema aciona uma comunicação (e-mail/SMS) para o pagador ou beneficiário confirmando a transação. Isso aumenta a transparência para o cliente.
Por que é importante Dá suporte à `Velocidade e Responsividade de Notificação`. Longos intervalos após a liquidação reduzem a confiança do cliente. Onde obter Logs de comunicação ou tabelas de histórico de interação com o cliente vinculadas ao ID da Transação. Captura Registrado ao disparar e-mail/SMS Tipo de evento explicit
	Pagamento Agendado	Ocorre quando um pagamento é aprovado, mas retido para uma data de vigência futura. O sistema coloca a transação em fila até que a janela de processamento seja aberta.
Por que é importante Explica os tempos de inatividade no processo. Diferencia um atraso causado por um gargalo de uma espera planejada até a data de vencimento. Onde obter Comparação entre 'Data de Entrada' vs 'Data de Vigência'. Se a Data de Vigência for futura, este estado fica ativo. Captura Derivado da comparação entre os campos X e Y Tipo de evento calculated
	Pagamento Autorizado	A confirmação interna final de que os fundos estão disponíveis e a transação está liberada para execução. Isso pode acontecer simultaneamente com a aprovação ou como uma verificação de sistema distinta.
Por que é importante Diferencia aprovações gerenciais de autorizações automáticas do sistema. Importante para o dashboard de 'Eficiência de Alçadas de Aprovação'. Onde obter Mudança de status indicando 'Autorizado' ou 'Pronto para Lançamento'. Captura Comparar campo de status antes/depois Tipo de evento inferred
	Pagamento Cancelado	O encerramento de um fluxo de pagamento antes da liquidação, iniciado por um usuário ou regra de sistema. Isso interrompe todo o processamento posterior.
Por que é importante Identifica desperdícios e trabalho abandonado. Altas taxas de cancelamento após a aprovação sugerem ineficiências no processo. Onde obter Mudança de status para 'Cancelado', 'Anulado' ou 'Interrompido'. Captura Registrado quando o status muda para Cancelado Tipo de evento explicit
	Pagamento Confirmado	Recebimento de uma confirmação positiva (ACK) da rede externa ou gateway. Isso confirma que a instrução foi recebida de forma válida pela entidade seguinte.
Por que é importante Valida que o `Instrução Enviada` foi bem-sucedido. Lacunas aqui indicam problemas de conectividade de rede ou de formato externo. Onde obter Logs de processamento de arquivos de entrada ou códigos de resposta de API confirmando o recebimento. Captura Registrado ao receber o ACK Tipo de evento explicit

Recomendado Opcional

Guias de Extração

Como obter seus dados da Fiserv

Etapas

1. Configurações Iniciais

Certifique-se de ter acesso ao portal de desenvolvedores do Fiserv Commerce Hub. Você precisará gerar uma API Key e um API Secret (às vezes chamados de Client ID e Client Secret) com permissões para acessar as APIs de Transaction Inquiry ou Search. Se houver restrições de IP no ambiente da Fiserv, verifique se o seu endereço IP está na lista de permissões (whitelist).

2. Configuração do Ambiente

Instale o Python 3.8 ou superior em seu servidor de extração ou máquina local. Você precisará das bibliotecas requests e pandas. Elas podem ser instaladas via pip: pip install requests pandas. Crie um diretório de trabalho para o seu script e para os arquivos de saída.

3. Configuração do Script

Baixe o script Python fornecido em seu diretório de trabalho. Abra o arquivo e atualize a seção de configuração no topo. Informe sua API_KEY, API_SECRET e a BASE_URL (use a URL de sandbox para testes e a URL de produção para a execução final). Ajuste as variáveis START_DATE e END_DATE para cobrir o período desejado para o Process Mining.

4. Implementação da Lógica de Autenticação

O script inclui uma classe auxiliar para lidar com os requisitos de autenticação específicos da Fiserv, que geralmente envolvem a geração de uma assinatura HMAC usando seu API Secret, o timestamp e o payload da requisição. Não modifique a lógica de geração da assinatura, a menos que sua implementação específica da Fiserv utilize outro padrão (como tokens OAuth2).

5. Compreendendo a Lógica de Parsing

O script consulta as transações via API. A API geralmente retorna um snapshot do objeto da transação contendo vários timestamps (ex: hora de submissão, hora de autorização, hora de liquidação). O script analisa esse objeto JSON único e o transforma (unpivot) em múltiplas linhas (eventos) para o event log. Por exemplo, um único registro JSON com um timestamp de submissão e um de liquidação gerará pelo menos duas linhas distintas no seu CSV.

6. Gerenciamento de Paginação

O script implementa um loop para gerenciar a paginação. As APIs da Fiserv limitam o número de registros por resposta (geralmente 50 ou 100). O script solicita automaticamente a próxima página até que todas as transações do período sejam recuperadas. Certifique-se de que sua conexão com a internet esteja estável, pois isso pode levar tempo em conjuntos de dados volumosos.

7. Execução

Execute o script via linha de comando: python fiserv_extraction.py. O console exibirá o progresso, mostrando o número de páginas processadas e transações recuperadas. Fique atento a erros HTTP 401 (Não autorizado) ou 429 (Limite de taxa excedido).

8. Verificação da Saída

Assim que o script terminar, verifique se existe um arquivo chamado fiserv_event_log.csv no diretório. Abra este arquivo e confirme se a coluna ActivityName contém as 13 atividades necessárias e se o campo EventTimestamp está formatado corretamente.

9. Pós-processamento (Opcional)

Se precisar de ajustes específicos de fuso horário (ex: converter UTC para o horário local), você pode modificar a seção de transformação do pandas no script ou fazer isso diretamente no ProcessMind após o upload.

10. Upload para o ProcessMind

Importe o arquivo CSV para o ProcessMind. Mapeie PaymentTransactionId como Case ID, ActivityName como Atividade e EventTimestamp como Timestamp. Certifique-se de que colunas numéricas como PaymentAmount sejam mapeadas como atributos.

Configuração

Credenciais da API: Requer chave da API (API Key) e Secret/Shared Secret. Certifique-se de que tenham acesso de leitura para os endpoints de Transaction Reporting.
Base URL: Configure para https://api.commerce.fiserv.com em produção ou use a URL específica de sandbox fornecida no onboarding.
Intervalo de Datas: Recomenda-se uma janela de extração de 30 a 90 dias devido ao volume dos dados. Para cargas históricas, execute o script em blocos mensais.
Tamanho da Página: Configurado para 100 registros por chamada para equilibrar o uso de memória e a latência da rede.
Fuso Horário (Timezone): A API retorna os timestamps em UTC. O script mantém esse padrão para garantir a consistência entre diferentes regiões.
Lógica de Retentativa: Inclui um mecanismo básico de retentativa para falhas intermitentes de rede (HTTP 500/502/503).

a Consulta de Exemplo python

import requests
import json
import time
import hmac
import hashlib
import base64
import uuid
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
API_KEY = class="hl-string">"YOUR_API_KEY"
API_SECRET = class="hl-string">"YOUR_API_SECRET"
BASE_URL = class="hl-string">"https://cert.api.fiservapps.com"  class=class="hl-string">"hl-comment"># Update to Production URL as needed
ENDPOINT = class="hl-string">"/ch/payments/v1/transaction-inquiry"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
PAGE_SIZE = 50
OUTPUT_FILE = class="hl-string">"fiserv_event_log.csv"

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># AUTHENTICATION HELPER
class=class="hl-string">"hl-comment"># ==========================================
def generate_headers(payload):
    class=class="hl-string">"hl-comment"># Fiserv Commerce Hub typically requires HMAC auth
    class=class="hl-string">"hl-comment"># This is a standard implementation pattern
    client_request_id = str(uuid.uuid4())
    timestamp = str(int(time.time() * 1000))
    
    class=class="hl-string">"hl-comment"># specific signature construction depends on Fiserv documentation version
    class=class="hl-string">"hl-comment"># standard pattern: apiKey + reqId + timestamp + payload
    raw_signature = API_KEY + client_request_id + timestamp + payload
    
    hmac_obj = hmac.new(
        API_SECRET.encode(class="hl-string">'utf-8'),
        raw_signature.encode(class="hl-string">'utf-8'),
        hashlib.sha256
    )
    message_signature = base64.b64encode(hmac_obj.digest()).decode(class="hl-string">'utf-8')
    
    return {
        class="hl-string">"Content-Type": class="hl-string">"application/json",
        class="hl-string">"Client-Request-Id": client_request_id,
        class="hl-string">"Api-Key": API_KEY,
        class="hl-string">"Timestamp": timestamp,
        class="hl-string">"Message-Signature": message_signature
    }

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># PARSING LOGIC (UNPIVOTING EVENTS)
class=class="hl-string">"hl-comment"># ==========================================
def extract_events_from_transaction(tx):
    events = []
    
    class=class="hl-string">"hl-comment"># Base Attributes
    case_id = tx.get(class="hl-string">"transactionId", class="hl-string">"")
    amount = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"total", 0.0)
    currency = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"currency", class="hl-string">"USD")
    method = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"type", class="hl-string">"Unknown")
    payer_acc = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"maskedAccountNumber", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Identifying common attributes
    base_data = {
        class="hl-string">"PaymentTransactionId": case_id,
        class="hl-string">"SourceSystem": class="hl-string">"Fiserv Commerce Hub",
        class="hl-string">"LastDataUpdate": datetime.utcnow().isoformat(),
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentMethod": method,
        class="hl-string">"PayerAccountNumber": payer_acc,
        class="hl-string">"PayeeAccountNumber": class="hl-string">"MerchantAccount", class=class="hl-string">"hl-comment"># Placeholder
        class="hl-string">"ErrorCode": tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseCode", class="hl-string">""),
        class="hl-string">"IsStraightThroughProcessing": class="hl-string">"True" class=class="hl-string">"hl-comment"># Default assumption unless error found
    }

    class=class="hl-string">"hl-comment"># Helper to append event
    def add_event(activity, timestamp_str, specific_attrs={}):
        if timestamp_str:
            row = base_data.copy()
            row.update({
                class="hl-string">"ActivityName": activity,
                class="hl-string">"EventTimestamp": timestamp_str
            })
            row.update(specific_attrs)
            events.append(row)

    class=class="hl-string">"hl-comment"># 1. Payment Request Created (Submission Time)
    submission_time = tx.get(class="hl-string">"submissionTime")
    add_event(class="hl-string">"Payment Request Created", submission_time)

    class=class="hl-string">"hl-comment"># 2. Payment Details Validated (Inferred: slightly after submission if no immediate 400 error)
    class=class="hl-string">"hl-comment"># We infer this exists if the transaction exists and has a submission time
    if submission_time:
        class=class="hl-string">"hl-comment"># Infer validation happened 1 second after submission
        val_time = (datetime.fromisoformat(submission_time.replace(class="hl-string">'Z', class="hl-string">'+00:00')) + timedelta(seconds=1)).isoformat()
        add_event(class="hl-string">"Payment Details Validated", val_time)

    class=class="hl-string">"hl-comment"># 3. Payment Error Identified / 4. Resolved
    status = tx.get(class="hl-string">"transactionStatus", class="hl-string">"")
    if status == class="hl-string">"FAILED":
        fail_time = tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseTimestamp", submission_time)
        add_event(class="hl-string">"Payment Error Identified", fail_time, {class="hl-string">"IsStraightThroughProcessing": class="hl-string">"False"})
    elif status == class="hl-string">"APPROVED" and tx.get(class="hl-string">"retryCount", 0) > 0:
        class=class="hl-string">"hl-comment"># Logic: If approved but had retries, an error was resolved
        add_event(class="hl-string">"Payment Error Resolved", submission_time) class=class="hl-string">"hl-comment"># Simplified assumption

    class=class="hl-string">"hl-comment"># 5. Payment Approved
    approval_time = tx.get(class="hl-string">"approvalTime")
    if approval_time:
        add_event(class="hl-string">"Payment Approved", approval_time)

    class=class="hl-string">"hl-comment"># 6. Payment Authorized
    auth_time = tx.get(class="hl-string">"authorizationTime")
    class=class="hl-string">"hl-comment"># If separate auth time not provided, use approval time
    if not auth_time and approval_time:
        auth_time = approval_time
    add_event(class="hl-string">"Payment Authorized", auth_time)

    class=class="hl-string">"hl-comment"># 7. Payment Scheduled (if future dated)
    req_exec_date = tx.get(class="hl-string">"requestedExecutionDate")
    if req_exec_date and req_exec_date > submission_time:
         add_event(class="hl-string">"Payment Scheduled", submission_time)

    class=class="hl-string">"hl-comment"># 8. Payment Instruction Sent
    gateway_time = tx.get(class="hl-string">"gatewayTransmitTime")
    add_event(class="hl-string">"Payment Instruction Sent", gateway_time)

    class=class="hl-string">"hl-comment"># 9. Payment Confirmed (Gateway ACK)
    gateway_ack = tx.get(class="hl-string">"gatewayAckTime")
    add_event(class="hl-string">"Payment Confirmed", gateway_ack)

    class=class="hl-string">"hl-comment"># 10. Payment Settled
    settle_time = tx.get(class="hl-string">"settlementTime") or tx.get(class="hl-string">"fundingDate")
    add_event(class="hl-string">"Payment Settled", settle_time)

    class=class="hl-string">"hl-comment"># 11. Payment Notification Sent (Inferred or specific field)
    notify_time = tx.get(class="hl-string">"customerNotificationEmailTime")
    add_event(class="hl-string">"Payment Notification Sent", notify_time)

    class=class="hl-string">"hl-comment"># 12. Payment Reconciled
    recon_time = tx.get(class="hl-string">"reconciliationDate")
    add_event(class="hl-string">"Payment Reconciled", recon_time)

    class=class="hl-string">"hl-comment"># 13. Payment Cancelled
    if status == class="hl-string">"VOIDED" or status == class="hl-string">"CANCELLED":
        void_time = tx.get(class="hl-string">"voidTime") or tx.get(class="hl-string">"lastUpdateTime")
        add_event(class="hl-string">"Payment Cancelled", void_time)

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXTRACTION LOOP
class=class="hl-string">"hl-comment"># ==========================================
def main():
    all_events = []
    page_number = 1
    has_more = True
    
    print(fclass="hl-string">"Starting extraction from {START_DATE} to {END_DATE}...")

    while has_more:
        class=class="hl-string">"hl-comment"># Construct Search Payload
        payload_dict = {
            class="hl-string">"startDate": START_DATE,
            class="hl-string">"endDate": END_DATE,
            class="hl-string">"page": page_number,
            class="hl-string">"limit": PAGE_SIZE
        }
        payload_json = json.dumps(payload_dict)
        
        headers = generate_headers(payload_json)
        full_url = BASE_URL + ENDPOINT
        
        try:
            response = requests.post(full_url, headers=headers, data=payload_json)
            
            if response.status_code == 200:
                data = response.json()
                transactions = data.get(class="hl-string">"reports", []) class=class="hl-string">"hl-comment"># Key depends on specific endpoint schema
                
                if not transactions:
                    print(fclass="hl-string">"No transactions found on page {page_number}. Finishing.")
                    has_more = False
                    break
                
                print(fclass="hl-string">"Processing page {page_number}, found {len(transactions)} transactions.")
                
                for tx in transactions:
                    events = extract_events_from_transaction(tx)
                    all_events.extend(events)
                
                class=class="hl-string">"hl-comment"># Pagination Check
                total_pages = data.get(class="hl-string">"totalPages", page_number)
                if page_number >= total_pages:
                    has_more = False
                else:
                    page_number += 1
            else:
                print(fclass="hl-string">"Error fetching data: {response.status_code} - {response.text}")
                has_more = False
                
        except Exception as e:
            print(fclass="hl-string">"Exception occurred: {str(e)}")
            has_more = False

    class=class="hl-string">"hl-comment"># ==========================================
    class=class="hl-string">"hl-comment"># EXPORT TO CSV
    class=class="hl-string">"hl-comment"># ==========================================
    if all_events:
        df = pd.DataFrame(all_events)
        class=class="hl-string">"hl-comment"># Column ordering
        cols = [
            class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 
            class="hl-string">"SourceSystem", class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentMethod",
            class="hl-string">"PayerAccountNumber", class="hl-string">"ErrorCode", class="hl-string">"IsStraightThroughProcessing"
        ]
        class=class="hl-string">"hl-comment"># Ensure columns exist even if empty
        for c in cols:
            if c not in df.columns:
                df[c] = None
                
        df = df[cols]
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">"Extraction complete. {len(df)} rows written to {OUTPUT_FILE}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    main()

Seu template de dados de processamento de pagamentos

Seu template de dados de processamento de pagamentos

Atributos de Processamento de Pagamentos

Atividades de Processamento de Pagamentos

Guias de Extração

Script Python para API do Fiserv Commerce Hub

Etapas

1. Configurações Iniciais

2. Configuração do Ambiente

3. Configuração do Script

4. Implementação da Lógica de Autenticação

5. Compreendendo a Lógica de Parsing

6. Gerenciamento de Paginação

7. Execução

8. Verificação da Saída

9. Pós-processamento (Opcional)

10. Upload para o ProcessMind

Configuração

a Consulta de Exemplo python

Pronto para Começar?

Otimize o Processamento de Pagamentos e Atinja 98% de STP

Seu template de dados de processamento de pagamentos

Seu template de dados de processamento de pagamentos

Atributos de Processamento de Pagamentos

Atividades de Processamento de Pagamentos

Guias de Extração

Script Python para API do Fiserv Commerce Hub

Etapas

1. Configurações Iniciais

2. Configuração do Ambiente

3. Configuração do Script

4. Implementação da Lógica de Autenticação

5. Compreendendo a Lógica de Parsing

6. Gerenciamento de Paginação

7. Execução

8. Verificação da Saída

9. Pós-processamento (Opcional)

10. Upload para o ProcessMind

Configuração

a Consulta de Exemplo python

Valorizamos sua privacidade

Pronto para Começar?

Otimize o Processamento de Pagamentos e Atinja 98% de STP