Created: October 10, 2011

Updated: Sep 25, 2020

What is Kount?

Kount delivers an all-in-one fraud and risk management solution for companies that have card-not-present environments looking to simplify their fraud/risk operations while dramatically improving bottom-line results. Kount provides a single, turnkey fraud solution that is easy-to-implement and easy-to-use. Kount’s proprietary technology has reviewed hundreds of millions of transactions and provides maximum protection for some of the world’s best-known brands.

For more information on Kount click here: https://www.kount.com/

For more information about this risk mitigation service provider, or to sign up for an account today, please contact our client success team at clientsuccess@sticky.io.

To configure Kount into your sticky.io Platform instance, you will go to Settings > Providers and under ACTIONS select Add New Provider Profile. Select the type = Risk Management and select Kount from the drop-down. Fill out the required parameters which are outlined below and click “Save”.

These parameters are briefly described here for your reference:

API Key: This is needed to send chargeback information to Kount and will need to be created in Kount’s web console. Please talk to your Client Success Manager for assistance in obtaining one.

Billing Type: Select the billing type for your profile. The fraud checks can be performed on initial transactions only or both initial and rebill transactions.

Chargeback Alert: Select if you would like to send an update to Kount for when a chargeback occurs within the Platform.

Is Test: Select if you would like to use Kount in test mode.

Merchant ID: This will be provided to you by Kount.

Send 0 Dollar Orders: Set to YES if you would like to send $0.00 orders to Kount

Site ID: This is an optional field for you to provide an 8 character or less description of your website if you currently have more than one website. Please contact your Kount representative before modifying the Site Id field.

Void/Refund Alert: Select if you would like to send an update to Kount for when a void / refund occurs within the Platform.

Alias: This is the name that you will assign to your risk mitigation provider. It is for internal purposes only; it helps you identify a specific provider account among several accounts in your Platform.

Provider Custom Fields: Map the custom fields that you have configured within Kount's web console to sticky.io. Kount supports all 90 UDFs offered in the sticky.io provider profile. The below screenshot shows the 4 custom fields configured for you during activation, plus UTM Source as an example. In order to configure the custom fields in Kount's web console, you will need to login to the AWC and go to the Fraud Control Tab --> "User Defined Fields" to add in UDFs. There you will make sure to create, label, and type match each UDF you wish to have configured in sticky.io and have passed to Kount.

After you have configured your Risk Management Provider account into your Platform, you will assign it at the campaign level. This means that it will not be automatically enabled on all your campaigns; instead, you will assign it to those campaigns that you choose to assign the risk mitigation protection to.

Additional Kount Configuration Notes

Orders that have passed the Kount fraud check will be sent to your payment gateway. Orders that have failed the Kount fraud check will not be sent to your payment gateway. The orders which have been flagged for review after the Kount fraud check will be sent to your payment gateway, and a note will be added to the order history within the Platform to indicate that the order is under review.IIf the order fails the fraud check after review, you can then manually mark the order as fraud from within the interface of the Platform. The IP address is suppressed on orders placed by Customer Service representatives on the Place Order page within the Platform so that Kount's fraud checks can be performed without IP concerns. 

Using Kount's Device Data Collector With A Campaign in sticky.io

Kount requires the implementation of its “Data Collector URL” JavaScript library on checkout pages. The Kount pixel has been deprecated and is no longer necessary. This should be added right before the ending <body> tag.

You will need to capture the sessionId that is created from the Device Data Collector script and pass it into the NewOrder requests using parameter sessionId. Without the sessionId parameter, Kount will not be able to match the transactions when the order is sent for risk assessment. Below is an example in the test environment. Please note the Device Data Collector URL is the code snippet seen below and you are responsible for inputting your unique merchant ID found within the Kount provider profile.

Be sure to add the parameters on the opening body tag (shown below):

<body class='kaxsdc' data-event='load'>
<script type='text/javascript'>
src='https://ssl.kaptcha.com/collect/sdk?m=<MERCHANT_ID>'>
</script>

<script>
var client = new ka.ClientSDK();

client.setupCallback({

    'collect-begin': function(params) {

        console.log('Kount Params', params);

        var checkoutForm = document.forms['payment_form'];

        var input = document.createElement('input');

        input.type = 'hidden';

        input.name = 'sessionId';

        input.value = params['MercSessId'];

        checkoutForm.appendChild(input);

    }

});

client.autoLoadEvents();
</script>

</body>

Optionally adding a Content Security Policy:

When adding the Content Security Policy to the header, be sure to add all domains that are included on your webpages in addition to the Kount URLs. For example, https://*.bootstrapcdn.com.

<meta
http-equiv=Content-Security-Policy"
content="img-src 'self' https://*.kpatcha.com https://*.bootstrapcdn.com script-src 'unsafe-inline' 'unsafe-eval' 'self' https://*.kaptcha.com
https://*.bootstrapcdn.com
child-src 'src' https://*.kaptcha.com https://*.bootstrapcdn.com
>

A Few Notes:

The example provided adds a hidden input field to your form labeled sessionId that can be posted in the NewOrder request. If you have a different implementation, you will have to make sure that the sessionId is still sent in the NewOrder request.

Did this answer your question?