Our Kount™ implementation is very simple to set up and to use. We’ve created an implementation that goes through PayCertify Fraud Portal in order to add reporting features, and make the fraud checks possible to happen on the browser (our implementation is 100% JavaScript) and block fraudulent transactions from happening without even touching your system’s back end or sending data to our gateway.

Our Kount implementation consists in three simple steps: linking a JavaScript library to your page, setting up couple data attributes and implementing a success and failure function to handle Kount™ Responses


To use PayCertify’s Kount™ you will need a Fraud Portal account and your PUBLIC API KEY, which can be requested to support or by navigating on your Fraud Portal Account to Settings > Integrations > Show.

With your PUBLIC API KEY in hands, you’ll be able to start using it.

Setting up the Rules

Kount™ has mechanisms to prevent fraud where you define statements that your business logic configures as fraud. These rules can be whenever a billing address isn’t in a specific country, or when a consumer has been doing transactions too fast, or whenever a consumer is known to be a fraudster, etc. Watch the videos below for a small overview of how Kount™ rules works.

In order to set up your Kount™ account, you mainly have two options:

  • Buy your own Kount MID
  • Operate under PayCertify’s MID

Most of our clients that want a higher level of customization / sophistication on rules set up end up with option #1, while merchants that just want to prevent common fraud pick #2. On both scenarios, you should be able to protect yourself against fraud. It’s mainly a choice of wether or not you need access to the Kount Portal to set up exclusive rules.

Setting up the Plugin

Once you have your Kount™ rules set, you should set up the plugin in your application. You should start by linking the following script into the end of the body tag on your checkout page or wherever the user is inputting credit card data:

<script type="text/javascript" src="https://js.paycertify.com/kount.js"></script>

After having the script linked into the page, you will need to add data-paycertify-kount data attribute to some inputs your checkout form so the javascript plugin will know which values to send for the fraud check:

Data Attribute Required? Description Type
name Yes Customer’s full name string
email Yes Customer’s email string
phone Yes Customer’s phone on E.164 format string
address Yes Customer’s full address string
city Yes Billing address city string
state Yes Billing address state string
country Yes Billing address country string
zip Yes Billing ZIP Code string
credit_card Yes Credit Card number string
amount Yes Transaction amount string

Below there’s an example HTML form with all the required data attributes to be sent over to the API:

<form action="" method="POST">
  <label for="name">Name</label><br/>
  <input value="John Doe" name="name" data-paycertify-kount="name"/><br/><br/>

  <label for="email">Email</label><br/>
  <input value="john@doe.com" name="email" data-paycertify-kount="email"/><br/><br/>

  <label for="phone">Phone</label><br/>
  <input value="+1 123 123-1234" name="phone" data-paycertify-kount="phone"/><br/><br/>

  <label for="address">Address</label><br/>
  <input value="123 One Street" name="address" data-paycertify-kount="address"/><br/><br/>

  <label for="city">City</label><br/>
  <input value="Campbell" name="city" data-paycertify-kount="city"/><br/><br/>

  <label for="state">State</label><br/>
  <input value="CA" name="state" data-paycertify-kount="state"/><br/><br/>

  <label for="country">Country</label><br/>
  <input value="US" name="country" data-paycertify-kount="country"/><br/><br/>

  <label for="zip">ZIP</label><br/>
  <input value="30123" name="zip" data-paycertify-kount="zip"/><br/><br/>

  <label for="cc">Credit card</label><br/>
  <input value="4111111111111111" data-paycertify-kount="credit_card"/><br/><br/>

  <input type="hidden" data-paycertify-kount="amount" value="1.00"/>

  <input type="submit"/><br/><br/>

And finally, at the bottom of the page, before closing body tag, after linking the script tag, instatiate a new PayCertify.Kount object with the following properties:

Property Required? Description Type
API_KEY Yes Your Fraud Portal Public API Key. string
mode Yes Can be production or test. This will determine to which Kount™ account you should be sending data to. string
merchantId Yes Your Kount™ Merchant ID. string
success Yes Function to be executed whenever the communication with the Fraud Portal API returns 200 function
failure Yes Function to be executed whenever the communication with the Fraud Portal API returns other HTTP statuses function

And here’s how you should instantiate the PayCertify.Kount object to make the plugin watch for the form submission event and do the fraud checks.

new PayCertify.Kount({
  mode: 'production',
  merchantId:  '691000',

  success: function(response, $form) {
    // gets here whenever it succeeds communicating with the API

  failure: function(response) {
    // If something goes wrong while posting to the API, e.g.: server issues,
    // wrong API token, any error bigger than HTTP 400.


Since both success and failure functions are complex and will determine how to prevent fraud or let the transaction pass, we have two sections below, outlining how to use those and all the possibilities that you have while using them.

Success Function

The success function is triggered whenever we get a HTTP 200 status from the Fraud Portal API. That does NOT means that the success function is called whenever you’re free to allow the form to be submitted. Below we’ll explain how the success function works and outline some possibilities.

This function receives two arguments: one of them being the response itself, which contains the Kount™ response data, which will help you on the decision-making process of wether let this transaction pass to the gateway or not, and the $form variable, which is the form that contains the data-paycertify-kount attributes.

The response argument contains the following properties:

Property Description
AUTO Auto-decision response code: A = Approve, D = Decline, R = Review, E = Escalate
OS Operating System
DSR Device screen resolution
UAS User agent string
BRND Brand of credit card used
DDFS Date device first seen
GEOX Persona related country with highest probability of fraud
KAPT Whether or not device data was collected by the Data Collector process
MERC Kount Merchant ID
MODE Specifies what mode type the RIS post is, Q, P, X, U, E
NETW Riskiest network type associated with persona within the last 14 days. A = Anonymous, H = High School, L = Library, N = Normal, O = Open Proxy, P = Prison, S = Satellite
ORDR Merchant’s Order Number
REGN Region associated to Device Location
SCOR Kount score
SESS Unique session ID
SITE Website identifier of where order originated
TRAN Kount transaction ID number
VELO Quantity of orders seen from persona within last 14 days.
VERS Specifies version of Kount, built into SDK, must be supplied by merchant if not using the SDK
VMAX Quantity of orders from persona within the most active 6 hour window in last 14 days.
CARDS Total number of credit cards associated to persona as seen by Kount
FLASH A flag to indicate if the device placing order has ’flash’ enabled or not
PROXY Was a proxy server detected with this order
EMAILS Total number of unique email addresses associated to persona as seen by Kount
IP_LAT Latitude of proxy IP address (Number, -90.1922)
IP_LON Longitude of proxy IP address (Number, 38.6312)
IP_ORG IP_ORG - Owner of IP address or address block (64, Organization Name)
REGION Region associated to GEOX Location
BROWSER Web browser
COOKIES A flag to indicate if the device placing order has ’cookies’ enabled or not
COUNTRY Two character ISO country code associated with the physical device
DEVICES Total number of unique devices associated to persona as seen by Kount
IP_CITY City of proxy IP address (255, Houston)
IP_IPAD IP address of proxy
PIP_LAT Latitude of pierced IP address (Number, -90.1922)
PIP_LON Longitude of pierced IP address (Number, 38.6312)
PIP_ORG Owner of pierced IP address or address block (64, Organization Name)
LANGUAGE The language the device owner has set in the device’s Control Panel
PIP_CITY City of pierced IP address (255, Houston)
PIP_IPAD Pierced IP address
PIP_COUNTRY Country of pierced IP address (US)
PIP_REGION State/Region of pierced IP address (255 character limit)
TIMEZONE The timezone the device owner has set in the device’s Control Panel. The value listed represents the number of minutes from Greenwich Meantime. Divide by 60 to get number of hours.
IP_REGION State/Region of proxy IP address (255 character limit)
LOCALTIME The local time the device owner has set in the device’s Control Panel
PC_REMOTE Is the device enabled to use PC Remote software
IP_COUNTRY Country of proxy IP address (US)
JAVASCRIPT A flag to indicate if the device placing order has ’javascript’ enabled or not
FINGERPRINT The unique fingerprint of the device placing the order
MOBILE_TYPE iPhone; Android; Blackberry; iPad, etc.
REASON_CODE Custom Reason Code associated with Rule Action
HTTP_COUNTRY User Home country the device owner has set in the device’s Control Panel
VOICE_DEVICE Is the device voice activated (related to mobile devices)
DEVICE_LAYERS 5 device layers representing the operating system, browser, javascript settings, cookie setting and flash settings. Device layers are used to create the device fingerprint.
MOBILE_DEVICE Is the device placing the order of a mobile nature (iPhone; Android; Blackberry; iPad, etc.)
MOBILE_FORWARDER If device is mobile, is it using a forwarder to process the carrier’s service
RULES_TRIGGERED Number of rules triggered by the RIS post
RULE_ID_X Rule ID associated with merchant created rules. X in this case will be a number ranging from 0 to any positive integer.
RULE_DESCRIPTION_X Rule descriptions associated with RULE_ID_X. X in this case will be a number ranging from 0 to any positive integer.


The simplest thing you can do for preventing fraud would be declining transactons that Kount recommends to decline. In order to do this, your success function could be simple as:

new PayCertify.Kount({
  mode: 'production',
  merchantId:  '691000',

  success: function(response, $form) {
    if (response.AUTO == 'D') {
      // redirect the user to another page?
      // window.location.href = 'http://my.webpage.com/somewhere'

      // maybe display an alert to the user saying that he should try with another card?
      // alert('Your card was rejected. Please try with another card number.').

      // Or which ever logic you'd like to put in place here.
    } else {
      // let the transaction be sent to the gateway

  failure: function(response) {
    console.log('failed: ', response);

You can also of course use which ever other variable you’d like, based on the RIS Response specified above. At this point, our Kount™ implementation is very flexible and you could create your own complex rule sets to prevent fraud based off your business constraints and internal logic.

Failure Function

The failure function is triggered whenever we get a response that isn’t successful while communicating to the Fraud Portal. You could create your own internal logic to, for example, hit a error notification system endpoint so your technical team is aware that something in regards to the communication is not working. Although, this function is used mostly for debugging purposes.

This function receives only one argument which is the response itself. Best way to inspect it is just logging it to the console and understanding what the issues are. Other than that, if you’re facing any issues while working with our Kount™ implementation, don’t hesitate to reach us at support@paycertify.com if you have any questions!