Simple Order API

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.