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
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
- Load the java script
- Initiate Profiling
- 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:
| string (required) — unique ID generated upon form view. |
| list (conditionally required) — a list of strings containing sensitive field IDs. |
| list (conditionally required) — a list of strings containing whitelisted field IDs. |
| list (optional) — a list of strings containing secret field IDs. |
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 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
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) CND Bedingung (condition) M Pflicht (mandatory) O optional C bedingt (conditional) Hinweis: Bitte beachten Sie, dass die Bezeichnungen der Parameter in Groß- oder Kleinbuchstaben zurückgegeben werden können.Definitionen
Datenformate
Format Beschreibung Abkürzungen
Abkürzung Beschreibung Kommentar Wenn ein Parameter Pflicht ist, dann muss er vorhanden sein Wenn ein Parameter optional ist, dann kann er vorhanden sein, ist aber nicht erforderlich Wenn ein Parameter bedingt ist, dann gibt es eine Bedingungsregel, die angibt, ob er Pflicht oder optional ist
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.
| Key | Format | CND | Description |
|---|---|---|---|
| attempt_reference | String maxlen 128 chars | R | Unique Id generated during invoking of profiling script |

