On This Page
REST 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
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.