About Method URL

Method URL is a mechanism for the Issuing Bank (or its ACS provider) to collect rich data during the checkout process, prior to the authentication request.

Open

Device Data Collection facilitates the running of the 3DS Method in EMV® 3-D Secure (EMV 3DS). This additional device data gathered by the Method URL improves the overall authentication experience. It can help positively impact authentication success rates, increase the opportunity for frictionless authentication, and reduce customer abandonment.

Open

Per EMVCo specifications, it is mandatory for merchants to run Method URL if one is provided by the issuer. Because the Method URL process is rolled into DDC, successfully implementing DDC means accounting for Method URL. This article won’t go into the details of implementing DDC; for instructions on how to implement DDC, use the following articles:

• For Cardinal Cruise API implementation, see our Device Data Collection documentation.

Cardinal has several technical documents that provide you with best practices related to DDC to help you achieve the best possible results. It is highly recommended to contact your Cardinal representative for these materials.

Why Have a Method URL Test Case?

Device Data Collection (DDC) is one of the most important steps of an EMV 3DS integration. Failure to integrate this step correctly can have significant impact on authentication performance. To help troubleshoot and prevent implementation issues, we’ve created a test case that allows you to test DDC in conditions that closely replicate the production environment.

To ensure a successful test case result, it can help to keep in mind some important aspects and requirements of Method URL:

1. 3DS Method URL requires a BIN to be sent in the DDC call.
   Though DDC may be invoked without sending a BIN, the DDC call must contain a BIN for Method URL to proceed. Best practice is to begin the DDC call the moment the customer’s card number is received.

2. BINs should be specified using at least nine digits whenever possible.
   Issuer account ranges may have unique Method URLs that differ by the 7th, 8th, or 9th BIN digit. If you provide fewer than the first nine digits of the customer’s card number, you’re at risk of running the incorrect issuer Method URL, to avoid this issue Cardinal recommends using our Data Exchange API.

3. The cmpi_lookup call should proceed as soon as the DDC response is received.
   In practice, the DDC call may require up to 10 seconds to run when Method URL is present. The cmpi_lookup request should occur when the DDC response is received or 10 seconds has passed since initiating DDC (whichever occurs first). While it’s rare that Method URL takes the full 10 seconds, allowances need to be made for a delay in your integration.

Test Case: Method URL Implementation Check

The Method URL test case is designed to be integrated into a holistic testing flow. DDC will be run, followed by a lookup, a possible challenge, and then authentication. This test case differs from others in that it enforces input rules on the DDC stage, as well as timing rules between the DDC stage and the cmpi_lookup that follows. Because there are several ways to implement Device Data Collection, not all flows will be similar. This article won’t attempt to summarize the current methods of implementing DDC, as this test case works equally well with all of them.

What’s important to know here is that when properly invoked with a BIN, the DDC call will automatically trigger Cardinal’s 3DS server to run Method URL. The DDC response is the indication that Method URL has completed and the cmpi_lookup request can proceed.

Warnings

If your implementation does not adhere to the rules of the test, the test case will fail and the cmpi_lookup call will return a Warning field containing one or more error messages. We'll outline those error messages below, along with guidance on how to resolve each. All warnings will be a language-specific version of the following form: