Method URL Test Case
Overview
This test case allows you to test your Method URL implementation to ensure it meets the following criteria:
6-8 digits of the BIN are sent in the DDC browser call.
The test case will impose an artificial delay of 7 seconds between the DDC Request and Response. The cmpi_lookup must be sent after the DDC Response is received.
If either of these two conditions are not met, the Method URL Test Case will fail. The cmpi_lookup will return a PAResStatus C and a Warning field to provide additional insight.
Table of Contents |
|---|
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.
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.
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:
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.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.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.
Test Case: Method URL Implementation Check | |
|---|---|
Scenario | This test case allows you to test your implementation of Device Data Collection (DDC) against simulated real-world conditions where a card issuer has a Method URL in place. To do so, this test implements two specific checks above and beyond the normal checks for correct formatting and the presence or absence of required fields. These two tests are:
These checks sit on top of the standard testing requirements, and a test case may still fail due to the absence or a required field, or a malformed or incorrect input. Failure of either of these two will result in PAResStatus |
Test Values | Visa PAN: 4000100000000000 |
Expected Results: cmpi_lookup Response | |
| Enrolled = <Enrolled>Y</Enrolled> |
PAResStatus = <PAResStatus>Y</PAResStatus> | |
CAVV = <CAVV Value> <Cavv>Y2FyZGluYWxjb21tZXJjZWF1dGg=</Cavv> | |
EciFlag = <ECI Value> Expected ECI Values grouped by Network:
| |
ErrorNo = ErrorDesc = (value will not be provided) | |
Warning: See Warnings section below. | |
Sample Lookup Request |
|---|
Sample Failure Response |
|---|
Sample Successful Response |
|---|
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:
Warning Error Message | Guidance |
|---|---|
| This is the first generic error message. It should appear as a part of most warnings, but can appear on its own when a generic failure occurs. If this error appears with no specific guidance, it may be due to a misconfiguration of the implementation. It may also correspond with a network failure, where one or more requests did not arrive at their intended endpoint. If a second test yields a similar failure, check that the DDC response was successful, and try re-running the lookup using the |
| This specific error message will occur when fewer than nine digits are passed for the BIN in a DDC request. A successful test case response requires anything from nine digits all the way up to the full PAN. In real world applications, shorter BINs may lead to identifying and running the wrong issuer’s 3DS Method. A nine or higher digit BIN represents the best practice recommendation from EMV Co., as well as the minimum required for success in this test case. |
or
| Both of these specific errors can occur when too little time elapses between the initiation of the DDC call and the cmpi_lookup request. The lookup request can occur as soon as the DDC response is received. In a real world scenario, this can take up to ten seconds. In this test case, an artificial delay has been put in place that causes the response to follow the request by seven seconds. If the lookup is made before this time, this error will occur. It’s important when designing the implementation to cue off either the DDC response or ten seconds total elapsed time, whichever comes first. |
| This is the second generic error message. It will only appear on its own with no specific error following it. This error can occur if no BIN was sent along with DDC, preventing Method URL from running. |