Hierarchical Payment Graphs for Distributed State Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current electronic payment systems face complexity and ambiguity in state transitions due to distributed architectures, leading to errors and inefficiencies in processing electronic payments across multiple micro financial services.

Innovation Solution

A hierarchical payment graph system is implemented, utilizing a main payment processing engine and distributed payment engines, with typed transitions defined via an extended graph definition language, ensuring robust and error-free state management across geographically distributed systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a distributed architecture is used for payment processing, then scalability and system robustness are improved, but state transition complexity and processing errors increase

Engineering Contradiction:
Improvesystem robustnessVSAvoidstate transition complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The payment processing system is divided into multiple independent microservices (authorization service, capture service, refund service, etc.), each responsible for specific payment operations. Each service maintains its own state management and transitions independently, reducing the complexity of coordinating state changes across the distributed system while improving overall robustness.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A centralized payment state manager acts as an intermediary that coordinates state transitions between distributed microservices. This mediator ensures consistent state management across the distributed architecture by mediating communication between services and maintaining the payment lifecycle state, thereby reducing processing errors while preserving scalability.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Device complexity

If a monolithic payment processing system is used, then state management is simpler, but scalability and system maintenance difficulty worsen

Engineering Contradiction:
Improvestate management simplicityVSAvoidsystem scalability
Core Design Contradiction:
Device complexityVSEase of manufacture

Solution Approach 1:

The monolithic system is segmented into independent microservices, each handling specific payment operations. This segmentation enables independent deployment, scaling, and maintenance of individual services without affecting the entire system, thereby improving scalability while maintaining manageable complexity through clear service boundaries.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system employs dynamic service discovery and flexible service composition patterns that allow the architecture to adapt to changing business requirements. Services can be dynamically added, removed, or reconfigured without disrupting the entire system, enabling easy maintenance and continuous evolution of payment processing capabilities.

Inventive Principle:
Principle #15Dynamics

3Adaptability or versatility

If payment processing handles multiple technologies and business rules, then system versatility is improved, but processing time and error rates increase

Engineering Contradiction:
Improvepayment technology supportVSAvoidprocessing time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

Different payment technologies and business rules are isolated into separate specialized services (e.g., credit card service, debit card service, mobile payment service). Each service is optimized for its specific domain and handles transactions independently, reducing the overhead of managing multiple technologies within a single service and minimizing processing time through targeted optimizations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system implements a universal payment state manager that provides common state management functionality across all payment types, while individual payment services specialize in specific technologies. This multi-functional architecture allows the system to handle diverse payment technologies efficiently by reusing common infrastructure while maintaining specialized processing capabilities.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS12437276B2Systems and methods for distributed electronic payment processing using hierarchical payment graph
Publication Date: 2025.10.07 WEPAY
  • US12437276B2 patent drawing
  • US12437276B2 patent drawing
  • US12437276B2 patent drawing

AI summary

A new approach is proposed that contemplates systems and methods to support distributed electronic payment processing based on a hierarchical payment graph. Specifically, a distributed electronic payment system comprising a plurality of distributed payment engines/processors. Upon receiving an electronic payment request from a client device, each distributed payment engine of the distributed electronic payment system is configured to handle one stage of the electronic payment processing lifecycle by traversing states and edges in a portion of the hierarchical payment graph assigned to the distributed payment engine. While processing the electronic payment, the distributed payment engine of each sub-graph of the hierarchical payment graph is configured to communicate with a payment engine of a main payment graph of the hierarchical payment graph, wherein such inter-graph communication is modeled or typed via an extended graph definition language (GDL), which declaratively defines a plurality of types of electronic payment processing.