Cascading

1. Introduction

A Cascading Rule is a configurable rule that automatically retries a failed payment through an alternative payment method (or a chain of methods) until the transaction is ultimately approved or no further fall-backs remain. Where Routing Rules decide where to send an initial payment, Cascading Rules decide what to do next after the first attempt is declined, cancelled, or otherwise not completed.

Key benefits of cascading

• Higher recovery rates – Redirect a declined payment to the acquirer most likely to approve it, improving overall conversion.
• Automated fail-over – Remove manual intervention by letting the platform pick the next payment method in real time.

How it works at run-time

1. The first payment attempt fails.
2. The platform sends the transaction data to the Cascading module.
3. The module looks for one rule that matches the failed transaction.
4. If a rule is found, it returns the next payment method.
5. The platform creates a new attempt with that payment method, collecting any extra data from the payer if required.
6. Steps 2 – 5 repeat until the payment is approved or no further methods are available.

2. Creating a cascading rule

Click Create cascading rule to open the configuration form:

1. Rule name – Enter a short, descriptive name.
2. Description (optional) – Add context that will help teammates understand why the rule exists.
3. Create sub-rules – Define the conditions that must be true for the failed payment to enter this cascade (see Defining sub-rules).
4. Select payment method – Choose the payment method that should handle the next attempt when the rule matches.
5. Buttons
   • Cancel closes the dialog without saving.
   • Create rule saves and activates the new rule.

3. Defining sub-rules (conditions)

A Cascading Rule can contain one or more Sub-rules. If any sub-rule is satisfied, the payment will be retried using the payment method you selected.

3.1 Sub-rule interface

Each Sub-rule block contains a primary Where selector plus nested parameters:

Field	Purpose	Allowed operators	Example values
Parameter	Top-level attribute to check	–	BIN, Email, Payment amount, Issue country, IP country, Transactions
Operator	• Logical / text: = ≠ • Numeric: = ≠ > < ≥ ≤
Value	Value to compare with (format depends on parameter)	–	411111, 100
Add parameter	Adds another comparison inside the same Sub-rule → AND logic	–	–
Add condition	Opens an additional parameter block inside the same Sub-rule. Everything inside the new block is still evaluated with AND in relation to the other blocks in that Sub-rule.	–	–
Add sub-rule	Starts a new Sub-rule block. Blocks are evaluated independently and combined with OR logic —the first block that matches triggers the cascade.	–	–

Add parameter vs Add condition vs Add sub-rule

Button	What it does	Logical effect
Add parameter	Inserts another row inside the current block.	AND – the payment must satisfy all rows in the block.
Add condition	Creates a secondary block of parameters inside the same Sub-rule.	AND – criteria in the new block are evaluated together with the rest of the Sub-rule.
Add sub-rule	Opens a completely new Sub-rule block.	OR – a match in any block routes the payment to the selected method.

3.2 The Transactions parameter

The Transactions parameter lets you build a rule on top of historical data. Behind the scenes, the rule engine performs an aggregate query against the transaction. Depending on your configuration, the engine either:

• Sums the monetary value of the matching transactions, or
• Counts the number of transactions that match.

Configuration levels

Up to five nested levels become available when you choose Transactions:

Level	Field	Purpose	Examples
1	Transactions	Aggregate to evaluate	By sum amount or By count of transactions
2	Type	Which transaction kind to consider	Payment, Payout, Refund
3	Filter by	Optional second-level filter	PAN, MID, Status
4	PAN / MID / Status	Specific value to match	MID = 123456, Status = Declined
5	Amount (only for By sum amount) or Count (for By count)	Comparison against the chosen metric	Amount ≥ 500, Count ≥ 3
	Currency (with Amount)	Restrict sum to one currency	Currency = EUR
6	Time measurement	Time bucket	Minute, Hour, Day, Month
	Time type	Bucket window	Current (ongoing) or Range
	Range value (if Range)	How many buckets back	5 (last 5 hours)

How the time window works

The Time measurement and Time type together define a rolling window. For example:

• Time measurement = Hour, Time type = Range, Range value = 24 → evaluates the last 24 complete hours.
• Time measurement = Day, Time type = Current → evaluates today so far (from 00:00 today until now).

Example – flag high-value activity on a MID today.

Retry the payment with an alternative acquirer whenever the same MID has processed EUR 1 000 or more today.

Example – Burst of declines on the same MID (rate-limit)

If three or more payments on the same MID have been declined within the last hour, retry the next attempt through a fallback acquirer.

4. Routing the retried transactions

Below the Sub-rule editor you will see Select payment method.

1. Click Select payment method – a modal window appears
2. Choose one of the active methods connected to your shop.
3. Confirm; the selected method is now shown under the form.
4. If that second attempt also fails, the platform repeats the same lookup: it evaluates all Cascading Rules again, potentially triggering a different rule and a third payment method, and so on, until either the payment succeeds or no rule matches.

5. Saving and activating the rule

1. Click Create rule.
   • The rule is stored, appears in the Cascading Rules list, and becomes active immediately.
2. The system will apply your rule automatically to any future failed payments that match its conditions.