Step 2: Device Data Collection

Device data collection starts on the merchant end after you receive the server-side Setup service response as described in Step 1: Setup Service and pass the access token and the device data collection URL to the front end. When device data gets to the data collection URL, a Method URL stipulated in the 3-D Secure protocal captures the entire card number to identify the issuing bank.
A hidden 10 x 10 pixel iframe is rendered in the browser, and using the access token, the merchant sends the customer device data to the device data collection URL. The device data collection can take up to 10 seconds. If you proceed with the check enrollment service as described in Step 3: Payer Authentication Check Enrollment Service before a response is received, the collection process is short-circuited and an error occurs. Despite the error, as long as you include the data from the eleven browser fields as explained in Step 3:Payer Authentication Check Enrollment Service, you can still proceed with the EMV authentication.
It is recommended that the device data collection start immediately after the merchant receives the customer card number to ensure that the data collection runs in the background while the customer continues with the checkout process, ensuring a minimum of waiting. When a customer changes to a different card number, begin the Setup and device data collection process again as soon as the new card number is entered.
Process Flow for Device Data Collection
Process Flow diagram for Device Data Collection

Best Practices

These practices should be followed for this step to achieve optimal performance and to minimize potential operating issues.
  • After the customer credit card number is entered, immediately begin the device data collection.
  • Device data collection must complete before beginning the enrollment check.
  • While not required, it is highly recommended to pass the values from the 11 browser-based fields in the request. The information from these fields serve as a backup, for when the device data collection does not complete correctly.
  • As much billing data as possible (unless restricted by regional mandates) should be supplied to the issuing bank to ensure that the issuer's risk assessment software has the most comprehensive data.
  • The billing data such as state and country must be formatted according to ISO 3166-2 format specifications to ensure that the network can properly validate the data.

Which Device Data is Collected

One of the key components to authenticating a cardholder during an online transaction is to compare information about the device that the buyer is currently using to information in the bank database about devices the buyer used in past transactions. This information is maintained in the acess control server (ACS) at the issuing bank. This device information focuses on the web browser and includes these types of data:
  • IP address
  • Browser language
  • Browser type
  • Bjava.io.PrintWriter@6cec873e rowser version
  • Computer operating system
  • System time zone
  • Screen dimensions
  • Color depth
A successful device data collection process that includes the 11 browser fields listed in the check enrollment step increases the chances of a frictionless authentication. Business rules evaluate whether a transaction is risky enough to require the buyer to authenticate their identity. These business rules are configured in the issuer's risk analysis software that evaluates each transaction.

Building the Iframe

The iframe has these parameters.
  • Form POST Action: The POST goes to the URL that is opened within an iframe. This URL is obtained from the
    consumerAuthenticationInformation.deviceDataCollectionUrl
    response field discussed in Step 1: Setup Service.
  • JWT POST Parameter: Use the value from the
    consumerAuthenticationInformation.accessToken
    response field discussed in Step 1: Setup Service.

Initiating the Device Data Collection Iframe

Initiate a form POST in a hidden 10 x 10 pixel iframe and send it to the device data collection URL (
consumerAuthenticationInformation.deviceDataCollectionUrl
).
Place the HTML anywhere inside the
element of the checkout page. Dynamically replace the value of the form action attribute and JWT POST parameter with the response values discussed in Step 1: Setup Service. See this example.
Initiate the Device Data Collection Iframe

Submitting the Device Data Collection Iframe

Add JavaScript to invoke the iframe form POST. Place the JavaScript after the closing
element as shown in this example. The JavaScript invokes the iframe form POST automatically when the window loads. You must submit it before requesting the Check Enrollment service.
JavaScript to Invoke the Iframe Form POST

Receiving the Device Data Collection URL Response

Receiving the response indicates that the device data collection URL completed its processing. The response is an event callback that contains a message with the status of the device data collection process.
Which
event.origin
URL that you use depends on whether you are in a test or production environment:
  • Test:
    https://centinelapistag.cardinalcommerce.com
  • Production:
    https://centinelapi.cardinalcommerce.com
Study the example below to understand how to subscribe to the event. Add JavaScript to receive the response from the device data collection iframe. Place the JavaScript after the closing
element.
Listen for Device Data Collection Response 
    
window.addEventListener("message", function(event) {
  if (event.origin === https://centinelapistag.cardinalcommerce.com) {
    console.log(event.data);
  }
}, false);
This example shows a response payload from the event. None of the returned data needs to be stored for future use.
Event Listener Callback Payload 
    
{
  "MessageType": "profile.completed",
  "Session Id": "f54ea591-51ac-48de-b908-eecf4ff6beff",
  "Status": true
}