Product Security and Best Practices

On this page:

The 3D Secure 2 transaction authentication process involves the transfer of PII information to the issuer and then authentication values back from the issuer to the merchant. Therefore, you must 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 threeDSServerTransID field value (unique to each session) during the transaction authentication life cycle. This unique ID will be generated in response to the /lookup or the /authenticate request, 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 /authenticate request, 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 every 10 minutes approximately. 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 aReq sent 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 the following card brands:

    • 3D Secure 2.1: Visa, Discover, Mastercard, and American Express
    • 3D Secure 2.2: Visa, Discover, and Mastercard

  • 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 /authenticate response as secure data: threeDSServerTransID, authenticationValue, and eci.

    note

    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 an 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 team.

Related topics