You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


About Computop AI Protect (Powered by Nethone)

Computop AI protect is a AI based fraud detection solution with Profiling and machine learning models to help lowering charge back rates and risk of fraud. The system works towards profiling the traffic on the site, detecting fraudulent behavior and providing business intelligence insight. It processes the data provided and it needs to be inquired in the right moment to assess the risk level of fraud or to provide insight in the moment of the inquiry


Logo


Info

With Computop AI protect fraud prevention solution screen every single user to stop all the risky ones without friction to the good ones. Passively and in real-time maximize the acceptance rate and reduce your fraud/chargeback ratio with the most accurate financial transaction fraud detection solutions.

TypeRisk Management


AI protect Solution

The solution work as two step process

  • Profiling solution - to collect user data
  • Inquiry - to provide recommendation on the transaction


This Fraud Screening/Check on transaction can be used for several payment methods, we focused on Credit Card, SEPA and Paypal transactions but it can be extended.

Recommendation result of the Fraud Screening from AI Protect is:

  • Accept – Transaction is considered non-fradulent
  • Reject – Transaction considered fradulent
  • Review - Transaction Rejected. Merchant has possibility to review the Inquiry in the Panel and make necessary changes to the rules if needed.

Implementation

Computop has implemented the AI Protect on our Hosted Payment Pages paymentpage.aspx, payssl.aspx and paysdd.aspx.

AI Protect (Profiling + Inquiry) HPP

The profiler module is implemented as the option to use a pre-authorization feature using our hosted payment page (payssl.aspx) or Payment forms paymentpage.aspx and paysdd.aspx .

The practical way is that before doing an authorization, we can use the data sent by the merchant in the request and do a fraud check before the authorization takes place.

The logic that can be used is:

  • if the fraud check status is accepted = Computop triggers the authorization
  • if the fraud check status is reject, the authorization never takes place, customer can use a different payment method

AI Protect (Profiling + Inquiry) server to server and Paypal

The profiler was implemented in order to be able to do fraud checks via server to server for Credit card, PayPal and EDD payment methods.

However the merchant need to implement profiling solution on their website.

Profiling Implementation

The following are the three steps of Profiling

  1. Load the java script
  2. Initiate Profiling
  3. Complete Profiling
JavaScript file

This JavaScript file contains profiling logic.  The static JavaScript file should be included on the website with URL of the form https://domain_name/s/merchant_id/script_name.js.

Note* : Profiling script is provided by Nethone during on-boarding.

Script Inclusion

The following code snippet needs to be included in the page where merchant wishes to have the profiling. Usually this is Payment Page.

<!-- javascript inserted at the bottom of body; merchant_id may be hardcoded or inserted by backend, crossorigin="use-credentials" property is mandatory-->
<script type="text/javascript" id="SCRIPT_TAG_ID" crossorigin="use-credentials" src="https://provided_name.nethone.io/s/${merchant_id}/dNfsXe.js" async></script>
Script initializing function

Script initializing function (dftp.init) must be executed  to gather user’s browser data. It should be called when the form has loaded. Function requires one argument, called options which is a JavaScript object with multiple properties.

Possible properties are:

attemptReference

string (required) — unique ID generated upon form view.
It can not contain a prefix mznx-
maxlen 128 chars

sensitiveFields

list (conditionally required) — a list of strings containing sensitive field IDs.
Behavioral data gathered for these fields will be stripped of sensitive information.
Typically those would be the credit card number field (‘ccn’) and three-digit cvv field (‘cvv’)

allowedFields

list (conditionally required) — a list of strings containing whitelisted field IDs.
Full behavioral data will be gathered for these fields, without any information stripping.
Typically those would be e.g. name or address fields.

secretFields

list (optional) — a list of strings containing secret field IDs.
No behavioral data will be gathered for these fields.
Typically this would be the password field.

attemptReference parameter

attemptReference is used to match the inquiry performed to the data gathered about a user by the profiling script. It must be a unique value generated upon every form view. You should never reuse attemptReference. In case of Single Page Applications do not reinitialize the profiling solution.

Behavioral data parameters

Handling of behavioral data gathered by the profiling script is controlled by sensitiveFields, allowedFields and secretFields parameters. Passing sensitiveFields and allowedFields controls how behavioral data from fields that are not otherwise specified will be treated. The possible modes of handling not specified fields are standard and alternative.

Standard mode:

This is the recommended mode. In this mode fields not otherwise specified will have full behavioral data gathered. Passing only sensititiveFields enables this mode, secretFields can be additionally passed.

Sample usage:

dftp.init({
    attemptReference: '8b7115e0-49d2-438b-b88f-b265e44b156f',
    sensitiveFields: ['number', 'cvc']
});
// or
dftp.init({
    attemptReference: '8b7115e0-49d2-438b-b88f-b265e44b156f',
    sensitiveFields: ['number', 'cvc'],
    secretFields: ['password']
});


Extra Consideration

Behavioral data gathered by the profiling script is grouped by form field IDs. It is highly recommended that all form fields have HTML IDs that remain stable over time.

(warning) Warning sensitive/allowed/secret fields MUST HAVE HTML IDs.

If any of the following is true:

    • fields do not have IDs in HTML code

    • HTML class property is passed instead of IDs

    • HTML name property is passed instead of IDs

ALL sensitive/secret key events (for example containing card data) may be sent to profiler.


Profiling completion

In order to ensure that all necessary profiling data was collected, it’s recommended to use dftp.profileCompleted function. It returns a Promise object that is resolved when we have completed processing and it’s safe to do an inquiry.


Sample usage with modern JavaScript:
 
try {
    await dftp.profileCompleted();
} catch (err) {
    console.error("Profiling failed with err: " + err);
}
doWorkAfterProfiling();
 
 
Sample usage with Promises:
 
dftp.profileCompleted().catch(err => console.error("Profiling failed with err: " + err)).finally(doWorkAfterProfiling);
 
 
doWorkAfterProfiling can be a function used to submit form data and perform the inquiry


Profiling script & page lifecycle

The profiling script must be loaded and initialized only once per page lifecycle. You can check for presence of the dftp object to avoid loading the script again. If the user makes repeated transactions without reloading the page you should keep using the same attemptReference when making an inquiry.

Sample payment page template and profiling script implementation
<html>
<head>
</head>
 
<body>
    <!-- payment form -->
    <form id="payment-form">
        <label>
            Name:<br>
            <input type="text" name="name" id="name" class="form-element">
        </label>
        <br>
        <label>
            Credit card number:<br>
            <input type="text" name="ccn" id="ccn" class="form-element">
        </label>
        <br>
        <label>
            Expiration date:<br>
            <input type="text" name="expiration" id="expiration" class="form-element">
        </label>
        <br>
        <label>
            CVV:<br>
            <input type="text" name="cvv" id="cvv" class="form-element">
        </label>
    </form>
    <!-- payment form end-->
 
    <!-- button which is used for sending data, calls dftp.profileCompleted inside sendForm wrapper-->
    <button id="send" onclick="sendForm()">Pay</button>
 
    <script>
        function validateFormAndSend(){
            // isValid is the merchants function used for card data validation
            if (isValid()) {
                // merchant function used for sending data to server
                sentPaymentData();
            } else {
                // merchant function used for displaying card data errors on the form
                displayValidationErrors();
            }
        }
 
        // function for handling case when script from profiler URL cannot be loaded and dftp object does not exist
        function sendForm() {
            if (window.dftp){
                dftp.profileCompleted().catch(err => console.error("Profiling failed with err: " + err)).finally(validateFormAndSend);
            }
            else {
                validateFormAndSend();
            }
        }
    </script>
 
    <!-- javascript inserted at the bottom of body; merchant_id may be hardcoded or inserted by backend, crossorigin="use-credentials" property is mandatory-->
    <script type="text/javascript" id="SCRIPT_TAG_ID" crossorigin="use-credentials" src="https://provided_name.nethone.io/s/${merchant_id}/dNfsXe.js" async></script>
 
    <!-- javascript initializing profiling -->
    <script>
      var scriptID = "SCRIPT_TAG_ID";       // ID of <script> tag where our script is being loaded
      var options = {
          attemptReference: "${attempt_reference}",   // inserted by the backend
          sensitiveFields: ["ccn", "cvv"];            // list of sensitive fields
      };
 
      if (window.dftp) {
          dftp.init(options);
      } else {
          var el = document.getElementById(scriptID);
          el.addEventListener("load", function () {
              dftp.init(options);
          });
      }
    </script>
 
</body>
</html>


Support

This is fully depending on the type of payment used, at the moment we have this available for:

  • Credit Card
  • SEPA Direct Debit
  • PayPal



Sequence Diagrams

Pre-Auth using HPP




Paygate-Schnittstelle

Definitionen

Datenformate

FormatBeschreibung

a

alphabetisch

as

alphabetisch mit Sonderzeichen

n

numerisch

an

alphanumerisch

ans

alphanumerisch mit Sonderzeichen

ns

numerisch mit Sonderzeichen

bool

Bool’scher Ausdruck (true oder false)

3

feste Länge mit 3 Stellen/Zeichen

..3

variable Länge mit maximal 3 Stellen/Zeichen

enum

Aufzählung erlaubter Werte

dttm

ISODateTime (JJJJ-MM-TTThh:mm:ss)


Abkürzungen

AbkürzungBeschreibungKommentar

CND

Bedingung (condition)


M

Pflicht (mandatory)

Wenn ein Parameter Pflicht ist, dann muss er vorhanden sein

O

optional

Wenn ein Parameter optional ist, dann kann er vorhanden sein, ist aber nicht erforderlich

C

bedingt (conditional)

Wenn ein Parameter bedingt ist, dann gibt es eine Bedingungsregel, die angibt, ob er Pflicht oder optional ist


Hinweis: Bitte beachten Sie, dass die Bezeichnungen der Parameter in Groß- oder Kleinbuchstaben zurückgegeben werden können.


Aufruf der Schnittstelle

Authorization Request:

To carry out a AI protect check via a Server-to-Server connection, please refer respective Payment Method Payments by Credit Card, Payments by Direct Debit, PayPal, PayPal V2

 The parameter attempt_reference need to be included in addition to the respective parameters of each Payment type.

KeyFormatCNDDescription
attempt_referenceString
maxlen 128 chars
RUnique Id generated during invoking of profiling script




  • No labels