Product security and best practices
The 3D Secure 2 transaction authentication process involves transfer of PII information to the issuer and then authentication values back from the issuer to the merchant. Therefore, it is important that you review the security features and follow the recommended best practices on this page.
Security features in the 3DS Server and the Web SDK
All API requests and responses use one
threeDSServerTransIDfield value (unique to each session) during the transaction authentication life cycle. This unique ID is generated in response to the
/authenticaterequest, and it will remain the same until the transaction authentication is complete. If this field value is different at any stage, the server will return an error response. However, if you send a wrong ID in the
/authenticaterequest, the server ignores the wrong ID and returns a new ID that will be used until the transaction is complete.
If the 3DS Server/ Web SDK doesn't receive a response from any component within X minutes, it returns an error response with a 'session timeout' error message. Note that the timeout time differs for different scenarios and the state of the transaction. For example, the authentication token expires after about every 10 minutes. The integrator can request a new token to prevent a session timeout.
The 3DS Server/ Web SDK uses a device fingerprinting mechanism to collect extra information about the device (browser/client) from which the request has originated. The data is included as part of the
aReqsent to the Issuer, who uses it to validate the authenticity of the transaction. The device fingerprinting data elements include any browser-specific properties and native device-specific properties when using the mobile SDKs.
Elavon's 3DS Server is certified by EMVco and by following card brands for 3D Secure 2.1: Visa/Discover/Mastercard/Amex
All inbound and outbound communication from the 3DS Server and the SDKs (Web and Mobile) uses TLS v1.2. It is a mandatory requirement for all communication within the solution.
All inter-server communication and processing use an encrypted form of the cardholder PAN. The decryption of the PAN only occurs at the outbound step of sending the aReq to the network Directory Server.
Best practices recommended for merchants
You can authenticate to the 3DS Server using either the HTTP basic authentication method (Base-64 encoded username and password) over secure HTTP or using the OAuth 2.0 (token-based). Elavon suggests that if you are integrating directly with the 3DS Server, use the Basic Auth method. However, if you are using the Web SDK, use token-based authentication. For details on these two methods, see Authentication.
You must also treat the following values that you receive in the
/authenticateresponse as secure data:
As part of the 3D Secure 2 flow, the integrator/merchant should never collect any data from the cardholder that's required to satisfy the challenge request. The challenge happens directly between the cardholder and the issuer, and the 3DS Server/ SDKs will communicate the challenge result to the merchant. An example of one such request is the one-time passcode sent by the issuer for extra identification during the challenge result.
If you get an authentication-related error such as invalid or expired API Key, contact the Elavon support team. Note that you might need to give your MID and other details.
For both speed and security, ZIP and password-protect (with the Advanced Encryption Standard (AES) encryption option) any files that you will send to the Elavon support tea,.