{"_id":"5c6c238ff7d5480039535580","category":{"_id":"5c6c238ff7d5480039535563","version":"5c6c238ff7d54800395355a0","project":"57336fd5a6a9c40e00e13a0b","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-11-03T20:45:01.593Z","from_sync":false,"order":7,"slug":"topics","title":"Guides"},"project":"57336fd5a6a9c40e00e13a0b","user":"560d5913af97231900938124","parentDoc":null,"version":{"_id":"5c6c238ff7d54800395355a0","project":"57336fd5a6a9c40e00e13a0b","__v":1,"forked_from":"5beb278ac442ab0213f009cf","createdAt":"2018-04-23T14:36:48.535Z","releaseDate":"2018-04-23T14:36:48.535Z","categories":["5c6c238ff7d548003953555d","5c6c238ff7d548003953555e","5c6c238ff7d548003953555f","5c6c238ff7d5480039535560","5c6c238ff7d5480039535561","5c6c238ff7d5480039535562","5beb278ac442ab0213f00990","5c6c238ff7d5480039535563","5c3f542c12c4ac004bc51718","5c928dba4aa821001ae4f050"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"Main","version_clean":"8976.0.0-Basics","version":"8976-Basics"},"githubsync":"","__v":0,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-10-16T18:09:20.576Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":11,"body":"Failing to stop fraudulent transactions can lead to higher chargebacks and chargeback-related expenses, in addition to lost merchandise. BlueSnap has partnered with Kount to analyze customer data and purchase behavior on every transaction to identify and stop fraudulent orders.\n\nLearn more about:\n  * [Fraud Service levels](#section-service-levels)\n  * [AVS and CVV fraud rules](#section-avs-and-cvv-fraud-rules)\n  * [Device data checks](#section-device-data-checks)\n  * [Site IDs and user-defined fields](#section-site-ids-and-user-defined-fields)\n  * [Fraud errors](#section-fraud-errors)\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Fraud analysis is based only on the fields that BlueSnap receives. If you define a fraud rule based on a field that you don't pass to BlueSnap, then that fraud rule is ignored. For example, if you set a fraud rule that uses the billing address but you do not include the billing address on the checkout form, then this fraud rule is not applied.\\n\\nNote that there are some fields that may be optional for order processing, depending on your BlueSnap integration type. These include Shopper Email, Shipping Address, Billing Address, CVV, and device data. If you configure fraud rules using any of these optional fields, you should verify that you include these fields in the checkout form so that the data is passed to BlueSnap and your fraud rules work.\",\n  \"title\": \"BlueSnap runs fraud rules based on the data you pass to us\"\n}\n[/block]\n#Service levels\nBlueSnap offers three levels of enhanced fraud prevention services, which provide different capabilities and opportunities for customization. Below is a summary of each level. For more in-depth information about each one, see [Fraud prevention service levels](http://support.bluesnap.com/docs/fraud-prevention-services).\n \n * **Managed** — BlueSnap’s Managed fraud prevention service is enabled on your account by default. We use the most sophisticated fraud detection technology available to analyze every transaction for fraud indicators. Based on the results, we either accept or reject each transaction.\n\n * **Merchant-Configurable** — This service level is ideal for merchants that would like to customize thresholds for key fraud rules. This service is available to all merchants for a monthly fee. Contact [Merchant Support](https://bluesnap.zendesk.com/hc/en-us/requests/new?ticket_form_id=360000127087) or your account manager for more details. For setup information, see [Merchant Configurable service setup & reporting](http://support.bluesnap.com/docs/merchant-configurable-service).\n\n * **Enterprise** — This service level is designed for merchants that want to customize their fraud prevention strategy, from creating and maintaining fraud rules, to manually reviewing transactions. Merchants signed up for this service manage their entire fraud strategy directly in Kount’s Agent Web Console. If you are interested in the Enterprise fraud prevention service, contact us to discuss pricing and availability.\n\n<a class=\"btn btn-primary\" href=\"#\" role=\"button\">Back to Top</a>\n\n#AVS and CVV fraud rules\nAll merchants can use the Address Verification Service (AVS) and Card Verification Value (CVV) fraud tools at no additional cost. These rules apply to credit card and debit card transactions only, and do not apply to recurring payments.\n \n##How it works\nWhen you submit a transaction request for a credit or debit card, BlueSnap passes the address and CVV information as entered by the cardholder to the issuing bank. The bank’s response usually includes AVS and CVV response codes. These codes indicate whether the numeric values in the address and CVV match their records for that cardholder.\n\nMany banks approve transactions even if the address information or CVV included with the order does not match what they have on file for that cardholder. Banks approve these transactions because they often have the right to chargeback the purchase to the merchant if the transaction is later determined to be fraudulent; and this costs you money.\n\nAVS rules are particularly useful for merchants that ship physical merchandise. If the issuing bank’s response triggers one of your AVS or CVV rules, we send a void request to the issuing bank. Alternatively, if you choose not to enable AVS or CVV rules, BlueSnap does not take any action based on the response codes.\n\n##Setup\nFore information on setting up these rules, refer to [Enabling AVS and CVV rules](http://support.bluesnap.com/docs/setting-up-avs-and-cvv#section-enabling-avs-and-cvv-rules).\n\n<br />\n<a class=\"btn btn-primary\" href=\"#\" role=\"button\">Back to Top</a>\n\n#Device data checks\nSome of the most critical fraud prevention rules depend on information related to the shopper’s device. All merchants using our API must add the BlueSnap JavaScript iFrame to their checkout pages. This small change greatly improves BlueSnap’s ability to detect fraudulent transactions by gathering device-specific information.\n\nThe JavaScript collects information about the shopper’s device and passes it to BlueSnap. The information being collected includes:\n  * browser settings\n  * operating system and other software version numbers\n  * cookies\n  * cache IDs\n\n&nbsp;\nThis data is used to stop fraud by identifying when:\n * multiple people are using the same device\n * a shopper is trying to hide their identity\n * a known fraudster is submitting an order\n * a shopper’s account has been taken over by a fraudster\n\nAlternatively, device data can also identify trusted customers when they return to your website.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Note\",\n  \"body\": \"You must use BlueSnap's Kount Merchant ID (`700000`) and start the Data Collector **before**  starting the checkout process.\"\n}\n[/block]\n##Implementing device data collector###\n\nImplementing this is a quick three-step process:\n\n###Step 1: Create a Fraud Session ID\nThe Fraud Session ID lets BlueSnap link a shopper’s device data with order details for analysis. This identifier must be unique for at least 30 days and must be unique for every transaction submitted by each unique customer. If a single session ID is used on multiple transactions, those transactions link together and negatively impact the fraud analysis.\n\nThe Fraud Session ID may contain up to 32 characters. You can use the UUID if you remove the hyphens (otherwise it would be 36 characters), or you can create your own Session ID. The Fraud Session ID should contain alphanumeric characters only.\n\n###Step 2: Embed BlueSnap Data in your checkout page\n[block:callout]\n{\n  \"type\": \"danger\",\n  \"body\": \"In the following examples, the Session ID (`fbcc094208f54c0e974d56875c73af7a`) is a **sample** Session ID. You must use your own Fraud Session ID from Step 1. If the Fraud Session ID parameter is missing or invalid (longer than 32 characters), the `logo.htm` and `logo.gif` URLs return HTTP error `400 (Bad Input)`.\",\n  \"title\": \"Replace the sample Session ID\"\n}\n[/block]\nInsert the following HTML code into your **Production** environment's payment page:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<iframe width='1' height='1' frameborder='0' scrolling='no'\\n        src='https://www.bluesnap.com/servlet/logo.htms=fbcc094208f54c0e974d56875c73af7a'>\\n             <img width='1' height='1' \\n                  src='https://www.bluesnap.com/servlet/logo.gif?s=fbcc094208f54c0e974d56875c73af7a'>\\n</iframe>\",\n      \"language\": \"html\",\n      \"name\": \"Production\"\n    }\n  ]\n}\n[/block]\nWhen working in your **Sandbox **environment, you must change the `www.bluesnap.com` URLs to `sandbox.bluesnap.com` as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<iframe width='1' height='1' frameborder='0' scrolling='no'\\n        src='https://sandbox.bluesnap.com/servlet/logo.htm?s=fbcc094208f54c0e974d56875c73af7a'>\\n             <img width='1' height='1' \\n                  src='https://sandbox.bluesnap.com/servlet/logo.gif?s=fbcc094208f54c0e974d56875c73af7a'>\\n</iframe>\",\n      \"language\": \"html\",\n      \"name\": \"Sandbox\"\n    }\n  ]\n}\n[/block]\nIf you are using Kount Enterprise, the Device Data Collector iframe's `logo.htm` and `logo.gif` requires an additional parameter, `m={Kount merchant ID}`.  For example:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<iframe width='1' height='1' frameborder='0' scrolling='no'\\n        src='https://www.bluesnap.com/servlet/logo.htms=fbcc094208f54c0e974d56875c73af7a&m=700000''>\\n             <img width='1' height='1' \\n                  src='https://www.bluesnap.com/servlet/logo.gif?s=fbcc094208f54c0e974d56875c73af7a\\n        &m=700000'>\\n</iframe>\",\n      \"language\": \"html\",\n      \"name\": \"Kount Enterprise\"\n    }\n  ]\n}\n[/block]\n###Step 3: Add the Fraud Session ID to your API call\nYou also must pass your Fraud Session ID as part of your API call, as follows:\n\n * **Payment API** — In the Payment API, the Fraud Session ID should be passed in the `fraudSessionId` property within the [transactionFraudInfo](/v8976-JSON/docs/transaction-fraud-info) object. For example:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"    \\\"transactionFraudInfo\\\": {\\n        \\\"fraudSessionId\\\": fbcc094208f54c0e974d56875c73af7a\\n    }\",\n      \"language\": \"json\",\n      \"name\": \"fraudSessionId in the Payment API\"\n    }\n  ]\n}\n[/block]\n * **Extended Payment API** — In the Extended Payment API, the Fraud Session ID should be passed in the `fraud-session-id` property within the [fraud-info](/v8976-Extended/docs/fraud-info) resource. For example:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<fraud-info>\\n  <fraud-session-id>fbcc094208f54c0e974d56875c73af7a</fraud-session-id>\\n</fraud-info>\",\n      \"language\": \"xml\",\n      \"name\": \"fraud-session-id in the Extended Payment API\"\n    }\n  ]\n}\n[/block]\n##Implementing Kount's SDKs\n * **Kount's SDK for Android** integrates Kount's anti-fraud solution into your Android app. For more details, refer to [BlueSnap's GitHub documentation](https://github.com/bluesnap/bluesnap-android-int/tree/doc_changes#kount).\n\n* **Kount's SDK for iOS** integrates Kount's anti-fraud solution into your iOS app. For more details, refer to [BlueSnap's GitHub documentation](https://github.com/bluesnap/bluesnap-ios/tree/master#initializing-fraud-prevention).\n\n<a class=\"btn btn-primary\" href=\"#\" role=\"button\">Back to Top</a>\n\n#Site IDs and user-defined fields\nIf you are using the Enterprise level fraud prevention service, you can configure these additional fields directly in Kount and then include them in your API requests:\n  * [Site IDs](#section-site-ids)\n  * [User-defined fields (UDFs)](#section-user-defined-fields-udfs-)\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Note:\",\n  \"body\": \"Site IDs and UDFs must first be defined in the Kount console before sending them in the BlueSnap API request (any value sent to BlueSnap as a UDF or SITE ID **must **match a value that was previously created in the Kount console).\"\n}\n[/block]\n##Site IDs\nA Site ID (or Website ID) is a custom field used to classify orders for rule creation or for order review. \n\nFor example, you might notice that fraud patterns differ by geographic region. Site IDs allow you to define specific fraud rules for your U.K., U.S., and Canadian websites.\n\nTo manage Site IDs, go to **Fraud Control > Websites** in the Kount web console.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/NqB20VOMRiuvUYciMtNh_site-id-kount.png\",\n        \"site-id-kount.png\",\n        \"1346\",\n        \"382\",\n        \"#bc813a\",\n        \"\"\n      ],\n      \"sizing\": \"80\",\n      \"border\": true\n    }\n  ]\n}\n[/block]\nTo implement a Site, define the Site ID in the Kount web console. When you add a Site ID, you are be prompted to assign it a name and a brief description. \n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/3F9hoHLGQgWBvAEZxoXw_site-id-kount2.png\",\n        \"site-id-kount2.png\",\n        \"1365\",\n        \"522\",\n        \"#3e5176\",\n        \"\"\n      ],\n      \"sizing\": \"80\",\n      \"border\": true\n    }\n  ]\n}\n[/block]\nOnce you have defined the Site IDs in Kount, then you can pass this data in your BlueSnap API calls, in the `enterpriseSiteId` property within the [transactionFraudInfo](/v8976-JSON/docs/transaction-fraud-info) object in the Payment API or within the [fraud-info](/v8976-Extended/docs/fraud-info) resource in the Extended Payment API. The Enterprise Site ID passed to BlueSnap must exactly match an existing Site ID in Kount. Only one Site ID should be passed for each transaction.\n\n##User-defined fields (UDFs)\nUser-defined fields (UDFs) allow you to pass information related to an order or shopper that may not be a standard field in Kount. User-defined fields can be referenced when creating a fraud rule or simply made available for reference when reviewing suspicious orders.\n\nFor example, it might be helpful to pass an indication of the shopper’s membership in a premium rewards program.  \n\nTo manage Site IDs, go to **Fraud Control > User Defined Fields** in the Kount web console.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/D3cGvua2RSy8P7Rq5eun_site-id-kount.png\",\n        \"site-id-kount.png\",\n        \"1346\",\n        \"382\",\n        \"#bc813a\",\n        \"\"\n      ],\n      \"sizing\": \"80\",\n      \"border\": true\n    }\n  ]\n}\n[/block]\nTo implement a user-defined field, define the UDF in the Kount web console. When you add a UDF, you are prompted to assign it a label and a brief description. Each UDF must also be defined as either a number, alphanumeric, a date, or amount.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/Np2sxQU8Q3auhfpo698Z_udf-kount.png\",\n        \"udf-kount.png\",\n        \"110\",\n        \"159\",\n        \"#e5e6e9\",\n        \"\"\n      ],\n      \"sizing\": \"smart\",\n      \"border\": true\n    }\n  ]\n}\n[/block]\nFor example, if you want to set up a UDF for reward membership, you might configure the UDF as follows:\n\n  * **Label**: PremiumRewardsMember\n  * **Description**: Is a member of our premium rewards program\n  * **Type**: Alpha-Numeric \n\nIn the value, you could pass “Yes” to indicate a member and “No” to indicate a non-member.\n\nOnce you have defined the UDF in Kount, then you can pass this data in your BlueSnap API calls, in the `enterpriseUdfs` resource within the [transactionFraudInfo](/v8976-JSON/docs/transaction-fraud-info) resource in the Payment API or within the [fraud-info](/v8976-Extended/docs/fraud-info) resource in the Extended Payment API. The UDF name passed to BlueSnap must exactly match an existing UDF label.\n&nbsp;\n<a class=\"btn btn-primary\" href=\"#\" role=\"button\">Back to Top</a>\n\n#Fraud errors\nWhen a transaction triggers fraud rules, BlueSnap returns error 15011 FRAUD_DETECTED, with information about what type of fraud rule was triggered and why.\nFor more details, refer to [Payment API Fraud Errors](/v8976-JSON/docs/fraud-errors) **or** [Extended Payment API Fraud Errors](/v8976-Extended/docs/fraud-errors).\n&nbsp;\n<a class=\"btn btn-primary\" href=\"#\" role=\"button\">Back to Top</a>","excerpt":"Learn about the tools BlueSnap offers to help detect and prevent fraudulent orders.","slug":"fraud-prevention","type":"basic","title":"Fraud Prevention"}

Fraud Prevention

Learn about the tools BlueSnap offers to help detect and prevent fraudulent orders.

Failing to stop fraudulent transactions can lead to higher chargebacks and chargeback-related expenses, in addition to lost merchandise. BlueSnap has partnered with Kount to analyze customer data and purchase behavior on every transaction to identify and stop fraudulent orders.

Learn more about:

BlueSnap runs fraud rules based on the data you pass to us

Fraud analysis is based only on the fields that BlueSnap receives. If you define a fraud rule based on a field that you don't pass to BlueSnap, then that fraud rule is ignored. For example, if you set a fraud rule that uses the billing address but you do not include the billing address on the checkout form, then this fraud rule is not applied.

Note that there are some fields that may be optional for order processing, depending on your BlueSnap integration type. These include Shopper Email, Shipping Address, Billing Address, CVV, and device data. If you configure fraud rules using any of these optional fields, you should verify that you include these fields in the checkout form so that the data is passed to BlueSnap and your fraud rules work.

Service levels

BlueSnap offers three levels of enhanced fraud prevention services, which provide different capabilities and opportunities for customization. Below is a summary of each level. For more in-depth information about each one, see Fraud prevention service levels.

  • Managed — BlueSnap’s Managed fraud prevention service is enabled on your account by default. We use the most sophisticated fraud detection technology available to analyze every transaction for fraud indicators. Based on the results, we either accept or reject each transaction.

  • Merchant-Configurable — This service level is ideal for merchants that would like to customize thresholds for key fraud rules. This service is available to all merchants for a monthly fee. Contact Merchant Support or your account manager for more details. For setup information, see Merchant Configurable service setup & reporting.

  • Enterprise — This service level is designed for merchants that want to customize their fraud prevention strategy, from creating and maintaining fraud rules, to manually reviewing transactions. Merchants signed up for this service manage their entire fraud strategy directly in Kount’s Agent Web Console. If you are interested in the Enterprise fraud prevention service, contact us to discuss pricing and availability.

Back to Top

AVS and CVV fraud rules

All merchants can use the Address Verification Service (AVS) and Card Verification Value (CVV) fraud tools at no additional cost. These rules apply to credit card and debit card transactions only, and do not apply to recurring payments.

How it works

When you submit a transaction request for a credit or debit card, BlueSnap passes the address and CVV information as entered by the cardholder to the issuing bank. The bank’s response usually includes AVS and CVV response codes. These codes indicate whether the numeric values in the address and CVV match their records for that cardholder.

Many banks approve transactions even if the address information or CVV included with the order does not match what they have on file for that cardholder. Banks approve these transactions because they often have the right to chargeback the purchase to the merchant if the transaction is later determined to be fraudulent; and this costs you money.

AVS rules are particularly useful for merchants that ship physical merchandise. If the issuing bank’s response triggers one of your AVS or CVV rules, we send a void request to the issuing bank. Alternatively, if you choose not to enable AVS or CVV rules, BlueSnap does not take any action based on the response codes.

Setup

Fore information on setting up these rules, refer to Enabling AVS and CVV rules.



Back to Top

Device data checks

Some of the most critical fraud prevention rules depend on information related to the shopper’s device. All merchants using our API must add the BlueSnap JavaScript iFrame to their checkout pages. This small change greatly improves BlueSnap’s ability to detect fraudulent transactions by gathering device-specific information.

The JavaScript collects information about the shopper’s device and passes it to BlueSnap. The information being collected includes:

  • browser settings
  • operating system and other software version numbers
  • cookies
  • cache IDs

 
This data is used to stop fraud by identifying when:

  • multiple people are using the same device
  • a shopper is trying to hide their identity
  • a known fraudster is submitting an order
  • a shopper’s account has been taken over by a fraudster

Alternatively, device data can also identify trusted customers when they return to your website.

Note

You must use BlueSnap's Kount Merchant ID (700000) and start the Data Collector before starting the checkout process.

Implementing device data collector

Implementing this is a quick three-step process:

Step 1: Create a Fraud Session ID

The Fraud Session ID lets BlueSnap link a shopper’s device data with order details for analysis. This identifier must be unique for at least 30 days and must be unique for every transaction submitted by each unique customer. If a single session ID is used on multiple transactions, those transactions link together and negatively impact the fraud analysis.

The Fraud Session ID may contain up to 32 characters. You can use the UUID if you remove the hyphens (otherwise it would be 36 characters), or you can create your own Session ID. The Fraud Session ID should contain alphanumeric characters only.

Step 2: Embed BlueSnap Data in your checkout page

Replace the sample Session ID

In the following examples, the Session ID (fbcc094208f54c0e974d56875c73af7a) is a sample Session ID. You must use your own Fraud Session ID from Step 1. If the Fraud Session ID parameter is missing or invalid (longer than 32 characters), the logo.htm and logo.gif URLs return HTTP error 400 (Bad Input).

Insert the following HTML code into your Production environment's payment page:

<iframe width='1' height='1' frameborder='0' scrolling='no'
        src='https://www.bluesnap.com/servlet/logo.htms=fbcc094208f54c0e974d56875c73af7a'>
             <img width='1' height='1' 
                  src='https://www.bluesnap.com/servlet/logo.gif?s=fbcc094208f54c0e974d56875c73af7a'>
</iframe>

When working in your Sandbox environment, you must change the www.bluesnap.com URLs to sandbox.bluesnap.com as follows:

<iframe width='1' height='1' frameborder='0' scrolling='no'
        src='https://sandbox.bluesnap.com/servlet/logo.htm?s=fbcc094208f54c0e974d56875c73af7a'>
             <img width='1' height='1' 
                  src='https://sandbox.bluesnap.com/servlet/logo.gif?s=fbcc094208f54c0e974d56875c73af7a'>
</iframe>

If you are using Kount Enterprise, the Device Data Collector iframe's logo.htm and logo.gif requires an additional parameter, m={Kount merchant ID}. For example:

<iframe width='1' height='1' frameborder='0' scrolling='no'
        src='https://www.bluesnap.com/servlet/logo.htms=fbcc094208f54c0e974d56875c73af7a&m=700000''>
             <img width='1' height='1' 
                  src='https://www.bluesnap.com/servlet/logo.gif?s=fbcc094208f54c0e974d56875c73af7a
        &m=700000'>
</iframe>

Step 3: Add the Fraud Session ID to your API call

You also must pass your Fraud Session ID as part of your API call, as follows:

  • Payment API — In the Payment API, the Fraud Session ID should be passed in the fraudSessionId property within the transactionFraudInfo object. For example:
    "transactionFraudInfo": {
        "fraudSessionId": fbcc094208f54c0e974d56875c73af7a
    }
  • Extended Payment API — In the Extended Payment API, the Fraud Session ID should be passed in the fraud-session-id property within the fraud-info resource. For example:
<fraud-info>
  <fraud-session-id>fbcc094208f54c0e974d56875c73af7a</fraud-session-id>
</fraud-info>

Implementing Kount's SDKs

Back to Top

Site IDs and user-defined fields

If you are using the Enterprise level fraud prevention service, you can configure these additional fields directly in Kount and then include them in your API requests:

Note:

Site IDs and UDFs must first be defined in the Kount console before sending them in the BlueSnap API request (any value sent to BlueSnap as a UDF or SITE ID must match a value that was previously created in the Kount console).

Site IDs

A Site ID (or Website ID) is a custom field used to classify orders for rule creation or for order review.

For example, you might notice that fraud patterns differ by geographic region. Site IDs allow you to define specific fraud rules for your U.K., U.S., and Canadian websites.

To manage Site IDs, go to Fraud Control > Websites in the Kount web console.

To implement a Site, define the Site ID in the Kount web console. When you add a Site ID, you are be prompted to assign it a name and a brief description.

Once you have defined the Site IDs in Kount, then you can pass this data in your BlueSnap API calls, in the enterpriseSiteId property within the transactionFraudInfo object in the Payment API or within the fraud-info resource in the Extended Payment API. The Enterprise Site ID passed to BlueSnap must exactly match an existing Site ID in Kount. Only one Site ID should be passed for each transaction.

User-defined fields (UDFs)

User-defined fields (UDFs) allow you to pass information related to an order or shopper that may not be a standard field in Kount. User-defined fields can be referenced when creating a fraud rule or simply made available for reference when reviewing suspicious orders.

For example, it might be helpful to pass an indication of the shopper’s membership in a premium rewards program.

To manage Site IDs, go to Fraud Control > User Defined Fields in the Kount web console.

To implement a user-defined field, define the UDF in the Kount web console. When you add a UDF, you are prompted to assign it a label and a brief description. Each UDF must also be defined as either a number, alphanumeric, a date, or amount.

For example, if you want to set up a UDF for reward membership, you might configure the UDF as follows:

  • Label: PremiumRewardsMember
  • Description: Is a member of our premium rewards program
  • Type: Alpha-Numeric

In the value, you could pass “Yes” to indicate a member and “No” to indicate a non-member.

Once you have defined the UDF in Kount, then you can pass this data in your BlueSnap API calls, in the enterpriseUdfs resource within the transactionFraudInfo resource in the Payment API or within the fraud-info resource in the Extended Payment API. The UDF name passed to BlueSnap must exactly match an existing UDF label.
 
Back to Top

Fraud errors

When a transaction triggers fraud rules, BlueSnap returns error 15011 FRAUD_DETECTED, with information about what type of fraud rule was triggered and why.
For more details, refer to Payment API Fraud Errors or Extended Payment API Fraud Errors.
 
Back to Top