Issuing authorisation rules

Learn how to limit authorisation approvals using Issuing authorisation rules.

Issuing rules help you prevent unauthorised activity by blocking authorisations that match custom conditions. For example, you can block card transactions outside of your geography, above a certain amount, or where certain fraud signals are present. You can access Issuing rules in the Rules tab in your Issuing Dashboard after enabling Radar.

You can configure Issuing rules to decline, then follow up with an SMS sent to the cardholder to confirm it was them who was making the transaction. The cardholder can retry the transaction if they confirm the SMS prompt. These rules can prevent fraud losses by confirming the legitimate use of a card. Learn more about fraud challenges.

Note

In addition to Issuing rules that you configure, Stripe enforces a number of default behaviours to prevent fraud.

Default rules

Your first login to Issuing rules creates a set of default rules you can enable at any time.

Create a rule

To create a rule, open the Rules tab in your Issuing Dashboard and complete the following steps:

1. Select + New rule.
2. If you’re a Connect platform, you can specify the connected accounts to apply the rule to. If you don’t define an audience, the rule applies to all of your connected accounts.
3. Give the rule a descriptive name.
4. Select the action for the rule. The action Block declines an authorisation when the rule condition is met, and the action Block and challenge declines and attempts to send a fraud challenge to the cardholder.

• You can use the Block and challenge action without enabling fraud challenges in your card issuing settings.

5. From the Attributes dropdown, select the attribute to use in evaluating the rule’s condition. For example, if you want to block authorisations from a specific country, select the Merchant country attribute. To instead use a custom metadata value, turn on the Use my own metadata toggle and enter the metadata.
6. From the next dropdown, select the operator for the condition. The dropdown includes operators applicable to the selected attribute. For details about each operator’s syntax and behaviour, see the Radar operator list.
7. Set the threshold value to compare to the attribute. Depending on the selected attribute and operator, you can select one or more of the following options:

• A value you enter or select from a list of values.
• Another attribute’s value.
• A value from your own metadata.

8. Optionally, add another attribute to the rule. See Complex rules.
9. Run a backtest, which allows you to observe the rule performance from historical data.
10. Enable the rule. Enabling the rule immediately deploys it to production.

To determine appropriate threshold values for your use case, we recommend backtesting your historical authorisation data. Be aware that string comparisons are case-insensitive.

Backtesting

Backtesting is a method to assess how a rule would have affected authorisations if implemented previously, before it goes live.

It allows you to evaluate a rule’s impact on authorisation and issuing volume early in the rule creation lifecycle, helping to prevent false positives such as blocking legitimate transactions.

Here are the metrics we use for backtesting:

Certain authorisations might be excluded from the backtest because they’re blocked by other Stripe defence layers prior to rule evaluation.

Rules built involving attribute or metadata comparison won’t yield backtest results.

Data counting commences from the enrolment date into the issuing authorisation rules.

Testing

You can create rules in a sandbox and create sandbox authorisations in the Dashboard or using the API. Enabled sandbox rules automatically evaluate against the authorisations.

You can inspect individual authorisations to see if they were blocked by a rule. When an authorisation declines due to triggering a rule, the Authorization object’s status is set to closed and its request_history.reason is set to rule_blocked. If the authorisation is blocked by a block and challenge rule, fraud_challenges is populated.

Learn how to test Block and challenge rules.

Evaluate rule performance

Review the performance of your rules on a regular basis, and replace them if needed. The list of rules displays the count and rate of blocked authorisations for each rule. To see detailed statistics about a particular rule, click it to open its details panel. You can view the count and rate by count of authorisations blocked by the rule, or their volume and rate by volume. The panel also displays a list of authorisations recently blocked by the rule, including their date, merchant, and amount.

Issuing rule metrics for the block action

Block and challenge rules display a similar set of metrics. However, they might include metrics for authorisations that were retried after a successful verification, because they measure rule evaluation.

Disable or delete a rule

You can’t edit a rule, but you can disable or delete it. Select the rule, then click Disable or Delete.

• Disabling a rule turns it off in production, but keeps it in your rules list in an inactive state and retains its performance history. You can re-enable a disabled rule by selecting it and clicking Enable .
• Deleting a rule stops it from running in production and permanently removes it from your rules list. It also deletes the rule’s performance history. You can’t recover a deleted rule or its history.

If you want to change an existing rule, create a new rule to replace it, then disable or delete the existing rule.

Use card metadata

Issuing rules handle metadata the same way as Radar’s metadata attributes. Metadata is interpreted as a string or number depending on the value compared with it, and its value is derived from the metadata field on the issued card. String metadata attributes are case-sensitive.

To use metadata as an attribute, turn on the Use my own metadata toggle, then enter the metadata in the Attribute field. Surround the metadata name with double colons ( ::), and separate subfields with a single colon ( :). For example, if your card metadata looks like { controls: { id: 'newUserControl'}}, then to use the id field in a rule, enter it in the Attribute field as ::controls:id::.

To use metadata as a comparison value, select the Metadata value type, then enter the metadata in the value field. Surround the metadata name with double colons ( ::), and separate subfields with a single colon ( :). For example, to compare an attribute to the disputeCount metadata, enter ::disputeCount::.

Complex rules

You can create complex rules that evaluate multiple attributes or groups of attributes. Groups work like parentheses in Radar’s complex conditions. After defining a condition, add another condition or group to the same rule by clicking + Add more and selecting what to add.

Conditions always belong to a group. The first condition belongs to a default group, and any conditions not explicitly added to a different group or subgroup also belong to the default group.

By default, each condition or group is appended with an AND operator. You can change it to OR using the dropdown.

Note

An Issuing rule with multiple conditions uses standard operator precedence of NOT, then AND, then OR. For example, if you create a rule with the four condition groups A AND B OR C OR Doesn’t match D, it’s evaluated as (A AND B) OR © OR (NOT D).

The following example uses two conditions joined by AND to block authorisations from businesses in Antarctica when the authorisation (merchant) currency is USD.

A rule with multiple conditions

Each group displays a dropdown at the top with the default value Matches. You can negate the group by selecting Doesn’t match. Negating a group makes the condition true when the group evaluates to false, equivalent to applying a NOT operator to the group.

To delete a condition or group from the rule, click the X icon in the top right of the condition or group. If the rule contains only one group and one condition, you can’t delete them.

Rule precedence

Your rules evaluate each authorisation with action-based prioritisation:

1. Block: Rules that block decline an authorisation. Block rules are evaluated before block and challenge rules.
2. Block and challenge: Rules that block and challenge decline an authorisation, and attempt to send a fraud challenge to the cardholder. The cardholder can respond to the challenge, and if their response verifies the transaction, they can retry the authorisation, which isn’t blocked by block and challenge rules. Here’s an example setup:
3. You have one rule that blocks authorisations above 1000 USD.
4. You have another rule that blocks and challenges transactions in a gaming-related merchant category (gaming MCC codes sometimes correspond to online gambling websites). The results for various scenarios with the setup are:

• A cardholder attempts to spend 2000 USD on a gaming website. Because the block rule takes precedence, the authorisation is blocked, and no fraud challenge is sent.
• A cardholder attempts to spend 50 USD on a gaming website. The block rule doesn’t trigger in this scenario, but it meets the criteria for the block and challenge rule, so a challenge is sent to the cardholder. The cardholder verifies the challenge, and attempts to transact again. This time, the transaction goes through.
• The cardholder already verified their transaction with the challenge from earlier. They attempt to spend 2000 USD at the same site. In this case, even though the challenge was verified, this is the same scenario as the first. The block rule is triggered so the authorisation is declined.

Block and challenge rules consider fraud challenges triggered outside Issuing rules. If a fraud challenge that Stripe sends in response to a high-risk authorisation verifies an authorisation, and a block and challenge rule triggers on a subsequent, similar authorisation, it considers the authorisation to be verified.

These are the possible results for related scenarios:

• You have a block and challenge rule that triggers for an amount over 100 USD. A cardholder attempts to buy an item online for 90 USD. It triggers Stripe’s fraud challenge logic so the authorisation fails, and the cardholder receives a challenge. The cardholder then verifies the challenge. The cardholder realises they forgot to add another item to cart earlier and does so now, bringing their total to 110 USD. The block and challenge rule is triggered, but the verifying challenge applies, and the authorisation is successful.
• If the scenario above had swapped order for example, the cardholder starts with both items and then removes an item, and the second transaction passed Stripe’s risk threshold), the authorisation and challenge experience would have been the same for the cardholder - they would receive a decline and challenge for the initial attempt, and approval for the second.

Webhook logic

Stripe evaluates Issuing rules before sending the issuing_authorization.request event. If you have a webhook listening for that event, then authorisations declined by Issuing rules don’t trigger it.

Attribute list

Most attributes correspond to properties in the Authorisation API. When using a string operator on an attribute that contains an enum value, get the enum strings from the corresponding property’s API Reference entry. When using certain other operators, you can select values or attributes from a dropdown.

Note

Some dropdown values are human-readable versions of enum values. For example, an enum value of not_provided might appear in the dropdown as “Not provided”. For a string operator, use the actual enum value, such as not_provided.

Authorisation details

Verification data

Merchant data

Cardholder data

Risk assessment

Velocity checks

The following attributes don’t count the authorisation under evaluation in their calculations.