WL SIPS DOCS

Release 24.5

go directly to content

Search by keywords

Overview

To search in the page use Ctrl+F on your keyboard

This page gives an onverview of the global functionning of the Business Score fraud solution.

All fraud management functions described in this documentation are administered in the Merchant Extranet.

You must have subscribed to the Business Score offer to be able to access these functions.

The Merchant Extranet is accessible through the following URL:

https://mex.fr.worldline.com/portal/home



Access is secure and requires a login and a password.

After login, click on the 'Fraud' tab to administer antifraud functions for your offer.

For more information please refer to the 'Configuring antifraud profiles with the Merchant Extranet' section.

Before you begin, it is absolutely essential you understand how fraudsters perform their attacks.

Fraudsters are very well organised and take advantage of most of the weaknesses in the security and legal aspects of e-commerce. In particular:

  • they operate internationally
  • they use honest locals to carry out their fraudulent activities
  • they hide behind overseas proxies
  • 3-D Secure is not an obstacle for them
  • they renew their types of attacks on a regular basis

Therefore, it is essential you understand fraudulent behaviours at the merchant level when implementing antifraud rules. It is also very important you monitor the results regularly and maintain the correct settings accordingly. This is usually achieved through the creation of a fraud management team on your side.

The fraud risk management engine uses antifraud profiles to evaluate transactions. These profiles consist of rules that you configure.

Antifraud rule management is a virtuous circle beginning with the creation of an effective antifraud profile that suits your business. It continues with regular reviews of fraudulent activities and regular fine-tuning of this profile.

Note: the existing fraud management extranet and reporting tools are designed so you can manage the antifraud solution independently.

An antifraud rule verifies one of the transaction's criteria. The criterion verified can be the card issuer country, cap collar amounts, card number, IP address, customer ID, etc. Rules are classified into categories: geolocation, velocity, list, basket and miscellaneous.

To be executed, rules must be configured in an antifraud profile. Please refer to the 'Antifraud profile definition' section to know how to define such a profile.

A positive rule aims to detect a favourable condition for the acceptance of the transaction (e.g. the customer ID is on the customer ID whitelist.).

If the condition is met, the rule returns a score that is higher than or equal to zero depending on the configuration of the rule. Otherwise, it does not return any score.

Currently, positive rules are based on the presence of an element of the transaction on whitelists, which are also called positive lists.

A negative rule aims to detect an unfavourable condition for the acceptance of the transaction (e.g. the customer ID is on the customer ID blacklist).

If the condition is met, the rule returns a score that is lower than or equal to zero depending on the configuration of the rule. Otherwise, it does not return any score.

There are five categories of negative rules:

  • geolocation rules
  • velocity rules
  • list rules
  • basket rules
  • miscellaneous rules

Some rules do not have necessarily a positive or negative nature (for example geolocation rules: you may want to favour some countries or unfavour others) whereas some others do have necessarily a positive nature (whitelists) or a negative nature (blacklists).

By default, the proposed rules are configurable in simple configuration mode, in which a rule is defined as being positive or negative.

Nevertheless, some rules have an advanced configuration mode. In this mode, the same rule can be both positive and negative. The rule will have a positive, negative or neutral influence on the result of the transaction check depending on the rule setting and the transaction context.

The choice to activate the advanced configuration mode is done during the rule configuration in the profile. It is possible to activate this mode only for certain rules and to let the simple configuration mode for the others.

Rule advanced settings allow specifying the criteria that will have a positive or negative influence on the result.

Example with the cap collar amount rule configured as decisive:

Rule configuration (profile) Transaction amount Result Consequences on pre-authentification mode
Simple configuration mode
  • Min = 50
  • Max = 200
45 Negative Trigger 3-D Secure
150 Neutral Proceed to the next rules
250 Negative Trigger 3-D Secure
Advanced configuration mode Positive range:
  • Min = 50
  • Max = 150

Negative range:

  • Min = 300
  • MAx = 400
45 Neutral Proceed to the next rules
100 Positive Trigger 3-D Secure
200 Neutral Proceed to the next rules
350 Negative Trigger 3-D Secure
450 Neutral Proceed to the next rules

Example with the 3-D Secure authentication rule configured as decisive:

Rule configuration (profile) 3-D Secure status of the transaction Result Consequences on pre-authorisation mode
Simple configuration mode Negative statuses:

ERROR

SUCCESS Neutral Proceed to the next rules
ERROR Negative Refuse the transaction before the authorisation request
Advanced configuration mode Negative statuses:

ERROR

Positive statuses:

SUCCESS

SUCCESS Positive Proceed to the authorisation request without doing the next rules
ERROR Negative Refuse the transaction before the authorisation request

There are two execution modes of the Worldline Sips antifraud tool:

  • pre-authorisation mode: allows stopping the fraudulent transaction before the authorisation request.
  • pre-authentication mode: allows bypassing 3-D Secure for transactions considered as safe.
Figure 1. execution of processes during a payment transaction


In pre-authorisation mode (default mode of the Worldline Sips fraud risk management tool), rules are executed prior to the authorisation request and following the 3-D Secure authentication (if the webshop is 3-D Secure enrolled). If the checking result is negative, the transaction will be declined prior to the authorisation request.

For means of payment with a redirection to a specific page for the related means of payment (Paypal for example), the pre-authorisation checking is trigerred prior to the redirection.

Depending on your needs, you define your pre-authorisation profile(s) by combining:

  • GO and/or NOGO rules
  • decisive and/or informational rules

A profile is informational when all of its rules are informational.

A profile is decisive when all of its rules are decisive.

A profile is mixed when it includes both informational and decisive rules.

Profile type Worldline Sips / merchant Consequences on acceptance
Informational profile Worldline Sips No consequences, Worldline Sips proceeds with the authorisation request.
Merchant The merchant must analyse the results of the rules and decide how the transaction should continue using the cancellation or validation operations.
Decisive profile Worldline Sips If the result is negative, Worldline Sips denies the transaction and no authorisation request is made.
If the result is positive or neutral, Worldline Sips carries on the acceptance process by making an authorisation request.
Merchant No consequences on the transaction acceptance since the merchant appointed Worldline Sips to make decisions with regard to fraud.
However, the merchant can analyse the reason.
Mixed profile Worldline Sips Ditto decisive profile.
Merchant If the transaction is declined, there are no consequences for the merchant.
If the transaction is accepted, the merchant must analyse the results of the informational rules and decide what to do next.

In pre-authentication mode, rules are executed prior to the 3-D Secure authentication. If the checking result is positive, the 3-D Secure authentication is bypassed and Worldline Sips carries on with the authorisation request.

This mode applies only to card transactions with 3-D Secure authentication.

Depending on your needs, you define your pre-authentication profile(s) by combining the GO and/or NOGO rules.

A profile is decisive when all of its rules are decisive.

Only decisive rules can be configured in a Go-No-Go profile for the pre-authentication step. Informative rules in such a profile are useless at this step.

Profile type Worldline Sips / merchant Consequences on acceptance
Decisive profile Worldline Sips If the result is positive, Worldline Sips bypasses the 3-D Secure authentication and carries on with pre-authorisation checking.
If the result is negative ou neutral, Worldline Sips carries on with 3-D Secure authentication prior to doing the pre-authorisation checking.
Merchant The merchant must analyse the results of the rules and decide how the transaction should continue using the cancellation or validation operations.
IMPORTANT: clarification on rules available in pre-authentication: since the 3-D Secure authentication bypass takes place only in case of a positive result, it is important to configure at least one GO rule as decisive so as to bypass the 3-D Secure authentication for some customers.
Attention:

risk of refusal in A1 code (soft decline) and no payment guarantee : it is not advisable to activate this mode because, within the framework of the DSP2, a 3-D Secure authentication is required, you risk seeing these transactions refused in A1 code (soft decline) or, if this is not the case, these transactions will not benefit from the payment guarantee.

An antifraud profile is a set of rules that you configure after choosing them from the rules made available by the distributor of the ePayment solution. Rules are executed prior to the 3-D Secure authentication and to the authorisation request according to your configuration (to understand the pre-authentication and pre-authorisation modes, please refer to the execution modes and their consequences on acceptance).

There are three types of antifraud profiles:

  • the distributor's "offering" profile
  • profile templates
  • merchant profiles

A distributor's "offering" profile is defined by the distributor and administered by Worldline. It defines the scope of the available rules and of the configurations that may be mandatory. If an webshop has no suitable profile for the means of payment used, then the distributor’s offering profile is used.

Profile templates are defined and administered by the distributor. They are used as templates for creating merchant profiles.

Merchant profiles are defined by you for your webshop and are administered by you and/or the distributor (depending on the distributor's choice). They can be created from profile templates. The terms "webshop profile" may be used in this document. They are equivalent to the merchant profile.

IMPORTANT: profile templates and merchant profiles are separated in pre-authentication and pre-authorisation. For example, a profile template in pre-authorisation cannot be used to create merchant profiles in pre-authentication. A merchant profile in pre-authentication cannot apply to the pre-authorisation step during payment.

Throughout this document, the notion of "profile" will refer to merchant profiles.

Antifraud profiles are set up through the fraud GUI of your extranet.

In most cases, you define a single antifraud profile that is applied to all transactions regardless of the means of payment used. However, you can also define additional profiles the settings of which suit one or more specific means of payment.

When a transaction must be evaluated, the risk management system first searches the webshop configuration for an antifraud profile specific to the means of payment used.

If no such profile is found, the system looks for the webshop default profile. This profile makes it possible to analyse the transactions that were not processed by the profiles specific to the means of payment.

To create a default profile, simply create a profile without associating any means of payment with it.

Attention: if no active profiles are available on the webshop, the distributor's offering profile will be used.

Only one profile can be active for a given means of payment. Likewise, only one default profile can be active.

For example, there can be:

  • a dedicated profile for CB, VISA and MASTERCARD
  • a dedicated profile for AMEX
  • a default profile that will check the transactions for which other means of payment are used.

Which means three active profiles at the same time.

You can create as many inactive profiles as required. This allows, for example, to keep profiles in reserve for particular periods of the year (sales, holidays, etc.).

Illustration of the weight of the settings:



When defining a profile, you must choose, activate and order the rules among those that are available in your offering.

When activating a rule, you must set its weight according to its importance:

  • the weight of positive rules ranges from 0 (neutral) to +3 (very important)
  • the weight of negative rules ranges from 0 (neutral) to -3 (very important).

If the condition of the rule is met, the score obtained is the weight that the merchant defined when they activated the rule in the profile. Otherwise, a score of 0 is obtained.

For example, a negative rule of average importance (-2) will produce a score of -2 if its condition is met.

The rules that you deem particularly important can be configured in decisive mode (see below).

If a rule is crucial for you, you can set it as decisive, which makes it possible to decide whether to accept the transaction or not while disregarding the other rules:

  • the weight of positive rules is +4
  • the weight of negative rules is -4

If the condition of the decisive rule is met, the result of antifraud checks is only determined by this rule, regardless of the results of the others. Otherwise, the result of antifraud checks is determined by the overall score.

IMPORTANT: you can set several rules as decisive. In this case, the favourable or unfavourable result of the first decisive rule prevails. Therefore, it is very important that decisive rules be ordered in decreasing order of importance.

In Business Score mode, each active rule of the profile evaluates an aspect of the transaction and can produce a score.

The rule scores are then added up to produce an overall score (please refer to the calculation of the overall score subsection to know how it is calculated). This overall score is then compared to the orange and green thresholds set in the profile so a decision can be made as to the continuation of the transaction.

The overall score is comprised between two limits:

  • the min bound, which is the value obtained if all negative rules and no positive rules are triggered (i.e. sum of negative rules' scores)
  • the max bound, which is the value obtained if all positive rules and no negative rules are triggered (i.e. sum of positive rules' scores)

Therefore, when you define the profile, you must define the orange and green thresholds between the min and max bounds, which will delimit 3 possible ranges for scores. Each of these ranges is associated with a colour: green, orange and red (please refer to the execution modes (pre-authentication & pre-authorisation) and their consequences on acceptance for further details about colours and their effects on transactions):

  • The orange threshold defines the limit between the orange area and red area. The value is included in the orange area.
  • The green threshold defines the limit between the orange area and green area. The value is included in the green area.

In the following example, orange threshold -8 is included in the orange area, and green threshold -4 is included in the green area.



If both the orange and green thresholds have the same value, then there is no orange area.

In the following example, the orange threshold and the green one both have the same score of -6. Score -6 is included in the green area.



Example: an antifraud profile contains 3 rules:

  • rule 1, negative rule, associated score -3
  • rule 2, negative, associated score -2
  • rule 3, positive rule, associated core +3

Therefore, you must set the orange and green thresholds between -5 (min bound) and +3 (max bound).

In this case:

  • the orange threshold is -2
  • the green threshold is +1
  • the red area is between score -5 (included) and -3 (included)
  • the orange area is between score -2 (included) and 0 (included)
  • the green area is between score +1 (included) and +3 (included)


When a transaction must be evaluated, the fraud risk management system first looks for the antifraud profile associated with the means of payment in the webshop configuration. If no such profile is found, the system uses the webshop's default profile.

The antifraud profile is executed before the authorisation request.

The profile's rules are executed simultaneously except for the rules set as decisive, which are executed in the order you defined. You can still disable or change the configuration of one or more rules for a given transaction.

You can bypass certain rules of the profile dynamically in the transaction request. For a list of directives to be used to bypass rules, please refer to the following section: 'Appendix disabling some rules in the profile dynamically'.

Attention: you cannot bypass the rules imposed by the distributor.
Note: The dynamic override is applicable to the active rules in both pre-authentication profiles and pre-authorisation profiles (to understand the pre-authentication and pre-authorisation modes, please refer to the following section: 'Execution modes and consequences on acceptance').

You can override some rules of the profiles dynamically in the transaction request.

The methods for overriding rules dynamically are described in the 'Descriptions and implementation of rules' section.

IMPORTANT: you cannot override the rules imposed by the distributor.
Note: dynamic overriding applies to the active rules inside pre-authentication and pre-authorisation profiles (please refer to the 'execution modes (pre-authentication & pre-authorisation) and consequences on acceptance' section to understand the pre-authentication and pre-authorisation modes).

The overall score is the sum of all rules' scores and determines the result of the antifraud checks.

For a given profile containing n individual checks:

  • let Rk be the result of the individual check indexed by k in the profile:
    • 0 if not checked
    • 1 if checked
  • let Pk be the weight associated with the individual check indexed by k:
    • 0 for neutral
    • 1 for low
    • 2 for medium
    • 3 for high
    • 4 for decisive
  • let Tk be the nature of the individual check indexed by k:
    • +1 when positive
    • -1 when negative

The overall score (S) of the transaction verified with this profile will be obtained through the following formula:



Note: the overall score is the mathematical sum of all rules including those set as decisive.

The final result of the antifraud checks of the Business Score offering is represented by one of five colours.

Three colours represent the result obtained from the overall score:

  • green: the overall score is higher than or equal to the profile's green threshold. The green result means that the transaction poses no risk.
  • orange: the overall score is higher than or equal to the profile's orange threshold, and lower than the green threshold. The orange result means that the transaction poses an average risk.
  • red: the overall score is lower than the profile's orange threshold. The red result means that the transaction poses a high risk.

Two colours represent a result that was obtained because a decisive rule was triggered:

  • white: the condition of a positive rule set as decisive is met; the rule produced a positive result. The white result means that the transaction poses no risk.
  • black: the condition of a negative rule set as decisive is met; the rule produced a negative result. The black result means that the transaction poses a high risk.
Note: order in which decisive rules are defined

If several decisive rules give positive and/or negative results, the first rule with the highest priority prevails. This means that the order in which decisive rules are defined in the profile is important.

IMPORTANT: the decision is made on the basis of the colour

It is important to understand that it is the colour which decides whether the transaction must be processed or not:

  • black or white: the decision is made without taking into account the overall score, which only has an informational value.
  • red, orange or green: the decision is made from the transaction’s overall score, which is compared to the set orange and green thresholds.

Therefore, the colour is not necessarily consistent with the overall score. It is thus possible to obtain a white result with an overall score that is lower than the orange threshold, or to obtain a black result with a score that is higher than the green threshold.

Example : profile set with 5 rules:

  • rule 1: customer ID whitelist set as decisive (weight: +4)
  • rule 2: card number blacklist set as decisive (weight: -4)
  • rule 3: IP address velocity (weight: -3)
  • rule 4: card issuer country (weight: -2)
  • rule 5: IP address country (weight: -2)

Orange threshold = 0, green threshold = +2

The CHALLENGE option enables you to put ORANGE transactions on hold (TO_CHALLENGE status) so you can assess the risk thereof before proceeding with the other steps of the acceptance process: validation, reauthorisation or capture.

If you do not have the CHALLENGE option, the transaction is accepted.

You have X days to assess the risk of fraud, and validate or refuse the transaction. X is the maximum value between the validity of the authorisation and the capture day (captureDay) you defined during the payment (please see the example below).

To assess the risk of the transaction, you can use the scoreInfo field, which contains the breakdown of the execution of the rules. This field is returned by Worldline Sips in the payment response (Sips Paypage, Sips Office).

You can use two transaction management operations:

  • acceptChallenge, to accept the transaction
  • refuseChallenge, to refuse the transaction (REFUSED status)

These two operations are available in the following interfaces:

  • Sips Office (please refer to the following documents: Sips Office SOAP, Sips Office JSON et Sips Office Batch)
  • Sips Office Extranet
  • Merchant Extranet

The main management rules of the challenge operations are as follows:

  • If the transaction is created in VALIDATION mode, the acceptance of the challenge can be combined with the validation of the transaction in a single step.
  • The life cycle of a transaction continues if the challenge is accepted (capture, refund, etc.).
  • The life cycle of a transaction ends if the challenge is refused (REFUSED status).
  • A transaction whose status is TO_CHALLENGE can be cancelled. If no operations are executed on the transaction within the allotted time, the transaction expires.
  • The management of the orange result only applies to CB, Visa, Mastercard and Amex transactions.

Below is the life cycle of a transaction with the management of the orange result.



Depending on when the challenge is accepted, on captureDay, on captureMode and on the maximum validity period of an authorisation, the day of the remittance varies.

A distinction is made between use cases in AUTHOR_CAPTURE mode and in VALIDATION mode.

AUTHOR_CAPTURE mode

  • Use case 1:
    • The captureDay is lower than the maximum period of validity of an authorisation.
    • The challenge is accepted before the end of the captureDay period.
    • The remittance is done as planned at the end of the captureDay period.

Example: captureDay at 3, authorisation period at 6. The challenge is accepted at D+2:



  • Use case 2:
    • The captureDay is lower than the maximum period of validity of an authorisation.
    • The challenge is accepted after the end of the captureDay period.
    • The remittance is done the evening of the acceptance of the challenge.

Example: captureDay at 3, authorisation period at 6. The challenge is accepted at D+4:



  • Use case 3:
    • The captureDay is higher than the maximum period of validity of an authorization.
    • The challenge is accepted after the end of the validity of the authorisation request.
    • A new request for authorization is made and the bank remittance is made in accordance with the captureDay.

Example: authorisation period at 6. Challenge is accepted at D+7, captureDay at 10:



VALIDATION mode

  • Use case 1:
    • The captureDay is lower than the maximum period of validity of an authorisation.
    • The challenge is accepted before the end of the captureDay period.
    • The validation is done after acceptance of the challenge and before or on the same day as the captureDay.
    • The bank remittance is done the evening of the validation.

Example: captureDay at 3, authorisation period at 6. The challenge is accepted at D+2, the validation at D+3:



  • Use case 2:
    • The captureDay is higher than the maximum period of validity of an authorisation.
    • The challenge is accepted before the end of the captureDay period.
    • The authorisation is executed during the validation operation.
    • The bank remittance is done the evening of the acceptance of the challenge.

Example: captureDay at 7, authorisation period at 6. The challenge is accepted at D+2, the validation at D+3:



Note: in validation mode, once the challenge has been accepted, you must validate your transaction before the end of the captureDay period, otherwise the transaction cannot be validated and therefore remitted to bank.

We advise you to do the validation at the same time as the acceptance of the challenge by populating the validationIndicator field in the acceptChallenge request with « Y ».

The result of the execution of the pre-authorisation profile is returned in the fields below:

  • scoreColor, rule results represented in the form of a colour
  • scoreValue, value of the overall score
  • scoreProfile, antifraud profile executed
  • preAuthorisationProfileValue, contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the checks were performed
  • scoreThreshold, thresholds set for this profile
  • scoreInfo, breakdown of the executed rules
  • preAuthorisationRuleResultList, a list of detailed results of each rule executed before the authorisation

Each object contained in the preAuthorisationRuleResultList field corresponds to a rule result and contains the following values:

  • ruleCode, the rule code. For rule codes, please refer to the list of rules.
  • ruleType, the rule type. For rule types, please refer to the list of rules.
  • ruleWeight, the rule weight defined in the profile:
    • 0: neutral
    • 1: low importance
    • 2: medium importance
    • 3: high importance
    • 4: decisive
  • ruleSetting, indicates the configuration type of the rule:
    • D: dynamic in the transaction
    • S: static in the merchant profile
    • I: static and imposed by the distributor offer
    • N: no configuration (when the rule cannot be configured)
  • ruleResultIndicator, the execution result of the rule:
    • N: negative result
    • P: positive result
    • O: neutral result
    • U: rule not executed due to an incomplete transaction (e.g. data not filled in)
    • X: rule not applicable to this kind of transaction
    • B: rule not executed because bypassed by the merchant
    • E: rule not executed due to a technical error
    • D: rule not executed due to a dynamic override error
  • ruleDetailedInfo, complementary information produced by the executed rule

Please refer to the 'Description and implementation of rules' section for detailed information about each rule.

You are returned these fields in the following interfaces:

  • automatic and manual responses from Sips Paypage
  • responses from Worldline Sips connectors (Checkout, CashManagement (duplication) and Diagnosis services)
  • the Merchant Extranet
  • the transactions report except the scoreInfo and preAuthorisationRuleResultList fields.
Field Description
Green / white result
responseCode Value set according to the authorisation response
acquirerResponseCode Value set according to the authorisation response
scoreColor WHITE/GREEN
scoreValue Value of the overall score
scoreProfile Name of the antifraud profile executed
preAuthorisationProfileValue Unique identifier of the antifraud profile executed
scoreThreshold Thresholds set for this profile
scoreInfo Value set according to the rules executed
transactionStatus Value set according to the authorisation response and capture mode
preAuthorisationRuleResultList A list of detailed result for each rule executed
Orange result
responseCode Value set according to the authorisation response
acquirerResponseCode Value set according to the authorisation response
scoreColor ORANGE
scoreValue Value of the overall score
scoreProfile Name of the antifraud profile executed
preAuthorisationProfileValue Unique identifier of the antifraud profile executed
scoreThreshold Thresholds set for this profile
scoreInfo Value set according to the rules executed
transactionStatus Value set according to the authorisation response and the merchant's challenge option
preAuthorisationRuleResultList A list of detailed result for each rule executed
Red / black result
responseCode Value set to 05
acquirerReponseCode Not specified
scoreColor BLACK/RED
scoreValue Value of the overall score
scoreProfile Name of the antifraud profile executed
preAuthorisationProfileValue Unique identifier of the antifraud profile executed
scoreThreshold Thresholds set for this profile
scoreInfo Value set according to the rules executed
TransactionStatus REFUSED
preAuthorisationRuleResultList A list of detailed result for each rule executed

The result of the execution of the pre-authentication profile is returned in the fields below:

  • preAuthenticationColor, rule results represented in the form of a colour
  • preAuthenticationValue, value of the overall score
  • preAuthenticationThreshold, thresholds set for this profile
  • preAuthenticationInfo, breakdown of the executed rules
  • preAuthenticationProfile, the name of the antifraud profile executed before the authentication
  • preAuthorisationProfileValue, contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the checks were performed.
  • preAuthenticationRuleResultList, a list of detailed result of each rule executed before the authentication.

Each object contained in the preAuthenticationRuleResultList field corresponds to a rule result and contains the same values as the preAuthorisationRuleResultList field in pre-authorisation mode. For the content, please refer to the pre-authorisation mode.

You are returned these fields in the following interfaces:

  • automatic and manual responses from Sips Paypage
  • response from the Sips Office connectors (services Checkout, CashManagement (duplication) et diagnosis services)
  • the Merchant Extranet
  • the transactions report except the preAuthenticationInfo and preAuthenticationRuleResultList fields.
Field Description
Green / white result
preAuthenticationColor WHITE/GREEN
preAuthenticationValue Value of the overall score
preAuthenticationThreshold Thresholds set for this profile
preAuthenticationInfo Breakdown of the rules executed
preAuthenticationProfile Name of the antifraud profile executed
preAuthenticationProfileValue Unique identifier of the antifraud profile executed
preAuthenticationRuleResultList A list of detailed result for each rule executed
Orange / red / black result
preAuthenticationColor BLACK/RED/ORANGE
preAuthenticationValue Value of the overall score
preAuthenticationThreshold Thresholds set for this profile
preAuthenticationInfo Breakdown of the rules executed
preAuthenticationProfile Name of the antifraud profile executed
preAuthenticationProfileValue Unique identifier of the antifraud profile executed
preAuthenticationRuleResultList A list of detailed result for each rule executed

The overall Worldline Sips offering supports many international means of payment such as Visa/Mastercard cards, the Paypal digital wallet, iDeal transfers, Sepa Direct Debits, etc.

The rules do not necessarily apply to all means of payment.

For single message** means of payment, means of payment, defining informational profiles is technically feasible, but the result of the check will have no consequences on the acceptance of the transaction.

To know if an antifraud rule is applicable to a means of payment, please refer to the following section: 'Correspondences between means of payment and antifraud rules'.

____________________

** “Single-message” refers to a means of payment for which the authorisation and capture are performed in a single step e.g. transfers with Ideal, Paybutton, or Paypal in immediate mode. Dual-message refers to a means of payment for which authorisation and capture are performed in two steps.

Antifraud profiles apply to transactions and cash management operations that result in a new transaction being created (duplication).

Thus, standard cash management operations that deal with existing transactions (validation, cancellation, refund, etc.) and credit holder transactions are not subject to antifraud checkings.

For payments in n instalments, only the first instalment is subject to antifraud checkings.

For some rules, data must be sent in the request. The latter will not be executed if the data is missing.

For example, for the customer ID velocity rule, the customer ID must be sent in the request. Otherwise the rule will not be executed.

The rules do not necessarily apply to both modes (pre-authentication et pre-authorisation).

For example the 3-D Secure authentication rule is not available in pre-authentication. Indeed, this rule is based on the 3-D Secure authentication result, but the pre-authentication antifraud profile is applied first. So this rule is of no use prior to authentication.

This site uses trackers to improve your experience, perform analysis and researches on your use of WL Sips documentation website.
You have several options:
Closing this banner you refuse the use of trackers on your device.

Configuration