Access API
Access API

Automating Payment Processing:
How a Rule Engine Can Help

Payment systems are essential to our modern economy and enable transactions to take place quickly and securely, facilitating commerce and economic growth.
    However, developing a payment system is a complex process that requires addressing several common issues related to scalability and transaction performance in the core processing subsystem, such as:

    1. Database performance: Payment systems require constant access to databases for transactions, and a high volume of transactions can cause performance issues like slow query response times and reduced throughput.

    2. Processing power: With a large volume of transactions, processing power becomes a critical factor. The core processing subsystem needs to be able to handle many transactions in parallel without slowing down or crashing.

    3. Data volume and storage: Payment systems generate and store large amounts of data, which can be challenging to manage and process in real-time. This can result in slow response times, errors, or system crashes.

    4. Network latency: A payment system must communicate with multiple external systems like banks, payment gateways, and merchant accounts. Network latency can lead to delays in processing transactions, which can be unacceptable for end-users.

    5. Security: Payment systems need to be highly secure to protect sensitive financial data. Implementing security measures can increase processing time and put additional strain on the core processing subsystem.

    Addressing these issues requires careful planning and design of the payment system's architecture, including the use of appropriate technologies and programming languages.

    Moreover, incorporating SaaS components and proper logic encapsulation is a challenging task. Despite addressing some issues, significant problems remain, including:

    • The need for fast data lookup: The system needs to be able to quickly access customer information, transaction history, and other relevant data in real-time to facilitate fast and secure payments. To achieve this, developers need to implement efficient data structures and caching mechanisms that can handle large volumes of data and provide low-latency access.

    • Quick decision-making algorithms: Suppose a person has a $600 invoice to pay using their EU bank card. They need to confirm if payment can be made, and if it is not possible, they need to know if and which additional actions are required.

    • Dynamic parameter values depending on incoming requests: For example, if a business wants to collect a bigger fee for non-EU customers.
    Such tasks have a significant impact on system performance, and each requires multiple teams to develop distributed SaaS components.
    Maximizing Efficiency in Payment Systems with a Rule Engine
    To address these challenges, Vladimir Kovalevskii, a founder and CEO at ReactivePay, came up with idea ofusing a rule engine, to manage and enforce payment rules, such as fraud prevention, risk management, and compliance.

    A payment system usually have complex rules that need to be applied to each transaction to ensure that it is legitimate and meets regulatory requirements. For example, a rule engine is therefore used to analyze transaction data in real-time and identify patterns that suggest fraudulent activity, such as unusual purchase behavior or a high number of chargebacks. The rule engine can then apply predefined rules to block the transaction or flag it for review by a human analyst.

    In addition, a rule engine can be used to route payments based on predefined rules, such as the payment method, location, and currency. This helps to ensure that payments are processed efficiently and cost-effectively while minimizing the risk of errors or delays.

    Overall, a rule engine is a powerful tool that can be used in payment systems to automate and enforce payment rules, reduce risk, and improve efficiency.
    Rule Engine Application in ReactivePay
    Reflecting back on his 15-year experience and deep knowledge in coding, Vladimir utilized a rule engine to aggregate incoming request parameters, calculate them, and trigger call-to-actions based on filter and rule triggers.

    The rule can be segmented into two distinct sections: "header" and "body" (taking inspiration from the HTML language specification). The "header" outlines whether the rule matches incoming request parameters, while the "body" contains several filters or any relevant data that should be returned if the rule matches the request. To optimize the speed of rule lookup, hashes can be utilized, formed from header parameter/value pairs, and compared to those formed from the request. Upon receiving a request, matching rules are identified, and aggregated/calculated parameter values are added to pre-defined tables, and stored in a lightweight, small database. This allows for easy retrieval of values using a hash lookup method based on the rules' header parameters.

    Overall, this approach appears to be flexible, reliable, transparent, and adaptable to any modifications, making it suitable for most business processes found in complex transactional environments, such as payment systems.
    More About Rule Engine
    The rule engine is a crucial module that allows for rules to be stored in JSON format and offers several important functionalities, including:

    • Rule storage in JSON formatted text
    • Rule parser and filter fetcher
    • Hash-based lookup module
    At the moment, MongoDB is used as the main storage system for rules, aggregated values, and counters. Each rule is mapped to a data model that includes:

    • Header: the value of the header section in the rule's JSON text
    • Body: the value of the body section in the rule's JSON text
    • Comment: a random comment for user-friendly search queries
    • Hash: built using header parameter/value pairs
    • HashDescr: a hash descriptor represented as param/value for full-text search by param/value
    The rule engine utilizes a straightforward hash lookup logic by building a list of hashes for the request parameters and then filtering the rules using the hash property from the rule dataset. After the rule engine has identified the list of rules that match the request parameters, it can examine the body section and execute any actions defined within the body's scope. For example, these actions could be presented as a list of filters that apply to the request, such as filtering requests if the number of requests within the last 24 hours exceeds 100.
    Overall, the rule engine provides a potent and flexible tool for managing rules in complex transactional environments, such as payment systems.
    Use Cases & Product Application: Flexy
    Flexy, which is a part of the ReactivePay framework, is a versatile tool that supports multiple geo parameters, currencies, and payment attributes. It has various use cases and live product applications, such as:
    ReactivePay Rule Engine is known for its impressive performance, with 15 TPS running on a single AWS c5.large instance. The average response time is 130 ms.
    With its numerous features and functionalities, ReactivePay Flexy is not limited to the fintech industry alone but can also be used in e-commerce and telecom applications.
    We encourage you to try Flexy today and experience its many benefits for yourself.