Understand Cipher security system and its offerings.
Cipher is Zeta's mobile-first advanced Access Control Server (ACS) that offers seamless and secure payments with best-in-class success rates. Superior integration, risk-based authentication, and superior OTP experience guarantee increased customer stickiness and higher profits. Cipher also offers powerful APIs, advanced SDKs and innovative features like Swipe To Authenticate and Super PIN to provide an unparalleled payment experience. Cipher does not require or store any payment sensitive data, like Card PAN, Expiry, CVV to perform authentication. Cipher requires minimal data depending on the various modes of authentication you may want to enable. Contact Zeta for supported use-cases.
This article explains the various integration options and key offerings that Cipher provides.
Cipher offers REST APIs as well as mobile SDKs to provide a modern and secure payment experience for your customers. Each option offers a wide range of features and you can decide to use one or both, based on your business needs.
Cipher provides secure REST APIs that can be integrated into the Card Management System (CMS) or other such systems to trigger updates on Cipher. Supported use-cases include Card Addition, Card Update, and cardholder Profile Update. See Cipher RESTful APIs for more information.
Cipher provides mobile SDKs that can be integrated into your Android and iOS applications. The SDK supports JWT tokens to provide a seamless S ingle-Sign-On (SSO) experience between the mobile app and the embedded SDK screens. Certificates or initialization can be easily customized for any specific needs of your app. Supported use-cases include Authentication (SuperPIN, Swipe To Authenticate), cardholder Controls, Authentication Push Notifications, and Authentication History.
Cipher provides SFTP and REST API-based mechanisms to enroll cards. Usually, Cipher enrolls or registers a card when a CMS activates or generates a card. A CMS delivers such notifications in the following way:
- Using Cipher RESTful APIs, a CMS notifies the Cipher.
- Using Cipher SFTP, a CMS transforms and uploads the generated data files to secure Cipher server.
Cipher need not receive Card PAN or other payment sensitive details to support cardholder authentication in a 3DS transaction. Three-Domain Secure (3DS) is a messaging protocol developed by EMVCo to enable consumers to authenticate themselves with their card issuer when making cards not present (CNP) transactions .
Card and cardholder Profile Updates
From time to time the card and card-holder profile information may change. The relevant changes are expected to be notified to Cipher so that Cipher can use this information in authentication challenge mechanisms configured and to enable/disable cards for authentication. Such data may come from the CRM system or the CMS of the bank.
Cipher supports both real-time and batch interfaces. A capable source system can trigger real-time updates using the REST API provided by Cipher. A batch system may generate files of changes performed during a batch. Such files can be transformed and uploaded to the Cipher SFTP interface.
Cipher need not receive Card PAN or other payment sensitive details to support cardholder authentication in a 3DS transaction.
Authentication at Switch
The integration of Cipher authentication with Payment Switch requires no specific configuration. The Issuer can specify the secret key the switch uses to verify the authentication code generated by the 3DS system per each BIN configured on Cipher. Cipher generates authentication code based on this secret for all successfully authenticated transactions.
Cipher provides Android and iOS SDKs to provide device-based authentication mechanisms. These SDKs need to authenticate the user of the mobile application and link the cards associated with the logged-in user to the device. This process is accomplished by using various industry-standard mechanisms like JWT Tokens, Digital Certificates, and OAuth 2.0. Cipher SDKs support all of these mechanisms.
If the host mobile app requires a custom mode of exchanging the logged-in user information along with some reliable credentials, the SDKs can be customized to support such a mechanism. Irrespective of the mechanism used, it is necessary to associate the card to a unique identifier of the cardholder during the card enrollment phase and to receive that unique identifier in the SDK initialization and login phases.
- No labels