Skip to content

Transaction Reports Documentation

Menu Location: Reports > Transaction Reports

Access Level: Manager / Administrator

Last Updated: 2026-03-01

Overview

The Transaction Reports page identifies customers with multiple transaction history entries in their payment records. It helps find payment processing issues, repeated transaction attempts, and customers experiencing payment problems.

Primary Functions:

  • Find customers with multiple transaction attempts
  • Filter by minimum transaction count threshold
  • View transaction history log details
  • Identify payment processing patterns and issues
  • Investigate failed or repeated payment attempts

Page Layout

Header Section

  • Page Title: Reports \ Transaction Reports
  • Info Alert: Explains this is an alpha version for specific analysis tasks

Filter Controls

  • Minimum Trans History Count Dropdown: Select how many transactions minimum to show
  • From/To Date Pickers: Define the search period
  • Generate Report Button: Creates report with current settings

Main Content Area

  • Results Table: Shows customers grouped by transaction count
  • Columns: Transaction Count, Customer, Payment ID, Trans ID, Trans History Log
  • Row Grouping: Customers with multiple transactions shown with rowspan

Report Data & Columns

Column Description Details
Transaction Count Number of transaction attempts for this customer Displays in first row only, spans multiple rows
Customer Customer ID and name with link Links to customer_info.php, displays once per customer
Payment ID cust_order_payment ID Individual payment record identifier
Trans ID trans_history record ID Transaction history log entry ID
Trans History Log Transaction result details Text from transaction processing log

Sorting: Results sorted by transaction count (highest first)

Filters & Search Options

Minimum Transaction History Count

Purpose: Filter customers by how many transaction attempts they have

Available Options:

  • At least 1 transaction
  • At least 2 transactions
  • At least 3 transactions (default)
  • ... up to ...
  • At least 19 transactions

Usage:

  • Default setting: 3 transactions
  • Higher numbers find customers with more payment issues
  • Lower numbers cast wider net for investigation

Example: Setting to "At least 10 transactions" finds customers with significant payment processing history, possibly indicating recurring problems.

Date Range Selection

From Date:

  • Calendar picker with manual entry
  • Defaults to 3 weeks ago if not specified
  • Filters transaction date (trans_history.date)

To Date:

  • Calendar picker with manual entry
  • Defaults to current time if not specified
  • Filters transaction date (trans_history.date)

Important Notes:

  • Filters by transaction attempt date, not payment completion date
  • Includes all transaction statuses (pending, complete, failed)
  • Searches both current cust_order_payment and trans_history tables

Common Use Cases

Use Case 1: Find Customers With Recurring Payment Issues

Goal: Identify customers experiencing repeated payment failures

Steps:

  1. Set From date to 30 days ago
  2. Set To date to today
  3. Select "At least 5 transactions"
  4. Click "Generate Report"
  5. Review Transaction Count column for high values
  6. Click customer names to investigate payment methods
  7. Contact customers to update payment information

Example: Customer with 12 transaction attempts in a month likely has expired card or insufficient funds. Proactive outreach can prevent churn.

Tips:

  • High transaction counts often indicate automatic retry processing
  • Review Trans History Log for specific error messages
  • Update payment methods to prevent future issues

Use Case 2: Audit Payment Processor Behavior

Goal: Understand how payment system handles retry attempts

Steps:

  1. Set date range to last month
  2. Set minimum to "At least 3 transactions"
  3. Click "Generate Report"
  4. Review Trans History Log entries
  5. Look for patterns in failure reasons
  6. Identify processor-specific issues

Example: If many logs show "insufficient funds" errors, consider adjusting retry timing to avoid multiple failed attempts.

Use Case 3: Investigate Specific Customer Payment History

Goal: Deep dive into one customer's transaction patterns

Steps:

  1. Set date range to wide window (90+ days)
  2. Set minimum to "At least 2 transactions"
  3. Click "Generate Report"
  4. Use browser search (Ctrl+F) to find customer ID or name
  5. Review all transaction attempts for this customer
  6. Identify failure patterns or timing issues

Tips:

  • Look for transaction timing - are failures on specific days?
  • Check if certain payment types have higher failure rates
  • Review transaction progression from fail to success

Use Case 4: Monthly Payment Processing Quality Check

Goal: Monitor overall payment processing health

Steps:

  1. Set From/To dates to last complete month
  2. Start with "At least 10 transactions" for severe issues
  3. Click "Generate Report"
  4. Note how many customers appear
  5. Gradually lower threshold to see broader patterns
  6. Document common failure reasons
  7. Report trends to payment processor

Example: If 50 customers have 5+ transaction attempts, but only 2 customers have 10+, processing is generally healthy with a few problem accounts.

Use Case 5: Validate Retry Logic Changes

Goal: Confirm payment retry logic improvements are working

Steps:

  1. Set date range to before retry logic change
  2. Set minimum to "At least 5 transactions"
  3. Note customer count and patterns
  4. Change date range to after retry logic change
  5. Run report again with same settings
  6. Compare transaction counts and patterns
  7. Verify reduced multi-attempt transactions

Example: Before change: 30 customers with 5+ attempts. After change: 8 customers with 5+ attempts indicates improvement.

Troubleshooting

No Results Showing

Symptoms: Table is empty after clicking Generate Report

Check:

  1. Verify date range includes payment transaction dates
  2. Lower the minimum transaction count threshold
  3. Check if any payments processed in date range
  4. Verify database contains transaction history data

Solutions:

  1. Expand date range to include more time
  2. Set minimum to "At least 1 transaction"
  3. Confirm trans_history table has data for period
  4. Try different date range to test query

If Problem Persists: Contact system administrator to verify trans_history table is being populated correctly.

Transaction Count Seems Too High

Symptoms: Customer shows 20+ transactions for a single payment

Check:

  1. Review Trans History Log entries for details
  2. Check if payment processor has retry loop issue
  3. Verify customer payment method isn't repeatedly failing
  4. Look for webhook or callback processing issues

Solutions:

  1. Investigate specific trans_history.id entries
  2. Check payment processor logs for retry behavior
  3. Update customer payment method if failing
  4. Contact payment processor about excessive retries

Common Causes:

  • Payment processor automatic retry logic
  • Webhook processing loops
  • Card authorization holds vs captures
  • Test transactions in production environment

Customer Appears With Single Transaction

Symptoms: Report shows customers even though "At least 2" was selected

Check:

  1. Verify dropdown selection was saved properly
  2. Check if data includes multiple payment IDs for same customer
  3. Review if trans_history entries are linked correctly

Solutions:

  1. Re-select minimum transaction count and submit again
  2. Review the actual Transaction Count column value
  3. Filter may be by unique trans_history records, not attempts
  • Customer Info (customer_info.php) - Full customer payment and transaction history
  • Payment Transactions (billing-payments.php) - Payment-level reporting and summaries
  • Customer Order Info (customer_order_info.php) - Individual order payment details
  • Payment Settings (settings-payment.php) - Configure payment processing behavior

Typical Workflow:

  1. Transaction Reports → Find problem customers → Customer Info → Update payment method
  2. Transaction Reports → Identify pattern → Payment Settings → Adjust retry logic
  3. Customer inquiry → Transaction Reports → Find transaction history → Explain issue

Permissions & Access

Required Access Level: View access (implied from code - no explicit permission check)

Access Level Capabilities:

  • Customer Service: View customer transaction patterns for support
  • Manager: Analyze payment processing trends
  • Administrator: Full access to all transaction history
  • Kiva Admin: All features plus database access for deep investigation

Best Practices

Regular Monitoring

  1. Run monthly reports with 5+ transaction threshold
  2. Investigate customers with very high counts immediately
  3. Track trends in overall transaction attempt rates
  4. Document common failure patterns

Data Analysis

  1. Start with high threshold, gradually lower to find patterns
  2. Group by transaction log message types
  3. Compare month-over-month transaction count trends
  4. Correlate with payment processor changes

Customer Service

  1. Proactively contact customers with 5+ failed attempts
  2. Use specific error messages to guide customer support
  3. Document resolution patterns for similar issues
  4. Update payment methods before next billing cycle

Things to Avoid

  • ❌ Don't ignore customers with high transaction counts - they may churn
  • ❌ Don't set threshold too low (1-2) for routine monitoring - creates noise
  • ❌ Don't assume all high counts are problems - some may be test transactions
  • ❌ Don't use this as primary payment report - use Payment Transactions instead

Quick Reference Card

Task Action/Location
Find problem payments Set threshold to 5+, run report
Check specific customer Search date range, find customer name
Monthly quality check Last month dates, threshold 5+
Audit payment processor Wide date range, check log patterns
Investigate high failures Sort by transaction count (already sorted)
View customer details Click customer name in table
Check specific error Read Trans History Log column
Compare time periods Run report twice with different dates
Find all transactions Set minimum to "At least 1"
Focus on severe issues Set minimum to 10+

FAQs

What causes multiple transaction entries for one payment?

Multiple entries occur when payment processing involves retry attempts (failed card, retry logic), authorization holds followed by captures, webhook callbacks, or test transactions. High counts may indicate payment method issues or processor retry loops.

Is this normal for some customers to have many transactions?

Yes, 2-4 transaction entries can be normal for successful payments with retries or authorization/capture workflows. Counts above 5 usually indicate problems worth investigating.

How is this different from Payment Transactions report?

Payment Transactions shows completed payments aggregated by time. Transaction Reports shows the underlying transaction attempts, including failures and retries, grouped by customer.

Can I see the specific error messages for failed transactions?

Yes, the Trans History Log column shows the details field from trans_history, which typically contains processor error messages, results, and status information.

Why don't I see a Download or Export button?

This alpha version page doesn't include export functionality. Copy table data manually or use browser print-to-PDF if you need to save results.

Change Log

2026-03-01

  • Initial documentation created
  • All sections completed based on transaction-report.php code review
  • Documented alpha version status
  • Added transaction count filtering details
  • Included common payment processing scenarios

End of Documentation

For additional help, contact your system administrator or Kiva Logic support.