This Device Data Collection page provides a set of options for our Customers to integrate one of these requirements for our Cardinal Cruise API integration. By choosing one of the Device Data Collection option, Cardinal is able to collect the 3DS 2.0 (EMV 3DS) required browser data elements in order to make the 3DS 2.0 request and invoke the 3DS Method URL if available. We will leverage this process to place the required Method URL on the merchant's site, within an iframe, if the Issuing Bank chooses to use one. (Per EMV 3DS requirements, a merchant must place and run the Method URL on their website if an Issuing Bank uses one).

The Method URL is a concept in the EMV 3DS protocol that allows the Issuing Bank to obtain additional browser information prior starting the authentication session to help facilitate risk-based authentication. The implementation techniques to obtain the additional browser information is out of scope of the EMV 3DS protocol. As a note, this same process was done in 3DS 1.0, however it was done when the Consumer's browser was redirected to the ACS URL, this Method URL step allow for a better user experience.

In an event where Method URL exists, Device Data Collection (DDC) may take up to 10 seconds to complete. In such cases, we recommend an interval of ~10 - 12 seconds between the DDC Request and cmpi_lookup request. If the merchant receives the DDC response before 10 seconds, the merchant may proceed with the cmpi_lookup request.

1 Endpoints
2 Prerequisites
3 Implementation Options
- 3.1 Option 1 - Data Exchange API plus JWT [Recommended]
- 3.2 Option 2 - JWT - Card BIN in JWT
4 Device Data Collection Response Options
- 4.1 Option 1 - Using a ReturnUrl
- 4.2 Option 2 - Using postMessage

Endpoints

Connection Endpoints for Staging and Production -

Version	Environment	Endpoint	Description

Version	Environment	Endpoint	Description
V2 (NEW)	Staging	https://centinelapistag.cardinalcommerce.com/V2/Cruise/Collect	Merchants integrating to the v2 endpoint will receive additional information regarding the Cardinal Data Collection and MethodUrl Collection.
V2 (NEW)	Production	https://centinelapi.cardinalcommerce.com/V2/Cruise/Collect
V1	Staging	https://centinelapistag.cardinalcommerce.com/V1/Cruise/Collect	N/A
V1	Production	https://centinelapi.cardinalcommerce.com/V1/Cruise/Collect	N/A

Prerequisites

To support Device Data Collection, you must complete one of these Options below

The Integrator must have access to the card BIN or full card number of cardholder
The Integrator must create an iframe on their website and post to the Device Data Collection URL

Implementation Options

Overview of each Device Data Collection option.

Option 1 - Data Exchange API plus JWT [Recommended]

This option allows the integrator to not pass the full Card Number in the JWT, but allows you to pass the full Card Number in an API Call to setup the Device Data Collection session and in response obtain a ReferenceId to pass up to the web frontend instead of the Card BIN. In addition to ReferenceId, you will receive additional data points for the given Card Number that can be leveraged during authentication.

Option 2 - JWT - Card BIN in JWT

This option allows the integrator to pass the Card BIN in the JWT

Device Data Collection Response Options

The merchant needs to handle the Response that they get from Device Data Collection Url.

This can be achieved by using either of the following options -

Option 1 - Using a ReturnUrl

Option 2 - Using postMessage

V2 Endpoint provides additional context related to Cardinal Data Collection and MethodUrl Collection when compared to the V1 Endpoint.
If a merchant is currently integrated to a V1 endpoint, they will need to change the way they handle Device Data Collection (/Collect) response.