What the Rules Engine Does

The Rules service evaluates merchant-defined fraud and risk policies and returns a decision based on those rules.

Each merchant configures their own rule set in the MIDSuite Portal. These rules evaluate incoming request data and other available fraud signals to determine how a transaction should be handled.

Rules typically consist of:

• Predicates – conditions that evaluate request data or fraud indicators

• Response statuses – the outcome returned when a predicate evaluates to true

When a request is processed, the rules engine evaluates the configured predicates and returns the corresponding decision status.

Because rules are merchant-configured, each integration may have different rule logic and outcomes.

Inputs That Influence Rule Evaluation

Rules can evaluate a wide range of signals depending on how the merchant has configured their rules. These may include information provided directly in the Rules request as well as signals generated by other MIDSuite services.

Common examples include:

• Card information

• Customer IP address

• Transaction metadata

• Device or session characteristics

• Results produced by other MIDSuite services when used in a Pipeline

When the Rules service is executed as part of a Pipeline request, rules can reference outputs from earlier pipeline stages. For example, a rule could evaluate a risk score generated by another service before determining the final decision.

The Rules service itself does not generate a risk score. Decisions are strictly based on rule predicates configured by the merchant.

Understanding RulesResponse.status

The Rules API returns a decision through the status field in RulesResponse.

ACCEPT

The transaction satisfied one or more rules that allow it to proceed.

Typical merchant behavior:

• Continue the checkout flow

• Proceed with payment authorization

REVIEW

The transaction triggered rules indicating that additional review may be appropriate.

Possible merchant responses include:

• Sending the transaction to a manual review queue

• Requesting additional verification

• Performing step-up authentication

• Delaying fulfillment

The appropriate action depends on the merchant’s risk tolerance and operational workflow.

DENY

The transaction triggered rules indicating a high likelihood of fraud or policy violation.

Typical merchant behavior:

• Reject the transaction

• Do not proceed with payment authorization

INCOMPLETE

This status indicates that the rules engine returned an incomplete evaluation result.

The conditions that produce this status are defined by the merchant’s rule configuration in the MIDSuite Portal.

Merchants may choose to treat this outcome conservatively, for example by routing the transaction for manual review.

NO_MATCH

No configured rules were triggered.

This means that all rule predicates evaluated to false, and no rule-generated decision applied to the request.

Merchants commonly treat this outcome as a neutral result and determine how to proceed based on their internal policies.

Integrating Rules Into a Checkout Flow

Rules are typically evaluated before payment authorization so that fraudulent or suspicious transactions can be filtered before contacting the payment processor.

A common checkout flow may look like this:

1. Validate card data using PreCheck

2. Evaluate fraud rules using Rules

3. Optionally run additional analysis using Sentry

4. If acceptable, proceed with payment authorization

Running Rules prior to authorization helps reduce:

• Payment processor costs

• Chargebacks

• Downstream fraud investigation workload

In more advanced integrations, the Rules service may also be executed within a Pipeline request, where it can reference signals produced by earlier services.

Retry and Fallback Strategies

Rules evaluations are deterministic based on the request data and the merchant’s configured rules.

For this reason, retries are generally unnecessary.

A retry may only be useful if:

• The original request failed due to validation errors

• Missing or incorrect request data has been corrected

Otherwise, repeating the same request will typically produce the same Rules result.