> Melhoria contínua de processos > Processamento de pagamentos > Fiserv > Template de dados

Seu Template de dados de processamento de pagamentos

Name: Template de dados de Process Mining para Processamento de pagamentos
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 do processamento de pagamentos (19) Atividades do processamento de pagamentos (13) Guias de extração (1)

Seu Template de dados de processamento de pagamentos

Este Template oferece uma estrutura para mapear seus dados do Fiserv em um formato adequado para Process Mining e análise. Ele apresenta os atributos e as atividades essenciais para dar visibilidade aos ciclos de liquidação e conciliação. Seguindo este guia, você pode criar um Event Log consistente, que destaca ineficiências e riscos de conformidade nas operações financeiras.

Atributos recomendados para análise de pagamentos
Principais marcos do processo a monitorar
Orientações técnicas para extrair dados do Fiserv

Novidade em Event Logs? Saiba como criar um Event Log para Process Mining.

Baixar Template

Atributos do processamento de pagamentos

Esses campos de dados recomendados fornecem o contexto necessário para que seu Event Log permita uma análise completa de todo o ciclo de pagamentos.

5 Obrigatório 9 Recomendado 5 Opcional

	Nome	Descrição
	Data e hora do evento EventTimestamp	Data e hora exatas em que a atividade ocorreu.
Descrição Este atributo registra o momento exato em que um evento ocorreu. Ele é a base de todas as análises temporais, incluindo tempos de ciclo, tempos de atravessamento e identificação de gargalos. Nos Dashboards, esses dados permitem calcular a duração entre etapas, como o intervalo entre "Solicitação de pagamento criada" e "Pagamento autorizado". Horários registrados com alta precisão são necessários para ordenar corretamente eventos que acontecem em rápida sucessão. Por que isso importa Necessário para ordenar eventos e calcular a duração da performance do processo. Onde encontrar Registros de auditoria ou colunas com data e hora das atualizações de transações. 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	Identificador exclusivo da instrução de pagamento ou do caso da transação.
Descrição Este atributo funciona como chave central para vincular todas as atividades de um mesmo ciclo de pagamento. Ele permite que analistas acompanhem o percurso desde a solicitação inicial até a validação, a aprovação e a liquidação final ou o cancelamento. Nos ambientes Fiserv, esse costuma ser o identificador principal nas tabelas de histórico de transações. Ele é essencial para reconstruir o fluxo do processo e garantir que eventos separados no tempo, como uma liquidação ocorrida dias após a autorização, sejam associados corretamente ao mesmo objeto de negócio. Por que isso importa É o ID do caso fundamental para agrupar eventos em instâncias do processo. Onde encontrar Consulte a documentação da Fiserv sobre as tabelas de transações ou cabeçalhos de pagamento. Exemplos TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Nome da atividade ActivityName	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 do mapa do processo e é essencial para entender a sequência das operações. Ao analisar as atividades distintas, as organizações podem visualizar o fluxo de trabalho, identificar etapas ignoradas e detectar caminhos fora de conformidade em que validações ou aprovações obrigatórias foram ignoradas. Por que isso importa Define os eventos que compõem a linha do tempo do processo. Onde encontrar Registro do histórico de transações ou tabelas de auditoria de mudanças de status. Exemplos Solicitação de pagamento criadaPagamento autorizadoErro de pagamento identificadoPagamento liquidadoPagamento cancelado
	Sistema de origem SourceSystem	Nome do sistema de onde os dados vieram.
Descrição Identifica o módulo específico da Fiserv ou o sistema externo que gerou o evento. Isso é especialmente útil em panoramas complexos, nos quais os pagamentos podem ser iniciados em um canal de front-end e liquidados em um sistema bancário central de back-end. Permite que analistas filtrem a visualização do processo pelo sistema de origem, direcionando a análise a ambientes técnicos ou pontos de integração específicos. Por que isso importa Fornece contexto técnico e linhagem dos dados. Onde encontrar Definido durante a extração ou obtido dos metadados do sistema. Exemplos Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Última atualização dos dados LastDataUpdate	Data e hora da última extração ou atualização do registro.
Descrição Indica o nível de atualização dos dados usados na análise. Isso é essencial para determinar se os Dashboards refletem operações em tempo real ou retratos históricos. Ajuda os usuários a confiar nas métricas exibidas e evita decisões baseadas em dados desatualizados, especialmente ao monitorar o cumprimento dos horários limite ou gargalos ativos. Por que isso importa Garante que os dados estejam atualizados e sejam confiáveis. Onde encontrar Horário do sistema no momento da execução do ETL. Exemplos 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Código da moeda CurrencyCode	Código ISO da moeda do pagamento.
Descrição Especifica a moeda em que o pagamento é expresso, como USD ou EUR. Este atributo é essencial para o Dashboard de tendências de volume por moeda e método, permitindo que a organização monitore a exposição a diferentes moedas estrangeiras. Também é usado para padronizar valores em relatórios globais e evitar que verificações de duplicidade sinalizem incorretamente transações com o mesmo valor numérico, mas em moedas diferentes. Por que isso importa Necessário para analisar o processamento em várias moedas. Onde encontrar Tabela de cabeçalho da transação, coluna Currency. Exemplos USDEURGBPCADJPY
	Código do erro ErrorCode	Código específico gerado quando um pagamento não passa na validação.
Descrição Registra o código de erro técnico ou de negócio associado às atividades de "Erro de pagamento identificado". Este atributo é a base do rastreador de erros de validação e retrabalho. Ao agrupar a frequência de códigos de erro específicos, a organização pode identificar problemas sistêmicos na qualidade dos dados, como "Número de roteamento inválido", e implementar correções direcionadas na lógica de validação ou no treinamento dos usuários. Por que isso importa Identifica as causas raiz do retrabalho. Onde encontrar Registros de erros ou detalhes do status da transação. Exemplos E-101INV_ACCNSF_ERRAUTH_FAIL
	Data de vencimento do pagamento PaymentDueDate	Data limite para o processamento do pagamento.
Descrição Data prevista para a conclusão do pagamento. É usada no monitor de conformidade com o horário limite de processamento para sinalizar transações com risco de atraso. Comparar a data e hora de "Pagamento liquidado" com este atributo permite calcular métricas de entregas no prazo e ajuda a organização a manter a confiança dos beneficiários. Por que isso importa Referência para medir o cumprimento do SLA. Onde encontrar Detalhes da instrução de pagamento. Exemplos 2023-11-012023-11-15
	É STP IsStraightThroughProcessing	Indicador de que o pagamento não exigiu intervenção manual.
Descrição Atributo booleano calculado que é verdadeiro quando o caso não contém as etapas "Erro de pagamento identificado", "Erro de pagamento resolvido" ou "Pagamento aprovado" manual, conforme a definição adotada. Isso contribui diretamente para o KPI de taxa de processamento direto (STP). Permite segmentar o processo em dois grupos: fluxos totalmente automatizados e fluxos que exigem intervenção humana, facilitando a identificação do potencial de automação. Por que isso importa Métrica essencial para a eficiência do processo e o sucesso da automação. Onde encontrar Calculado durante a transformação dos dados. Exemplos truefalse
	Método de pagamento PaymentMethod	Mecanismo usado para realizar o pagamento, como Wire ou ACH.
Descrição Classifica a transação pelo canal de processamento utilizado. Este atributo é fundamental para a análise do tempo de ciclo de autorização, pois cada método pode ter procedimentos operacionais padrão e acordos de nível de serviço muito diferentes. Analisar as variantes do processo por método de pagamento ajuda a identificar se os atrasos são específicos de um canal, como transferências internacionais, ou se afetam a organização como um todo. Por que isso importa Segmenta os fluxos do processo pela infraestrutura utilizada. Onde encontrar Coluna de tipo de transação ou código do instrumento. Exemplos Transferência WireACHChequeRTPTransferência interna
	Número da conta do beneficiário PayeeAccountNumber	Número da conta em que os fundos são creditados.
Descrição Identifica a conta de destino. Assim como a conta do pagador, é essencial para a visualização de detecção de pagamentos duplicados. Garante que a análise considere corretamente as relações com beneficiários específicos. No monitoramento dos horários limite, saber quem é o beneficiário ajuda a priorizar fornecedores estratégicos ou liquidações críticas que não podem falhar. Por que isso importa Essencial para detectar duplicidades e analisar beneficiários. Onde encontrar Detalhes da transação, coluna Credit Account ou Beneficiary. Exemplos 555000111222333444BEN-882-11
	Número da conta do pagador PayerAccountNumber	Número da conta da qual os fundos são debitados.
Descrição Identifica a conta de origem do pagamento. É um componente essencial da visualização de detecção de pagamentos duplicados. Combinado com o beneficiário, o valor e o horário, forma a combinação exclusiva usada para identificar pagamentos duplicados acidentais. Também permite analisar o volume de pagamentos por conta de origem e identificar as carteiras internas mais ativas. Por que isso importa Essencial para detectar duplicidades e analisar fraudes. Onde encontrar Detalhes da transação, coluna Debit Account. Exemplos 123456789987654321ACC-001-992
	Usuário responsável pelo processamento ProcessingUser	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 do sistema. Esses dados alimentam os Dashboards de eficiência do ciclo de resolução de erros e de volume de aprovações por nível de autoridade. Ao acompanhar os usuários, analistas podem identificar necessidades de treinamento para quem apresenta altas taxas de erro ou encontrar gargalos causados por aprovadores específicos sobrecarregados de solicitações. Por que isso importa Permite analisar recursos e identificar gargalos. Onde encontrar Registros de auditoria, coluna User ID. Exemplos jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Valor do pagamento PaymentAmount	Valor monetário da transação de pagamento.
Descrição Este atributo representa o valor financeiro associado ao pagamento. É uma dimensão essencial para segmentar a análise e diferenciar pagamentos estratégicos de alto valor de transações rotineiras de baixo valor. É essencial para a visualização de detecção de pagamentos duplicados, em que valores idênticos combinados com os dados do pagador e do beneficiário sinalizam possíveis erros. Também contribui para a análise dos níveis de aprovação, já que valores mais altos costumam seguir fluxos de trabalho diferentes. Por que isso importa Essencial para a análise de risco financeiro e a detecção de duplicidades. Onde encontrar Tabela de cabeçalho da transação, coluna Amount. Exemplos 150.0025000.5010.991000000.00
	Banco beneficiário BeneficiaryBank	Nome ou identificador do banco que recebe o pagamento.
Descrição Identifica a instituição financeira que recebe o pagamento. É útil para analisar atrasos na liquidação, pois cada banco recebedor pode ter uma velocidade de processamento ou problemas de integração diferentes. Acrescenta outra dimensão ao Dashboard do intervalo entre liquidação e conciliação, ajudando a identificar se os atrasos são externos, específicos de um banco, ou internos. Por que isso importa Análise de dependências externas. Onde encontrar Detalhes da transação, coluna Bank ID ou Name. Exemplos ChaseBank of AmericaWells FargoCitibank
	É retrabalho IsRework	Indicador de que esta atividade específica faz parte de um ciclo de retrabalho.
Descrição Indicador booleano que marca atividades realizadas após a identificação de um erro e antes de sua resolução, ou atividades repetidas. Isso contribui para o KPI de taxa de retrabalho na validação de pagamentos. Permite que analistas filtrem o mapa do processo para mostrar apenas o caminho ideal ou, por outro lado, se concentrem no caminho de retrabalho para entender os modos de falha. Por que isso importa Separa o trabalho que agrega valor do trabalho de correção. Onde encontrar Calculado com base nos ciclos do processo. Exemplos truefalse
	Nível de aprovação ApprovalLevel	Nível hierárquico necessário ou utilizado para autorizar o pagamento.
Descrição Indica o nível de senioridade ou autoridade associado à atividade "Pagamento aprovado". É usado no Dashboard de volume de aprovações por nível de autoridade para analisar se aprovadores de níveis mais altos estão se tornando gargalos. Entender como os pagamentos se distribuem entre os níveis, como Nível 1 e Nível 3, ajuda a otimizar as políticas de delegação de autoridade. Por que isso importa Segmenta os gargalos de aprovação por nível hierárquico. Onde encontrar Tabelas de funções de usuários ou de fluxo de trabalho de aprovação. Exemplos Nível 1GerenteDiretorCFO
	O horário limite foi perdido IsCutoffMissed	Indicador de que o pagamento foi enviado após o horário limite diário do banco.
Descrição Valor booleano calculado pela comparação entre o horário de envio da instrução de pagamento e o horário limite diário da moeda e do método específicos. Isso contribui para o KPI de taxa de cumprimento do horário limite. Identificar horários limite perdidos ajuda a investigar as causas raiz dos atrasos, seja uma iniciação tardia ou um processamento interno lento. Por que isso importa Essencial para a conformidade operacional e a gestão de liquidez. Onde encontrar Calculado pela comparação entre EventTimestamp e a tabela Cutoff Reference. Exemplos truefalse
	Unidade de negócio BusinessUnit	Departamento ou divisão que iniciou o pagamento.
Descrição Categoriza o pagamento pela unidade organizacional responsável pela despesa. Isso ajuda a alocar custos e entender quais áreas da organização geram mais retrabalho manual ou erros. Contribui para a auditoria de conformidade do fluxo de pagamento, garantindo que cada unidade cumpra seus requisitos regulatórios ou de controle interno. Por que isso importa Fornece contexto organizacional para analisar a performance. Onde encontrar Mapeamento de centros de custo ou código do departamento. Exemplos Banco de varejoCrédito comercialGestão de patrimônioOperações

Obrigatório Recomendado Opcional

Atividades do processamento de pagamentos

Registre no Event Log estas etapas e marcos essenciais do processo para identificar e otimizar seus fluxos de trabalho de pagamento com precisão.

5 Recomendado 8 Opcional

	Atividade	Descrição
	Instrução de pagamento enviada	Transmissão do arquivo de pagamento, como um lote ACH ou uma mensagem Wire, para a rede externa ou câmara de compensação. Este é um ponto crítico de transferência.
Por que isso importa Essencial para o monitor de conformidade com o horário limite de processamento. Garante que a organização cumpra os horários limite bancários diários. Onde encontrar Registros de processamento em lote ou horários de geração do arquivo. Geralmente registrados como "Lote criado" ou "Arquivo transmitido". Coleta Registrado quando o arquivo do lote é gerado Tipo de evento explicit
	Pagamento aprovado	Decisão manual ou automatizada que permite o pagamento com base nos limites de alçada. Esse evento é registrado quando um usuário autorizado ou uma regra do sistema atualiza o indicador de aprovação.
Por que isso importa Essencial para a 'Análise do tempo de ciclo de autorização'. Atrasos nessa etapa indicam gargalos na cadeia de aprovação humana. Onde encontrar Registros de auditoria que mostram uma ação do usuário alterando o status de 'Aguardando aprovação' para 'Aprovado'. Coleta Registrado quando a aprovação é concedida Tipo de evento explicit
	Pagamento conciliado	Conferência interna da transação com extratos bancários ou arquivos de liquidação. Essa etapa fecha o ciclo contábil.
Por que isso importa Necessário para medir o intervalo entre liquidação e conciliação. Garante o fechamento correto dos livros contábeis. Onde encontrar Registros do módulo de conciliação em que o status muda para "Correspondente" ou "Conciliado". Coleta Registrado quando ocorre a correspondência na conciliação Tipo de evento explicit
	Pagamento liquidado	A movimentação dos fundos é concluída e registrada no razão geral. Isso marca a conclusão financeira da transação do ponto de vista do banco.
Por que isso importa Principal ponto final para a taxa de processamento direto (STP). Indica que o dinheiro realmente foi transferido. Onde encontrar Status da transação "Contabilizado" ou presença de um horário de contabilização no razão. Coleta Registrado quando ocorre o lançamento no razão geral Tipo de evento explicit
	Solicitação de pagamento criada	Registro inicial da instrução de pagamento no sistema Fiserv. Esse evento é registrado quando um usuário ou sistema externo inicia uma transação por API ou interface.
Por que isso importa Marca o início da linha do tempo do processo. É essencial para calcular o tempo de ciclo total e identificar gargalos na entrada. Onde encontrar Data e hora de criação do registro na tabela de histórico de transações. Procure o registro mais antigo com o ID da transação de pagamento correspondente. Coleta Registrado quando o registro da transação é inserido Tipo de evento explicit
	Dados do pagamento validados	O sistema verifica números de conta, números de roteamento e conformidade do formato. Em geral, isso é inferido quando uma transação passa do status recebido para pendente ou aprovado sem gerar um erro.
Por que isso importa Indica que a primeira etapa automatizada de verificação foi concluída. Uma falha aqui aponta para problemas na qualidade dos dados, não para questões de liquidez ou aprovação. Onde encontrar Inferido quando o status muda de 'Recebido' para 'Pendente' ou 'Pronto' em pouco tempo. Coleta Compare o campo de status antes e depois Tipo de evento inferred
	Erro de pagamento identificado	Registra o momento em que uma transação recebe um status de falha ou um código de exceção. Isso ocorre quando as regras de validação falham ou verificações externas retornam uma resposta negativa.
Por que isso importa Essencial para o dashboard 'Rastreador de erros de validação e retrabalho'. Um volume elevado aqui indica problemas na qualidade dos dados de origem. Onde encontrar O campo de status da transação muda para um código de exceção (por exemplo, 'Inválido', 'Em espera', 'Erro'). Coleta Registrado quando o status muda para Erro Tipo de evento explicit
	Erro de pagamento resolvido	Representa a correção de uma transação que apresentou erro. Isso é inferido quando a transação passa de um status de erro para um status de processamento ou válido.
Por que isso importa Essencial para calcular o 'Tempo médio para resolver erros de pagamento'. Ajuda a medir a eficiência da equipe de operações. Onde encontrar Inferido quando o status da transação muda de um código de erro para um código normal de processamento. Coleta Compare o campo de status antes e depois Tipo de evento inferred
	Notificação de pagamento enviada	O sistema envia uma comunicação por e-mail ou SMS ao pagador ou beneficiário para confirmar a transação. Isso aumenta a transparência para o cliente.
Por que isso importa Contribui para medir a rapidez e a agilidade das notificações. Longos intervalos após a liquidação reduzem a confiança do cliente. Onde encontrar Registros de comunicação ou tabelas de histórico de interações com clientes vinculadas ao ID da transação. Coleta Registrado quando o e-mail ou SMS é enviado Tipo de evento explicit
	Pagamento agendado	Ocorre quando um pagamento é aprovado, mas fica retido até uma data futura de efetivação. O sistema mantém a transação na fila até o início da janela de processamento.
Por que isso importa Explica o tempo ocioso no processo. Diferencia atrasos causados por um gargalo de uma espera programada até a data de vencimento. Onde encontrar Comparação entre "Data de entrada" e "Data de efetivação". Se a data de efetivação for futura, este status fica ativo. Coleta Derivado da comparação entre o campo X e o campo Y Tipo de evento calculated
	Pagamento autorizado	Confirmação interna final de que há recursos disponíveis e a transação está liberada para execução. Isso pode ocorrer ao mesmo tempo que a aprovação ou em uma verificação separada do sistema.
Por que isso importa Diferencia a aprovação gerencial da autorização no nível do sistema. Importante para o Dashboard de volume de aprovações por nível de autoridade. Onde encontrar Mudança de status que indica "Autorizado" ou "Pronto para contabilização". Coleta Compare o campo de status antes e depois Tipo de evento inferred
	Pagamento cancelado	Encerramento do fluxo de pagamento antes da liquidação, iniciado por um usuário ou por uma regra do sistema. Isso interrompe todo o processamento subsequente.
Por que isso importa Identifica desperdícios e trabalho abandonado. Uma alta taxa de cancelamento após a aprovação pode indicar ineficiências no processo. Onde encontrar Mudança de status para "Cancelado", "Anulado" ou "Interrompido". Coleta Registrado quando o status muda para Cancelado Tipo de evento explicit
	Pagamento confirmado	Recebimento de uma confirmação positiva (ACK) da rede externa ou do Gateway. Isso confirma que a próxima entidade recebeu a instrução corretamente.
Por que isso importa Valida se o envio da instrução foi bem-sucedido. Lacunas nesta etapa indicam problemas de conectividade de rede ou de formato externo. Onde encontrar Registros de processamento de arquivos recebidos ou códigos de resposta da API que confirmam o recebimento. Coleta Registrado quando o ACK é recebido Tipo de evento explicit

Recomendado Opcional

Guias de extração

Como obter seus dados do Fiserv

Etapas

1. Configuração prévia

Confirme que você tem acesso ao portal de desenvolvedores do Fiserv Commerce Hub. Gere uma API Key e um API Secret (às vezes chamados de Client ID e Client Secret) com permissão para acessar a API Transaction Inquiry ou Search. Se as restrições de IP estiverem ativadas no ambiente Fiserv, confirme que seu endereço IP está na lista de permissões.

2. Configuração do ambiente

Instale o Python 3.8 ou superior no servidor de extração ou no computador local. Você precisará das bibliotecas requests e pandas. Instale-as com o pip: pip install requests pandas. Crie um diretório de trabalho para o script e os arquivos de saída.

3. Configuração do script

Baixe o script Python fornecido para o diretório de trabalho. Abra-o e atualize a seção de configuração no início do arquivo. Informe seu API_KEY, API_SECRET e BASE_URL específicos (use a URL de sandbox para testes e a URL de produção na execução final). Ajuste START_DATE e END_DATE para abranger o período de Process Mining desejado.

4. Implementação da lógica de autenticação

O script inclui uma classe auxiliar para lidar com os requisitos específicos de autenticação do Fiserv, que normalmente envolvem gerar uma assinatura HMAC usando seu API Secret, a data e hora da solicitação e o conteúdo enviado. Não altere a lógica de geração da assinatura, a menos que sua implementação específica do Fiserv use outro padrão (por exemplo, tokens bearer OAuth2).

5. Entenda a lógica de análise dos dados

O script consulta a API para obter as transações. Em geral, a API retorna um retrato do objeto da transação com várias datas e horários (por exemplo, horário de envio, autorização e liquidação). O script analisa esse único objeto JSON e o converte em várias linhas (eventos) para o Event Log. Por exemplo, um único registro JSON com os horários de envio e liquidação vai gerar pelo menos duas linhas distintas no CSV.

6. Como lidar com a paginação

O script usa um loop para lidar com a paginação. As APIs do Fiserv limitam o número de registros por resposta (geralmente 50 ou 100). O script solicita automaticamente a próxima página até recuperar todas as transações do período. Mantenha a conexão com a internet estável, pois o processo pode levar algum tempo quando há muitos dados.

7. Execução

Execute o script pela linha de comando: python fiserv_extraction.py. O console exibirá o andamento, incluindo o número de páginas processadas e de transações recuperadas. Fique atento a erros HTTP 401 (não autorizado) ou 429 (limite de solicitações).

8. Verificação dos resultados

Quando o script terminar, procure no diretório o arquivo fiserv_event_log.csv. Abra-o e confirme que a coluna ActivityName contém uma combinação das 13 atividades obrigatórias e que o campo EventTimestamp está formatado corretamente.

9. Pós-processamento (opcional)

Se você precisar ajustar o fuso horário (por exemplo, converter UTC para o horário local), poderá modificar a seção de transformação do pandas no script ou fazer esse ajuste no ProcessMind depois de carregar o arquivo.

10. Carregue no ProcessMind

Importe o arquivo CSV para o ProcessMind. Mapeie PaymentTransactionId para Case ID, ActivityName para Activity e EventTimestamp para Timestamp. Mapeie colunas numéricas, como PaymentAmount, como atributos.

Configuração

Credenciais da API: requer API Key e Secret/Shared Secret. Confirme que elas têm acesso de leitura aos endpoints de relatórios de transações.
URL base: use https://api.commerce.fiserv.com para produção ou a URL específica de certificação/sandbox fornecida durante a integração.
Período: recomenda-se extrair dados de 30 a 90 dias devido ao tamanho das respostas da API. Para cargas históricas, execute o script em períodos mensais.
Tamanho da página: configurado para 100 registros por chamada, equilibrando o uso de memória e a sobrecarga de rede.
Fuso horário: a API retorna datas e horas em UTC. O script mantém esse padrão para garantir a consistência entre regiões.
Lógica de nova tentativa: inclui um mecanismo básico de nova tentativa para interrupções temporárias 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()

Pronto para começar?

Comece a otimizar seus fluxos de trabalho financeiros aplicando este Template ao seu ambiente Fiserv. Nossa abordagem guiada ajuda você a reunir os dados certos para promover melhorias significativas no fluxo de caixa e na conformidade operacional.

Voltar ao guia de melhoria Baixar Template

Otimize o processamento de pagamentos e alcance 98% de STP hoje

Elimine atrasos na conciliação e tenha mais controle sobre seus fluxos de trabalho no Fiserv.

Comece o teste grátis

Não é necessário informar cartão de crédito. Configure em poucos minutos.

Seu Template de dados de processamento de pagamentos

Seu Template de dados de processamento de pagamentos

Atributos do processamento de pagamentos

Atividades do processamento de pagamentos

Guias de extração

Script Python para a API do Fiserv Commerce Hub

Etapas

1. Configuração prévia

2. Configuração do ambiente

3. Configuração do script

4. Implementação da lógica de autenticação

5. Entenda a lógica de análise dos dados

6. Como lidar com a paginação

7. Execução

8. Verificação dos resultados

9. Pós-processamento (opcional)

10. Carregue no ProcessMind

Configuração

a Consulta de exemplo python

Pronto para começar?

Otimize o processamento de pagamentos e alcance 98% de STP hoje

Sua privacidade é importante para nós