What is 2-Step Authentication

2-Step Authentication is a generic solution offered by Worldline to provide various implantations of Strong Customer Authentication. Currently, supported authentication methods are 3-D Secure 1.0 and 3-D Secure 2.0.

What is 3-D Secure

The 3-D Secure authentication protocol is based on a three-domain model where the Acquirer Domain and Issuer Domain are connected by the Interoperability Domain for the purpose of authenticating a Cardholder during an electronic commerce (e-commerce) transaction or to provide identity verification and account confirmation. EMVCo specifies protocol and core functions of 3-D Secure 2.0. EMVCo is an organization overseen by American Express, Discover, JCB, MasterCard, UnionPay, and Visa.

Worldline clients who implement 3-D Secure benefit by reducing the chargeback risk of transactions and in most cases also shifts the liability for chargeback’s from themselves to the issuing banks.

3-D Secure 2.0 Frictionless

1. Cardholder checkout.
2. Merchant Initiate Authentication to determine whether cardholder authentication is necessary or not.
   • Authentication Status equal to SUCCESSFUL indicates that the authentication was successful and that the ThreeDSecureResult contains 3-D Secure data that shall be provided in the Initiate Payment request to be able to claim liability shift.
3. Merchant Initiate Payment.

3-D Secure 2.0 Frictionless with 3DS Method Data

1. Cardholder checkout.
2. Merchant Initiate Authentication to determine whether cardholder authentication is necessary or not.
3. Authentication Status equal to CONTINUE indicates that the TDSMethodContent of the Initiate Authentication Response shall be rendered in an invisible iFrame for about 2-3 seconds.
4. The TDSMethodContent is rendered in an invisible iFrame for about 2-3 seconds.
5. Continue is posted by merchant.
6. Merchant Continue Authentication.
   • Authentication Status equal to SUCCESSFUL indicates that the authentication was successful and that the ThreeDSecureResult contains 3-D Secure data that shall be provided in the Initiate Payment request to be able to claim liability shift.
7. Merchant Initiate Payment.

3-D Secure 2.0 Challenge

1. Cardholder checkout.
2. Merchant Initiates Authentication to determine whether cardholder authentication is necessary or not.
   • Note, the merchant URL argument specifies the URL that ACS will use to redirect back to merchant after cardholder has authenticated; see 7.
3. Authentication Status equal to REQUIRED indicates that authentication is required and AuthenticationProtocolVersion of the ThreeDSecureResult specifies the 3-D secure version.
4. Cardholder is redirected to the ACS based on the Authentication Redirect attributes of the Initiate Authentication Response.
   • CReq and session data posted to ACS.
   • Note; session data is one alternative to keep track of merchant id, order id etc., needed to Complete Authentication.
5. The cardholder authenticates.
6. ACS redirects back to merchant based on merchant URL, see 2.
7. CRes and session data posted to merchant.
8. Merchant Completes Authentication.
   • Authentication Status equal to SUCCESSFUL indicates that the authentication was successful and that the ThreeDSecureResult contains 3-D Secure data that shall be provided in the Initiate Payment request to be able to claim liability shift.
9. Merchant Initiate Payment.

3-D Secure 2.0 Challenge with 3DS Method Data

1. Cardholder checkout.
2. Merchant Initiates Authentication to determine whether cardholder authentication is necessary or not.
   • Note, the merchant URL argument specifies the URL that ACS will use to redirect back to merchant after cardholder has authenticated; see 11.
3. Authentication Status equal to CONTINUE indicates that the TDSMethodContent of the Initiate Authentication Response shall be rendered in an invisible iFrame for about 2-3 seconds.
4. The TDSMethodContent is rendered in an invisible iFrame for about 2-3 seconds.
5. Continue is posted by merchant.
6. Merchant Continue Authentication.
7. Authentication Status equal to REQUIRED indicates that authentication is required and AuthenticationProtocolVersion of the ThreeDSecureResult specifies the 3-D secure version.
8. Cardholder is redirected to the ACS based on the Authentication Redirect attributes of the Initiate Authentication Response.
   • CReq and session data posted to ACS.
   • Note; session data is one alternative to keep track of merchant id, order id etc., needed to Complete Authentication.
9. The cardholder authenticates.
10. ACS redirects back to merchant based on merchant URL, see 2.
11. CRes and session data posted to merchant.
12. Merchant Completes Authentication.
    • Authentication Status equal to SUCCESSFUL indicates that the authentication was successful and that the ThreeDSecureResult contains 3-D Secure data that shall be provided in the Initiate Payment request to be able to claim liability shift.
13. Merchant Initiate Payment.

3-D Secure 1.0 Challenge

1. Cardholder checkout.
2. Merchant Initiates Authentication to determine whether cardholder authentication is necessary or not.
   • Note, the merchant URL argument specifies the URL that ACS will use to redirect back to merchant after cardholder has authenticated; see 7.
3. Authentication Status equal to REQUIRED indicates that authentication is required and AuthenticationProtocolVersion of the ThreeDSecureResult specifies the 3-D secure version.
4. Cardholder is redirected to the ACS based on the Authentication Redirect attributes of the Initiate Authentication Response.
   • PAReq and session data posted to ACS.
   • Note; session data is one alternative to keep track of merchant id, order id etc., needed to Complete Authentication.
5. The cardholder authenticates.
6. ACS redirects back to merchant based on merchant URL, see 2.
7. PARes and session data posted to merchant.
8. Merchant Completes Authentication.
   • Authentication Status equal to SUCCESSFUL indicates that the authentication was successful and that the ThreeDSecureResult contains 3-D Secure data that shall be provided in the Initiate Payment request to be able to claim liability shift.
9. Merchant Initiate Payment.