3D Secure 2 Mobile SDK is a 3DS2 component enabling impeccable user experience on mobile devices during online shopping. It addresses the inability of 3DS1 to offer a unified UX for mobile purchases. It demanded multiple browsers working at once and switching between apps in order to process a single payment.
3DS2 SDK native integration with mobile apps (both Android and iOS) finally results in a seamless authentication flow embedded in your app. The cardholder is able to authenticate a purchase within your mobile app without having to maneuver between browsers and/or mobile banking apps. It is designed in a way that the authentication process looks and feels like it is a part of the mobile app. This approach helps reduce mobile payment fraud, as well as cart abandonment. This way, cardholders are not bothered with suspicious redirects, which were a part of the previous version of 3D Secure protocol.
It is no secret that the use of smartphones has changed the way we operate on a daily basis. And it is no wonder that smartphones have changed the way we shop as well. It is convenient, fast, and available 24/7. What more can a user ask for? The answer is security. With more consumers than ever before indulging in mobile payments, mobile payment fraud became a hot topic. 3D Secure 2 responded to the newly occurring threats by introducing a variety of secure authentication methods, including biometrics, as well as Risk Based Authentication, enabling frictionless online and mobile payments. By implementing 3DS2 SDK, you are protecting both your customers and your business, offering an excellent user experience and high security levels to match today's standards.
To put things in perspective, let's take a look at some of the Mobile Payment Stats for 2021 listed by Digital Product Trends.
These numbers are proof of the mobile payment industry's rapid growth and serve as a guideline for upcoming security trends. By implementing 3D Secure 2 SDK you are securing higher conversion rates, frictionless authentication flow, and most importantly, happy customers.
As previously mentioned, one of the main motivators for developing 3DS2 was bad user experience on mobile devices. With this problem out of the way, Mobile SDK brings a number of additional benefits to you and your customers. Heightened security measures granted through multiple authentication method choices and frictionless flow enabled by risk assessment are at the top of our list. Let's dig a little deeper see why we refer to Mobile SDK as a bundle of benefits.
The number one reason for high cart abandonment rates within 3DS1 was due to checkout issues caused by the unavoidable challenge request presented to the cardholder. 3D Secure 2 enables frictionless flow by implementing risk assessment, granting successful customer authentication without challenge requests; i.e. if the transaction risk is lower than the set threshold. In translation, Mobile SDK allows the cardholder to process their transaction without having to deal with additional authentication steps.
Mobile SDK participates in cardholder data collection enabling quality risk assessment, a pillar for frictionless authentication. SDK is able to gather richer data in comparison to the previous browser-based authentication. This data is used by Issuing banks for determining the risk level of a particular transaction with more accuracy. In the end, this eliminates unnecessary friction and impacts the approval rate positively.
Ultimately, cardholders won't be bothered with multiple browser screens and apps necessary to finalize a purchase. The authentication process is seamless and takes on the look of the app being used for online purchasing. This minimizes the risk of cardholders abandoning the site due to sketchy redirects and tedious authentication steps.
There is no more room for easy-to-forget passwords. Mobile SDK offers the cardholder to choose the wanted authentication method, biometrics included. Scanning a fingerprint provides more convenience and security, don't you agree?
3D Secure Mobile SDK supports two transaction flows, frictionless and challenge flow. In the case of a challenge flow, SDK communicates with ACS Server (Issuer side) and handles mutual authentication using standard TLS protocol.
If you want to find out more, contact our ASEE 3D Secure Team at [email protected] or download the datasheet.
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 get even messier when In-app purchase and mobile SDK are involved.
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 aligned 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 is generated by a proprietary authentication interface module that is adapted to the issuing bank.
Such test case is covered 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 was used, which sent sufficient data to pass the test. But the bank had its own customized authentication module containing text that they defined by themselves. This was not tested with mobile devices as a part of an internal regression testing on the test environment. The result? The issue was overlooked during the testing phase and was spotted only when it was already in production.
Another issue causing transactions to be rejected 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.
Need help with 3D Secure? Contact us at [email protected] to get a free, zero-obligation consultation or try our DEMO to see 3D Secure in action.
Account Takeover Fraud (ATO) is happening when a fraudster uses somebody else's credentials in order to gain unauthorized access to an account and uses it to their own advantage. The fraudster monetizes the account by either transferring funds, making unauthorized purchases, or selling the account data elsewhere. The main problem of this particular type of fraud is that the credentials used for taking over one account are usually used to access multiple other accounts and cause that much more damage. This makes it distinct from card-not-present fraud, where only one relationship is endangered. A more detailed overview of account takeover fraud is available in our recent blog post.
Account takeover fraud is an emerging type of attack targeting customer's accounts with valuable information such as saved credit card data, personal information, loyalty points, etc. In this way, the fraudster is able to monetize the account by either stealing the funds or the account data and reselling it on the dark web.
Account takeover fraud isextremely harmful to the business. Not only do they cause chargebacks and ruin their chargeback rates, but they have a detrimental effect on the company's reputation and customer loyalty.
Even though we are dealing with a type of fraud that is incredibly hard to detect, we gathered best practices regarding account takeover fraud detection. Watch out for these telltale signs of an ATO attack, and protect your business and your customers.
Users and companies who have account-based websites are the prime targets for fraudsters. A common puzzle piece of an account takeover fraud is phishing. For instance, the victim receives a legitimate-looking email containing a link leading to a familiar site that requires login. The unsuspecting victim enters their credentials, while the fraudster on the other side of the screen harvests their usernames and passwords. Regularly educate both your customers and staff regarding online security threats such as this one. Be proactive about security measures and implement best practices such as regular changes of user passwords and tips on how to protect user credentials.
Fraudsters are no strangers to contacting the call center of a company directly in order to get more information about sensitive data necessary for login. Train your staff to ask questions that are specific, i.e., questions that only a legitimate account holder could know the answers to.
When a fraudster takes over an account, their goal is to keep it. In order to do that, they need to change specific details necessary for the account recovery process, such as email or mobile phone number. If you notice multiple accounts having the same account details listed, e.g., mobile phone number, the chances of an account takeover fraud are pretty high.
By observing the account history, you are able to detect certain anomalies in customer behavior. If a user suddenly spends an amount larger than the usual or places a suspicious number of orders in a short period of time, investigate further and see if any of the account details have been recently changed. If yes, that might indicate account takeover fraud.
Another way of protecting your business and your customers is by implementing backend monitoring. Detect fraudulent activity regarding suspicious IP addresses and analyze timestamp data transfers. This enables you to identify whether a fraudster is trying to intercept any communication happening between the site form and the backend of the website.
Sometimes, fraudsters tend to be lazy and they don't mask their device data. They carelessly log in to multiple accounts, and the recorded activity shows the same device number, the fraudster's. Keep an eye on this one, but don't act too quickly because family members and work colleagues often share the same device. Look for more clues in order to make sure that you are witnessing legitimate account takeover fraud.
Staying on the same topic, there are also fraudsters who mask their device data by using device spoofing. Usually, if they implement device spoofing, the device details show up as ''unknown''. There is a pattern where the victim's accounts are usually connected to more ''unknown'' devices than legitimate ones where you are able to see the exact device model. Look out for this one!
Following a data breach, multiple user credentials are published/purchased on the dark web. That also means that fraudsters are trying to log in to the user account using that fresh information. Since they can't possibly know the exact location of each customer, they also can't match their IP address country to fit the profile. Observe accounts that have an unusually high number of IP address counties connected to them. It is a clear sign of account takeover fraud.
As mentioned earlier, a data breach results in a multitude of user credentials ending up on the dark web. When fraudsters get a hold of those credentials, they use credential stuffing in order to quickly check if any of the purchased usernames and passwords actually work. This is done through checking for both technical and behavioral tracking of bot activity.
We mentioned the necessity to track customer behavior, but if an attacker is behind the observed activity, we are talking about fraudster behavior. The (un)fortunate course of events is pretty predictable, and it is the following:
Upon taking over an account, fraudsters tend to leave the details untouched for some time. They gained access and will take care of the rest later. But if there is a notification sent to the user, alerting them about suspicious activity, fraudsters end up in panic mode. They rush to change details such as email and password in order to keep the stolen account. Track these changes triggered by a security alert. Password reset requests might soar.
Loyalty points are often overlooked by legitimate users and remain untouched. But one man's trash is another man's treasure. Fraudsters often target accounts solely because of loyalty programs. Stay alert and track if there is any sudden activity involving the use of loyalty points.
With Account takeover fraud, timing is crucial. It is extremely important to stop the attack in the earliest stage of the fraud lifecycle. By continuous monitoring of account history and customer behaviour, it is possible to detect anomalies and extract activities that do not match previous patterns. Mentioned best practices, accompanied by Strong Customer Authentication (SCA) and 3D Secure technology, promise the highest level of security.
Need help with 3D Secure? Contact us at [email protected] to get a free, zero-obligation consultation or try our DEMO to see 3D Secure in action.
EMVCo continues the 3D Secure strategy set with EMV3DS v2.0 – having a strong focus on adopting current trends in e-commerce and online payment, fast and smooth transactions, minimal friction and disturbance for the Payee, great User Experience, and ultimate level of transaction security.
Check out most notable 3DS v2.1 and 3DS v2.2 improvements in our recent blog post.
In 3DS v2.2 there were additional protocol improvements in this direction. These improvements include the following:
Both VISA and MC, have different 3DS 2.2 adoption roadmaps. As one of the main card schemes, VISA has defined a milestone for issuers and acquirers to adapt to EMV3DS 2.2; until the end of Q1 this year (2021). However, Mastercard has not set such a milestone; since MC has adopted some of the features from EMV3DS 2.2 through its MC 2.1+ extensions.
In addition, ASEE provided a comprehensive overview of the extended transition period. Learn more about the efficient management of the extended transition period in our recent blog post.
If you want to make a fast upgrade to EMV3DS 2.2, contact us at [email protected] to get a free, zero-obligation consultation; or try our DEMO to see 3D Secure in action.
