Auth Rules
auth_rules
auth_rules.v2
Methods
Creates a new V2 Auth rule in draft mode
Lists V2 Auth rules
Fetches a V2 Auth rule by its token
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.
Deletes a V2 Auth rule
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.
Promotes the draft version of an Auth rule to the currently active version such that it is enforced in the respective stream.
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.
Fetches the current calculated Feature values for the given Auth Rule
This only calculates the features for the active version.
- VelocityLimit Rules calculates the current Velocity Feature data. This requires a
card_tokenoraccount_tokenmatching what the rule is Scoped to. - ConditionalBlock Rules calculates the CARD_TRANSACTION_COUNT_* attributes on the rule. This requires a
card_token
Timestamp at which the Features were evaluated
Calculated Features used for evaluation of the provided Auth Rule
Domain types
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.ADDRESS_MATCH: Lithic's evaluation result comparing transaction's address data with the cardholder KYC data if it exists. Valid values areMATCH,MATCH_ADDRESS_ONLY,MATCH_ZIP_ONLY,MISMATCH,NOT_PRESENT.
The operation to apply to the attribute
A regex string, to be used with MATCHES or DOES_NOT_MATCH
The event stream during which the rule will be evaluated.
Velocity over the current day since 00:00 / 12 AM in Eastern Time
auth_rules.v2.backtests
Methods
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_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.
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.
Domain types
