Create a transaction rule

The level at which data must be accumulated, used in rules with type velocity or maxUsage. The level must be the same or lower in hierarchy than the entityKey.

If not provided, by default, the rule will accumulate data at the paymentInstrument level.

Possible values: paymentInstrument, paymentInstrumentGroup, balanceAccount, accountHolder, balancePlatform.

Your description for the transaction rule.

The date when the rule will stop being evaluated, in ISO 8601 extended offset date-time format. For example, 2025-03-19T10:15:30+01:00.

If not provided, the rule will be evaluated until the rule status is set to inactive.

The outcome that will be applied when a transaction meets the conditions of the rule.

Possible values:

• hardBlock (default): the transaction is declined.

• scoreBased: the transaction is assigned the score you specified. Adyen calculates the total score and if it exceeds 100, the transaction is declined. This value is not allowed when requestType is bankTransfer.

• enforceSCA: your user is prompted to verify their identity using 3D Secure authentication. If the authentication fails or times out, the transaction is declined. This value is only allowed when requestType is authentication.

The id of the transaction rule you want to override or skip for the specified entityKey.

Specifies the reason for creating the rule.

Possible values:

• fraud: the rule is created to regulate fraudulent activity.
• policy: the rule is created to ensure that the transaction adheres to your business' policies. For example, if your business has policies about the Merchant Category Codes (MCCs) allowed on a transaction, you can create a rule to block transactions that have specific MCCs.

Your reference for the transaction rule.

Indicates the type of request to which the rule applies. If not provided, by default, this is set to authorization.

Possible values: authorization, authentication, tokenization, bankTransfer.

A positive or negative score applied to the transaction if it meets the conditions of the rule. Required when outcomeType is scoreBased. The value must be between -100 and 100.

The date when the rule will start to be evaluated, in ISO 8601 extended offset date-time format. For example, 2025-03-19T10:15:30+01:00.

If not provided when creating a transaction rule, the startDate is set to the date when the rule status is set to active.

The status of the transaction rule. If you provide a startDate in the request, the rule is automatically created with an active status.

Possible values: active, inactive.

The type of rule, which defines if a rule blocks transactions based on individual characteristics or accumulates data.

Possible values:

• blockList: decline a transaction when the conditions are met.
• maxUsage: add the amount or number of transactions for the lifetime of a payment instrument, and then decline a transaction when the specified limits are met.
• velocity: add the amount or number of transactions based on a specified time interval, and then decline a transaction when the specified limits are met.
• bypass: bypass or skip a rule for the specified entityKey. Transactions processed to that entity are no longer evaluated by the bypassed rule. You must provide the id of the rule to bypass in overridesRule and leave the ruleRestrictions object empty.

The level at which data must be accumulated, used in rules with type velocity or maxUsage. The level must be the same or lower in hierarchy than the entityKey.

If not provided, by default, the rule will accumulate data at the paymentInstrument level.

Possible values: paymentInstrument, paymentInstrumentGroup, balanceAccount, accountHolder, balancePlatform.

Your description for the transaction rule.

The date when the rule will stop being evaluated, in ISO 8601 extended offset date-time format. For example, 2025-03-19T10:15:30+01:00.

If not provided, the rule will be evaluated until the rule status is set to inactive.

The unique identifier of the transaction rule.

The outcome that will be applied when a transaction meets the conditions of the rule.

Possible values:

• hardBlock (default): the transaction is declined.

• scoreBased: the transaction is assigned the score you specified. Adyen calculates the total score and if it exceeds 100, the transaction is declined. This value is not allowed when requestType is bankTransfer.

• enforceSCA: your user is prompted to verify their identity using 3D Secure authentication. If the authentication fails or times out, the transaction is declined. This value is only allowed when requestType is authentication.

The id of the transaction rule you want to override or skip for the specified entityKey.

Specifies the reason for creating the rule.

Possible values:

• fraud: the rule is created to regulate fraudulent activity.
• policy: the rule is created to ensure that the transaction adheres to your business' policies. For example, if your business has policies about the Merchant Category Codes (MCCs) allowed on a transaction, you can create a rule to block transactions that have specific MCCs.

Your reference for the transaction rule.

Indicates the type of request to which the rule applies. If not provided, by default, this is set to authorization.

Possible values: authorization, authentication, tokenization, bankTransfer.

A positive or negative score applied to the transaction if it meets the conditions of the rule. Required when outcomeType is scoreBased. The value must be between -100 and 100.

The date when the rule will start to be evaluated, in ISO 8601 extended offset date-time format. For example, 2025-03-19T10:15:30+01:00.

If not provided when creating a transaction rule, the startDate is set to the date when the rule status is set to active.

The status of the transaction rule. If you provide a startDate in the request, the rule is automatically created with an active status.

Possible values: active, inactive.

The type of rule, which defines if a rule blocks transactions based on individual characteristics or accumulates data.

Possible values:

• blockList: decline a transaction when the conditions are met.
• maxUsage: add the amount or number of transactions for the lifetime of a payment instrument, and then decline a transaction when the specified limits are met.
• velocity: add the amount or number of transactions based on a specified time interval, and then decline a transaction when the specified limits are met.
• bypass: bypass or skip a rule for the specified entityKey. Transactions processed to that entity are no longer evaluated by the bypassed rule. You must provide the id of the rule to bypass in overridesRule and leave the ruleRestrictions object empty.