Skip to main content
The RetryNewProcessor decision rules enables to modify the payment provider used for specific retry attempts. It can benefit capture success rates by allowing to retry the failed Transaction with a different payment provider, where chances for capture may be improved due to higher success rates for retries. These may not be the providers that merchants want to use for the bulk of their billing attempts due to fees and other reasons. The RetryNewProcessor decision rule works alongside the merchant’s defined routing rules and requires the relevant payment providers be defined by name_value_processor (22) method definition. See the Before You Begin section for more details. Note: The feature is only relevant when we have the full PAN or detokenized with the original payment provider.

​
Before You Begin

Define the relevant payment provider Routing Rules as follows:
  1. In Portal 1.0 Admin menu , select Merchant configuration.
  2. Edit the merchant’s configuration.
  3. In Routing Rules section, add the relevant Providers and set the ordinals where higher ordinals will be selected first.
  4. For Rule method, select name_value_processor (22) method.
  5. For the value field, enter the identical spelling of the payment provider as the value.

​
Setting and Understanding the RetryNewProcessor Decision Rule

To understand decision rules, first read, Configuration Method - Decision Rules. The RetryNewProcessor decision rule will allow you to define routing to specific payment providers of specific retry attempts. The decision rule adds a Name-Value Pair to the retry Transaction, identifying the payment provider, the routing rule then receives the defined value (for the name_value_processor method) and routes the retry attempt accordingly. Division Numbers are also changed by the decision rule so that the payment provider can identify the merchant of the Transaction. Note: Defining this rule will mean that a different payment provider will be used to attempt to capture. This may incur additional fees than the original provider but may be advised in order to retain the Transaction and customer. Defining the rule uses the following elements:
  • **”@“**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.