Auth Rules
Auth Rules
Auth Rules
auth_rulesAuth RulesV2
auth_rules.v2Update a rule
Updates a V2 Auth rule's properties
If account_tokens, card_tokens, program_level, or excluded_card_tokens is provided, this will replace existing associations with the provided list of entities.
Apply a rule
Associates a V2 Auth rule with a card program, the provided account(s) or card(s).
Prefer using the PATCH method for this operation.
Draft a new rule version
Creates a new draft version of a rule that will be ran in shadow mode.
This can also be utilized to reset the draft parameters, causing a draft version to no longer be ran in shadow mode.
Promote a rule version
Promotes the draft version of an Auth rule to the currently active version such that it is enforced in the respective stream.
Request a performance report
This endpoint is deprecated and will be removed in the future.
Requests a performance report of an Auth rule to be asynchronously generated. Reports can only be run on rules in draft or active mode and will included approved and declined statistics as well as examples.
The generated report will be delivered asynchronously through a webhook with event_type = auth_rules.performance_report.created. See the docs on setting up webhook subscriptions.
Reports are generated based on data collected by Lithic's processing system in the trailing week. The performance of the auth rule will be assessed on the configuration of the auth rule at the time the report is requested. This implies that if a performance report is requested, right after updating an auth rule, depending on the number of events processed for a card program, it may be the case that no data is available for the report. Therefore Lithic recommends to decouple making updates to an Auth Rule, and requesting performance reports.
To make this concrete, consider the following example:
- At time
t, a new Auth Rule is created, and applies to all auth events on a card program. The Auth Rule has not yet been promoted, causing the draft version of the rule to be applied in shadow mode. - At time
t + 1 houra performance report is requested for the Auth Rule. This performance report will only contain data for the Auth Rule being executed in the window betweentandt + 1 hour. This is because Lithic's transaction processing system will only start capturing data for the Auth Rule at the time it is created. - At time
t + 2 hoursthe draft version of the Auth Rule is promoted to the active version of the Auth Rule by calling the/v2/auth_rules/{auth_rule_token}/promoteendpoint. If a performance report is requested at this moment it will still only contain data for this version of the rule, but the window of available data will now span fromttot + 2 hours. - At time
t + 3 hoursa new version of the rule is drafted by calling the/v2/auth_rules/{auth_rule_token}/draftendpoint. If a performance report is requested right at this moment, it will only contain data for events to which both the active version and the draft version is applied. Lithic does this to ensure that performance reports represent a fair comparison between rules. Because there may be no events in this window, and because there may be some lag before data is available in a performance report, the requested performance report could contain no to little data. - At time
t + 4 hoursanother performance report is requested: this time the performance report will contain data from the window betweent + 3 hoursandt + 4 hours, for any events to which both the current version of the Auth rule (in enforcing mode) and the draft version of the Auth rule (in shadow mode) applied.
Note that generating a report may take up to 15 minutes and that delivery is not guaranteed. Customers are required to have created an event subscription to receive the webhook. Additionally, there is a delay of approximately 15 minutes between when Lithic's transaction processing systems have processed the transaction, and when a transaction will be included in the report.
Retrieve a performance report
Retrieves a performance report for an Auth rule containing daily statistics and evaluation outcomes.
Time Range Limitations:
- Reports are supported for the past 3 months only
- Maximum interval length is 1 month
- Report data is available only through the previous day in UTC (current day data is not available)
The report provides daily statistics for both current and draft versions of the Auth rule, including approval, decline, and challenge counts along with sample events.
Auth Rule
Auth Rule Condition
Conditional Attribute
The attribute to target.
The following attributes may be targeted:
MCC: A four-digit number listed in ISO 18245. An MCC is used to classify a business by the types of goods or services it provides.COUNTRY: Country of entity of card acceptor. Possible values are: (1) all ISO 3166-1 alpha-3 country codes, (2) QZZ for Kosovo, and (3) ANT for Netherlands Antilles.CURRENCY: 3-character alphabetic ISO 4217 code for the merchant currency of the transaction.MERCHANT_ID: Unique alphanumeric identifier for the payment card acceptor (merchant).DESCRIPTOR: Short description of card acceptor.LIABILITY_SHIFT: Indicates whether chargeback liability shift to the issuer applies to the transaction. Valid values areNONE,3DS_AUTHENTICATED, orTOKEN_AUTHENTICATED.PAN_ENTRY_MODE: The method by which the cardholder's primary account number (PAN) was entered. Valid values areAUTO_ENTRY,BAR_CODE,CONTACTLESS,ECOMMERCE,ERROR_KEYED,ERROR_MAGNETIC_STRIPE,ICC,KEY_ENTERED,MAGNETIC_STRIPE,MANUAL,OCR,SECURE_CARDLESS,UNSPECIFIED,UNKNOWN,CREDENTIAL_ON_FILE, orECOMMERCE.TRANSACTION_AMOUNT: The base transaction amount (in cents) plus the acquirer fee field in the settlement/cardholder billing currency. This is the amount the issuer should authorize against unless the issuer is paying the acquirer fee on behalf of the cardholder.RISK_SCORE: Network-provided score assessing risk level associated with a given authorization. Scores are on a range of 0-999, with 0 representing the lowest risk and 999 representing the highest risk. For Visa transactions, where the raw score has a range of 0-99, Lithic will normalize the score by multiplying the raw score by 10x.CARD_TRANSACTION_COUNT_15M: The number of transactions on the card in the trailing 15 minutes before the authorization.CARD_TRANSACTION_COUNT_1H: The number of transactions on the card in the trailing hour up and until the authorization.CARD_TRANSACTION_COUNT_24H: The number of transactions on the card in the trailing 24 hours up and until the authorization.CARD_STATE: The current state of the card associated with the transaction. Valid values areCLOSED,OPEN,PAUSED,PENDING_ACTIVATION,PENDING_FULFILLMENT.PIN_ENTERED: Indicates whether a PIN was entered during the transaction. Valid values areTRUE,FALSE.PIN_STATUS: The current state of card's PIN. Valid values areNOT_SET,OK,BLOCKED.WALLET_TYPE: For transactions using a digital wallet token, indicates the source of the token. Valid values areAPPLE_PAY,GOOGLE_PAY,SAMSUNG_PAY,MASTERPASS,MERCHANT,OTHER,NONE.
Conditional Block Parameters
Rule Stats
Velocity Limit Params
Velocity Limit Params Period Window
The window of time to calculate Spend Velocity over.
DAY: Velocity over the current day since midnight Eastern Time.WEEK: Velocity over the current week since 00:00 / 12 AM on Monday in Eastern Time.MONTH: Velocity over the current month since 00:00 / 12 AM on the first of the month in Eastern Time.YEAR: Velocity over the current year since 00:00 / 12 AM on January 1st in Eastern Time.
Auth RulesV2Backtests
auth_rules.v2.backtestsRequest a backtest
Initiates a request to asynchronously generate a backtest for an Auth rule. During backtesting, both the active version (if one exists) and the draft version of the Auth Rule are evaluated by replaying historical transaction data against the rule's conditions. This process allows customers to simulate and understand the effects of proposed rule changes before deployment. The generated backtest report provides detailed results showing whether the draft version of the Auth Rule would have approved or declined historical transactions which were processed during the backtest period. These reports help evaluate how changes to rule configurations might affect overall transaction approval rates.
The generated backtest report will be delivered asynchronously through a webhook with event_type = auth_rules.backtest_report.created. See the docs on setting up webhook subscriptions.
It is also possible to request backtest reports on-demand through the /v2/auth_rules/{auth_rule_token}/backtests/{auth_rule_backtest_token} endpoint.
Lithic currently supports backtesting for CONDITIONAL_BLOCK / CONDITIONAL_3DS_ACTION rules. Backtesting for VELOCITY_LIMIT rules is generally not supported. In specific cases (i.e. where Lithic has pre-calculated the requested velocity metrics for historical transactions), a backtest may be feasible. However, such cases are uncommon and customers should not anticipate support for velocity backtests under most configurations.
If a historical transaction does not feature the required inputs to evaluate the rule, then it will not be included in the final backtest report.
Retrieve backtest results
Returns the backtest results of an Auth rule (if available).
Backtesting is an asynchronous process that requires time to complete. If a customer retrieves the backtest results using this endpoint before the report is fully generated, the response will return null for results.current_version and results.draft_version. Customers are advised to wait for the backtest creation process to complete (as indicated by the webhook event auth_rules.backtest_report.created) before retrieving results from this endpoint.
Backtesting is an asynchronous process, while the backtest is being processed, results will not be available which will cause results.current_version and results.draft_version objects to contain null.
The entries in results will also always represent the configuration of the rule at the time requests are made to this endpoint. For example, the results for current_version in the served backtest report will be consistent with which version of the rule is currently activated in the respective event stream, regardless of which version of the rule was active in the event stream at the time a backtest is requested.