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

Su Template de datos para el procesamiento de pagos

Name: Procesamiento de pagos Process Mining Data Template
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 un marco estructurado para ayudarle a transformar sus datos de Fiserv en un formato adecuado para Process Mining y el análisis. Describe los atributos y las actividades esenciales que necesita para obtener una visión clara de sus ciclos de liquidación y conciliación. Si sigue esta guía, podrá crear un Registro de eventos sólido que ponga de manifiesto las ineficiencias y los riesgos de cumplimiento de sus operaciones financieras.

Atributos recomendados para el análisis de pagos
Principales hitos del proceso que debe supervisar
Orientación técnica para extraer datos de Fiserv

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

Descargar Template

Atributos del procesamiento de pagos

Estos campos de datos recomendados proporcionan el contexto necesario en su registro de eventos para realizar un análisis completo de todo el ciclo de vida de sus pagos.

5 Obligatorio 9 Recomendado 5 Opcional

	Nombre	Descripción
	ID de transacción del pago PaymentTransactionId	Identificador único de la instrucción de pago o del caso de transacción específico.
Descripción Este atributo actúa como clave central para vincular todas las actividades de un mismo ciclo de vida del pago. Permite a los analistas seguir el recorrido desde la solicitud inicial hasta la validación, la aprobación y la liquidación o cancelación final. En entornos Fiserv, normalmente es la clave principal de las tablas del historial de transacciones. Es esencial para reconstruir el flujo del proceso y garantizar que los eventos desconectados, como una liquidación que se produce días después de la autorización, se asocien correctamente con el mismo objeto de negocio. Por qué es importante Es el Case ID fundamental necesario para agrupar los eventos en instancias de 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 tuvo lugar 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 impulsan el cálculo de la duración entre pasos, como el tiempo transcurrido entre «Payment Request Created» y «Payment Authorized». Las marcas de tiempo de alta precisión son necesarias para ordenar correctamente los eventos que ocurren con rapidez. 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 específico o cambio de estado que se produjo en el proceso de pago.
Descripción Este atributo describe el paso realizado, como «Payment Request Created» o «Payment Settled». Define los nodos del mapa de procesos y es fundamental para comprender la secuencia de operaciones. Al analizar las actividades diferenciadas, las organizaciones pueden visualizar el Workflow, identificar pasos omitidos y detectar rutas que no cumplen las normas porque se omitieron validaciones o aprobaciones obligatorias. Por qué es importante Define los eventos que componen la línea temporal 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 identificadoPago 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 entornos complejos donde los pagos pueden originarse en un canal de front-end y liquidarse en un sistema bancario central de back-end. Permite a los analistas 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 Proporciona contexto técnico y trazabilidad de los datos. Dónde obtenerlo Definido durante la extracción o a partir de los metadatos del sistema. Ejemplos Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Última actualización de datos LastDataUpdate	Marca de tiempo de la última extracción o actualización del registro.
Descripción Indica la actualidad de los datos utilizados para el análisis. Es fundamental para determinar si los Dashboards reflejan operaciones en tiempo real o instantáneas históricas. Ayuda a que los usuarios confíen en las métricas mostradas y garantiza que no tomen decisiones basadas en datos obsoletos, especialmente al supervisar el cumplimiento de los cortes o los cuellos de botella activos. Por qué es importante Garantiza la actualidad y fiabilidad de los datos. Dónde obtenerlo Hora del sistema en el momento de la ejecución del 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 «Payment Error Identified». Este atributo es la base de Validation Error and Rework Tracker. Al agregar la frecuencia de códigos de error específicos, la organización puede localizar problemas sistémicos de calidad de datos, como «Invalid Routing Number», e implementar correcciones específicas en la lógica de validación o la formación de los usuarios. Por qué es importante Identifica las causas raíz del reprocesamiento. 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 Currency and Method Volume Trends, ya que permite supervisar la exposición a distintas divisas. También se utiliza para normalizar los importes en los informes globales y garantizar que las comprobaciones de duplicados no señalen por error transacciones con el mismo valor numérico, pero en monedas diferentes. Por qué es importante Es necesario para analizar el procesamiento en varias monedas. Dónde obtenerlo Tabla de cabecera de transacciones, columna Currency. Ejemplos USDEURGBPCADJPY
	Es STP IsStraightThroughProcessing	Indicador que señala si el pago no requirió intervención manual.
Descripción Atributo booleano calculado que es verdadero si el caso no contiene pasos «Payment Error Identified», «Payment Error Resolved» ni «Payment Approved» manuales, según la definición aplicada. Contribuye directamente al KPI Straight Through Processing Rate. Permite segmentar el proceso de forma binaria: flujos totalmente automatizados frente a flujos que requieren intervención humana, lo que facilita una visión clara del potencial de automatización. Por qué es importante Métrica principal de la eficiencia del proceso y el éxito de la automatización. Dónde obtenerlo Se calcula durante la transformación de datos. Ejemplos truefalse
	Fecha de vencimiento del pago PaymentDueDate	Fecha límite en la que debe procesarse el pago.
Descripción Fecha prevista para completar el pago. Se utiliza en Processing Cutoff Compliance Monitor para señalar las transacciones que corren riesgo de retrasarse. Comparar la marca de tiempo de «Payment Settled» con este atributo permite calcular las métricas de entregas puntuales 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 entre pagos estratégicos de alto valor y transacciones rutinarias de bajo valor. Es esencial para la vista Duplicate Payment Detection, donde los importes idénticos combinados con los datos del ordenante y el beneficiario señalan posibles errores. También permite analizar la autoridad de aprobación, ya que los importes más elevados suelen activar distintas rutas de Workflow. Por qué es importante Es fundamental para el análisis del riesgo financiero y la detección de duplicados. Dónde obtenerlo Tabla de cabecera de transacciones, columna Amount. Ejemplos 150.0025000.5010.991000000.00
	Método de pago PaymentMethod	Mecanismo utilizado para ejecutar 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 los distintos métodos tienen procedimientos operativos estándar y acuerdos de nivel de servicio muy diferentes. Analizar las variantes del proceso por método de pago ayuda a determinar si los retrasos son propios 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 código del instrumento. Ejemplos Transferencia bancariaACHChequeRTPTransferencia interna
	Número de cuenta del beneficiario PayeeAccountNumber	Número de cuenta en el que se abonan los fondos.
Descripción Identifica la cuenta de destino. Al igual que la cuenta del ordenante, es fundamental para la vista Duplicate Payment Detection. Garantiza que el análisis se centre correctamente en relaciones específicas con beneficiarios. En la supervisión del cumplimiento de horarios límite, conocer al beneficiario ayuda a priorizar proveedores estratégicos o liquidaciones críticas que no deben fallar. Por qué es importante Es esencial para detectar duplicados y analizar beneficiarios. Dónde obtenerlo Detalles de la transacción, columna Credit Account o Beneficiary. Ejemplos 555000111222333444BEN-882-11
	Número de cuenta del ordenante PayerAccountNumber	Número de cuenta desde el que se debitan los fondos.
Descripción Identifica la cuenta de origen del pago. Es un componente clave de la vista Duplicate Payment Detection. Combinado con el beneficiario, el importe y la hora, forma la huella única utilizada para detectar pagos duplicados accidentales. También permite analizar el volumen de pagos por cuenta de origen e identificar las carteras internas más activas. 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
	Usuario de procesamiento ProcessingUser	ID de usuario o agente del sistema responsable de la actividad.
Descripción Identifica quién realizó una acción concreta, ya sea una persona aprobadora o un bot de automatización del sistema. Estos datos alimentan los Dashboards «Error Resolution Cycle Efficiency» y «Approval Authority Throughput». Al hacer un seguimiento de los usuarios, los analistas pueden identificar necesidades de formación en personas con índices de error elevados o detectar cuellos de botella en los que determinados aprobadores están sobrecargados de 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. Es útil para analizar los retrasos de liquidación, ya que determinados bancos receptores pueden tener distintas velocidades de procesamiento o problemas de integración. Añade otra dimensión al Dashboard Settlement to Reconciliation Gap y permite determinar si los retrasos son externos, específicos de un banco, o internos. 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 reprocesamiento IsRework	Indicador que señala si esta actividad específica forma parte de un ciclo de reprocesamiento.
Descripción Indicador booleano que marca las actividades realizadas después de identificar un error y antes de resolverlo, así como las actividades repetidas. Contribuye al KPI Payment Validation Rework Rate. Permite a los analistas filtrar el mapa de procesos para mostrar solo la «ruta ideal» o, por el contrario, centrarse por completo en la «ruta de reprocesamiento» para comprender los modos de fallo. 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 «Payment Approved». Se utiliza en el Dashboard Approval Authority Throughput para analizar si los aprobadores de mayor nivel se están convirtiendo en cuellos de botella. Comprender la distribución de los pagos entre niveles, por ejemplo, Nivel 1 frente a 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 por jerarquía. Dónde obtenerlo Tablas de roles de usuario o de Workflow de aprobación. Ejemplos Nivel 1GerenteDirectorCFO
	Se incumplió el horario límite IsCutoffMissed	Indicador que señala si el pago se envió después del horario límite bancario diario.
Descripción Booleano calculado que compara la hora de «Payment Instruction Sent» con la hora límite diaria correspondiente a la moneda y el método específicos. Contribuye al KPI Cutoff Adherence Rate. Identificar los horarios límite incumplidos ayuda a investigar las causas raíz de los retrasos, ya 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. Ayuda a asignar costes y a comprender qué áreas de la organización generan más reprocesamiento manual o errores. Contribuye a Payment Path Compliance Audit al garantizar que las distintas unidades cumplan sus requisitos normativos o de control interno específicos. Por qué es importante Proporciona 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

Capture estos pasos esenciales y estos hitos del proceso en su registro de eventos para permitir el descubrimiento y la optimización precisos de sus Workflows de pagos.

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. Este es un punto crítico de transferencia.
Por qué es importante Es fundamental para «Processing Cutoff Compliance Monitor». Garantiza que la organización cumpla los horarios límite bancarios diarios. Dónde obtenerlo Registros del procesamiento por lotes o marcas de tiempo de generación de archivos. A menudo se registran como «Batch Created» o «File Transmitted». Recopilar Se registra cuando se genera el archivo por lotes Tipo de evento explicit
	Pago aprobado	Decisión manual o automatizada que permite continuar el pago según los límites de autoridad. 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 'Authorization Cycle Time Analysis'. Los retrasos en este punto indican cuellos de botella en la cadena de aprobación humana. Dónde obtenerlo Registros de auditoría que muestran una acción de usuario que cambia el estado de 'Pending Approval' a 'Approved'. Recopilar Se registra cuando se ejecuta la acción de aprobación Tipo de evento explicit
	Pago conciliado	Conciliación interna de la transacción con los extractos bancarios o archivos de liquidación. Esto cierra el ciclo contable.
Por qué es importante Es necesario para «Settlement to Reconciliation Gap». Garantiza el cierre preciso de los libros contables. Dónde obtenerlo Registros del módulo de conciliación donde el estado se actualiza a «Matched» o «Reconciled». Recopilar Se registra cuando se concilia la transacción Tipo de evento explicit
	Pago liquidado	El movimiento de fondos finaliza y se registra 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 de «Straight Through Processing Rate». Indica que el efectivo se ha transferido realmente. Dónde obtenerlo Estado de la transacción «Posted» o presencia de una marca de tiempo «Post Date» en el libro mayor. Recopilar Se registra cuando se realiza el registro en el libro mayor Tipo de evento explicit
	Solicitud de pago creada	La introducción inicial de la instrucción de pago en el sistema Fiserv. Se registra explícitamente cuando un usuario o un sistema externo inicia una transacción mediante una API o una interfaz.
Por qué es importante Marca el inicio de la línea temporal del proceso. Es esencial para calcular el tiempo de ciclo total e identificar los cuellos de botella de entrada. Dónde obtenerlo Marca de tiempo de creación de la tabla del historial de transacciones. Busque el registro más antiguo con el Payment Transaction ID específico. Recopilar Se registra cuando se inserta el registro de la transacción Tipo de evento explicit
	Datos del pago validados	El sistema comprueba los números de cuenta, los números de ruta bancaria y el cumplimiento del formato. Normalmente se infiere cuando una transacción pasa correctamente de un estado recibido a un estado pendiente o aprobado sin activar un error.
Por qué es importante Indica que se ha superado el primer control automatizado. Un fallo en este punto representa problemas de calidad de datos, no problemas de liquidez o aprobación. Dónde obtenerlo Se infiere a partir de un cambio de estado de 'Received' a 'Pending' o 'Ready' en un periodo breve. Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Error de pago identificado	Registra el momento en que una transacción se marca con un estado de fallo o un código de excepción. Esto ocurre cuando fallan las reglas de validación o las comprobaciones externas devuelven una respuesta negativa.
Por qué es importante Es fundamental para el panel 'Validation Error and Rework Tracker'. Un volumen elevado en este punto indica problemas de calidad de datos en etapas anteriores. Dónde obtenerlo El campo de estado de la transacción cambia a un código de excepción, por ejemplo, 'Invalid', 'Hold' o 'Error'. Recopilar 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 una 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 'Mean Time to Resolve Payment Errors'. Ayuda a medir la eficiencia del equipo de operaciones. Dónde obtenerlo Se infiere cuando el estado de la transacción se actualiza de un código de error a un código de procesamiento normal. Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Notificación de pago enviada	El sistema activa una comunicación, por correo electrónico o SMS, al ordenante o beneficiario para confirmar la transacción. Esto mejora la transparencia para el cliente.
Por qué es importante Contribuye a «Notification Speed and Responsiveness». Las esperas 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 transacción. Recopilar Se registra cuando se activa el correo electrónico o SMS Tipo de evento explicit
	Pago autorizado	La confirmación interna final de que hay fondos disponibles y la transacción está autorizada para su ejecución. Puede producirse simultáneamente con la aprobación o como una comprobación independiente del sistema.
Por qué es importante Diferencia entre la aprobación gerencial y la autorización a nivel de sistema. Es importante para el Dashboard «Approval Authority Throughput». Dónde obtenerlo Cambio de estado que indica «Authorized» o «Ready to Post». Recopilar 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 un usuario o una regla del sistema. Esto detiene todo procesamiento posterior.
Por qué es importante Identifica el desperdicio y el trabajo abandonado. Unas tasas elevadas de cancelación después de la aprobación sugieren ineficiencias en el proceso. Dónde obtenerlo Cambio de estado a «Cancelled», «Void» o «Stopped». Recopilar Se registra cuando el estado cambia a Cancelled Tipo de evento explicit
	Pago confirmado	Recepción de una confirmación positiva (ACK) de la red externa o la pasarela. Confirma que la siguiente entidad recibió correctamente la instrucción.
Por qué es importante Valida que «Instruction Sent» se haya completado correctamente. Las brechas en este punto indican problemas de conectividad de red o de formato externo. Dónde obtenerlo Registros del procesamiento de archivos entrantes o códigos de respuesta de la API que confirman la recepción. Recopilar 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 efectiva 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. Diferencia entre un retraso causado por un cuello de botella y una espera deliberada hasta la fecha prevista. Dónde obtenerlo Comparación entre «Entry Date» y «Effective Date». Si «Effective Date» es futura, este estado está activo. Recopilar Se deriva de la comparación del 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 API Key y una API Secret, denominadas en ocasiones Client ID y Client Secret, con permisos para acceder a Transaction Inquiry o Search API. Verifique que su dirección IP esté incluida en la lista de permitidas del entorno de Fiserv si hay restricciones de IP activadas.

2. Configuración del entorno

Instale Python 3.8 o una versión posterior en su servidor de extracción o equipo local. Necesitará las bibliotecas requests y pandas. Puede instalarlas mediante 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 su directorio de trabajo. Ábralo y actualice la sección de configuración situada al principio. Debe indicar su API_KEY, API_SECRET y BASE_URL específicos. Utilice la URL de sandbox para las pruebas y la URL de producción para la ejecución final. Ajuste START_DATE y END_DATE para cubrir el periodo 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 normalmente implican generar una firma HMAC mediante su API Secret, 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, como tokens bearer de OAuth2.

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

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

6. Gestión de la paginación

El script implementa un bucle para gestionar la paginación. Las API de Fiserv limitan el número de registros por respuesta, normalmente a 50 o 100. El script solicita automáticamente la página siguiente hasta recuperar todas las transacciones del intervalo de fechas. Asegúrese de que su conexión a Internet sea estable, ya que el proceso puede tardar con grandes volúmenes de datos.

7. Ejecución

Ejecute el script desde la línea de comandos: python fiserv_extraction.py. La consola mostrará el progreso, incluido el número de páginas procesadas y de transacciones recuperadas. Preste atención a los errores HTTP 401 (Unauthorized) o 429 (Rate Limit).

8. Verificación de la salida

Cuando termine el script, compruebe que en el directorio exista un archivo llamado fiserv_event_log.csv. Ábralo y verifique 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 ajustes específicos de zona horaria, por ejemplo, convertir UTC a la hora local, puede modificar la sección de transformación de pandas del script o realizar el ajuste en ProcessMind después de la carga.

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, como atributos.

Configuración

Credenciales de la API: requiere una API Key y un Secret/Shared Secret. Asegúrese de que tengan acceso de lectura a los endpoints de Transaction Reporting.
URL base: establezca https://api.commerce.fiserv.com para producción o la URL específica de certificación o sandbox proporcionada durante la incorporación.
Intervalo de fechas: se recomienda un periodo de extracción de 30 a 90 días debido al tamaño de las respuestas de la API. Para cargas históricas, ejecute el script en bloques mensuales.
Tamaño de página: configurado en 100 registros por llamada para equilibrar el uso de memoria y la carga de red.
Zona horaria: la API devuelve las marcas de tiempo en UTC. El script conserva este estándar para garantizar la coherencia entre regiones.
Lógica de reintento: incluye un mecanismo básico de reintento para tiempos de espera de red intermitentes, como HTTP 500, 502 y 503.

a 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()

¿Listo para comenzar?

Comience a optimizar sus Workflows financieros aplicando este Template a su entorno de Fiserv. Nuestro enfoque guiado garantiza que disponga de los datos adecuados para impulsar mejoras significativas en su flujo de caja y en 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 de conciliación y domine sus Workflows de Fiserv.

Inicie su prueba gratuita

No necesita 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 de 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

a Consulta de ejemplo python

¿Listo para comenzar?

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

Valoramos su privacidad