What is a Rule engine?

Rule engine is a combination of Routing and Trigger rules that are settled to allow the system distribute the payments via the correct Routes based on your business needs. Apparently, the final destination point for your payments should be the most suitable Provider account.

You can review how our system addresses and consolidates all the building blocks of the Rule engine and take a look at a case study below.

How does it work?

The Rule engine main elements are a Routing tree, Trigger scheme, Sections and Groups, Actions, and Cascading. Those elements are brought together to perform a specific function and bring in one particular result implied by the user. Also, all the elements help you create the conditions for the system to choose what Routes to include in the process.

1. Routing tree

The Routing tree is practically one of the core elements of the Rule engine, along with the Trigger scheme. It consists of Rules and Actions that work side-by-side to create the conditions for initiating the Routing. Such Rules consist of the Condition property, Relational operator and the Value.

📘
Important!
The Routing functions on the Transaction level after the Payment Commit is made.

To learn how to create Routing rules, go to the Apply Routing rules guide.

2. Trigger scheme

The Trigger scheme possesses a mechanism similar to that of the Routing tree. It also presupposes creating the Rules to fulfil the specific conditions. However, unlike Routing, the Trigger scheme steps in at the Payment Commit level and specifies additional measures and steps to be taken before the system initiates Routing.

To learn more about the Trigger scheme, go to the Apply Triggers rules guide.

3. Sections VS Groups

Sections and Groups are the dividing blocks that help to structure the data and organise the conditions correctly.

Sections work on the higher level and split the data into separate units based on your requirements.
Groups exist both within the means of the same property, adding one more entity to the condition, and within the different properties while functioning as logical parentheses.

4. Actions

Actions signify the system behavior in case the condition is met or not. As it defines the Routing strategy, it greatly influences the payment distribution. You can manually choose the actions and establish the Cascading based on your needs.

To learn more about the Actions and Routing strategies, go to the Employ Routing actions & Cascading guide.

5. Cascading

Cascading is an important feature that reduces the potential transaction failures and identifies the alternative Routes if the main chosen Route is unavailable. This feature is presented on the Routing and Triggers levels to minimise the risks and ensure smooth operation and the ongoing process with minimum delays.

To discover the Cascading specifics, go to the Employ Routing actions & Cascading guide.

Case study

The simple case study can help you dive deeper into the Routing process and get familiar with Rules and Conditions establishment in a broader sense. Thus, look at the scheme and its description below to learn the real-life representation of the complex yet well-built payment workflow.

You can see the Routing rules and Conditions on the left side of the scheme. On the right side, the Triggers are visualised. The Trigger scheme is initiated at the Payment Commit level, and the system is ready to initiate Routing only if all the Trigger conditions are met.

Let us assume that you need to accept payments on separate Routes based on such Conditions:

The Main rule	Positive outcome = The Condition is met	Negative outcome
The Payment amount should be less than $100 to use particular route.	Then, the payments should be distributed on the Route A.	If the amount exceeds $100, the system should check the Card BIN first. If the Card is connected to the VISA or Mastercard payment network, the payment should be distributed to Route B. If not, the Condition should be moved to the next section.
The Card type should be Debit to allow the system to accept payments.	Then, the payments should be distributed on the Route C.	If the Card is not a Debit, but a Credit or a Prepaid one, the system should terminate such payments.
Additional rule (Trigger rule)	Positive outcome = The Condition is met	Negative outcome
The Payment amount should be over $10 to apply the additional security checking.	You can set up the Authentication measures and rules, namely, make the 3DS Required. As this special checking is obligatory, you may set CVV auth as Optional and OTP auth as Disabled.	No special checking is needed for payments that are less than $10. Thus, the system should accept such payments at once.