> Mejora continua de procesos > Procesamiento de pagos > Fiserv > Template de datos

Su Template de datos para el procesamiento de pagos

Name: Template de datos de Process Mining para Procesamiento de pagos
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

Su Template de datos para el procesamiento de pagos

← Volver a la guía de mejora

Atributos del procesamiento de pagos(19) Actividades del procesamiento de pagos(13) Guías de extracción(1)

Su Template de datos para el procesamiento de pagos

Este Template ofrece una estructura para organizar los datos de Fiserv en un formato adecuado para Process Mining y el análisis. Describe los atributos y las actividades esenciales para obtener una visión clara de los ciclos de liquidación y conciliación. Si sigue esta guía, podrá crear un Registro de eventos completo que ponga de manifiesto las ineficiencias y los riesgos de cumplimiento en sus operaciones financieras.

Atributos recomendados para el análisis de pagos
Hitos clave del proceso que conviene supervisar
Orientación técnica para extraer datos de Fiserv

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos del procesamiento de pagos

Estos campos de datos recomendados aportan el contexto necesario para que el Registro de eventos permita analizar de forma integral todo el ciclo de vida de los pagos.

5 Obligatorio 9 Recomendado 5 Opcional

	Nombre	Descripción
	ID de la transacción de pago PaymentTransactionId	Identificador único de la instrucción de pago o del caso de transacción.
Descripción Este atributo es la clave central que permite vincular todas las actividades de un mismo ciclo de pago. Permite a quienes analizan el proceso seguir su recorrido desde la solicitud inicial hasta la validación, la aprobación y la liquidación final o la cancelación. En los entornos de Fiserv, suele ser la clave principal de las tablas del historial de transacciones. Es esencial para reconstruir el flujo del proceso y asociar correctamente los eventos que no están conectados entre sí, como una liquidación que se produce días después de la autorización, con el mismo objeto de negocio. Por qué es importante Es el ID del caso fundamental que se necesita para agrupar los eventos en instancias del proceso. Dónde obtenerlo Consulte la documentación de Fiserv sobre las tablas Transaction o Payment Header. Ejemplos TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Marca de tiempo del evento EventTimestamp	Fecha y hora exactas en que se produjo la actividad.
Descripción Este atributo registra el momento exacto en que se produjo un evento. Es la base de todos los análisis temporales, incluidos los tiempos de ciclo, los tiempos de entrega y la identificación de cuellos de botella. En los Dashboards, estos datos permiten calcular la duración entre pasos, por ejemplo, el tiempo transcurrido entre «Solicitud de pago creada» y «Pago autorizado». Se necesitan marcas de tiempo de alta precisión para ordenar correctamente los eventos que ocurren con poca diferencia de tiempo. Por qué es importante Es necesario para ordenar los eventos y calcular la duración del rendimiento del proceso. Dónde obtenerlo Registros de auditoría o columnas de marcas de tiempo de actualización de transacciones. Ejemplos 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Nombre de la actividad ActivityName	Evento o cambio de estado específico que se produjo en el proceso de pago.
Descripción Este atributo describe el paso realizado, como «Solicitud de pago creada» o «Pago liquidado». Define los nodos del mapa del proceso y es fundamental para comprender la secuencia de operaciones. Al analizar las distintas actividades, las organizaciones pueden visualizar el flujo de trabajo, identificar pasos omitidos y detectar rutas que no cumplen los requisitos, en las que se hayan omitido validaciones o aprobaciones obligatorias. Por qué es importante Define los eventos que componen la cronología del proceso. Dónde obtenerlo Registro del historial de transacciones o tablas de auditoría de cambios de estado. Ejemplos Solicitud de pago creadaPago autorizadoError de pago detectadoPago liquidadoPago cancelado
	Sistema de origen SourceSystem	Nombre del sistema del que proceden los datos.
Descripción Identifica el módulo específico de Fiserv o el sistema externo que generó el evento. Resulta especialmente útil en panoramas complejos, donde los pagos pueden originarse en un canal de atención y liquidarse en un sistema bancario central de back-end. Permite filtrar la vista del proceso por sistema de origen y orientar el análisis a entornos técnicos o puntos de integración específicos. Por qué es importante Aporta contexto técnico y permite rastrear el origen de los datos. Dónde obtenerlo Valor codificado durante la extracción o metadatos del sistema. Ejemplos Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Última actualización de los datos LastDataUpdate	Marca de tiempo de la última extracción o actualización del registro.
Descripción Indica qué tan actualizados están los datos utilizados en el análisis. Esto es fundamental para determinar si los Dashboards reflejan las operaciones en tiempo real o una instantánea histórica. Ayuda a que las personas usuarias confíen en las métricas mostradas y evita que tomen decisiones basadas en datos desactualizados, especialmente al supervisar el cumplimiento de las horas límite o los cuellos de botella activos. Por qué es importante Garantiza que los datos estén actualizados y sean fiables. Dónde obtenerlo Hora del sistema en el momento de la ejecución de ETL. Ejemplos 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Código de error ErrorCode	Código específico que se genera cuando un pago no supera la validación.
Descripción Registra el código de error técnico o de negocio asociado a las actividades de «Error de pago identificado». Este atributo es la base del seguimiento de errores de validación y retrabajo. Al agrupar la frecuencia de los códigos de error específicos, la organización puede detectar problemas sistémicos de calidad de los datos, como «Número de ruta no válido», y aplicar correcciones específicas a la lógica de validación o a la formación de las personas usuarias. Por qué es importante Permite identificar las causas raíz del retrabajo. Dónde obtenerlo Registros de errores o detalles del estado de la transacción. Ejemplos E-101INV_ACCNSF_ERRAUTH_FAIL
	Código de moneda CurrencyCode	Código ISO de la moneda del importe del pago.
Descripción Especifica la moneda en la que se expresa el pago (por ejemplo, USD o EUR). Este atributo es esencial para el Dashboard de tendencias de volumen por moneda y método, que permite a la organización supervisar su exposición a distintas divisas. También se utiliza para normalizar los importes en los informes globales y evitar que las comprobaciones de duplicados señalen por error transacciones con el mismo valor numérico pero en monedas distintas. Por qué es importante Es necesario para analizar el procesamiento en varias monedas. Dónde obtenerlo Tabla de encabezado de transacciones, columna Currency. Ejemplos USDEURGBPCADJPY
	Es STP IsStraightThroughProcessing	Indicador de si el pago se procesó sin intervención manual.
Descripción Atributo booleano calculado que es verdadero si el caso no contiene pasos de «Error de pago identificado», «Error de pago resuelto» ni «Pago aprobado» manual, según la definición utilizada. Permite calcular directamente el KPI de tasa de procesamiento directo. Permite segmentar el proceso en dos categorías: flujos totalmente automatizados y flujos que requieren intervención humana. Así se obtiene una visión clara del potencial de automatización. Por qué es importante Métrica clave de la eficiencia del proceso y del éxito de la automatización. Dónde obtenerlo Se calcula durante la transformación de los datos. Ejemplos truefalse
	Fecha de vencimiento del pago PaymentDueDate	Fecha límite para procesar el pago.
Descripción Fecha prevista para completar el pago. Se utiliza en el monitor de cumplimiento de la hora límite de procesamiento para señalar las transacciones que corren el riesgo de retrasarse. Comparar la marca de tiempo de «Pago liquidado» con este atributo permite calcular las métricas de puntualidad y ayuda a la organización a mantener la confianza de los beneficiarios. Por qué es importante Punto de referencia para medir el cumplimiento del SLA. Dónde obtenerlo Detalles de la instrucción de pago. Ejemplos 2023-11-012023-11-15
	Importe del pago PaymentAmount	Valor monetario de la transacción de pago.
Descripción Este atributo representa el valor financiero asociado al pago. Es una dimensión principal para segmentar el análisis y permite diferenciar los pagos estratégicos de alto valor de las transacciones rutinarias de bajo valor. Es esencial para la vista de detección de pagos duplicados, donde los importes idénticos junto con los datos del pagador y del beneficiario pueden señalar posibles errores. También permite analizar las facultades de aprobación, ya que los importes más altos suelen seguir distintas rutas de flujo de trabajo. Por qué es importante Es fundamental para analizar el riesgo financiero y detectar duplicados. Dónde obtenerlo Tabla de encabezado de transacciones, columna Amount. Ejemplos 150.0025000.5010.991000000.00
	Método de pago PaymentMethod	Mecanismo utilizado para realizar el pago (por ejemplo, Wire o ACH).
Descripción Clasifica la transacción según el canal de procesamiento utilizado. Este atributo es fundamental para el análisis del tiempo de ciclo de autorización, ya que cada método puede tener procedimientos operativos estándar y acuerdos de nivel de servicio muy distintos. Analizar las variantes del proceso por método de pago ayuda a determinar si las demoras son propias de un canal específico, como las transferencias internacionales, o si afectan a toda la organización. Por qué es importante Segmenta los flujos del proceso según la infraestructura utilizada. Dónde obtenerlo Columna del tipo de transacción o del código del instrumento. Ejemplos Transferencia bancariaACHChequeRTPTransferencia interna
	Número de cuenta del beneficiario PayeeAccountNumber	Número de la cuenta en la que se abonan los fondos.
Descripción Identifica la cuenta de destino. Al igual que la cuenta del pagador, es fundamental para la vista de detección de pagos duplicados y permite orientar correctamente el análisis a relaciones específicas con beneficiarios. Al supervisar el cumplimiento de las horas límite, conocer al beneficiario puede ayudar a priorizar proveedores estratégicos o liquidaciones críticas que no deben fallar. Por qué es importante Es esencial para detectar duplicados y analizar a los beneficiarios. Dónde obtenerlo Detalles de la transacción, columna Credit Account o Beneficiary. Ejemplos 555000111222333444BEN-882-11
	Número de cuenta del pagador PayerAccountNumber	Número de la cuenta de la que se debitan los fondos.
Descripción Identifica la cuenta de origen del pago. Es un componente clave de la vista de detección de pagos duplicados. Al combinarlo con el beneficiario, el importe y la hora, se obtiene una huella única que permite detectar pagos duplicados accidentales. También permite analizar el volumen de pagos por cuenta de origen e identificar las carteras internas con mayor actividad. Por qué es importante Es esencial para detectar duplicados y analizar el fraude. Dónde obtenerlo Detalles de la transacción, columna Debit Account. Ejemplos 123456789987654321ACC-001-992
	Persona usuaria que procesa ProcessingUser	ID de la persona usuaria o del agente del sistema responsable de la actividad.
Descripción Identifica quién realizó la acción específica, ya sea una persona que aprobó la operación o un bot de automatización del sistema. Estos datos alimentan los Dashboards de eficiencia del ciclo de resolución de errores y de volumen de aprobaciones por autoridad. Al hacer un seguimiento de las personas usuarias, quienes analizan el proceso pueden detectar necesidades de formación en quienes registran muchos errores o identificar cuellos de botella cuando ciertas personas responsables de aprobar reciben demasiadas solicitudes. Por qué es importante Permite analizar los recursos e identificar cuellos de botella. Dónde obtenerlo Registros de auditoría, columna User ID. Ejemplos jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Banco beneficiario BeneficiaryBank	Nombre o identificador del banco receptor.
Descripción Identifica la entidad financiera que recibe el pago. Resulta útil para analizar las demoras en la liquidación, ya que algunos bancos receptores pueden tener distintas velocidades de procesamiento o problemas de integración. Añade otra dimensión al Dashboard de brecha entre liquidación y conciliación y permite determinar si las demoras son externas, específicas de un banco, o internas. Por qué es importante Análisis de dependencias externas. Dónde obtenerlo Detalles de la transacción, columna Bank ID o Name. Ejemplos ChaseBank of AmericaWells FargoCitibank
	Es retrabajo IsRework	Indicador de si esta actividad específica forma parte de un ciclo de retrabajo.
Descripción Indicador booleano que marca las actividades realizadas después de identificar un error y antes de resolverlo, así como las actividades repetidas. Permite calcular el KPI de tasa de retrabajo en la validación de pagos. Quienes analizan el proceso pueden filtrar el mapa para mostrar solo la ruta ideal o centrarse exclusivamente en la ruta de retrabajo y comprender los tipos de fallos. Por qué es importante Distingue el trabajo que aporta valor del trabajo de corrección. Dónde obtenerlo Se calcula a partir de los ciclos del proceso. Ejemplos truefalse
	Nivel de aprobación ApprovalLevel	Nivel jerárquico necesario o utilizado para autorizar el pago.
Descripción Indica el nivel de antigüedad o autoridad asociado a la actividad «Pago aprobado». Se utiliza en el Dashboard de volumen de aprobaciones por autoridad para analizar si las personas con mayor nivel de aprobación se están convirtiendo en cuellos de botella. Comprender cómo se distribuyen los pagos entre los distintos niveles, por ejemplo, entre el nivel 1 y el nivel 3, ayuda a optimizar las políticas de delegación de autoridad. Por qué es importante Segmenta los cuellos de botella de aprobación según la jerarquía. Dónde obtenerlo Tablas de roles de usuario o de flujo de trabajo de aprobación. Ejemplos Nivel 1GerenteDirectorCFO
	Se incumplió la hora límite IsCutoffMissed	Indicador de si el pago se envió después de la hora límite bancaria diaria.
Descripción Valor booleano calculado que compara la hora de envío de la instrucción de pago con la hora límite diaria correspondiente a la moneda y al método. Permite calcular el KPI de tasa de cumplimiento de la hora límite. Identificar las horas límite incumplidas ayuda a investigar las causas raíz de las demoras, ya sea que se deban a un inicio tardío o a un procesamiento interno lento. Por qué es importante Es fundamental para el cumplimiento operativo y la gestión de la liquidez. Dónde obtenerlo Se calcula comparando EventTimestamp con la tabla Cutoff Reference. Ejemplos truefalse
	Unidad de negocio BusinessUnit	Departamento o división que inició el pago.
Descripción Clasifica el pago según la unidad organizativa responsable del gasto. Esto ayuda a asignar los costes y a comprender qué áreas de la organización generan más retrabajo manual o errores. Permite realizar la auditoría de cumplimiento de las rutas de pago y comprobar que cada unidad respete sus requisitos normativos o de control interno. Por qué es importante Aporta contexto organizativo para evaluar el rendimiento. Dónde obtenerlo Asignación del centro de costes o código del departamento. Ejemplos Banca minoristaPréstamos comercialesGestión patrimonialOperaciones

Obligatorio Recomendado Opcional

Actividades del procesamiento de pagos

Registre estos pasos e hitos esenciales del proceso en el Registro de eventos para descubrir y optimizar con precisión los flujos de trabajo de pago.

5 Recomendado 8 Opcional

	Actividad	Descripción
	Instrucción de pago enviada	Transmisión del archivo de pago (por ejemplo, un lote ACH o un mensaje Wire) a la red externa o cámara de compensación. Es un punto de transferencia crítico.
Por qué es importante Es fundamental para el «Monitor de cumplimiento de la hora límite de procesamiento». Permite comprobar que la organización respeta las horas límite bancarias diarias. Dónde obtenerlo Registros del procesamiento por lotes o marcas de tiempo de generación de archivos. A menudo se registran como «Lote creado» o «Archivo transmitido». Capturar Se registra cuando se genera el archivo por lotes. Tipo de evento explicit
	Pago aprobado	Decisión manual o automatizada que permite continuar con el pago según los límites de autorización. Se registra cuando un usuario autorizado o una regla del sistema actualiza el indicador de aprobación.
Por qué es importante Es clave para el «Análisis del tiempo de ciclo de autorización». Los retrasos en esta etapa indican cuellos de botella en la cadena de aprobación. Dónde obtenerlo Registros de auditoría que muestran la acción de un usuario al cambiar el estado de Pending Approval a Approved. Capturar Se registra cuando se aprueba el pago Tipo de evento explicit
	Pago conciliado	Conciliación interna de la transacción con los extractos bancarios o archivos de liquidación. Este paso cierra el ciclo contable.
Por qué es importante Es necesario para medir la «Brecha entre liquidación y conciliación». Permite cerrar correctamente los libros contables. Dónde obtenerlo Registros del módulo de conciliación en los que el estado cambia a «Emparejado» o «Conciliado». Capturar Se registra cuando se concilia la transacción. Tipo de evento explicit
	Pago liquidado	Se completa el movimiento de fondos y se contabiliza en el libro mayor. Desde la perspectiva del banco, esto marca la finalización financiera de la transacción.
Por qué es importante Es el principal punto final para la «Tasa de procesamiento directo». Indica que el dinero se ha transferido efectivamente. Dónde obtenerlo Estado de la transacción «Contabilizada» o presencia de una marca de tiempo de «Fecha de contabilización» en el libro mayor. Capturar Se registra cuando se contabiliza en el libro mayor. Tipo de evento explicit
	Solicitud de pago creada	Registro inicial de la instrucción de pago en el sistema Fiserv. Queda registrado cuando un usuario o un sistema externo inicia una transacción mediante una API o una interfaz.
Por qué es importante Marca el inicio del proceso. Es esencial para calcular el tiempo de ciclo total e identificar cuellos de botella en la recepción de solicitudes. Dónde obtenerlo Marca de tiempo de creación de la tabla del historial de transacciones. Busque el registro más antiguo que tenga el ID de transacción de pago correspondiente. Capturar Se registra al insertar el registro de la transacción Tipo de evento explicit
	Datos del pago validados	El sistema comprueba los números de cuenta y de ruta, así como el cumplimiento del formato. Por lo general, se infiere que la validación se completó correctamente cuando la transacción pasa del estado recibido al estado pendiente o aprobado sin generar errores.
Por qué es importante Indica que se superó el primer control automatizado. Si se produce un fallo en esta etapa, suele deberse a problemas con la calidad de los datos, no con la liquidez o la aprobación. Dónde obtenerlo Se infiere cuando el estado cambia de Received a Pending o Ready en poco tiempo. Capturar Compare el campo de estado antes y después Tipo de evento inferred
	Error de pago detectado	Registra el momento en que una transacción recibe un estado de fallo o un código de excepción. Esto ocurre cuando no se cumplen las reglas de validación o una comprobación externa devuelve un resultado negativo.
Por qué es importante Es fundamental para el Dashboard «Seguimiento de errores de validación y correcciones». Un volumen elevado en esta etapa indica problemas de calidad de los datos en fases anteriores. Dónde obtenerlo El campo de estado de la transacción cambia a un código de excepción, como Invalid, Hold o Error. Capturar Se registra cuando el estado cambia a Error Tipo de evento explicit
	Error de pago resuelto	Representa la corrección de una transacción que había generado un error. Se infiere cuando la transacción pasa de un estado de error a un estado de procesamiento o válido.
Por qué es importante Es esencial para calcular el «Tiempo medio de resolución de errores de pago» y medir la eficiencia del equipo de operaciones. Dónde obtenerlo Se infiere cuando el estado de la transacción cambia de un código de error a un código de procesamiento normal. Capturar Compare el campo de estado antes y después Tipo de evento inferred
	Notificación de pago enviada	El sistema envía una comunicación (correo electrónico o SMS) al pagador o beneficiario para confirmar la transacción. Esto mejora la transparencia para el cliente.
Por qué es importante Contribuye a medir la «Rapidez y capacidad de respuesta de las notificaciones». Las demoras prolongadas después de la liquidación reducen la confianza del cliente. Dónde obtenerlo Registros de comunicaciones o tablas del historial de interacciones con clientes vinculadas al ID de la transacción. Capturar Se registra cuando se envía el correo electrónico o SMS. Tipo de evento explicit
	Pago autorizado	Confirmación interna final de que hay fondos disponibles y la transacción está autorizada para ejecutarse. Puede ocurrir al mismo tiempo que la aprobación o como una comprobación independiente del sistema.
Por qué es importante Distingue entre la aprobación de un responsable y la autorización a nivel de sistema. Es importante para el Dashboard «Volumen de aprobaciones por autoridad». Dónde obtenerlo Cambio de estado que indica «Autorizado» o «Listo para contabilizar». Capturar Compare el campo de estado antes y después Tipo de evento inferred
	Pago cancelado	Finalización del flujo de pago antes de la liquidación, iniciada por una persona usuaria o una regla del sistema. Esto detiene todo procesamiento posterior.
Por qué es importante Permite identificar el trabajo desperdiciado y abandonado. Una tasa elevada de cancelaciones después de la aprobación puede indicar ineficiencias en el proceso. Dónde obtenerlo Cambio de estado a «Cancelado», «Anulado» o «Detenido». Capturar Se registra cuando el estado cambia a «Cancelado». Tipo de evento explicit
	Pago confirmado	Recepción de una confirmación positiva (ACK) de la red externa o Gateway. Confirma que la siguiente entidad recibió correctamente la instrucción.
Por qué es importante Valida que el envío de la instrucción se haya realizado correctamente. Las brechas en este punto pueden indicar problemas de conectividad de red o con el formato externo. Dónde obtenerlo Registros del procesamiento de archivos entrantes o códigos de respuesta de la API que confirman la recepción. Capturar Se registra cuando se recibe el ACK. Tipo de evento explicit
	Pago programado	Se produce cuando se aprueba un pago, pero se retiene hasta una fecha futura. El sistema pone la transacción en cola hasta que se abre la ventana de procesamiento.
Por qué es importante Explica el tiempo de inactividad del proceso. Distingue entre una demora causada por un cuello de botella y una espera deliberada hasta la fecha de vencimiento. Dónde obtenerlo Comparación entre «Fecha de entrada» y «Fecha efectiva». Si la fecha efectiva es futura, este estado está activo. Capturar Se obtiene al comparar el campo X con el campo Y. Tipo de evento calculated

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Fiserv

Pasos

1. Configuración previa

Asegúrese de tener acceso al portal para desarrolladores de Fiserv Commerce Hub. Deberá generar una clave de API y un secreto de API (a veces denominados Client ID y Client Secret) con permisos para acceder a la API Transaction Inquiry o Search. Si las restricciones de IP están habilitadas, compruebe que la dirección IP esté autorizada en el entorno de Fiserv.

2. Configuración del entorno

Instale Python 3.8 o una versión posterior en el servidor de extracción o en su equipo local. Necesitará las bibliotecas requests y pandas. Puede instalarlas con pip: pip install requests pandas. Cree un directorio de trabajo para el script y los archivos de salida.

3. Configuración del script

Descargue el script de Python proporcionado en el directorio de trabajo. Abra el script y actualice la sección de configuración al principio. Debe indicar su API_KEY, API_SECRET y BASE_URL específicos (utilice la URL de pruebas para las pruebas y la URL de producción para la ejecución final). Ajuste START_DATE y END_DATE para abarcar el período de Process Mining deseado.

4. Implementación de la lógica de autenticación

El script incluye una clase auxiliar para gestionar los requisitos de autenticación específicos de Fiserv, que suelen implicar la generación de una firma HMAC con el secreto de API, la marca de tiempo y el contenido de la solicitud. No modifique la lógica de generación de la firma, salvo que su implementación específica de Fiserv utilice otro estándar (por ejemplo, tokens de portador OAuth2).

5. Comprensión de la lógica de análisis

El script consulta las transacciones mediante la API. Normalmente, la API devuelve una instantánea del objeto de transacción con varias marcas de tiempo (por ejemplo, la hora de envío, de autorización y de liquidación). El script analiza este único objeto JSON y lo convierte en varias filas (eventos) para el Registro de eventos. Por ejemplo, un registro JSON con una marca de tiempo de envío y otra de liquidación generará al menos dos filas distintas en el archivo CSV.

6. Gestión de la paginación

El script incluye un bucle para gestionar la paginación. Las API de Fiserv limitan la cantidad de registros por respuesta (a menudo, 50 o 100). El script solicita automáticamente la página siguiente hasta recuperar todas las transacciones del período indicado. Asegúrese de tener una conexión a Internet estable, ya que el proceso puede tardar con conjuntos de datos grandes.

7. Ejecución

Ejecute el script desde la línea de comandos: python fiserv_extraction.py. La consola mostrará el progreso, incluida la cantidad de páginas procesadas y transacciones recuperadas. Esté atento a los errores HTTP 401 (no autorizado) o 429 (límite de solicitudes).

8. Verificación de la salida

Cuando termine el script, busque en el directorio el archivo fiserv_event_log.csv. Ábralo y compruebe que la columna ActivityName contenga una combinación de las 13 actividades obligatorias y que el campo EventTimestamp tenga el formato correcto.

9. Posprocesamiento (opcional)

Si necesita ajustar la zona horaria (por ejemplo, convertir UTC a la hora local), puede modificar la sección de transformación de pandas del script o hacerlo en ProcessMind después de cargar los datos.

10. Carga en ProcessMind

Importe el archivo CSV en ProcessMind. Asigne PaymentTransactionId a Case ID, ActivityName a Activity y EventTimestamp a Timestamp. Asegúrese de asignar las columnas numéricas, como PaymentAmount, a los atributos.

Configuración

Credenciales de API: Se necesita una clave de API y un secreto o secreto compartido. Asegúrese de que tengan acceso de lectura a los endpoints de informes de transacciones.
URL base: Utilice https://api.commerce.fiserv.com para producción o la URL específica de certificación o pruebas que se le haya proporcionado durante la incorporación.
Período de fechas: Debido al tamaño de las respuestas de la API, se recomienda extraer datos de entre 30 y 90 días. Para cargas históricas, ejecute el script en períodos mensuales.
Tamaño de página: Configurado para 100 registros por llamada, a fin de equilibrar el uso de memoria y la carga de la red.
Zona horaria: La API devuelve las marcas de tiempo en UTC. El script conserva este estándar para garantizar la coherencia entre regiones.
Reintentos: Se incluye un mecanismo básico de reintento para los tiempos de espera de red intermitentes (HTTP 500/502/503).

Consulta de ejemplo 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()

¿Todo listo para comenzar?

Empiece a optimizar sus flujos de trabajo financieros aplicando este Template a su entorno de Fiserv. Nuestro método guiado le ayuda a disponer de los datos adecuados para lograr mejoras concretas en el flujo de caja y el cumplimiento operativo.

Volver a la guía de mejora

Descargar Template

Optimice el procesamiento de pagos y alcance hoy un 98 % de STP

Elimine los retrasos en la conciliación y gestione mejor sus flujos de trabajo de Fiserv.

Comience su prueba gratuita

No se requiere tarjeta de crédito. Configuración en minutos.

Su Template de datos para el procesamiento de pagos

Su Template de datos para el procesamiento de pagos

Atributos del procesamiento de pagos

Actividades del procesamiento de pagos

Guías de extracción

Script de Python para la API de Fiserv Commerce Hub

Pasos

1. Configuración previa

2. Configuración del entorno

3. Configuración del script

4. Implementación de la lógica de autenticación

5. Comprensión de la lógica de análisis

6. Gestión de la paginación

7. Ejecución

8. Verificación de la salida

9. Posprocesamiento (opcional)

10. Carga en ProcessMind

Configuración

Consulta de ejemplo python

¿Todo listo para comenzar?

Optimice el procesamiento de pagos y alcance hoy un 98 % de STP