Remote Messaging

This section details the messaging requirements for connecting between ActiveAccess and an issuer's remote systems.

The ActiveAccess authentication system is responsible for managing the authentication of cardholders during American Express SafeKey, Diners Club International ProtectBuy, JCB J/Secure, Mastercard SecureCode / Identity Check and Verified by Visa / Visa Secure transactions. In order to support this requirement, the system must have access to appropriate information in order to uniquely determine the identity of the cardholder, whether a cardholder transaction requires authentication and what type of authentication is required. The determination of whether a cardholder is registered, whether a transaction requires authentication and what type of authentication is required for any particular transaction is currently performed by the ActiveAccess system. However, in order to delegate any of these duties to external issuer systems, some level of integration will be required.

In order to determine the correct 3-D Secure registration status, an issuer may be required to maintain the status of each of its cardholder's within the ActiveAccess system. Where this requires a significant investment in the development of maintenance procedures, an alternative may be to connect to determine the registration status of a cardholder by connecting with an issuer's systems. This procedure will remove the need to synchronise systems and ensure the maintenance of only one source of truth.

In a similar way, where an issuer is currently providing authentication services for its cardholders and wishes to re-use some of these services, it is possible to connect to the issuer's existing authentication system and leverage off their existing process for cardholder authentication. While the capability to perform second factor authentication is provided by ActiveAccess, this integration may be the issuer's preferred implementation model. This approach ensures a seamless user experience for the bank's customers across its banking channels.

The following sections explain the messaging requirements for connecting between ActiveAccess and an issuer's remote systems.

Message Format¶

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services for messaging between ActiveAccess and an external system. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

The Web Services Description Language is an XML-based language that is used for describing the functionality offered by a Web service. A WSDL description of a web service (also referred to as a WSDL file) provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. It thus serves a roughly similar purpose as a method signature in a programming language.

Support for generating client-side and server-side API code based on WSDL is provided in most languages.

For WSDL of the services discussed in this document, refer to Remote System Integration WSDL.

Request¶

During a 3-D Secure transaction, the first stage of the messaging is to determine the registration status of a cardholder. By integrating with the issuer's system, ActiveAccess can determine the cardholder's registration status and therefore determine whether a transaction requires authentication.

Having determined a transaction requires authentication, the second stage in the process is to perform an authentication and by integrating with the issuer's system, ActiveAccess is capable of reusing the issuer's infrastructure to determine the authentication result. At the end of the process, the ActiveAccess system responds to the MPI with the authentication result in accordance with the 3-D Secure protocol.

The purpose of remote system integration is to:

• Determine the registration status of a cardholder

  and/or

• Initiate and verify the cardholder authentication.

The types of messages sent by ActiveAccess are:

• VerifyRegistration: determine the registration status of a cardholder

• InitAuthentication: initiate the cardholder authentication process

• VerifyAuthentication: verify the authentication result

• PreAuthentication: determine the action for exemption

• VerifyIdentity: verify the identification results

• Register: register the card

• ResetPassword: initiate the reset password process

• Ping: determine the status of the service.

CAAS Services¶

Table 1 - CAAS Services¶

Verify Registration¶

The Verify Registration request is used to determine the registration status of a cardholder, within the remote system. Where a cardholder cannot be uniquely identified, such as the case where primary and secondary exist, it may be necessary for the remote system to provide the registration status of all related cardholders. ActiveAccess will then determine the appropriate course of action based on the response and in line with the issuer's business requirements.

Once the cardholder has been uniquely identified and where authentication is required, ActiveAccess should commence the appropriate authentication process.

Verify Registration Request¶

Table 2 - VerifyRegReq¶

Table 3 - Card¶

Table 4 - Transaction¶

Transaction	Table 4
Attribute	Description	Usage	Sample Value
XID	The transaction ID as defined in the PAReq message	Optional. Up to 28 characters.	MDAwMDAwMDAwMDAwMDAwMDAxMDA=
PurchaseDate	The transaction purchase date and time as defined in the PAReq message	Optional. Up to 17 characters in XMLGregorianCalendar format.	20091023 06:11:00
PurchaseAmount	The transaction purchase amount as defined in the PAReq message	Optional. Up to 12 characters in decimal format.	12345
PurchaseCurrency	The 3-digit transaction currency value as defined in the PAReq message. Refer to Country and Currency Codes	Optional. Up to 3 digits.	840
PurchaseExponent	The minor units of currency specified in ISO 4217	Optional. 1 character in length.	2
PurchaseDesc	A description of the purchase as defined in the PAReq message	Optional. Up to 125 characters.	Blue Shirt
MerchantID	The merchant ID as defined in the PAReq message	Optional. Up to 24 characters.	123456789012345
AcqBIN	The acquirer BIN as defined in the PAReq message	Optional. Up to 11 characters.	412345
MerchantName	The merchant name as defined in the PAReq message	Optional. Up to 25 characters.	Test Merchant
MerchantURL	The fully qualified merchant URL as defined in the PAReq message	Optional. Up to 2048 characters.	http://www.testmerchant.com.au/
MerchantCountry	The 3-digit merchant country code as defined in the PAReq message. Refer to Country and Currency Codes	Optional. 3 digits in length.	036
CardExpiry	The 4-digit expiry date of the card as defined in the PAReq message, e.g. YYMM	Optional. 4 or 6 digits in length.	1012
CardholderIP	The IP address of the cardholder browser where available	Optional. 15 or 45 characters in IPv4 or IPv6 format.	192.168.0.157
CVD	Card Verification Data code is the 3 or 4-digit code found on the back of a payment card	Optional. 3 or 4 digits in length.	0320
issuerName	Name of Issuer/Bank to be displayed on OOB page	Optional. Up to 64 characters.	Any Bank
theeDSProtocolVersion	Version of 3DS protocol in x.x.x format	Optional. 5 characters in length.	2.1.0
acsTransId	Universally Unique transaction identifier assigned by the ACS to identify a single transaction.	Optional. 36 alphanumeric characters in length.	ee5de3bc-a1a3-4648-9c5f-350422146fe1
threeDSTransId	Universally Unique transaction identifier assigned by the 3DS Server to identify a single transaction.	Optional. 36 alphanumeric characters in length.	we5de3bc-a213-46lk-9cas-35456ed46fe1
dsTransId	Universally Unique transaction identifier assigned by the Directory Server to identify a single transaction.	Optional. 36 alphanumeric characters in length.	tg6de3bc-a213-4r3k-9c12-35456ed4edr43

Verify Registration Response¶

A response message should be sent back for each request. The response message should provide the result of the request message with details of appropriate response information or errors as appropriate. Where one card is found in the remote system, registration details for that card should be included in the response. Where multiple cards are found, the registration details for each of the cards should be included in the response.

Table 5 - VerifyRegResp¶

Table 6 - CardInfo¶

Table 7 - SIS¶

Table 8 - Data¶

Table 9 - Error¶

Pre Authentication¶

The ability to integrate ActiveAccess with an external risk engine has been established in the Pre Authentication process in which header data including cookie and HTTP header data in addition to potential extension information will be sent to CAAS for it to determine if authentication is required or exempt.

Pre Authentication¶

Table 10 - PreAuthReq¶

Table 11 - HeaderParams¶

ExtensionParams

The elements differ by different message extensions are difend in messages. Like for intance, American Express extension params differ from MasterCard extension params.

Table 12 - AdditionalParams¶

Pre Authentication Response¶

A response message should be sent back by the remote authentication system to decide on the continuation of the authentication process.

Table 13 - PreAuthResp¶

Initiate Authentication¶

The Initiate Authentication step is optional and depends upon the type of authentication device being used. Once the registration status of the cardholder has been determined, ActiveAccess may initiate the authentication process by sending a request to the issuer's remote system. This step may be used for the first, and subsequent, generate challenge requests.

This step will commonly be used to initiate out of band authentication such as SMS, Question and Answer, Challenge and Response and Email.

Initiate Authentication Request¶

Table 14 - InitAuthReq¶

Initiate Authentication Response¶

A response message should be sent back by the remote authentication system to indicate the status of sending an SMS or Email, or otherwise return AuthData for the authentication initiation.

Table 15 - InitAuthResp¶

Verify Authentication¶

Where the remote system determines that authentication is required and after an authentication has been initiated, the cardholder should be presented with an appropriate page. In many circumstances this page will request the cardholder to enter their authentication credential, such as password or one-time password. However, in some circumstances, the screen presented may ask the cardholder to press a button after having completed their out of band authentication.

When a cardholder enters their password, ActiveAccess will format the details of the authentication request and send it to the remote system for verification. The response provided will determine the authentication status of the transaction, with ActiveAccess formatting the 3-D Secure payer authentication response message to be returned to the merchant's MPI.

Verify Authentication Request¶

Table 16 - VerifyAuthReq¶

Verify Authentication Response¶

Table 17 - VerifyAuth¶

A response message should be sent back by the remote authentication system to indicate the success, or otherwise of the authentication verification.

Verify Identity¶

Verify Identity data is used in ADS or the Forgot password process to primarily verify the identity of the cardholder before changing/setting authentication data.

A request message should be sent to CAAS with the user identity data and to have CAAS verify the data.

Verify Identity Request¶

Table 18 – VerifyIdentityReq¶

Verify Identity Response¶

A response message should be sent back to ActiveAccess to inform whether user identity has been verified or not and to return the reason in case of identity failure. In addition, it returns failed identity items to be highlighted in the page. In the case of a successful response, it returns AuthData to be asked for a subsequent authentication process.

Table 19 - VerifyIdentityResp¶

Register¶

A request message should be sent to CAAS to set Authentication data for subsequent authentication.

Register Request¶

Table 20 – RegisterReq¶

Register Response¶

Table 21 – RegisterResp¶

Reset Password¶

Reset Password Request¶

A request message should be sent to CAAS for ResetPasswordData and have data set for further use.

Table 22 - ResetPasswordReq¶

Reset Password Response¶

A response message should be sent back to ActiveAccess to indicate the result of the reset password process in CAAS.

Table 23 – ResetPasswordResp¶

Ping¶

The ping request is used to determine the responsiveness and availability of the server. Simply send a ping request to the server to check if the service is up and operational or not.

Ping Request¶

Ping has no request parameter.

Ping Response¶

Ping has no response. Successful return of the operation invocation without any exception means the service is up and running.

Messaging Requirements¶

Securing Message Channel¶

Communication security must be ensured by using SSL with server and client authentication.

Critical Card Data Encryption and Decryption¶

The key, which is used for encrypting/decrypting the critical card data, must be a 112 or 168 bit DESede key. A KeyStore with the following details should be prepared for the encryption key that is to be uploaded, through MIA, for the specified issuer or group of issuers:

KeyStore type/format: JCEKS

KeyStore provider: SunJCE

Key algorithm: DESede

Key size: 112 or 168 bit

Key name: can be any

No of keys in the KeyStore: Only one key must be populated in the KeyStore

Such KeyStores can be easily created through the Java keytool utility using the following command:

keytool -genseckey -alias enckey168 -keypass 123456 -keyalg DESede -keysize 168 -keystore enc-key.JKS -storepass 123456 -storetype JCEKS

Calling Convention¶

Requests will be sent using SOAP on HTTPS.

Remote System Integration WSDL¶