# Authenticate a 3D-Secure Transaction with a One-Time Passcode Sent by the ACS Provider
source: https://developer.mastercard.com/mastercard-processing-authentication/documentation/use-cases/auth-trans-with-otp-acs-provider/index.md

## Overview {#overview}

The use case describes the process for a cardholder to authenticate a 3D-Secure (3DS) transaction using the one-time passcode (OTP) generated and sent to the cardholder by the ACS provider.


Note: To simplify the sequence diagram, the 3DS Server and Directory Server have been omitted. However, merchants and ACS providers communicate through the 3DS Server (or 3DS SDK) and Mastercard Directory Server, which are part of the Acquirer domain and Interoperability domain, respectively. Alert: This authentication method does not comply with PSD2 2FA requirements and can be used only outside the EEA and the UK. Alert: There is a 3-second timeout set at the Mastercard API Gateway level for all outbound calls. However, it is strongly recommended to ensure that your endpoint responds quickly, within 1.5 seconds, to prevent the 3DS secure transaction from failing due to a timeout on the ACS or DS side.

<br />

## Sequence diagram {#sequence-diagram}

Diagram auth-trans-otp-acs-provider

## Explanation {#explanation}

1. The cardholder decides to initiate a payment with a card at the e-commerce merchant.
2. The merchant initiates the 3DS process using its 3DS server that sends the authentication request to the Mastercard DS, which routes the request to the Mastercard Processing ACS provider.
3. The ACS provider decides that the authentication will be non-frictionless based on the issuer configuration and sends the authentication request (`acsAReq`) to the Mastercard Processing Authentication Hub API. Note: In the standard Authentication Hub setup, the ACS provider forwards all authentication requests to the issuer. However, once the onboarding process is completed, the issuer will have access to the ACS admin panel, where they can maintain their configuration, including creating frictionless rules that can be applied at the ACS level.
4. The Mastercard Processing Authentication Hub API adds the following details to the `acsAReq` request body:
   * Technical card identifiers (`cardContractId` and `cbsNumber`) linked in the CMS with the `cardContractNumber` received from the ACS provider in the `acsAReq` request. Note: For PAN-less issuers, the Mastercard Processing Authentication Hub API can be configured to mask the full PAN received from the ACS Provider in the `cardContractNumber` field before forwarding the request to the issuer. For the Authentication Hub API, the PAN masking pattern cannot be modified and is the following:
     * The first six and last four digits are visible.
     * All others are replaced with \*.

     For example, 512345\*\*\*\*\*\*2345.
5. The Mastercard Processing Authentication Hub API forwards the `acsAReq` request to the server by sending the `POST` request to the `https://issuer-host-name.com:443/three-ds-transactions/{three_ds_server_transaction_id}/acs-authentication-requests` endpoint.
6. The server decides to authenticate the cardholder with the mobile application. It returns the response, containing the value `2` in the `authenticationMethod` field in the response body, to the Mastercard Processing Authentication Hub API.
7. The Mastercard Processing Authentication Hub API forwards the issuer response to the `acsAReq` request to the ACS provider.
8. The ACS provider sends the authentication result to the DS, which routes the result to the merchant.
9. The merchant sends the challenge request to the ACS provider through the DS.
10. The ACS provider displays the authentication page to the cardholder. The authentication page informs the cardholder to enter the verification code sent to the cardholder mobile number by SMS. Alert: Ensure the cardholder mobile phone number is provided during the client object creation or update in the CMS using the [Mastercard Processing Core API](https://developer.mastercard.com/mastercard-processing-core/documentation/). The mobile phone number will automatically be enrolled in the ACS. Otherwise, the ACS provider will display that the card has no registered mobile phone number on the authentication page. Note: The authentication page template can be customized to your needs during the onboarding process. Later, you can manage page templates using the ACS admin panel.
11. The ACS server sends the OTP generated in step 3 to the cardholder by SMS.
12. The cardholder enters the OTP received by SMS on the authentication page rendered by the ACS server.
13. The OTP verification result is presented to the cardholder.
14. The ACS provider sends the authentication result to the DS, which routes the result to the merchant.
15. The merchant displays the authentication status to the cardholder.
16. The ACS provider sends the `acsCStatus` request to the Mastercard Processing Authentication Hub API. The `acsCStatus` request contains the final status of the authentication performed by the ACS provider.
17. The Mastercard Processing Authentication Hub API adds the following details to the `acsCStatus` request body:
    * Technical card identifiers (`cardContractId` and `cbsNumber`) linked in the CMS with the `cardContractNumber` received from the ACS provider in the `acsCStatus` request.
18. The Mastercard Processing Authentication Hub API forwards the `acsCStatus` request to the server by sending the `POST` request to the `https://issuer-host-name.com:443/three-ds-transactions/{three_ds_server_transaction_id}/acs-challenge-statuses` endpoint.
19. The server returns the HTTP status `200` to the Mastercard Processing Authentication Hub API.
20. The Mastercard Processing Authentication Hub API forwards the HTTP status `200` to the ACS provider.

## Endpoints {#endpoints}

`acsAReq`

API Reference: `POST /three-ds-transactions/{three_ds_server_transaction_id}/acs-authentication-requests`

`acsCStatus`

API Reference: `POST /three-ds-transactions/{three_ds_server_transaction_id}/acs-challenge-statuses`