Merchants are being instructed to adopt 3DS, and use 3DS for SCA compliance, but for SCA compliant authentication, a 2nd factor (such as FIDO or behavioral biometrics) must be added to any existing device recognition solution (such as Threatmetrix-style device IDs or text verification).
Merchants are caught in an integration battleground where they may be required to integrate five (repeat… 5!) SDKs into their browser and mobile app experiences, specifically SDKs for 3DS, device recognition, behavioral biometrics, FIDO, and SRC. A merchant might even need to consider more SDKs for tokenization and QR Code payments! The result is bloated online storefronts that are difficult to manage and update.
Whatever the ultimate SDK count is, the problem is multiplied because a merchant must perform vastly different integrations for 3DS data exchanges with browser and mobile app transactions.
The industry is trying to resolve the issues of a poor user experience and complex integration, but the solutions come with their own problems:
- The next 3DS version 2.3 is expected to unify browser and app integrations and address the related problem of 3rd Party data blocking by browsers… but current EMV 3DS plans include doubling the number of certified SDKs from 4 to 8
- 3DS’s Delegated Authentication enabled merchants to engage Trusted Third Parties (TTPs) to score risk as part of the transaction, not as an interruption later… but the TTP interface and liability shift rules are vague
Unfortunately for the consumers and industry, often the merchant’s response is “analysis paralysis” … doing nothing!
Merchants require easy integration that enables frictionless consumer payment experiences for browser and app transactions that are compliant with 3DS and SCA.
The integration must include a migration path which embraces new standards and subsequent versions without causing unnecessary re-integrations.
To achieve these industry requirements, mSIGNIA has proposed a Client API (cAPI) and Universal SDK (uSDK) standard to groups like EMVCo 3DS, FIDO, and W3C. cAPI + uSDKs allow various web protocols to specify the client and user data I/O the protocols require, not to certify specific SDKs that performs these tasks. A cAPI standard abstracts the diversity and complexity of client capability from the related ‘cloud’ standards protocols.
Since all SDKs use the same system resources to gather data – iFrames, app permissions, etc. – the 5+ SDKs perform the same, fundamental services regardless of the client. A cAPI + uSDK standard can certify an SDK’s ability to:
- Extend a consistent interface and data experience by leveraging native device capabilities and augmenting functionality as required.
- Collect USER input including user interface actions, data input, and biometric capture.
- Collect DEVICE data typically used for authentication of the device
- Perform device functionality including network transfer, storage, digital ciphering, key generation, etc.
As the diagram to the right shows, a single uSDK integrated by a client provider (such as a merchant) could process data I/O requests for multiple standards (3DS, Delegated Authenticators, FIDO, Behavioral biometrics, W3C, SCA, Device IDs like Threatmetrix, SRC …).
As the diagram also shows, Trusted Third Parties (TTPs such as the Issuer, Delegated Authenticators, FIDO reliant parties, etc.) can interface with cAPI to request additional data and functionality from the same uSDKs. By pre-declaring risk data needs that satisfy SCA, etc., iFrame callouts and challenges become unnecessary except for extraordinary risk situations where only additional data (and friction) would yield a transaction approval.
As the diagram below shows, cAPI Instructions create a single, consistent, ‘frictionless flow’ data exchange process for both the merchant implementation and the TTP data collection; the same process is used for both browser and app-based transactions.
Merchants can also interface with cAPI to
- Transparently view and ultimately manage the availability and privacy compliance of cAPI data instructions TTPs are requesting of the merchant’s consumers
- Enable payment orchestration such as rules regarding the choice between credit and debit processing.
Read on for cAPI + uSDK benefits with Trusted Third Parties or explore more mSIGNIA differences here.