Testing complex solutions built from several different software components has always been a challenge. It demands a deep understanding of the solution, its business and process flows, as well as the appropriate testing solutions.
3D Secure is an example of such a solution. The overall 3D Secure environment consists of at least four components (ACS, Directory server, 3DS server, Payment Gateway). This number amounts up to seven components if Authentication and Risk Scoring services are separate from the ACS. By introducing a core banking system integrated with ACS, the complexity of the solution becomes relatively high. Things can get even messier when In-app purchase and mobile SDK enter the conversation.
Luckily, 3D Secure software components need to be tested and approved by the 3DS protocol owner; i.e., EMVCo, but also by card schemes when deployed at the issuer and acquirer side. Still, even upon certification, after implementation and integration testing, it is common that certain issues occur.
From our experience, one of the main challenges when it comes to successfully testing the 3DS solution is covering all the possible scenarios to confirm the functionality of the solution. By introducing new features, the configuration needs to be in line with various protocols and regulations. Not to mention the specific client change requests that open more possibilities for errors. Additional issues occur by providing more flexibility in message and data formats. In the two examples below, we describe two problematic scenarios which you can face and where production issues occurred.
Problems might happen with rejected transactions identified after the solution has been deployed in production. In some cases, a missing element in the challenge response sent by the authentication service of a specific bank is identified. This message generates by a proprietary authentication interface module adapted to the issuing bank.
Such test case appears in the EMVCo certification regression testing. It is a part of the ACS2 upgrade to 3DS v2.2. The test passed the EMVCo certification, although each bank has the possibility to configure the text contained in the module. During the EMVCo certification testing, a dummy authentication module is in use, which sends sufficient data to pass the test. But the bank had its own customized authentication module containing text that they defined by themselves. This is not tested with mobile devices as a part of an internal regression testing on the test environment. The result? The issue is unnoticed during the testing phase and spotted only when it is already in production.
Another issue causing transaction rejection by issuing or acquiring domain (ACS or 3DSS) is due to the incorrect or unexpected values in the message flow.
3D Secure environment and stakeholders are aligning these days. Card schemes issue 3DS announcements and updates regularly. Newly introduced values that were not updated correctly or not supported at all on one domain might create unexpected behavior of the other domain. This is common for flows that do not pass through the card scheme directory server, such as the challenge flow.
In order to ensure such a robust solution for any of the domains (ACS, 3DS Server), the testing process should involve behavioral analysis in case of such unregulated boundary scenarios, as soon as the card scheme announces new fields.
Even proper adoption of newly introduced values might cause issues for non-robust 3DS solutions because other parties might introduce them prior to you.
3D Secure service providers continuously work with testing environments in order to conduct SW update testing, interoperability testing, testing new business processes, user experience flows, etc. For each of those cases, one or more components are changed in the configuration matter, or the SW upgrade matter and impact the overall process and the environment.
The best way of testing the 3DS environment includes independent testing of each 3DS component first. However, the end-to-end testing should be done prior to migrating the upgrade to production.
End-to-end testing poses a particular challenge as use cases and test cases exponentially rise with new and proprietary business processes. Such test cases should be defined in detail and configured in test tools, which also need to be upgraded in order to support certain test cases.
Banks or 3D Secure service providers usually use commercially available test tools for testing separate 3DS components. However, when it comes to end-to-end testing, they typically develop their own solutions and test environments. Having separate testing solutions in play requires additional (re)configuration when moving from single application testing to environment testing. This demands additional effort and opens new chances for error in (re)configuration.
When it comes to 3D Secure, that means that the test solution needs to be able to simulate other components aside from the device under testing. Let’s put it this way; when ACS is being tested, the test tool simulates both 3DS server, Directory server, and sometimes even Payment gateway. For end-to-end testing, simulators are replaced by configuring other 3DS components, URLs, and necessary keys, as well as other parameters. All of those parameters are stored in the so-called testing profiles for fast switching between testing modules.
In conclusion, test solutions should be easily applied for testing single 3DS components, as well as easily configured for environment testing, end-to-end testing, and UX testing. Such a solution will reduce costs in 3DS regular maintenance and upgrades, as well as minimize possibilities for errors.
As a dedicated guide for eCommerce app owners and merchants this eBook covers m-commerce security best practices and provides turnkey solution for in-app payments security.
To find out more about Trides2 portfolio, contact us or visit our blog section.
