The Cardinal Virtual SDK is currently in Beta and is subject to changes within the codebase and documentation. Please reach out to your AE if there are any questions.
Below is a list of components that we will be discussing as we go through the Virtual SDK documentation.
Virtual SDK Client
The SDK Client will be implemented by the merchant directly within their application/device and can leverage conventional or proprietary languages. The Virtual SDK client will be responsible for assisting in the device data collection, render step-up challenge, and transport response.
Merchant SDK Server
The Merchant SDK Server will be used to communicate with Cardinal in aspects that include: device data, step-up challenge messaging, and other components.
Virtual SDK Server
The Virtual SDK server functionality is contained in the Cardinal Network. All interactions to the Virtual SDK server will be controlled using APIs with JSON/XML payloads.
The Virtual SDK server will provide the merchant various mechanisms for supplying device data to Cardinal, as well as completing the challenge and gathering required information needed to obtain the required values to complete authorization.
Cardinal Centinel
Centinel is a rules-based authentication solution that gives merchants the ability to create customized, adjustable rules, from hundreds of different enhanced data fields. This in addition to various other technologies that determine whether a transaction is being conducted by a legitimate consumer while utilizing the 3-D Secure protocols.
For the Virtual SDK, the merchant will be utilizing Centinel to communicate with the card networks on behalf of the merchants.
Next Steps
With an understanding of the components that we are touching, let's move on to Step 2: Device Data