Using device data

Include the collected client device data via the top-level device_data parameter when creating a customer, payment method, or transaction.

Here's an example of passing device data with a transaction:

Ruby
result = gateway.transaction.sale(
  :amount => "1000.00",
  :payment_method_nonce => nonce_from_the_client,
  :options => {
    :submit_for_settlement => true
  },
  :device_data => params[:device_data]
)
This code snippet now uses gateway instance methods instead of class-level methods. Learn more.

And here's an example of passing device data with a payment method creation (thus triggering a verification request):

Ruby
result = gateway.payment_method.create(
  :customer_id => "131866",
  :payment_method_nonce => nonce_from_the_client,
  :options => {
    :verify_card => true
  },
  :device_data => params[:device_data]
)
This code snippet now uses gateway instance methods instead of class-level methods. Learn more.

When to pass device data

In general, we strongly recommend including device data on any event where:

We send both transactions and verification requests to Kount to ensure that you get the most comprehensive fraud protection possible, and Kount will be more accurate when you include device data.

This is especially important on verifications: verifying cards is the best way to stop fraudsters from getting into your Vault. Sending the verification to Kount with device data will ensure that preliminary fraud checks are being run in addition to normal AVS/CVV/risk threshold checks you may have enabled. This further augments the level of protection you have, as Kount is able to identify fraudulent patterns linked to a device sooner than if you only passed device data with transaction requests.

important

When you create PayPal transactions using our Vault flow, it's critical to include device data for a different reason – to reduce decline rates. See our PayPal guide for more details.

Excluding device data for certain payment method types

If your integration does not differentiate between payment method types when creating transactions with device data, that data will likely be sent to Kount by default. To block device data from being passed for specific payment method types, you can check the nonce type on the client side before creating the transaction and write your own logic to determine whether device data is appropriate. Alternatively, if you use Kount Custom, you can tailor your fraud rules in Kount to exclude certain payment method types.

Skipping Advanced Fraud Tools

If you do not want Kount to perform Advanced Fraud Tools checks on a specific transaction, pass options.skip_advanced_fraud_checking when creating the transaction via the API. This will prevent it from being sent to Kount for evaluation.

Customer email address

Passing a customer email is optional. If the customer does not provide an email, we recommend that you do not pass the parameter at all. However, if your system requires it, pass the dummy address noemail@kount.com.

If multiple orders are made using the same email address but different card numbers or devices, Kount—our fraud detection partner—will flag these orders, which can lead to a high decline rate. Using noemail@kount.com instead of your own dummy address (e.g. fakeemail@merchant.com) will prevent Kount from linking orders based on the email address and will reduce the likelihood of false positives. When you do not pass customer email, we will pass noemail@kount.com for you.

Response handling

We return the risk data on credit card verifications and on transactions with all compatible payment methods. The data includes the risk identifier, the device data captured flag, and the risk decision, which can provide further context on how a verification or transaction was scored by Kount.

Ruby
result.transaction.risk_data.id
#=> "1SG23YHM4BT5"
result.transaction.risk_data.decision
#=> "Decline"
result.transaction.risk_data.device_data_captured
#=> true

The possible values of the risk decision are Not Evaluated, Approve, Review, and Decline.

See also

Next Page: Testing and Go Live →