Issuing authorization rulesPrivate preview
Learn how to limit authorization approvals using Issuing authorization rules.
Issuing rules help you prevent unauthorized activity by blocking authorizations 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. Access Issuing rules in the Stripe Issuing Dashboard by selecting the Rules tab.
Note
In addition to Issuing rules that you configure, Stripe enforces a number of default behaviors to prevent fraud.
When an authorization is declined due to triggering a rule, the Authorization
object’s status is set to closed
and its request_history.reason, is set to rule_
.
Generate default rules
When you first log in to Issuing rules, you can generate a set of rules tailored to your use case by answering some questions. You can delete or disable any of these generated rules, the same as rules that you create. To answer the questions later, click Remind me later.
Creating a rule
To create a rule, open the Rules tab in your Issuing Dashboard and complete the following steps:
Select + New rule.
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.
Give the rule a descriptive name.
From the Attributes dropdown, select the attribute to use in evaluating the rule’s condition. For example, if you want to block authorizations 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.
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 behavior, see the Radar operator list.
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 To determine appropriate threshold values for your use case, we recommend backtesting your historical authorization data.
Note
String comparisons are case-insensitive.

Select the attribute, operator, and threshold value when creating a condition
- Optionally, add another attribute to the rule. See Complex rules.
- Enable the rule. Enabling the rule immediately deploys it to production.
Evaluating 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 authorizations 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 authorizations blocked by the rule, or their volume and rate by volume. The panel also displays a list of authorizations recently blocked by the rule, including their date, merchant, and amount.

Issuing rule metrics
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.
Using 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 Does not match D, it’s evaluated as (A AND B) OR (C) OR (NOT D).
The following example uses two conditions joined by AND
to block authorizations from businesses in Antarctica when the authorization (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 Does not 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.
Webhook logic
Stripe evaluates Issuing rules before sending the issuing_authorization.request event. If you have a webhook listening for that event, then authorizations declined by Issuing rules don’t trigger it.
Attribute list
Most attributes correspond to properties in the Authorization 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_
might appear in the dropdown as “Not provided”. For a string operator, use the actual enum value, such as not_
.
Authorization details
Attribute | Type | Example Value |
Amount in cardholder currency | Numeric (integer) | 253 |
The amount Stripe will hold if the authorization is approved, in the smallest currency unit of the card’s currency. Corresponds to pending_request.amount. | ||
Amount in merchant currency | Numeric (integer) | 1880 |
The amount the merchant is requesting to be authorized, in the smallest currency unit of the merchant’s currency. Corresponds to pending_request.merchant_amount. | ||
Cardholder currency | String | eur |
Three-letter (case-insensitive) ISO currency code representing the card’s currency. Corresponds to pending_request.currency. | ||
Merchant currency | String | usd |
Three-letter (case-insensitive) ISO currency code representing the merchant’s currency. Corresponds to pending_request.merchant_currency. |
Verification data
Attribute | Type | Example Value |
3D Secure result | String | authenticated |
The outcome of the 3D Secure authentication request. The supported values are attempt_acknowledged, authenticated, failed, and required. exempted is not a supported value. For exemptions, use the 3D Secure exemption request value. Corresponds to verification_data.three_d_secure.result. | ||
Address first line check | String | match |
Whether the cardholder provided an address first line and whether it matched the cardholder’s billing. . The supported values are match, mismatch, and not_provided. Corresponds to verification_data.address_line1_check. | ||
Address postal code check | String | mismatch |
Whether the cardholder provided a postal code and whether it matched the cardholder’s billing. . The supported values are match, mismatch, and not_provided. Corresponds to verification_data.address_postal_code_check. | ||
Authentication exemption claiming entity | String | acquirer |
The entity that requested the exemption, either the acquiring merchant or the Issuing user. The supported values are acquirer and issuer. Corresponds to verification_data.authentication_exemption.claimed_by. | ||
Authentication exemption type | String | low_value_transaction |
The specific exemption claimed for this authorization. The supported values are low_value_transaction, transaction_risk_analysis, and unknown. Corresponds to verification_data.authentication_exemption.type. | ||
CVC check | String | not_provided |
Whether the cardholder provided a CVC and whether it matched Stripe’s record. The supported values are match, mismatch, and not_provided. Corresponds to verification_data.cvc_check. | ||
Expiry check | String | match |
Whether the cardholder provided an expiration date and whether it matched Stripe’s record. The supported values are match, mismatch, and not_provided. Corresponds to verification_data.expiry_check. | ||
PIN check | String | not_provided |
Whether the cardholder entered a PIN and whether it matched the PIN on the card or in Stripe’s record. The supported values are offline_pin_match, offline_pin_mismatch, online_pin_match, online_pin_mismatch, and not_provided. Corresponds to verification_data.pin_check. | ||
Verification data postal code | String | 10928 |
The postal code submitted for verification as part of the authorization. Corresponds to verification_data.postal_code. |
Merchant data
Attribute | Type | Example Value |
Merchant category code | String | 4091 |
The merchant category code (MCC) for the seller’s business. The value selection dropdown shows human-readable names, but if you enter a value manually, use the 4-digit MCC code. For a list of supported values, see Issuing merchant categories. Corresponds to merchant_data.category_code. | ||
Merchant city | String | SAN FRANCISCO |
The city where the seller is located. Corresponds to merchant_data.city. | ||
Merchant country | String | US |
The country where the seller is located. Corresponds to merchant_data.country. | ||
Merchant name | String | Rocket Rides |
The name of the seller. Corresponds to merchant_data.name. | ||
Merchant network ID | String | 123ABCDE |
An identifier assigned to the seller by the card network. Different card networks can assign different network IDs to the same merchant. Corresponds to merchant_data.network_id. | ||
Merchant postal code | String | 94103 |
The postal code where the seller is located. Corresponds to merchant_data.postal_code. | ||
Merchant state | String | CA |
The state where the seller is located. Corresponds to merchant_data.state. | ||
Merchant terminal ID | String | 1234567ABC |
An ID assigned by the seller to the location of the sale. Corresponds to merchant_data.terminal_id. | ||
Merchant url | String | https://rocketrides.stripe.com |
URL provided by the merchant on a 3DS request. Corresponds to merchant_data.url. |
Enriched merchant data Private preview
You can create granular authorization rules using data from the enriched_
property of the Authorization
object. The following table shows some of the fields available on this property. Open real-time authorizations while logged in to your Stripe account to learn more and sign up to join the preview.
Attribute | Type | Example Value |
Merchant business identifier | String | bu_123 |
Stripe’s unique identifier for the seller (or specific seller location). | ||
Merchant industry ID | String | breweries_distilleries_and_wineries |
The most specific value of the seller’s industry. | ||
Merchant industry names | Array of Strings | [“Food and Drink”, “Breweries, Distilleries, and Wineries”] |
An array with up to four values describing the seller’s industry, in increasing levels of detail. | ||
Merchant location coordinates latitude | Numeric (Float) | 37.7749 |
Latitude of the seller’s location. | ||
Merchant location coordinates longitude | Numeric (Float) | 122.4194 |
Longitude of the seller’s location. | ||
Merchant logo | String | https://stripe-camo.global.ssl.fastly.net/abcd |
Image link to the seller’s logo. | ||
Merchant name | String | Rocket Rides |
The normalized name of the seller. | ||
Merchant phone | String | +18888675309 |
Phone number of the seller. | ||
Third party logo | String | https://stripe-camo.global.ssl.fastly.net/efgh |
Image link to the third party’s logo. | ||
Third party name | String | Affirm |
The normalized name of the third party. | ||
Third party identifier | String | tpt_123 |
Stripe’s unique identifier for the third party. |
Risk assessment
Attribute | Type | Example Value |
Authorization fraud score | Numeric (integer) | 11 |
Stripe’s numerical model score assessing the likelihood that this authorization is fraudulent. A score above 25 is considered high risk. Corresponds to risk_assessment.fraud_risk.fraud_score. | ||
Authorization risk level | String | high |
The likelihood that this authorization is fraudulent. The supported values are high, normal, and unknown. Corresponds to risk_assessment.fraud_risk.risk_level. | ||
Card testing risk level | String | high |
The likelihood that this authorization is part of card testing activity. The supported values are elevated, high, highest, normal, not_assessed, and unknown. Corresponds to risk_assessment.card_testing_risk.risk_level. | ||
Fraud disputability likelihood | String | neutral |
The likelihood that this transaction will be disputable in the event of fraud. The supported values are neutral, unknown, very_likely, and very_unlikely. | ||
Invalid account number decline rate over the past hour | Numeric (integer) | 23 |
The percentage of the merchant’s declined authorizations in the past hour that are due to a card number not existing. Corresponds to risk_assessment.card_testing_risk.invalid_account_number_decline_rate_past_hour. | ||
Invalid credentials decline rate over the past hour | Numeric (integer) | 77 |
The percentage of the merchant’s declined authorizations in the past hour that are due to incorrect verification data (like CVV or expiration date). Corresponds to risk_assessment.card_testing_risk.invalid_credentials_decline_rate_past_hour. | ||
Merchant risk level | String | normal |
The likelihood that authorizations from this merchant will result in a dispute, based on their Stripe Issuing history. The supported values are elevated, high, normal, not_assessed, and unknown. Corresponds to risk_assessment.merchant_dispute_risk.risk_level. | ||
Seller dispute rate | Numeric (integer) | 2 |
The merchant’s dispute rate across all Stripe Issuing authorizations. Corresponds to risk_assessment.merchant_dispute_risk.dispute_rate. |
Velocity checks
Attribute | Type | Example Value |
Card transactions in the past day | Numeric (integer) | 6 |
The count of transactions in the past day, regardless of their authorization status. | ||
Card transactions in the past hour | Numeric (integer) | 5 |
The count of transactions in the past hour, regardless of their authorization status. | ||
Card transactions with same currency and amount in the past day | Numeric (integer) | 7 |
The count of transactions with the same amount and currency in the past day, regardless of their authorization status. | ||
Card transactions with same currency and amount in the past hour | Numeric (integer) | 4 |
The count of transactions with the same amount and currency in the past hour, regardless of their authorization status. | ||
Card transactions with same MCC in the past day | Numeric (integer) | 8 |
The count of transactions with the same merchant category code (MCC) in the past day, regardless of their authorization status. | ||
Card transactions with same MCC in the past hour | Numeric (integer) | 3 |
The count of transactions with the same merchant category code (MCC) in the past hour, regardless of their authorization status. | ||
Card transactions with same network ID in the past day | Numeric (integer) | 6 |
The count of transactions with the same merchant network ID in the past day, regardless of their authorization status. | ||
Card transactions with same network ID in the past hour | Numeric (integer) | 3 |
The count of transactions with the same merchant network ID in the past hour, regardless of their authorization status. | ||
Days since card creation | Numeric (integer) | 20 |
The count of days since the card was created. | ||
Days since cardholder creation | Numeric (integer) | 15 |
The count of days since the cardholder was created. | ||
Days since token creation | Numeric (integer) | 30 |
The count of days since the card network token was created. | ||
Total USD amount in cents approved on a card in the past day | Numeric (integer) | 10000 |
The total amount of approved transactions on the card in USD in the past day, in the smallest currency unit (cents). | ||
Total USD amount in cents approved on a card in the past hour | Numeric (integer) | 5000 |
The total amount of approved transactions on the card in USD in the past hour, in the smallest currency unit (cents). |