Optimize Evaluate is our new feature-rich risk management solution operating in real time during payment authorisation, as well as providing all the necessary tools for your fraud team to manage risk. For more information about our Optimize suite please follow this link.
Enabling Optimize Evaluate allows you to make informed decisions about whether to send the transaction for bank authorisation, decline it or defer it for manual review. We will return back to you the result of the fraud check and the summary of rules that were triggered via our API. Additional detail can be viewed in the Risk Management section in the merchant portal.
Optimize Evaluate is available to use on the following transaction types:
- Payments
- Authorisations
- Payouts
- Repeats
It is important to send as much as accurate data as possible on your API requests in order to make the most effective use of the Optimize products.
The API description below indicates which fields can be used in Optimize Fraud Evaluate and Optimize Investigate. Note for Optimize Investigate certain fields which are normally optional are mandatory and this is clearly highlighted below.
You can find more information on all our Optimize services here.
parameters:
parameters:
When a Fraud check is performed we’ll provide information about the outcome of that check in the authorisation response. Below is a summary of the outcome fields you will receive.
| processing { | Information about the authorisation status of your transaction. |
| decision { | Information about the results of a Fraud check. |
| decisionResult | string Possible Values: BLOCK, DEFER, PROCEED. The result of the Fraud check. |
| decisionSource | string Possible Values: RULE, NEGATIVE_LIST, POSITIVE_LIST, BLACKLIST, WHITELIST, TERRITORY MANAGEMENT, FRAUDGUARD. What caused the Fraud check result. |
| decisionReason | string Possible Values: DERIVED_BY_TRIGGERED_RULE_ACTION, DECIDED_BY_RISK_CONTROLS, DECIDED_BY_FRAUDGUARD, RULE_ENGINE_UNAVAILABLE, UNABLE_TO_DEFER_TRANSACTION, NO_RULES_TRIGGERED. The reason for the decision. |
| requestedType | string Possible Values: PAYMENT, PREAUTH, PAYOUT, REPEAT. The type of transaction that was submitted to Pay360. |
| decidedType | string Possible Values: PAYMENT, PREAUTH, PAYOUT, REPEAT. The new transaction type for the transaction following the Fraud check. For example, a transaction submitted as a Payment may be updated to an Authorisation (PreAuth) to allow manual review before the transaction is approved for settlement. |
| rulesTriggered [ | An array containing information about the Optimize fraud rules triggered. |
| { | |
| name | string The rule name. |
| action | string The action advised by the rule. |
| description | string The rule description. |
| } | |
| ] | |
| } | |
| … | |
Rules
Rules for Optimize Evaluate are created via our merchant portal.
Rule Conditions
A rule is made up of one or more conditions which are evaluated to determine if a rule is triggered. There are a number of condition types available that will help you write rules specific to your business needs. The following condition types are currently available:
- Geolocation
- Simple
- Velocity (count and sum)
- Morphing
- List
- Comparison
- Age
Details of conditions in a rule are not currently returned in our API response. You will need to view the rule in our merchant portal to see what conditions a rule is made up of.
Rule Actions
When creating a rule you must assign it an action that will input into the decision for what will happen to the transaction after all rules are evaluated. The available rule actions are:
- Accept – Force accept the transaction
- Block – Decline the transaction
- Defer – Defer the transaction with an option of capture or decline after a specified time period
- Test – Ignore this transaction. The transaction will proceed as normal and nothing will be returned on the API response. The transaction details in the Portal will indicate that the rule was triggered.
Rule Evaluation
The rules that are triggered are evaluated by our platform and an overall decision result will be determined. This decision result informs you what has happened to the transaction. The rule evaluation process looks at the action of each rule that has been triggered and uses an order of precedence to resolve conflicting actions. The possible decision results are:
- DEFER – The transaction has been deferred. Deferred transactions will automatically be captured or declined based on the period configured in the dominant rule. Typically, deferred transactions will need to be accepted or rejected manually.
- BLOCK – The transaction has been declined
- PROCEED – The transaction has been allowed to go to authorisation
Territory Management Rules
Within the merchant portal it is possible to create territory management rules for blocking or deferring transactions based on country and location data such as customer IP address and country of card issue. There is a designated territory management section in the merchant portal for creating these rules. Territory management rules will be evaluated amongst all other rules that are triggered and will always take precedence over standard rules. Due to the nature and usage of these rules, a territory management rule with a Block action will take precedence over a territory management rule with a Defer action. In comparison, a standard rule with an action of Defer will take precedence over standard rule with an action of Block.
Rule Action Precedence
When multiple rules are triggered for the same transaction there is an order of precedence that determines what the overall decision result will be. The order of precedence is:
- Positive list
- Negative list
- Territory Management Block
- Territory Management Defer
- Accept
- Defer
- Block
- Test
3-D Secure and rules
3-D Secure is performed before rules are evaluated meaning that you can write rules based on the outcome or data provided from a 3-D Secure check. This applies to both 3-D Secure V1 and V2.
In-flight call-backs
Rules are evaluated before pre-authorisation call-backs are sent meaning the full details of the rule evaluation are provided in the pre-authorisation call-back request to the merchant. It is then possible to use the decision details returned to decide whether to proceed with or cancel the transaction. The exception to this is when a transaction is blocked by Optimize Evaluate, a Pre-Auth or Post-Auth call-back will not be sent in this case as the decision to block the transaction cannot be overturned by a call-back.
See In-flight call-backs for more details about call-backs.
Other reasons transactions may be rejected
Optimize Evaluate is not the only way that a transaction can be rejected or blocked. It is worth bearing in mind that there are other reasons why a transaction may not be completed successfully, including but not limited to:
- Card declined by authoriser
- Simple installation level card or IP velocity rules
- Failure of system territory management rules (for gaming merchants)
- 3-D Secure requirements
- Transaction cancelled by In flight callbacks
Lists
Positive and Negative lists
When boarded you will be assigned 6 positive lists and 6 negative lists for the following data fields:
- Card number
- Email address
- IP Address
- Normalised Billing Address*
- Billing Postcode
- Telephone Number
* This uses the Advanced Payments normalisation standard of numeric digits from the first line of the address and postcode followed by the city name (in lower case and with non-alphanumeric characters removed).
The positive and negative lists can be edited and enabled individually via the merchant portal. If a data field from a transaction is matched on a negative lists then a rule with a NEGATIVE_LIST action will be returned and the transaction will be declined. If a data field from a transaction is matched on a positive then a rule with a POSITIVE_LIST action will be returned and the transaction will be accepted. Positive lists always take precedence over negative lists. Positive and negative lists are case sensitive, for example, ‘test@example.com is different from ‘Test@example.com’.
Custom Lists
Custom lists can be created for all available data types via the merchant portal. Once a list has been created it can be used in one or more rules via the List condition type.
It is worth noting that if a rule that uses a custom list is triggered, the API does not return any details of the list, it will only contain the details of the rule that uses the list. For this reason it is important to give your rules meaningful names.
