Auto Enrollment Flow for Android

casan142saas
Typically, a payment card is valid for a fixed duration. This is denoted by the validity period printed on the card. At the end of this validity period, the bank issues a new card to replace the existing card. This replacement card has a new card number, validity period, and so on.
CA  Strong Authentication supports auto enrollment of replacement card accounts. This Auto Enrollment flow is a variant of the Activation Flow for Android. On the user's mobile, the Auto Enrollment flow takes place when the user uses the replacement card to perform a transaction.
The following topics provide information about the Auto Enrollment flow for a replacement card account:
For information about the APIs mentioned in these topics, see API Reference for Android.
The screenshots shown in these steps were taken on a reference app. Some of the screenshots from the Auto Enrollment flow on the reference app have not been included in this section.
The app UI and actual steps in the flow can vary depending on the flow that you design.
Prerequisites for the Auto Enrollment Flow
The enterprise Operations team or IT team must complete the following server-side steps before a replacement card can be activated on the user’s mobile. This is the
Enrollment on Server
stage.
  1. Upload an abridged record of the replacement card to CA Transaction Manager.
  2. Link the replacement card with other accounts of the user for which CA Strong Authentication has already been activated.
    On CA Identity Risk Insight Service, support for the Linked Accounts feature is a prerequisite for using the Auto Enrollment feature.
Steps in the Auto Enrollment Flow
The following steps take place when the user performs a transaction by using the replacement card. This is the
Activation on User's Mobile
stage.
  1. The user reaches the payment stage of a 3-D Secure purchase transaction.
  2. The CA Strong Authentication server sends push notification to the user.
  3. The user taps the push notification or opens the app on the mobile, the transaction details are displayed.
    Auto_Enroll_Transaction_Details_Android.png
  4. The user taps the YES button to show that she wants to proceed with the transaction.
  5. Suppose both PIN authentication and biometric authentication are enabled on the mobile. The user is prompted to select an authentication type.
    Auto_Enroll_Authentication_Select_Android.png
  6. The user selects biometric authentication and then responds to the authentication prompt.
    Auto_Enroll_Biometric_Auth_Android.png
  7. After the user successfully clears authentication, the card account is set up on the app. At the same time, a message stating that the transaction has been approved is displayed.
    Auto_Enroll_Transaction_Success_Android.png
  8. The user can see the newly set-up account by using the Display Accounts option. The user can now use this card account for authentication during 3-D Secure transactions.
    Auto_Enroll_New_Account_Android.png
Sequence Diagrams for the Auto Enrollment Flow
The following sequence diagram summarizes the API flows that take place between the app and SDK during the Auto Enrollment flow:
Auto_Enrollment_Stage_2.png
Auto Enrollment Flow Diagram
The following flow diagram shows the sequence of API calls that take place during the Auto Enrollment flow:
Auto Enrollment Flow - Android
Auto Enrollment Flow - Android
Sample Code for the Auto Enrollment Flow
The following is sample code for the Auto Enrollment flow:
//Sample code for TransactionScreen.java private void handleAuthentication(AuthenticationType selectedAuthType) { // Call the appropriate authentication API based on the selection // Verify PIN using biometric authentication if (selectedAuthType == AuthenticationType.BIOMETRIC_AUTH) { FingerPrintAuthenticator fingerPrintAuthenticator = new FingerPrintAuthenticator(TransactionScreen.this, TransactionScreen.this, transactionDetailsResponse); fingerPrintAuthenticator.authenticate(); } else if (selectedAuthType == AuthenticationType.USER_PIN_AUTH) { // If autoEnrollId is present, then set the following values before triggering the in PIN Activity. // ... String autoEnrollId = transactionDetailsResponse.getAutoEnrollId(); if (null != autoEnrollId && autoEnrollId.trim().length() > 0) { pinIntent.putExtra(AppConstants.AUTO_ENROLL_TXN, true); pinIntent.putExtra(AppConstants.AUTO_ENROLL_ID, autoEnrollId); } startActivity(pinIntent); } else { ... } }
//Sample code for PIN.java protected Boolean doInBackground(String...params) { AuthenticationHandler handler = new AuthenticationHandler(PIN.this); String action = params[0]; String userPin = params[1]; if (action.equals(AppConstants.SET_PIN)) { ...... } else if (action.equals(AppConstants.VERIFY_PIN)) { ...... } else if (action.equals(AppConstants.AUTO_ENROLL_TXN)) { String autoEnrollId = (String) extras.get(AppConstants.AUTO_ENROLL_ID); VerifyPinResponse verifyPinResponse = handler.verifyPin(userPin, TransactionScreen.transactionDetailsResponse, autoEnrollId); if (M3DSConstants.SUCCESS.equals(verifyPinResponse.getStatus())) { ... AutoEnrollmentResponse autoEnrollmentResponse = handler.autoEnrollAccount(displayName); if (M3DSConstants.SUCCESS.equals(autoEnrollmentResponse.getStatus())) { // TO DO App Developer: Display a Success message ... } else { // TO DO App Developer: Display a Failure message } } else { // TO DO App Developer: Handle failure condition if (null != verifyPinResponse && verifyPinResponse.getStatus().equals(M3DSConstants.FAILURE) && verifyPinResponse.getAttemptsAgain()) { // TO DO App Developer: Show incorrect PIN message } else { // TO DO App Developer: Display error message corresponding to the error code returned } } }... }