> Continuous Process Improvement > Payments Processing > Fiserv > Data Template

Your Payments Processing Data Template

Name: Payments Processing Process Mining Data Template
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

← Back to Improvement Guide

Payments Processing Attributes (20) Payments Processing Activities (13) Extraction Guides (1)

Your Payments Processing Data Template

This template provides a structured framework to help you map your Fiserv data into a format suitable for process mining and analysis. It outlines the essential attributes and activities needed to gain clear visibility into your settlement and reconciliation cycles. By following this guide, you can create a robust event log that highlights inefficiencies and compliance risks within your financial operations.

Recommended attributes for payment analysis
Key process milestones to monitor
Technical guidance for Fiserv data extraction

New to event logs? Learn how to create a process mining event log.

Download Template

Payments Processing Attributes

These recommended data fields provide the necessary context for your event log to support a comprehensive analysis of your entire payments lifecycle.

5 Required 10 Recommended 5 Optional

	Name	Description
	Activity Name ActivityName	The specific event or status change that occurred in the payment process.
Description This attribute describes the step performed, such as 'Payment Request Created' or 'Payment Settled'. It defines the nodes in the process map and is critical for understanding the sequence of operations. By analyzing the distinct activities, organizations can visualize the workflow, identify skipped steps, and detect non-compliant paths where mandatory validations or approvals were bypassed. Why it matters Defines the events that make up the process timeline. Where to get Transaction history log or status change audit tables. Examples Payment Request CreatedPayment AuthorizedPayment Error IdentifiedPayment SettledPayment Cancelled
	Event Timestamp EventTimestamp	The exact date and time when the activity occurred.
Description This attribute records the precise moment an event took place. It is the basis for all temporal analysis, including cycle times, lead times, and bottleneck identification. In dashboards, this data drives the calculation of duration between steps, such as the time from 'Payment Request Created' to 'Payment Authorized'. High-precision timestamps are necessary to accurately order events that happen in rapid succession. Why it matters Required to order events and calculate process performance durations. Where to get Audit logs or transaction update timestamp columns. Examples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Payment Transaction ID PaymentTransactionId	The unique identifier for the specific payment instruction or transaction case.
Description This attribute serves as the central key for linking all activities within a single payment lifecycle. It allows analysts to trace the journey from the initial request through validation, approval, and final settlement or cancellation. In Fiserv environments, this is typically the primary key in the transaction history tables. It is essential for reconstructing the process flow and ensuring that disjointed events (like settlement occurring days after authorization) are correctly associated with the same business object. Why it matters It is the fundamental Case ID required to group events into process instances. Where to get Consult Fiserv documentation for Transaction or Payment Header tables. Examples TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Last Data Update LastDataUpdate	The timestamp when the record was last extracted or refreshed.
Description Indicates the freshness of the data used for analysis. This is crucial for determining if the dashboards reflect real-time operations or historical snapshots. It helps users trust the metrics displayed, ensuring they are not making decisions based on stale data, especially when monitoring cutoff compliance or active bottlenecks. Why it matters Ensures data currency and reliability. Where to get System time at moment of ETL execution. Examples 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Source System SourceSystem	The name of the system where the data originated.
Description Identifies the specific Fiserv module or external system that generated the event. This is particularly useful in complex landscapes where payments might originate in a front-end channel and settle in a back-end core banking system. It allows analysts to filter the process view by system of origin, ensuring that analysis can be targeted toward specific technical environments or integration points. Why it matters Provides technical context and data lineage. Where to get Hardcoded during extraction or system metadata. Examples Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Currency Code CurrencyCode	The ISO currency code for the payment amount.
Description Specifies the currency in which the payment is denominated (e.g., USD, EUR). This attribute is vital for the Currency and Method Volume Trends dashboard, enabling the organization to monitor exposure to different foreign exchanges. It is also used to normalize amounts for global reporting and to ensure that duplicate checks do not falsely flag transactions of the same numerical value but different currencies. Why it matters Necessary for multi-currency processing analysis. Where to get Transaction header table, Currency column. Examples USDEURGBPCADJPY
	Error Code ErrorCode	The specific code generated when a payment fails validation.
Description Captures the technical or business error code associated with 'Payment Error Identified' activities. This attribute is the foundation of the Validation Error and Rework Tracker. By aggregating frequencies of specific error codes, the organization can pinpoint systemic data quality issues (e.g., 'Invalid Routing Number') and implement targeted fixes to validation logic or user training. Why it matters Identifies the root causes of rework. Where to get Error logs or transaction status details. Examples E-101INV_ACCNSF_ERRAUTH_FAIL
	Is STP IsStraightThroughProcessing	Flag indicating if the payment required no manual intervention.
Description A calculated boolean attribute that is true if the case contains no 'Payment Error Identified', 'Payment Error Resolved', or manual 'Payment Approved' steps (depending on definition). This directly supports the Straight Through Processing Rate KPI. It allows for binary segmentation of the process: purely automated flows versus those requiring human touch, facilitating a clear view of automation potential. Why it matters Core metric for process efficiency and automation success. Where to get Computed during data transformation. Examples truefalse
	Payee Account Number PayeeAccountNumber	The account number to which funds are credited.
Description Identifies the destination account. Like the Payer account, this is critical for the Duplicate Payment Detection View. It ensures that the analysis correctly targets specific beneficiary relationships. In cutoff compliance monitoring, knowing the payee can help prioritize strategic vendors or critical settlements that must not fail. Why it matters Essential for duplicate detection and payee analysis. Where to get Transaction details, Credit Account or Beneficiary column. Examples 555000111222333444BEN-882-11
	Payer Account Number PayerAccountNumber	The account number from which funds are debited.
Description Identifies the source account for the payment. This is a key component of the Duplicate Payment Detection View. When combined with Payee, Amount, and Time, it forms the unique fingerprint used to catch accidental double payments. It also allows for analysis of payment volume by originating account to identify the most active internal portfolios. Why it matters Essential for duplicate detection and fraud analysis. Where to get Transaction details, Debit Account column. Examples 123456789987654321ACC-001-992
	Payment Amount PaymentAmount	The monetary value of the payment transaction.
Description This attribute represents the financial value associated with the payment. It is a primary dimension for segmenting analysis, allowing users to differentiate between high-value strategic payments and low-value routine transactions. It is essential for the Duplicate Payment Detection View, where identical amounts paired with payer/payee details flag potential errors. It also supports approval authority analysis, as higher amounts often trigger different workflow paths. Why it matters Critical for financial risk analysis and duplicate detection. Where to get Transaction header table, Amount column. Examples 150.0025000.5010.991000000.00
	Payment Due Date PaymentDueDate	The date by which the payment must be processed.
Description The target date for the payment completion. This is used in the Processing Cutoff Compliance Monitor to flag transactions that are at risk of being late. Comparing the 'Payment Settled' timestamp against this attribute allows for the calculation of on-time delivery metrics and helps the organization maintain trust with payees. Why it matters Reference point for measuring SLA adherence. Where to get Payment instruction details. Examples 2023-11-012023-11-15
	Payment Method PaymentMethod	The mechanism used to execute the payment (e.g., Wire, ACH).
Description Classifies the transaction by its processing rail. This attribute is fundamental for the Authorization Cycle Time Analysis, as different methods have vastly different standard operating procedures and service level agreements. Analyzing process variants by payment method helps isolate whether delays are systemic to a specific channel (like international wires) or general to the organization. Why it matters Segments process flows by the infrastructure used. Where to get Transaction type or instrument code column. Examples WireACHCheckRTPInternal Transfer
	Processing Duration ProcessingDuration	The time taken for the specific activity to complete.
Description Represents the duration of the activity itself or the time since the previous activity. This allows for granular analysis of where time is being spent in the process. It is used to populate the Processing Time generic mapping and helps identifying specific steps that are consistently slower than expected. Why it matters Measures the efficiency of individual process steps. Where to get Computed from timestamp differences. Examples 00:05:0024:00:0000:00:30
	Processing User ProcessingUser	The user ID or system agent responsible for the activity.
Description Identifies who performed the specific action, whether it be a human approver or a system automation bot. This data powers the Error Resolution Cycle Efficiency and Approval Authority Throughput dashboards. By tracking users, analysts can identify training needs for individuals with high error rates or recognize bottlenecks where specific approvers are overloaded with requests. Why it matters Enables resource analysis and bottleneck identification. Where to get Audit logs, User ID column. Examples jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Approval Level ApprovalLevel	The hierarchical level required or used for authorizing the payment.
Description Indicates the seniority or authority level associated with the 'Payment Approved' activity. This is used in the Approval Authority Throughput dashboard to analyze if higher-level approvers are becoming bottlenecks. Understanding the distribution of payments across levels (e.g., Level 1 vs. Level 3) helps optimize delegation of authority policies. Why it matters Segments approval bottlenecks by hierarchy. Where to get User role or approval workflow tables. Examples Level 1ManagerDirectorCFO
	Beneficiary Bank BeneficiaryBank	The name or identifier of the receiving bank.
Description Identifies the financial institution receiving the payment. This is useful for analyzing settlement delays, as specific receiving banks may have different processing speeds or integration issues. It adds another dimension to the Settlement to Reconciliation Gap dashboard, highlighting if delays are external (bank-specific) or internal. Why it matters External dependency analysis. Where to get Transaction details, Bank ID or Name column. Examples ChaseBank of AmericaWells FargoCitibank
	Business Unit BusinessUnit	The department or division that initiated the payment.
Description Categorizes the payment by the organizational unit responsible for the expense. This helps in allocating costs and understanding which parts of the organization generate the most manual rework or errors. It supports the Payment Path Compliance Audit by ensuring that different units are adhering to their specific regulatory or internal control requirements. Why it matters Provides organizational context for performance. Where to get Cost center mapping or department code. Examples Retail BankingCommercial LendingWealth ManagementOperations
	Is Cutoff Missed IsCutoffMissed	Flag indicating if the payment was sent after the daily bank cutoff.
Description A calculated boolean that compares the 'Payment Instruction Sent' time against the daily cutoff time for the specific currency/method. This supports the Cutoff Adherence Rate KPI. Identifying missed cutoffs helps investigate the root causes of delays, whether they stem from late initiation or slow internal processing. Why it matters Critical for operational compliance and liquidity management. Where to get Computed by comparing EventTimestamp with Cutoff Reference table. Examples truefalse
	Is Rework IsRework	Flag indicating if this specific activity is part of a rework loop.
Description A boolean flag marking activities that happen after an error has been identified but before it is resolved, or repeated activities. This supports the Payment Validation Rework Rate KPI. It allows analysts to filter the process map to show only the 'happy path' or conversely, to focus entirely on the 'rework path' to understand failure modes. Why it matters Isolates value-added work from correction work. Where to get Computed based on process loops. Examples truefalse

Required Recommended Optional

Payments Processing Activities

Capture these essential process steps and milestones in your event log to enable accurate discovery and optimization of your payment workflows.

5 Recommended 8 Optional

	Activity	Description
	Payment Approved	A manual or automated decision to allow the payment to proceed based on authority limits. This is captured when an authorized user or system rule updates the approval flag.
Why it matters Key for the 'Authorization Cycle Time Analysis'. Delays here indicate bottlenecks in the human approval chain. Where to get Audit logs showing a user action that changes status from 'Pending Approval' to 'Approved'. Capture Logged when approval action is taken Event type explicit
	Payment Instruction Sent	The transmission of the payment file (e.g., ACH batch, Wire message) to the external network or clearing house. This is a critical handover point.
Why it matters Critical for 'Processing Cutoff Compliance Monitor'. Ensures the organization meets daily banking cutoffs. Where to get Batch processing logs or file generation timestamps. Often logged as 'Batch Created' or 'File Transmitted'. Capture Logged when batch file generated Event type explicit
	Payment Reconciled	The internal matching of the transaction against bank statements or settlement files. This closes the loop for accounting.
Why it matters Required for 'Settlement to Reconciliation Gap'. Ensures financial books are closed accurately. Where to get Reconciliation module logs where status updates to 'Matched' or 'Reconciled'. Capture Logged when reconciliation match occurs Event type explicit
	Payment Request Created	The initial entry of the payment instruction into the Fiserv system. This is explicitly logged when a user or external system initiates a transaction via API or interface.
Why it matters Marks the start of the process timeline. Essential for calculating total cycle time and identifying intake bottlenecks. Where to get Transaction history table creation timestamp. Look for the earliest record with the specific Payment Transaction ID. Capture Logged when transaction record inserted Event type explicit
	Payment Settled	The movement of funds is finalized and posted to the general ledger. This marks the financial completion of the transaction from the bank's perspective.
Why it matters The primary end point for 'Straight Through Processing Rate'. Indicates the cash has actually moved. Where to get Transaction status 'Posted' or presence of a 'Post Date' timestamp in the ledger. Capture Logged when GL posting occurs Event type explicit
	Payment Authorized	The final internal confirmation that funds are available and the transaction is cleared for execution. This may happen simultaneously with approval or as a distinct system check.
Why it matters Differentiates between managerial approval and system-level authorization. Important for the 'Approval Authority Throughput' dashboard. Where to get Status change indicating 'Authorized' or 'Ready to Post'. Capture Compare status field before/after Event type inferred
	Payment Cancelled	The termination of a payment flow before settlement, initiated by a user or system rule. This stops all further processing.
Why it matters Identifies waste and abandoned work. High cancellation rates after approval suggest process inefficiencies. Where to get Status change to 'Cancelled', 'Void', or 'Stopped'. Capture Logged when status changes to Cancelled Event type explicit
	Payment Confirmed	Receipt of a positive acknowledgement (ACK) from the external network or gateway. This confirms the instruction was received validly by the next entity.
Why it matters Validates that the 'Instruction Sent' was successful. Gaps here indicate network connectivity or external format issues. Where to get Inbound file processing logs or API response codes acknowledging receipt. Capture Logged when ACK received Event type explicit
	Payment Details Validated	System checks account numbers, routing numbers, and format compliance. This is typically inferred when a transaction successfully moves from a received status to a pending or approved status without triggering an error.
Why it matters Indicates the first automated gate has been passed. Failure here represents data quality issues rather than liquidity or approval issues. Where to get Inferred from a status change from 'Received' to 'Pending' or 'Ready' within a short timeframe. Capture Compare status field before/after Event type inferred
	Payment Error Identified	Captures the moment a transaction is flagged with a failure status or exception code. This occurs when validation rules fail or external checks return a negative response.
Why it matters Critical for the 'Validation Error and Rework Tracker' dashboard. High volumes here indicate upstream data quality problems. Where to get Transaction status field changes to an exception code (e.g., 'Invalid', 'Hold', 'Error'). Capture Logged when status changes to Error Event type explicit
	Payment Error Resolved	Represents the correction of a previously errored transaction. This is inferred when a transaction moves from an error status back to a processing or valid status.
Why it matters Essential for calculating 'Mean Time to Resolve Payment Errors'. It helps measure the efficiency of the operations team. Where to get Inferred when the transaction status updates from an error code to a normal processing code. Capture Compare status field before/after Event type inferred
	Payment Notification Sent	The system triggers a communication (email/SMS) to the payer or payee confirming the transaction. This enhances customer transparency.
Why it matters Supports 'Notification Speed and Responsiveness'. Long gaps after settlement reduce customer trust. Where to get Communication logs or customer interaction history tables linked to the Transaction ID. Capture Logged when email/SMS triggered Event type explicit
	Payment Scheduled	Occurs when a payment is approved but held for a future effective date. The system queues the transaction until the processing window opens.
Why it matters Explains idle time in the process. Differentiates between a delay caused by a bottleneck and a deliberate wait for the due date. Where to get Comparison of 'Entry Date' vs 'Effective Date'. If Effective Date is future, this state is active. Capture Derive from comparing field X to Y Event type calculated

Recommended Optional

Extraction Guides

How to get your data from Fiserv

Steps

1. Prerequisite Configuration

Ensure you have access to the Fiserv Commerce Hub developer portal. You will need to generate an API Key and API Secret (sometimes referred to as Client ID and Client Secret) with permissions to access the Transaction Inquiry or Search API. Verify that your IP address is whitelisted in the Fiserv environment if IP restrictions are enabled.

2. Environment Setup

Install Python 3.8 or higher on your extraction server or local machine. You will need the requests and pandas libraries. You can install these via pip: pip install requests pandas. Create a working directory for your script and output files.

3. Script Configuration

Download the provided Python script into your working directory. Open the script and update the configuration section at the top. You must provide your specific API_KEY, API_SECRET, and the BASE_URL (use the sandbox URL for testing and production URL for the final run). Adjust the START_DATE and END_DATE to cover the desired process mining window.

4. Authentication Logic Implementation

The script includes a helper class to handle Fiserv's specific authentication requirements, which typically involve generating an HMAC signature using your API Secret, the timestamp, and the request payload. Do not modify the signature generation logic unless your specific Fiserv implementation uses a different standard (e.g., OAuth2 bearer tokens).

5. Understanding the Parsing Logic

The script queries the API for transactions. The API typically returns a snapshot of the transaction object containing various timestamps (e.g., submission time, authorization time, settlement time). The script parses this single JSON object and unpivots it into multiple rows (events) for the event log. For example, a single JSON record with a submission timestamp and a settlement timestamp will generate at least two distinct rows in your CSV.

6. Handling Pagination

The script implements a loop to handle pagination. Fiserv APIs limit the number of records per response (often 50 or 100). The script automatically requests the next page until all transactions in the date range are retrieved. Ensure your internet connection is stable, as this may take time for large datasets.

7. Execution

Run the script via command line: python fiserv_extraction.py. The console will print the progress, showing the number of pages processed and transactions retrieved. Watch for any HTTP 401 (Unauthorized) or 429 (Rate Limit) errors.

8. Output Verification

Once the script finishes, check the directory for a file named fiserv_event_log.csv. Open this file and verify that the ActivityName column contains a mix of the 13 required activities and that the EventTimestamp field is correctly formatted.

9. Post-Processing (Optional)

If you require specific timezone adjustments (e.g., converting UTC to local time), you can modify the pandas transformation section in the script or handle this within ProcessMind after upload.

10. Upload to ProcessMind

Import the CSV file into ProcessMind. Map PaymentTransactionId to Case ID, ActivityName to Activity, and EventTimestamp to Timestamp. Ensure numeric columns like PaymentAmount are mapped as attributes.

Configuration

API Credentials: Requires API Key and Secret/Shared Secret. Ensure these have read access to Transaction Reporting endpoints.
Base URL: Set to https://api.commerce.fiserv.com for production or the specific cert/sandbox URL provided during onboarding.
Date Range: Recommended extraction window is 30 to 90 days due to API payload sizes. For historical loads, run the script in monthly chunks.
Page Size: Configured to 100 records per call to balance memory usage and network overhead.
Timezone: The API returns timestamps in UTC. The script preserves this standard to ensure consistency across regions.
Retry Logic: Included basic retry mechanism for intermittent network timeouts (HTTP 500/502/503).

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

Your Payments Processing Data Template

Your Payments Processing Data Template

Payments Processing Attributes

Payments Processing Activities

Extraction Guides

Fiserv Commerce Hub API Python Script

Steps

1. Prerequisite Configuration

2. Environment Setup

3. Script Configuration

4. Authentication Logic Implementation

5. Understanding the Parsing Logic

6. Handling Pagination

7. Execution

8. Output Verification

9. Post-Processing (Optional)

10. Upload to ProcessMind

Configuration

a Sample Query python

Ready to Get Started?

Optimize Payments Processing and Reach 98% STP Today

Your Payments Processing Data Template

Your Payments Processing Data Template

Payments Processing Attributes

Payments Processing Activities

Extraction Guides

Fiserv Commerce Hub API Python Script

Steps

1. Prerequisite Configuration

2. Environment Setup

3. Script Configuration

4. Authentication Logic Implementation

5. Understanding the Parsing Logic

6. Handling Pagination

7. Execution

8. Output Verification

9. Post-Processing (Optional)

10. Upload to ProcessMind

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize Payments Processing and Reach 98% STP Today