# Authenticate a 3D-Secure Transaction in a Frictionless Way Based on the Issuer's Decision
source: https://developer.mastercard.com/mastercard-processing-authentication/documentation/use-cases/auth-trans-with-iss-decision/index.md

## Overview {#overview}

The use case describes the process for a cardholder to authenticate a 3D-Secure (3DS) transaction frictionlessly based on the issuer's internal risk-based rules.
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: 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.

## Sequence diagram {#sequence-diagram}

Diagram auth-trans-iss-decision

## 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.
6. The server, based on their internal risk-based engine (for example, 10€ transaction amount), decides that the authentication should be frictionless and returns the response, containing value `4` 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 sends the authentication result to the DS, which routes the result to the merchant.
9. The merchant displays the authentication status to the cardholder.
10. Optionally, the ACS provider, depending on the issuer configuration agreed upon during the onboarding process, 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. By default, the ACS provider does not send the `acsCStatus` request in case of frictionless authentication.
11. 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.
12. 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.
13. The server returns the HTTP status `200` to the Mastercard Processing Authentication Hub API.
14. 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`