Configuration Method - Decision Rules - Vindicia Subscribe

Decision rules are a dynamic way to change system behavior without making code changes per merchant. Each decision rule utilizes a predefined object or a defined function. Decision rules are a a proprietary tool. Decision rules are not visible or accessible to merchants. Merchants provide their input to related features and Vindicia inputs the values as decision rules. Despite this, decision rules are a powerful tool as they allow dynamic behavior per merchant and new rules can be defined using the tools we have in place already. The rule main syntax is: an IF condition followed by a THEN answer = value FLAG The value entered for the decision rule is received and acted on by the Vindicia codebase. A decision rule can contain several condition statements that are evaluated in descending order, from the highest ordinary to the lowest one. Conditions can use data elements from objects, that are specified by ”@” , or from another object that was passed to the decision rule from the caller side.Those are marked by ”_”. The table below details the entities that are used for each decision rule and the ”_” data that can be used for each rule. The FLAG allows additional flexibility, such as an option to mark a label on the IF condition and to define the behavior in a different rule Example : IF @.country = “US” THEN :=‘Do_US’ IF @.country = ‘CA’ THEN :=‘Do_Canada’ STOP :Do_US IF @.district = ‘AL’ THEN ans=“Alabama” IF @.district = ‘CA’ THEN ans=“California” IF 1 THEN STOP This topic provides explanations of how to define decision rules. In configuration pages appearing later in this book, the required decision rule and functionality is explained not how to write the syntax. These are the decision rules in use and their respective objects:

Decision rule type	Role	Utilized on	Example	Comments
Sales Taxes There are four types : SalesTax, SalesTax_Avalara, SalesTax_AvaBrazil, SalesTax_Vertex	Used when sending data to the tax interface. For more details see section below	Subscribe	IF _.caller = ‘calculate_tax’ AND _.addr.country = ‘BR’ THEN rule = {“header.entity.federalTaxId” => ‘12345678987654321’,“lines.#.itemCode” => ‘D100’} STOP	”@” uses any taxable class”_” data is tax vendor dataReturns rule = tax vendor hashref
InvoiceLifeCycle	Used for MAP Subscriptions, to set the invoice lifecycle differently based on different parameters of the subscription	Subscribe	IF (_.error_count > 0) and (_.days_till_due < 1) THEN ans = “SetDelinquent”, ans = “CancelAutoBill”, ans =“Disentitle”, ans = “SendCancellation” STOP	”@” uses TransactionBilling”_” data:error_count is set from TransactionBilling.dunning_index days_till_due is the days till the invoice is due template_exists whether the current statement template exists next_template_exists whether the next statement template exists terms something to do with AutoBill.invoice_terms Returns ans = anything- ISee TramsactionBilling::process_statement() for details.
RetryInterval	Defines rules for retry in case of a soft failure. There are diferent nuances between Subscribe & Retain, that are described in the relevant chapter	& & Retain	IF _.transaction_index =2 THEN ‘ans’ =‘3 days’ STOP	- ”@” uses Transaction - ”_” data: - transaction_index is the TransactionBilling.soft_error_count. - billing_day is the day of the week (Sun, Mon, etc) for either the TransactionBilling.original_activity, or the current time. - Returns ans = an interval (1 day, 3 weeks)
RetryNewProcessor	Defines rules for routing retry attempts to specific payment providers . Note: The payment providers that can be defined, must also be defined in the merchant’s Routing Rules using the name_value_processor (22) method	Retain & Subscribe	IF _.prior_routing = ‘CyberSource’ THEN pp = ({‘value’ => ‘CyberSource’}) STOP THEN pp = ({‘1’ => {‘value’ => ‘Compass’}, ‘2’ => {‘value’ => ‘CyberSource’}}{_.soft_error_count} \	\	null) STOP THEN pp = null STOP	- ”@“uses Transaction - ”_” data: - transaction_index is the TransactionBilling.soft_error_count the soft error count is used for the Transaction - this serves as a counter for retry attempts. You can define which attempt to route to a specific provider using this index - prior_routing is the original payment provider name to which the Transaction was routed prior to the NVPs added by the decision rule. - Note: TransactionBilling::generate_transaction sets a NVP for the selected payment_provider on the Tx which is then used by the name_value_processor method routing rules to redirect the transaction retry.
RetryOverride	Defines when to “flip” the recurring flag for a transaction	Retain	THEN override = ({‘2’ => {‘recurring’ => 0},‘3’ => {‘recurring’ => 0}}{_.transaction_index} \	\	null) STOP	”@” uses Transaction- ”_” data: - billing_attempt is TransactionBilling.autobill_sequence - transaction_index depends on where it is called from: - CashBox_Utils::deposit_failed_authorization() sets it to TransactionBilling.soft_error_count + 1. - TransactionBilling::set_retry_overrides() sets it to TransactionBilling.soft_error_count, or 0 if not defined. - year_month is the current year and month, as YYYYMM - returns override = specially formatted string - CashBox_Utils::deposit_failed_authorization() only cares if it got back any answer, not what the answer is. - TransactionBilling::set_retry_overrides() evals some answers, ignores others (see the code for details).
ExpiryOverride	In case of expired cards, the system tries to guess possible exoiration dates. Every retry (as setin the rule) will attempt to add a number of years either to today date ot to the card expiration date. The rule is evaluated when a transaction is created.	Subscribe & Retain	THEN ans = ({‘0’ => ‘BLANK’, ‘1’ => ‘EXP 1 year’,‘2’ => ‘EXP 4 year’, ‘3’ => ‘EXP 3 year’, ‘4’ => ‘EXP 2 year’}{_.transaction_index} \	\	null) STOP	- ”@” uses Transaction - ”_” data: - transaction_index is the TransactionBilling.soft_error_count. Returns ans = anything
ForcedDeposit	Rule that set the conditions if to force deposit a transaction. The rule is evaluated during post_processing of a transaction, looks at the auth code response that was received from the payment processor and based on that, flag that the next transaction should be forced.	Subscribe merchants that have ART mode turned on and Retain Merchants	IF @.auth_response_code IN (‘100’,‘302’, ‘530’, ‘303’) THEN ans = 1	- ”@” uses Transaction - ”_” data: - billing_attempt is the TransactionBilling.autobill_sequence - transaction_index is the TransactionBilling.soft_error_count Returns ans = anything- Only cares that there is a non-false answer
WhiteList	Rule that is relevant only if a Forced Deposit. was enabled. Allows to force only on a pre-defined list of BINS	Subscribe merchants that have ART mode turned on and Retain Merchants	IF (@.auth_response_code IN (‘100’,‘530’,‘302’,‘303’)) THEN ans = 1 STOP	- ”@” uses Transaction - ”_” data: - billing_attempt is the TransactionBilling.autobill_sequence - transaction_index is the TransactionBilling.soft_error_count
For more information on how to add decisions rules, see the Adding Decision rule Vindicia wiki page.

Additional Decision Rules, Not as widely used

Rule	Utilized on	Utilize	Answer
AuthenticationProvider		- ”@” uses Transaction - ”_” data is not used	Returns ans = string of key=val joined by comma- enable_3ds=1 sets Transaction.enable_3ds to 1, otherwise sets it to 0. - authentication_provider=val sets tx_detail.authentication_provide
AutoFight	Chargeguard	- ”@” uses Chargeback - ”_” data is not used	Returns status = CBDisposition.id- Unimplemented
DivisionNumber	Subscribe & Retain	- ”@” uses Transaction - ”_” data is unused	Returns ans = anything- Unimplemented
Full Deposit Threshold	Retain	- ”@” uses Transaction - ”_” data: - billing_attempt is the TransactionBilling.autobill_sequence - transaction_index is the TransactionBilling.soft_error_count	- Returns ans = anything - Returned verbatim by Transaction::get_full_deposit_threshold().
PartialAuthThreshold	Retain	- ”@” uses Transaction - ”_” data: - billing_attempt is the TransactionBilling.autobill_sequence - transaction_index is the TransactionBilling.soft_error_count - otx_amount is the Transaction.amount or original_amount	- Returns ans = anything - The returned answer is the partial auth threshold.
Routing	Subscribe & Retain	- ”@” uses Transaction - ”_” data is unused	- Returns pp = PaymentProvider - It is used by Obj::Entity::RoutingRule::get_payment_provider_for_merchant().
Whitelist		- ”@” uses Transaction - ”_” data: - billing_attempt is the TransactionBilling.autobill_sequence - transaction_index is the TransactionBilling.soft_error_count	- Returns ans = anything - It is apparently just a true/false flag; returns true to check the whitelist. - See CashBox_Utils::check_bin_whitelist() for details.

Sales Tax Specific Decision rules

SalesTax	Enables adjusting the fields sent to the tax interface based on the function that is used	Subscribe - will be decomission when all merchants are moving out the sales tax engine
SalesTax_Avalara		Subscribe
SalesTax_Vertex	Enables adjusting the fields sent to the tax interface based on the function that is invoked	Subscribe

Outside tax vendor types have some common features:

Writing tax vendor rules requires deep knowledge of vendor requests and through testing.
Their only use is custom modifications of the tax vendor requests fr special cases.
- DirecTV uses this to convert from our Vertex default version of 7/9 to their version 6.
Uses any taxable class:
- Transaction
- TransactionBilling
- Chargeback
- Refund
- MerchantCustomer when dealing with exemptions. These are obsolete but the code is still active.
Data is tax data:
- addr is the possibly-mangled sales tax address.
- caller is a string identifying the calling method:
  - calculate_tax
  - ping
  - post
  - void
  - “_item” will be appended on each line item, as opposed to the entire request. Yes, there can be separate rules for the entire request and for line items.
- req is the specific line item hashref of the request; not the entire request.
Returned tax data
- This is a very peculiar hashref. See SalesTax::merge_request() et al for details.

For more information on decision rules syntax, see the Writing Decision Rules Vindicia wiki page

Home

Guides

APIs

Configuration Method - Decision Rules

Additional Decision Rules, Not as widely used

Sales Tax Specific Decision rules

​Additional Decision Rules, Not as widely used

​Sales Tax Specific Decision rules

Additional Decision Rules, Not as widely used

Sales Tax Specific Decision rules