> Mejora Continua de Procesos > Pagos en Procesamiento > Fiserv > Plantilla de Datos

Su `Plantilla` de Datos para el Procesamiento de Pagos

Name: Pagos en Procesamiento Process Mining Data Template
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

Su `Plantilla` de Datos para el Procesamiento de Pagos

← Volver a la Guía de Mejora

Atributos de Procesamiento de Pagos (20) Actividades de Procesamiento de Pagos (13) Guías de Extracción (1)

Su `Plantilla` de Datos para el Procesamiento de Pagos

Esta `plantilla` proporciona un marco estructurado para ayudarle a mapear sus datos de Fiserv en un formato adecuado para el `Process Mining` y el análisis. Describe los atributos y actividades esenciales necesarios para obtener una visibilidad clara de sus ciclos de liquidación y reconciliación. Siguiendo esta guía, usted puede crear un `registro de eventos` robusto que resalte las ineficiencias y los riesgos de cumplimiento dentro de sus operaciones financieras.

Atributos recomendados para el análisis de pagos
Hitos clave del proceso a monitorear
Orientación técnica para la extracción de datos de Fiserv

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de Procesamiento de Pagos

Estos campos de datos recomendados proporcionan el contexto necesario para su `registro de eventos` para apoyar un análisis exhaustivo de todo su ciclo de vida de pagos.

5 Requerido 10 Recomendado 5 Opcional

	Nombre	Descripción
	ID de Transacción de Pago PaymentTransactionId	El identificador único para la instrucción de pago o caso de transacción específico.
Descripción Este atributo sirve como clave central para vincular todas las actividades dentro de un mismo ciclo de vida de pago. Permite a los analistas rastrear el recorrido desde la solicitud inicial a través de la validación, aprobación y liquidación final o cancelación. En entornos Fiserv, esta es típicamente la clave primaria en las tablas de historial de transacciones. Es esencial para reconstruir el flujo del proceso y asegurar que los eventos desvinculados (como la liquidación que ocurre días después de la autorización) se asocien correctamente con el mismo objeto de negocio. Por qué es importante Es el ID de Caso fundamental requerido para agrupar eventos en instancias de proceso. Dónde obtener Consulte la documentación de Fiserv para las tablas de Encabezado de Transacción o de Pago. Ejemplos TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Nombre de la Actividad ActivityName	El evento o cambio de estado específico que ocurrió en el proceso de pago.
Descripción Este atributo describe el paso realizado, como 'Solicitud de Pago Creada' o 'Pago Liquidado'. Define los nodos en el mapa de proceso y es crítico para comprender la secuencia de operaciones. Al analizar las actividades distintas, las organizaciones pueden visualizar el `workflow`, identificar pasos omitidos y detectar rutas no conformes donde se omitieron validaciones o aprobaciones obligatorias. Por qué es importante Define los eventos que componen la línea de tiempo del proceso. Dónde obtener Registro de historial de transacciones o tablas de auditoría de cambio de estado. Ejemplos Solicitud de Pago CreadaPago autorizadoError de Pago IdentificadoPago LiquidadoPago Cancelado
	Timestamp del Evento EventTimestamp	La fecha y hora exactas en que ocurrió la actividad.
Descripción Este atributo registra el momento preciso en que ocurrió un evento. Es la base para todo análisis temporal, incluyendo tiempos de ciclo, plazos 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 desde 'Solicitud de Pago Creada' hasta 'Pago Autorizado'. Los `timestamps` de alta precisión son necesarios para ordenar con exactitud los eventos que ocurren en rápida sucesión. Por qué es importante Necesario para ordenar eventos y calcular las duraciones del rendimiento del proceso. Dónde obtener Registros de auditoría o columnas de marca 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
	Source System SourceSystem	El nombre del sistema donde se originaron los datos.
Descripción Identifica el módulo específico de Fiserv o el sistema externo que generó el evento. Esto es particularmente ú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, asegurando que el análisis pueda dirigirse a entornos técnicos específicos o puntos de integración. Por qué es importante Proporciona contexto técnico y linaje de datos. Dónde obtener Codificado directamente durante la extracción o metadatos del sistema. Ejemplos Fiserv PremierFiserv SignatureFiserv DNAPlataforma de Pagos Empresariales Fiserv
	Última actualización de datos LastDataUpdate	La timestamp en que el registro fue extraído o actualizado por última vez.
Descripción Indica la actualidad de los datos utilizados para el análisis. Esto es crucial para determinar si los dashboards reflejan operaciones en tiempo real o instantáneas históricas. Ayuda a los usuarios a confiar en las métricas mostradas, asegurando que no tomen decisiones basadas en datos obsoletos, especialmente al monitorear el cumplimiento de horarios de corte o cuellos de botella activos. Por qué es importante Asegura la actualidad y fiabilidad de los datos. Dónde obtener 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	El código específico generado cuando un pago falla la validación.
Descripción Captura el código de error técnico o de negocio asociado con las actividades de 'Error de Pago Identificado'. Este atributo es la base del Rastreador de Errores de Validación y Reprocesamiento. Al agregar las frecuencias de códigos de error específicos, la organización puede identificar problemas sistémicos de calidad de datos (por ejemplo, 'Número de Enrutamiento Inválido') e implementar soluciones específicas para la lógica de validación o la capacitación de usuarios. Por qué es importante Identifica las causas raíz del reprocesamiento. Dónde obtener Registros de errores o detalles de estado de transacción. Ejemplos E-101INV_ACCNSF_ERRAUTH_FAIL
	Código de Moneda CurrencyCode	El código de moneda ISO para el importe del pago.
Descripción Especifica la moneda en la que se denomina el pago (ej. USD, EUR). Este atributo es vital para el `dashboard` de Tendencias de Volumen por Moneda y Método, permitiendo a la organización monitorear la exposición a diferentes divisas. También se utiliza para normalizar los importes para informes globales y para asegurar que las comprobaciones de duplicados no marquen falsamente transacciones con el mismo valor numérico pero diferentes monedas. Por qué es importante Necesario para el análisis de procesamiento de múltiples monedas. Dónde obtener Tabla de cabecera de transacción, columna de Moneda. Ejemplos USDEURGBPCADJPY
	Duración del Procesamiento ProcessingDuration	El tiempo que tarda en completarse la actividad específica.
Descripción Representa la duración de la actividad en sí o el tiempo transcurrido desde la actividad anterior. Esto permite un análisis granular de dónde se está invirtiendo el tiempo en el proceso. Se utiliza para rellenar el mapeo genérico de 'Tiempo de Procesamiento' y ayuda a identificar pasos específicos que son consistentemente más lentos de lo esperado. Por qué es importante Mide la eficiencia de los pasos individuales del proceso. Dónde obtener Calculado a partir de diferencias de marca de tiempo. Ejemplos 00:05:0024:00:0000:00:30
	Es STP IsStraightThroughProcessing	Indicador que señala si el pago no requirió intervención manual.
Descripción Un atributo booleano calculado que es verdadero si el caso no contiene pasos de 'Error de Pago Identificado', 'Error de Pago Resuelto' o 'Pago Aprobado' manual (dependiendo de la definición). Esto apoya directamente el KPI de Tasa de Procesamiento Directo (STP). Permite la segmentación binaria del proceso: flujos puramente automatizados frente a aquellos que requieren intervención humana, facilitando una visión clara del potencial de automatización. Por qué es importante Métrica central para la eficiencia del proceso y el éxito de la automatización. Dónde obtener Calculado durante la transformación de datos. Ejemplos truefalse
	Fecha de Vencimiento de Pago PaymentDueDate	La fecha límite para procesar el pago.
Descripción La fecha objetivo para la finalización del pago. Esto se utiliza en el Monitor de Cumplimiento de Plazos de Procesamiento para marcar las transacciones que corren el riesgo de retrasarse. Comparar el `timestamp` de 'Pago Liquidado' con este atributo permite el cálculo de métricas de entrega a tiempo y ayuda a la organización a mantener la confianza con los beneficiarios. Por qué es importante Punto de referencia para medir el cumplimiento de los SLA. Dónde obtener Detalles de la instrucción de pago. Ejemplos 2023-11-012023-11-15
	Método de Pago PaymentMethod	El mecanismo utilizado para ejecutar el pago (ej. Wire, ACH).
Descripción Clasifica la transacción por su vía de procesamiento. Este atributo es fundamental para el Análisis del Tiempo de Ciclo de Autorización, ya que los diferentes métodos tienen procedimientos operativos estándar y acuerdos de nivel de servicio (SLAs) muy distintos. Analizar las variantes del proceso por método de pago ayuda a aislar si los retrasos son sistémicos de un canal específico (como transferencias internacionales) o generales para la organización. Por qué es importante Segmenta los flujos de proceso según la infraestructura utilizada. Dónde obtener Columna de tipo de transacción o código de instrumento. Ejemplos WireACHChequeRTPTransferencia Interna
	Monto del Pago PaymentAmount	El 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, permitiendo a los usuarios diferenciar entre pagos estratégicos de alto valor y transacciones rutinarias de bajo valor. Es esencial para la Vista de Detección de Pagos Duplicados, donde las cantidades idénticas combinadas con los detalles del pagador/beneficiario marcan posibles errores. También apoya el análisis de la autoridad de aprobación, ya que cantidades mayores a menudo desencadenan diferentes rutas de `workflow`. Por qué es importante Crítico para el análisis de riesgo financiero y la detección de duplicados. Dónde obtener Tabla de cabecera de transacción, columna de Importe. Ejemplos 150.0025000.5010.991000000.00
	Número de Cuenta del Beneficiario PayeeAccountNumber	El número de cuenta al que se abonan los fondos.
Descripción Identifica la cuenta de destino. Al igual que la cuenta del Pagador, esto es crítico para la Vista de Detección de Pagos Duplicados. Asegura que el análisis apunte correctamente a relaciones de beneficiarios específicas. En la monitorización del cumplimiento de horarios de corte, conocer al beneficiario puede ayudar a priorizar proveedores estratégicos o liquidaciones críticas que no deben fallar. Por qué es importante Esencial para la detección de duplicados y el análisis de beneficiarios. Dónde obtener Detalles de la transacción, columna de Cuenta de Crédito o Beneficiario. Ejemplos 555000111222333444BEN-882-11
	Número de Cuenta del Pagador PayerAccountNumber	El número de cuenta del que se adeudan los fondos.
Descripción Identifica la cuenta de origen del pago. Es un componente clave de la Vista de Detección de Pagos Duplicados. Cuando se combina con Beneficiario, Importe y Hora, forma la huella digital única utilizada para detectar pagos dobles accidentales. También permite el análisis del volumen de pagos por cuenta de origen para identificar las carteras internas más activas. Por qué es importante Esencial para la detección de duplicados y el análisis de fraude. Dónde obtener Detalles de la transacción, columna de Cuenta de Débito. Ejemplos 123456789987654321ACC-001-992
	Usuario de Procesamiento ProcessingUser	El ID de usuario o el agente del sistema responsable de la actividad.
Descripción Identifica quién realizó la acción específica, ya sea un aprobador humano o un bot de automatización del sistema. Estos datos alimentan los dashboards de Eficiencia del Ciclo de Resolución de Errores y Rendimiento de Autoridad de Aprobación. Al rastrear a los usuarios, los analistas pueden identificar necesidades de capacitación para individuos con altas tasas de error o reconocer cuellos de botella donde aprobadores específicos están sobrecargados de solicitudes. Por qué es importante Permite el análisis de recursos y la identificación de cuellos de botella. Dónde obtener Registros de auditoría, columna de ID de Usuario. Ejemplos jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	¿Es Retrabajo? IsRework	Indicador que señala si esta actividad específica forma parte de un bucle de reprocesamiento.
Descripción Un indicador booleano que marca las actividades que ocurren después de que se ha identificado un error pero antes de que se resuelva, o las actividades repetidas. Esto respalda el KPI de Tasa de Reprocesamiento por Validación de Pagos. Permite a los analistas filtrar el mapa de procesos para mostrar solo el 'flujo ideal' o, por el contrario, centrarse completamente en la 'ruta de reprocesamiento' para comprender los modos de falla. Por qué es importante Aísla el trabajo de valor añadido del trabajo de corrección. Dónde obtener Calculado basándose en bucles de proceso. Ejemplos truefalse
	Banco Beneficiario BeneficiaryBank	El nombre o identificador del banco receptor.
Descripción Identifica la institución financiera que recibe el pago. Esto es útil para analizar los retrasos en la liquidación, ya que los bancos receptores específicos pueden tener diferentes velocidades de procesamiento o problemas de integración. Añade otra dimensión al dashboard de Brecha de Liquidación a Conciliación, resaltando si los retrasos son externos (específicos del banco) o internos. Por qué es importante Análisis de dependencias externas. Dónde obtener Detalles de la transacción, columna de ID o Nombre del Banco. Ejemplos ChaseBank of AmericaWells FargoCitibank
	Incumplió Horario de Corte IsCutoffMissed	Indicador que señala si el pago se envió después del horario de corte bancario diario.
Descripción Un booleano calculado que compara el tiempo de 'Instrucción de Pago Enviada' con la hora de corte diaria para la moneda/método específico. Esto respalda el KPI de Tasa de Adherencia a Horarios de Corte. Identificar los incumplimientos de horarios de corte ayuda a investigar las causas raíz de los retrasos, ya sea que provengan de una iniciación tardía o de un procesamiento interno lento. Por qué es importante Crítico para el cumplimiento operativo y la gestión de liquidez. Dónde obtener Calculado comparando EventTimestamp con la tabla de Referencia de Horario de Corte. Ejemplos truefalse
	Nivel de Aprobación ApprovalLevel	El nivel jerárquico requerido o utilizado para autorizar el pago.
Descripción Indica el nivel de antigüedad o autoridad asociado con la actividad 'Pago Aprobado'. Esto se utiliza en el dashboard de Rendimiento de Autoridad de Aprobación para analizar si los aprobadores de mayor nivel se están convirtiendo en cuellos de botella. Comprender la distribución de pagos entre niveles (por ejemplo, Nivel 1 vs 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 obtener Tablas de roles de usuario o de `workflow` de aprobación. Ejemplos Nivel 1GerenteDirectorCFO
	Unidad de Negocio BusinessUnit	El departamento o división que inició el pago.
Descripción Clasifica el pago por la unidad organizacional responsable del gasto. Esto ayuda a asignar costos y a comprender qué partes de la organización generan la mayor cantidad de reprocesamiento manual o errores. Apoya la Auditoría de Cumplimiento de la Ruta de Pago asegurando que las diferentes unidades cumplan con sus requisitos específicos regulatorios o de control interno. Por qué es importante Proporciona contexto organizacional para el rendimiento. Dónde obtener Mapeo de centros de costo o código de departamento. Ejemplos Banca MinoristaPréstamos ComercialesGestión de PatrimoniosOperaciones

Requerido Recomendado Opcional

Actividades de Procesamiento de Pagos

Capture estos pasos y hitos esenciales del proceso en su registro de eventos para permitir un descubrimiento y una optimización precisos de sus flujos de trabajo de pago.

5 Recomendado 8 Opcional

	Actividad	Descripción
	Instrucción de Pago Enviada	La transmisión del archivo de pago (ej. lote ACH, mensaje Wire) a la red externa o cámara de compensación. Este es un punto de transferencia crítico.
Por qué es importante Crítico para el 'Monitor de Cumplimiento de Horarios de Corte de Procesamiento'. Asegura que la organización cumpla con los horarios de corte bancarios diarios. Dónde obtener Registros de procesamiento por lotes o marcas de tiempo de generación de archivos. A menudo se registra como 'Lote Creado' o 'Archivo Transmitido'. Capturar Registrado al generar archivo de lote Tipo de evento explicit
	Pago aprobado	Una decisión manual o automatizada para permitir que el pago proceda según los límites de autoridad. Esto se registra cuando un usuario autorizado o una regla del sistema actualiza el indicador de aprobación.
Por qué es importante Clave para el 'Análisis del Tiempo de Ciclo de Autorización'. Los retrasos aquí indican cuellos de botella en la cadena de aprobación humana. Dónde obtener Registros de auditoría que muestran una acción de usuario que cambia el estado de 'Aprobación Pendiente' a 'Aprobado'. Capturar Registrado al realizar acción de aprobación Tipo de evento explicit
	Pago Conciliado	La conciliación interna de la transacción con los extractos bancarios o los archivos de liquidación. Esto cierra el ciclo contable.
Por qué es importante Requerido para la 'Brecha de Liquidación a Reconciliación'. Asegura que los libros financieros se cierren con precisión. Dónde obtener Registros del módulo de reconciliación donde el estado se actualiza a 'Conciliado' o 'Reconciliado'. Capturar Registrado al producirse la coincidencia de conciliación Tipo de evento explicit
	Pago Liquidado	El movimiento de fondos se finaliza y se registra en el libro mayor. Esto marca la finalización financiera de la transacción desde la perspectiva del banco.
Por qué es importante El punto final principal para la 'Tasa de Procesamiento Directo'. Indica que el efectivo se ha movido realmente. Dónde obtener Estado de transacción 'Contabilizado' o presencia de un `timestamp` de 'Fecha de Contabilización' en el libro mayor. Capturar Registrado al realizar contabilización en GL Tipo de evento explicit
	Solicitud de Pago Creada	La entrada inicial de la instrucción de pago en el sistema Fiserv. Esto se registra explícitamente cuando un usuario o sistema externo inicia una transacción a través de API o interfaz.
Por qué es importante Marca el inicio de la línea de tiempo del proceso. Esencial para calcular el tiempo de ciclo total e identificar cuellos de botella en la entrada. Dónde obtener `Timestamp` de creación de la tabla de historial de transacciones. Busque el registro más antiguo con el ID de Transacción de Pago específico. Capturar Registrado al insertar registro de transacción Tipo de evento explicit
	Detalles de Pago Validados	El sistema verifica los números de cuenta, números de ruta y el cumplimiento del formato. Esto se infiere típicamente cuando una transacción pasa exitosamente de un estado recibido a un estado pendiente o aprobado sin desencadenar un error.
Por qué es importante Indica que se ha superado la primera puerta automatizada. Un fallo aquí representa problemas de calidad de datos en lugar de problemas de liquidez o aprobación. Dónde obtener Inferido a partir de un cambio de estado de 'Recibido' a 'Pendiente' o 'Listo' dentro de un corto período de tiempo. Capturar Compare el campo de estado antes/después Tipo de evento inferred
	Error de Pago Identificado	Registra el momento en que una transacción es marcada con un estado de falla o código de excepción. Esto ocurre cuando las reglas de validación fallan o las verificaciones externas devuelven una respuesta negativa.
Por qué es importante Crítico para el dashboard 'Rastreador de Errores de Validación y Reprocesamiento'. Volúmenes altos aquí indican problemas de calidad de datos en fases anteriores. Dónde obtener El campo de estado de la transacción cambia a un código de excepción (ej. 'Inválido', 'En Espera', 'Error'). Capturar Registrado al cambiar el estado a Error Tipo de evento explicit
	Error de Pago Resuelto	Representa la corrección de una transacción previamente errónea. Esto se infiere cuando una transacción pasa de un estado de error a un estado de procesamiento o válido.
Por qué es importante Esencial para calcular el 'Tiempo Medio de Resolución de Errores de Pago'. Ayuda a medir la eficiencia del equipo de operaciones. Dónde obtener Inferido cuando el estado de la transacción se actualiza de un código de error a un código de procesamiento normal. Capturar Compare el campo de estado antes/después Tipo de evento inferred
	Notificación de Pago Enviada	El sistema activa una comunicación (correo electrónico/SMS) al pagador o beneficiario confirmando la transacción. Esto mejora la transparencia para el cliente.
Por qué es importante Apoya la 'Velocidad y Capacidad de Respuesta de Notificaciones'. Las grandes brechas después de la liquidación reducen la confianza del cliente. Dónde obtener Registros de comunicación o tablas de historial de interacción con el cliente vinculadas al ID de Transacción. Capturar Registrado al activar correo electrónico/SMS Tipo de evento explicit
	Pago autorizado	La confirmación interna final de que los fondos están disponibles y la transacción está autorizada para su ejecución. Esto puede ocurrir simultáneamente con la aprobación o como una verificación de sistema distinta.
Por qué es importante Diferencia entre la aprobación gerencial y la autorización a nivel de sistema. Importante para el dashboard de 'Rendimiento de Autoridad de Aprobación'. Dónde obtener Cambio de estado que indica 'Autorizado' o 'Listo para Contabilizar'. Capturar Compare el campo de estado antes/después Tipo de evento inferred
	Pago Cancelado	La terminación de un 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. Altas tasas de cancelación después de la aprobación sugieren ineficiencias en el proceso. Dónde obtener Cambio de estado a 'Cancelado', 'Anulado' o 'Detenido'. Capturar Registrado al cambiar el estado a Cancelado Tipo de evento explicit
	Pago Confirmado	Recepción de un acuse de recibo (ACK) positivo de la red externa o pasarela. Esto confirma que la instrucción fue recibida válidamente por la siguiente entidad.
Por qué es importante Valida que la 'Instrucción Enviada' fue exitosa. Las brechas aquí indican problemas de conectividad de red o de formato externo. Dónde obtener Registros de procesamiento de archivos entrantes o códigos de respuesta de API que confirman la recepción. Capturar Registrado al recibir ACK Tipo de evento explicit
	Pago programado	Ocurre cuando un pago es aprobado pero retenido para 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 en el proceso. Diferencia entre un retraso causado por un cuello de botella y una espera deliberada hasta la fecha de vencimiento. Dónde obtener Comparación de 'Fecha de Entrada' vs 'Fecha Efectiva'. Si la Fecha Efectiva es futura, este estado está activo. Capturar Derivar de la comparación del `field` X con Y Tipo de evento calculated

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Fiserv

Pasos

1. Configuración de Prerrequisitos

Asegúrese de tener acceso al portal para desarrolladores de Fiserv Commerce Hub. Deberá generar una Clave API y un Secreto API (a veces denominados ID de Cliente y Secreto de Cliente) con permisos para acceder a la API de Consulta o Búsqueda de Transacciones. Verifique que su dirección IP esté en la lista blanca en el entorno de Fiserv si las restricciones de IP están habilitadas.

2. Configuración del Entorno

Instale Python 3.8 o superior en su servidor de extracción o máquina local. Necesitará las bibliotecas requests y pandas. Puede instalarlas a través de pip: pip install requests pandas. Cree un directorio de trabajo para su script y archivos de salida.

3. Configuración del Script

Descargue el script de Python proporcionado en su directorio de trabajo. Abra el script y actualice la sección de configuración en la parte superior. Debe proporcionar su API_KEY, API_SECRET específicos y la BASE_URL (use la URL de sandbox para pruebas y la URL de producción para la ejecución final). Ajuste la START_DATE y la END_DATE para cubrir la ventana deseada de Process Mining.

4. Implementación de la Lógica de Autenticación

El script incluye una clase de ayuda para manejar los requisitos de autenticación específicos de Fiserv, que típicamente implican generar una firma HMAC utilizando su Secreto API, la marca de tiempo y la carga útil de la solicitud. No modifique la lógica de generación de firma a menos que su implementación específica de Fiserv utilice un estándar diferente (por ejemplo, tokens de portador OAuth2).

5. Comprensión de la Lógica de Análisis

El script consulta la API para transacciones. La API típicamente devuelve una instantánea del objeto de transacción que contiene varias marcas de tiempo (por ejemplo, tiempo de envío, tiempo de autorización, tiempo de liquidación). El script analiza este objeto JSON único y lo desvincula en múltiples filas (eventos) para el registro de eventos. Por ejemplo, un único registro JSON con una marca de tiempo de envío y una marca de tiempo de liquidación generará al menos dos filas distintas en su CSV.

6. Manejo de la Paginación

El script implementa un bucle para manejar la paginación. Las API de Fiserv limitan el número de registros por respuesta (a menudo 50 o 100). El script solicita automáticamente la siguiente página hasta que se recuperan todas las transacciones en el rango de fechas. Asegúrese de que su conexión a internet sea estable, ya que esto puede llevar tiempo para grandes conjuntos de datos.

7. Ejecución

Ejecute el script a través de la línea de comandos: python fiserv_extraction.py. La consola imprimirá el progreso, mostrando el número de páginas procesadas y transacciones recuperadas. Esté atento a cualquier error HTTP 401 (No Autorizado) o 429 (Límite de Tasa).

8. Verificación de Salida

Una vez que el script finalice, verifique el directorio en busca de un archivo llamado fiserv_event_log.csv. Abra este archivo y verifique que la columna ActivityName contenga una mezcla de las 13 actividades requeridas y que el campo EventTimestamp esté formateado correctamente.

9. Post-procesamiento (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 en el script o manejar esto dentro de ProcessMind después de la carga.

10. Carga a ProcessMind

Importe el archivo CSV a ProcessMind. Mapee PaymentTransactionId a ID de Caso, ActivityName a Actividad y EventTimestamp a Marca de Tiempo. Asegúrese de que las columnas numéricas como PaymentAmount se mapeen como atributos.

Configuración

Credenciales de API: Requiere Clave API y Secreto/Secreto Compartido. Asegúrese de que tengan acceso de lectura a los endpoints de informes de transacciones.
URL base: Establezca https://api.commerce.fiserv.com para producción o la URL específica de certificación/sandbox proporcionada durante la incorporación.
Rango de fechas: La ventana de extracción recomendada es de 30 a 90 días debido al tamaño de las cargas útiles de la API. Para cargas históricas, ejecute el script en segmentos mensuales.
Tamaño de página: Configuradas 100 registros por llamada para equilibrar el uso de memoria y la sobrecarga de red.
Zona horaria: La API devuelve las marcas de tiempo en UTC. El script conserva este estándar para asegurar la consistencia entre regiones.
Lógica de reintentos: Incluye un mecanismo básico de reintentos para tiempos de espera de red intermitentes (HTTP 500/502/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()

Su `Plantilla` de Datos para el Procesamiento de Pagos

Su `Plantilla` de Datos para el Procesamiento de Pagos

Atributos de Procesamiento de Pagos

Actividades de Procesamiento de Pagos

Guías de Extracción

Script de Python para la API de Fiserv Commerce Hub

Pasos

1. Configuración de Prerrequisitos

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. Manejo de la Paginación

7. Ejecución

8. Verificación de Salida

9. Post-procesamiento (Opcional)

10. Carga a ProcessMind

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice el Procesamiento de Pagos y Alcance el 98% de STP Hoy

Su Plantilla de Datos para el Procesamiento de Pagos

Su Plantilla de Datos para el Procesamiento de Pagos

Atributos de Procesamiento de Pagos

Actividades de Procesamiento de Pagos

Guías de Extracción

Script de Python para la API de Fiserv Commerce Hub

Pasos

1. Configuración de Prerrequisitos

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. Manejo de la Paginación

7. Ejecución

8. Verificación de Salida

9. Post-procesamiento (Opcional)

10. Carga a ProcessMind

Configuración

a Consulta de ejemplo python

Valoramos su privacidad

¿Listo para comenzar?

Optimice el Procesamiento de Pagos y Alcance el 98% de STP Hoy

Su `Plantilla` de Datos para el Procesamiento de Pagos

Su `Plantilla` de Datos para el Procesamiento de Pagos