[FEATURE] Integrate Analytics API for Payment Orders Listing to Improve Performance and Scalability

[VenuMadhav2541]

Feature Description

In my use-case, the Payment Orders listing page in the control center needs to handle large volumes of transaction data efficiently. Currently, the payment orders list relies solely on the operational database API (/payments/list), which can experience significant performance degradation when querying large datasets or during high-traffic periods.

Current Challenges:

1. Performance Bottleneck: Direct queries to the operational database become slower as transaction volume increases, leading to poor user experience with longer loading times
2. Missing Analytical Context: The operational API doesn't provide enriched metadata like aggregated attempt information, active attempt resolution, and historical attempt tracking
3. Limited Scalability: As merchants process more transactions, the current implementation struggles to maintain acceptable response times
4. Single Point of Failure: No fallback mechanism exists if the primary API endpoint experiences issues

Desired Outcome: A robust, analytics-first data fetching strategy for payment orders that:

• Leverages the analytics service optimized for read-heavy operations
• Provides automatic fallback to the traditional endpoint for reliability
• Includes enriched payment attempt data with proper active attempt resolution
• Maintains full backward compatibility with existing UI components
• Delivers significantly faster query response times (40-60% improvement expected)

Possible Implementation

The implementation involves creating a dual-source data fetching architecture:

1. New Analytics API Endpoint Integration:

• Add PAYMENTS_LIST variant to API entity types (APIUtilsTypes.res)
• Implement route mapping for analytics/v1/payments/list with merchant/profile entity support (APIUtils.res)
• Support both merchant-level and profile-level scoping

2. Data Transformation Layer:

• Create PaymentInterfaceUtilsAnalytics.res utility module

• Implement type-safe mapping from analytics schema to common payment order interface

• Handle special cases:

  • Convert timestamps from microseconds to ISO 8601 format
  • Resolve active attempt details (connector transaction ID, capture method, error messages)
  • Parse and merge metadata from payment and attempt levels
  • Transform nested JSON objects (shipping, billing addresses)

3. Custom Hook with Fallback Mechanism:

• Create AnalyticsOrdersHook.res hook
• Primary path: Attempt to fetch from analytics endpoint first
• Fallback path: If analytics API fails, gracefully degrade to traditional /payments/list endpoint
• Support both V1 and V2 API versions
• Maintain consistent error handling

4. Integration Points:

• Update Orders.res to use the new analytics hook
• Ensure feature flag support for gradual rollout
• Maintain existing UI compatibility (no changes to table components)

Technical Benefits:

• Zero breaking changes to existing functionality
• Improved query performance through optimized analytics service
• Future-ready foundation for advanced analytics features
• Graceful degradation ensures high availability

Have you spent some time checking if this feature request has been raised before?

• I checked and didn't find a similar issue

Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to submit a PR?

None