Fraud Prevention

Iovation is a fraud prevention service which is already integrated with the Checkin.com Framework. Iovation delivers state of the art device tracking in order to ensure you can reject and capture fraudulent or non wanted devices based on customizable rules.

If the rule evaluation returns "3" (Deny) the module will display an error message towards the user. The user will then not be allowed to finalize the registration and no regilyDoneCallback will be emitted.

📘

You also get access directly to the Iovation back-office allowing full control of your rules and settings

What do you need to add to your standard Checkin.com integration?

No code-integration is needed to get started
If Iovation is enabled, the rules set up by you in the backend will be observed, and rejected devices cannot complete registration.

All you have to do is to set the Iovation flag before initiating your Checkin sign-up flow.

window.checkin.settings.enableFraudPrevention()

Connecting the userAccountID and device used for registration (optional)
For better tracking of multiple accounts per device, the created userAccountID (in your system) of the registered player can be connected to the device that was used for registration. This is done by resolving the final regilyDoneCallback with your newly created userAccountID.

Monitoring the result in the front end (optional)
If you want to log the result in a tracking tool, this can be done using the regilyUpdateCallback as in the example below.

Verify signature before saving user data (optional)
If you want to be sure that the collection has been done and the user has received a real rating, you can verify that the data has been signed by Checkin.com.

Connecting the userAccountID and device used for registration (optional)

AccountCode is the key used to identify accounts in the backoffice. When the device is evaluated before registration is saved it will be stored using the SessionID as accountCode, meaning that all new registrations have different ones.

To easier track which accounts in your system the device have been registered with the module can take your real stored userAccountId (or PlayerID) at the end of the registration flow and it will add the connection in the backend. This is done by resolving the createdUserAccountId in the regilyDoneCallback.

Here is a short example on how to resolve and connect a created userAccountID and store it to the backend as accountCode.

//Capture the callback and create user
Object.defineProperty(window, 'regilyDoneCallback', {
  value: function (data) {
    return new Promise(function (resolve, reject) {
      
      //Example function to your backend to create the user
      registerDataToBackend(data)
        .then( result => {
          //Store and resolve the userAccountId / playerId 
          const dataToResolve = { createdUserAccountId: result.playerId}
          resolve(dataToResolve);
        });
    });
  }
});

Monitoring the result in the front end (optional)

This is an example of the additional data structure, user.auth.signedData, which is added to regilyUpdateCallback and regilyDoneCallback.

//Additional returned data in updateCallback and doneCallback
const returnData =  { user: {
	auth: {
 		signedData = 'eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9.eyJ1bmlxdWVVVc3M2EtZjVjZC0zNW' 	
  	},
   // ... All other user data
  },
	// ... All other data
} }

Here is an example on how to decode the data from the JWT signing if you are using javascript. For more language examples, have a look at jwt.io.

import jwtDecode from 'jwt-decode'

Object.defineProperty(window, 'regilyUpdateCallback', {
  value: function(data, dataDiff) {
    return new Promise(function(resolve, reject) {
      if(dataDiff.user.auth){
        let params = jwtDecode(dataDiff.user.auth.signedData)
        //log to GA or do something with the data
        switch(params.result){
          case 1:
            //All is good.. registration will continue
          case 2:
            //User was flagged for "review" in backend... registration will continue
          case 3:
            //User was denied by rule, the regily module have stopped registration and shown an error message
        }
      }
      resolve()
    });
  }
});

Verify signature before saving user data (optional)

📘

Fraudulent users may post directly to your back endpoint

Fraudulent users skilled in coding may bypass your sign-up flow by directly posting to your registration back-end. To avoid this scenario it is recommended to verify the JWT token sent back by Checkin.com before saving the user data.

To verify that the rules have been evaluated, and that the token is valid, a check can be made before saving the data.

The public signing key is described in Public verification token.
This example is for javascript (node). For more language examples, have a look at jwt.io.

//The regily public key
const publicKey = fs.readFileSync(path.resolve('regily-public-key.pem'));
const jsonwebtoken = require('jsonwebtoken');

//This is an example name of your backend call
function recieveFrontendDataAndSaveToDatabase(regilyRegistrationData) {
  
  //Make sure the token is valid
  try {
    const verifiedData = jsonwebtoken.verify(regilyRegistrationData.signedData, publicKey);
  } catch (err) {    
    //EITHER:
    // Tag user for manual review in some system 
    
    // OR block:
    //Throw new NotAuthorizedError('Not passed rule check')
  }

  //Store and create user As normally ....
  // ...
  // createUserInDatabase(regilyRegistrationData)
}

🚧

Remember to include fault handling

Although unlikely, if Iovation is down, unreachable or unresponsive, the signed token will not be sent. In that case, you may want to "tag" users for manual review instead of blocking them fully.

Do you want to use our Iovation integration?

Reach out to [email protected] and we will enable this functionality for you.