Flexible transaction controls support attribute groups, which allow you to define sets of values, such as merchant IDs or Merchant Category Codes (MCCs), that can be shared across multiple controls within the same organization. This feature simplifies control configuration and significantly improves maintainability.

You create attribute groups at the organization level and can share them across all entities within the same organization (programs, accounts, customers, and cards). This centralized approach promotes consistency, simplifies control management across different scopes, and ensures that the control logic dynamically evaluates the group values during the authorization workflow. When you update an attribute group, the platform automatically reflects this change across all flex controls that reference it, enabling efficient bulk updates.

To enable this functionality, you must first create an attribute group and then reference it in flex controls using the new operators: in_group and not_in_group. These operators allow the control to evaluate whether a transaction attribute matches any value within the defined group.

During the authorization workflow, the flex controls engine evaluates incoming payload attributes against the values defined in the referenced group. If a match is found, the condition is satisfied. If no match is found, the condition fails.

Create attribute group

To create an attribute group, use the Create attribute group endpoint.

📘

Currently, there is no user interface, such as Control Center, to manage attribute groups within flex controls. All operations must be performed via the API.

Each attribute group must include the following.

This structure allows the group to be referenced across multiple flex controls within the same organization.

The following example request payload of the Create attribute group endpoint defines the attribute group of non-trusted merchants.

{  
    "id": "non-trusted-merchants",  
    "description": "High-risk merchant IDs",  
    "type": "merchant_id",  
    "values": [  
        "0001",  
        "0010",  
        "0002"  
    ]  
}

Reference attribute group in flex controls

Once you create an attribute group, you reference it in flex controls in the conditions configuration in the Create account flex control or Create customer flex control endpoint.

• In the operator field, use the operators in_group or not_in_group.
• In the value field, include the attribute group ID.

The following example request payload of the Create account flex control or Create customer flex control endpoint uses the previously defined attribute group of non-trusted merchants to restrict operations with those merchants.

{  
    "name": "non_trusted_merchant_restriction",  
    "type": "restriction",  
    "deny_code": "merchant_not_allowed",  
    "conditions": [  
       {  
         "attribute": "merchant_id",  
         "operator": "in_group",  
         "value": "non-trusted-merchants"  
    }  
  ]  
}

For more details on how to create flex controls at different levels, refer to the following documentation:

• Flexible transaction controls
• Flex controls in Control Center

Manage attribute groups

To update the values field in an attribute group, use the Update attribute group endpoint.

To return all details of the attribute group specified by its ID, use the Get attribute group endpoint.

To list all available attribute groups, use the List attribute group endpoint. You can optionally provide the limit query parameter to specify the maximum number of groups to return per page.

Authorization workflow integration

During the authorization process, the platform evaluates the payload against the configured flex controls. When a condition references a group, the platform performs the following steps:

• Identifies the relevant attribute in the incoming payload (for example, merchant_id)
• Checks whether the attribute value exists within the referenced group
• Applies the control logic based on the result of this evaluation

This mechanism ensures that group-based conditions are evaluated dynamically and consistently during real-time authorizations, allowing for flexible and centralized control logic.

Best practices

• Use clear, descriptive IDs for groups (for example, trusted_merchants, high_risk_mccs).
• Validate the attribute group's existence before referencing it in flex controls.
• Test the attribute group behavior in the sandbox environment before configuring it in production.
• Keep group values updated to reflect business logic changes.