Guides
Client Login

Dynamic Merchant Block

What the Dynamic Merchant Block action is

The Dynamic Merchant Block action is a Decision Engine action that blocks a merchant dynamically when a rule is triggered.

In platform terms, the action dynamically creates the merchant block when the rule fires, and subsequent transactions from that merchant are then declined by the dynamic-block validation. If you want the triggering transaction declined as well, the rule needs a separate DECLINE action linked alongside BLOCK_MERCHANT.

The merchant is identified from the transaction itself, using the merchant acceptor ID in the authorisation message. This means the block is created from live transaction data rather than from a preconfigured static merchant list.


Why it is useful

This action is useful when you want Decision Engine not only to decline a suspicious or unwanted transaction, but also to immediately prevent repeat attempts from the same merchant.

Without Dynamic Merchant Block, you would typically:

  • decline the triggering transaction
  • then rely on manual operational follow-up to add a merchant block later

With Dynamic Merchant Block:

  • the merchant is blocked automatically
  • later attempts from the same merchant can be stopped without waiting for manual intervention

This is especially valuable for rapid containment.


Value it brings

  • Faster response: a risky merchant can be blocked as soon as the triggering rule fires.
  • Less operational overhead: no separate manual merchant-block step is needed in the normal flow.
  • Better repeat-attempt protection: the same merchant can be stopped from trying again after the first suspicious event.
  • Consistent enforcement: the blocking logic is tied directly to your Decision Engine policy.
  • Flexible reach: you can choose whether the block applies at product or client scope.

How it works

When the configured rule outcome triggers this action, the runtime:

  • reads the merchant acceptor ID from the transaction
  • reads the action configuration for duration and scope
  • creates or updates a merchant block record for that merchant

The two key settings are:

  • block duration
  • scope

Scope options

The action supports two scope values:

  • PRODUCT
  • CLIENT

PRODUCT scope limits the merchant block to the product involved in the triggering transaction.

CLIENT scope applies the block more broadly at client level.

This is an important design choice:

  • use PRODUCT when the problem is specific to one product configuration or customer segment
  • use CLIENT when you want the merchant blocked across the client estate

Block duration

The action supports either:

  • a fixed block period in seconds
  • an indefinite block

In PayControl, indefinite blocking is configured through the Block Indefinitely option.

When to use it

Use Dynamic Merchant Block when:

  • you want to immediately block the same merchant
  • you want automatic containment after a rule breach
  • you need product-level or client-level merchant suppression based on live transaction behaviour

Typical examples include:

  • repeated suspicious merchant behaviour
  • merchants associated with confirmed fraud patterns
  • scenarios where one failed or high-risk attempt should stop further attempts from that merchant

How to set it up in PayControl

1. Create the action

In the Decision Engine actions area for the relevant client, create a new action.

Select the action type:

  • BLOCK MERCHANT

Enter an action name that reflects the intended policy, for example:

  • Block suspicious merchant at product scope
  • Block merchant after fraud trigger

2. Choose the block duration

Set how long the merchant should remain blocked.

Options:

  • enable Block Indefinitely
  • or enter a duration in seconds

Use indefinite blocking only when you want the merchant to remain blocked until operational review or explicit removal.


3. Choose the scope

Select one of:

  • PRODUCT
  • CLIENT

Guidance:

  • choose PRODUCT for narrower impact
  • choose CLIENT when the same merchant should be blocked across the client rather than only the triggering product or card program

4. Save the action

Save the action once duration and scope are configured.

Optional action attributes can also be included if your wider action framework uses them.


5. Link the action to the rule outcome

As with other Decision Engine actions, creating the action is not enough by itself.

You must still link it to the appropriate rule outcome.

Typical pattern:

  1. Create or edit the rule.
  2. Open the rule outcome section.
  3. Link the Dynamic Merchant Block action to the outcome that should trigger the merchant block.
  4. If you would like the in-flight transaction which triggered the dynamic merchant block, you would also need to assign a decline action to the rule.

Example scenario

You have a fraud rule that identifies suspicious ATM cash-out behaviour from a merchant.

You want the first triggering transaction to be declined and also want to stop further attempts from the same merchant.

With Dynamic Merchant Block:

  • the rule fires
  • the merchant acceptor ID from that transaction is used to create the merchant block
  • future attempts from the same merchant can then be blocked according to the configured scope and duration

If the action is configured with:

  • PRODUCT scope, the effect is limited to that product
  • CLIENT scope, the merchant is blocked more broadly at client level

Summary

The Dynamic Merchant Block action is useful because it turns a one-off decline into an automated containment step. It lets Decision Engine dynamically block the triggering merchant, using live transaction data, with configurable duration and scope, while coexisting safely with merchant blocks that are already managed through PayControl.

Updated 12 days ago