WL SIPS DOCS

Release 23.3

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 Go-No-Go fraud solution.

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

You must have subscribed to the Go-No-Go or Go-No-Go+ Fraud risk management service to be able to access these functions.

The Merchant Extranet is accessible through the following URL:

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


image of the MEX login page

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 checks one of the transaction criteria. The controlled criterion can be, for example, the card issuer country, the amounts range, the card number, the IP address, the client id, etc. The rules are sorted by category: geolocation, velocity, velocity, list, basket ans miscellaneous.

For example, the criterion checked can be the card country, the cap collar amounts, the card number, the IP address, the customer ID, etc. The rules are sorted by category: geolocation, velocity, list, basket and miscellaneous.

There are two types of rules: GO-type rules (detecting a favourable condition for the continuation of the transaction) and NOGO-type rules (detecting an unfavourable condition for the transaction).

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

A GO-type rule aims to detect a favourable condition on the transaction, which results in a GO i.e. the transaction being accepted (e.g. the customer ID is on the customer ID whiteliste).

The rule returns a positive result if the condition is met and a neutral result otherwise.

For now, GO-type rules are based on the presence of a transaction element on whitelists, which are also called positive lists.

A NOGO-type rule aims to detect an unfavourable condition on the transaction, which results in a NOGO i.e. the transaction being refused (e.g. the customer ID is on the customer ID blacklist).

The rule returns a negative result if the condition is met an a neutral result otherwise.

There are 5 categories of NOGO-type rules:

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

Rules can be configured in decisive or informational mode.

A rule set as decisive has consequences on the execution of the transaction.

Decisive rules can produce 3 types of results that have consequences on the acceptance of the transaction:

  • Positive result

    A positive result indicates that the criterion checked is favourable for the acceptance of the transaction.

    Par example, if the customer ID is on the list of VIP customers ("customer ID whitelist" rule), there is no need to check other criteria.

  • Negative result

    A negative result indicates that the criterion verified is unfavourable for the acceptance of the transaction.

    For example, in pre-authorisation mode, the transaction is denied if the card in on the card greylist or blacklist.

  • Neutral result

    A neutral result indicates that the criterion checked is neither favourable nor unfavourable for the acceptance of the transaction.

    For example, the customer ID is not on the list of VIP customers ("customer ID whitelist" rule).

A rule set as informational has no consequences on the execution of the transaction. You are returned the result of the rule for analysis. For example, if the "IP address country" rule is set as informational, the rule simply returns the IP address country but will have no consequences on the acceptance of the transaction.

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 (GO) or negative (NOGO).

Nevertheless, some rules have an advanced configuration mode. In this mode, the same rule can be both positive (GO) and negative (NOGO). 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 for the Worldline Sips fraud risk management tool:

  • pre-authorisation mode: makes it possible to stop fraudulent transactions prior to the authorisation request
  • pre-authentication mode: makes it possible to bypass 3-D Secure for transactions considered as safe
Figure 1. processing progress during a payment transaction

image too complex to be described, please contact the  support

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.).

The rules are executed sequentially according to the order defined in the profile settings.

The first decisive rule that produces a positive result for GO rules or a negative result for NOGO rules prevents the execution of the rest of the decisive rules.

Informational rules are systematically executed.

Please refer to the 'Expression of rule results' section for the restitution of rule results in informational or decisive mode. The diagram below shows how rules are trigerred.

Figure 2. procedure for trigerring an antifraud profile

image too complex to be described, please contact the  support

You can bypass some rules of the profile dynamically in the transaction request. Please refer to the data cardProductProfil in the data dictionnary.

IMPORTANT: you cannot bypass the rules imposed by the distributor.
Note: dynamic bypass 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).

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 executing result of the pre-authorisation profile is returned in the complementaryCode, complementaryInfo, preAuthorisationProfile, preAuthorisationProfileValue and preAuthorisationRuleResultList fields:

  • complementaryCode contains the specific code of the decisive or informative rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive or informative rule returned a negatie or positive result, the field is set to 00.
  • complementaryInfo* contains 3 types of information:
    • the result of each rule (decisive or informative) executed in the merchant profile, in the following format: <RULE_RESULT XX=Y XX=Y … XX=Y />, where:
      Letter(s) Description Value
      XX Rule code For rule codes, please refer to the list of rules.
      Y Executing result N: negative result
      P: positive result
      O: neutral result
      U: rule not executed because of incomplete transaction data (i.e. data not specified).
      X: rule not applicable to this transaction type.
      B: rule not executed because you bypassed it
      E: rule not executed due to a technical error
      D: rule not executed due to a dynamic overriding error.
    • the complementary information produced by the executed rules. For detailed information, please refer to the 'Description and implementation of rules' section. Please note that only certain rules feed the complementaryInfo field.
    • the information on the payment card in use, if any. For detailed information, please refer to the 'Card information' section.
  • preAuthorisationProfile contains the name of the antifraud profile executed prior to the authorisation request.
  • 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 rules were executed.
  • preAuthorisationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.

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' section.
  • ruleType, the rule type. For the rule type of each rule please refer to the 'List of rules' section. If the advanced configuration mode is activated for a rule, the value of the ruleType field is set to "MI".
  • ruleWeight:
    • D: if the rule is configured as decisive in the profile
    • I: if the rule is configured as informative in the profile
  • ruleSetting, indicates the rule configuration type:
    • D: dynamic in the transaction
    • S: static in the merchant configuration
    • I: static and imposed by the distributor offer
    • N: no configuration (when the rule does not require any configuration),
  • ruleResultIndicator, the executing result of the rule:
    • N: negative result
    • P: positive result
    • O: neutral result
    • U: rule not executed because of incomplete transaction data (i.e. data not specified)
    • X: rule not applicable to this transaction type
    • B: rule not executed because you bypassed it
    • E: rule not executed due to a technical error
    • D: rule not executed due to a dynamic overriding 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 Sips Office connectors (Checkout, CashManagement (duplication) and Diagnostic services)
  • Extranet
  • Transactions report except the preAuthorisationRuleResultList field

Informative profile

Field Description
Neutral result
responseCode Value set depending on the authorisation response
acquirerResponseCode Value set depending on the authorisation response
complementaryCode Value set depending on the executed informative rules, otherwise 00**
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule

Decisive or mixed profile

Field Description
Neutral result
responseCode Value set depending on the authorisation response
acquirerResponseCode Value set depending on the authorisation response
complementaryCode Value set depending on the executed informative rules, otherwise 00*
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule
Positive result
responseCode Value set depending on the authorisation response
acquirerResponseCode Value set depending on the authorisation response
complementaryCode Value set depending on the GO rule that generated the acceptance
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule
Negative result
responseCode Value set to 05
acquirerResponseCode Not specified
complementaryCode Value set depending on the NOGO rule that generated the refusal
complementaryInfo* Value set depending on the executed rules
preAuthorisationProfile Name of the executed antifraud profile
preAuthorisationProfileValue Unique identifier of the executed profile
preAuthorisationRuleResultList List of detailed results for each executed rule

* The complementaryInfo field is deprecated as of version 17R1. It will no longer evolve and will eventually stop being populated. The information it contains is available in an improved version, in the preAuthorisationRuleResultList field.

** See the list of rules

The executing result of the pre-authentication profile is returned in the preAuthenticationProfileValue, preAuthenticationProfile, preAuthenticationProfileValue and preAuthenticationRuleResultList fields:

  • preAuthenticationValue specific code of the rule which returned a negative result (for NOGO type rules) or a positive result (for GO type rules). If no decisive rule returned a negative or positive result, the field is empty.
  • preAuthenticationProfile contains the name of the antifraud profile executed prior to authentication.
  • preAuthenticationProfileValue contains the unique identifier of the executed profile version. This information is useful to retrieve the profile in the same configuration as when the checkings were executed.
  • preAuthenticationRuleResultList contains a list of detailed results for each rule executed prior to the authorisation request.

Each object contained in the preAuthenticationRuleResultList field corresponds to a rule result and contains the same values as those in the preAuthorisationRuleResultList field in pre-authorisation mode. Please refer to the 'Pre-authorisation mode' section to know the content of this field.

You are returned these fields in the following interfaces:

  • automatic and manual responses from Sips Paypage
  • responses from Sips Office connectors (CashManagement (duplication) and Diagnostic)
  • Extranet
  • Transactions report except the preAuthorisationRuleResultList field
Field Description
Neutral result
preAuthenticationValue Value set to empty*
preAuthenticationProfile Name of the executed antifraud profile
preAuthenticationProfileValue Unique identifier of the executed profile
preAuthenticationRuleResultList List of detailed results for each executed rule
Positive result (3DS bypassed)
preAuthenticationValue Value set depending on the GO rule that generated the acceptance*
preAuthenticationProfile Name of the executed antifraud profile
preAuthenticationProfileValue Unique identifier of the executed profile
preAuthenticationRuleResultList List of detailed results for each executed rule
Negative result
preAuthenticationValue Value set depending on the NOGO rule that generated the refusal*
preAuthenticationProfile Name of the executed antifraud profile
preAuthenticationProfileValue Unique identifier of the executed profile
preAuthenticationRuleResultList List of detailed results for each executed rule

____________________

* See the various codes in the list of rules

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

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

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

Please refer to the 'Correspondences between means of payment and antifraud rules' section to know whether an antifraud rule applies to a means of payment or not.

** Single message means of payment: authorisation and capture are performed in a single step, e.g. transfers with Ideal, Sofort, Paybutton or Paypal in immediate mode. Dual message means of payment: 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.

In the case of a card payment, some card information is returned in the complementaryInfo field. The return information includes:

  • card issuer country
  • card scheme name
  • card issuer code and name
  • card product code and name
  • card product profile

information is returned in the following format: <CARD_INFOS BDOM=<card issuer name> COUNTRY=<card issuer country> PRODUCTCODE=<card product code> NETWORK=<card scheme name> BANKCODE=<card issuer code> PRODUCTNAME=<card product name> PRODUCTPROFILE=<card product profile>/>$

For the list of country codes, please refer to the data countryList in the data dictionary.

For the list of card schemes, please refer to the data cardScheme in the data dictionary.

For the list of product profiles, please refer to the data cardProductProfil in the data dictionary.

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