# Authenticate a 3D-Secure Transaction in a Frictionless Way Based on ACS Risk-Based Rules
source: https://developer.mastercard.com/mastercard-processing-authentication/documentation/use-cases/auth-trans-with-acs-risk-based-rules/index.md

## Overview {#overview}

The use case describes the process for a cardholder to authenticate a 3D-Secure (3DS) transaction frictionlessly based on the ACS risk-based rules set by the issuer. The setup of frictionless rules is optional, and the issuer can add such rules at any time after the onboarding process is completed.
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.

## Sequence diagram {#sequence-diagram}

Diagram auth-trans-acs-risk-based-rules

## 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 frictionless based on the risk-based rules agreed with the issuer during the onboarding process and sends the authentication result to the DS, which routes the result to the merchant. Note: After the onboarding process, the issuer has access to the ACS admin panel, where they can maintain their configuration, including maintenance of the authentication risk rules.
4. The merchant displays the authentication status to the cardholder.
5. Optionally, depending on the issuer configuration agreed upon during the onboarding process, 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. By default, the ACS provider does not send the `acsCStatus` request in case of frictionless authentication.
6. The Mastercard Processing Authentication Hub API adds the following details to the request body:
   * Technical card identifiers (`cardContractId` and `cbsNumber`) linked in the CMS with the `cardContractNumber` received from the ACS provider in the `acsCStatus` 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 other digits are replaced with \*.

     For example, 512345\*\*\*\*\*\*2345.
7. 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.
8. The server returns the HTTP status `200` to the Mastercard Processing Authentication Hub API.
9. The Mastercard Processing Authentication Hub API forwards the HTTP status `200` to the ACS provider.

## Endpoint {#endpoint}

`acsCStatus`

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