SCA result

The following fields will be discussed:
- transStatus
- scaStatusReason
- transStatusReason

• authorizationData
  • authorizationStatus
  • authorizationResponseCode
  • authorizationApprovalCode
  • merchantReference
  • cardholderReference
  • threeDSFlowIndicator

transStatus

Directly corresponds to the respective 3DS field (see excerpt of EMV 3DS 2.2 spec below). However, during the different messages exchanged as part of 3DS this status may change. The learning data message to the risk engine should contain the final status. Note: This status can be reached in different steps of the processing.

Examples:

1. 3DS flow is initiated and the issuer's ACS exempts the transaction. ARes contains final status Y, as there is no RReq/RRes exchange.

2. 3DS flow is initiated and the issuer's ACS challenges the cardholder. ARes contains (intermediate) status C. After the challenge, there is a subsequent message exchange with the final status (contained in RReq) being Y (success) or N (no success).

Whilst there might be (different) intermediate states, only the final outcome should be communicate via the learning data message. In case there is no 3DS flow (threeDSFlowIndicator=``) this field can be provided empty.

See "EMV 3-D Secure Protocol and Core Functions Specification v2.2.0 / 3-D Secure Data Elements":

Fallback 3DS 1.x:
3DS 1 there will be only one transaction status from the PaRes message:

- Y: Authentication successful.
- N: Authentication failed.
- U: Authentication could not be performed.
- A: Attempts processing performed.

This status can be provided, (and correctly interpreted in combination with other fields, e.g. threeDSFlowIndicator=SUBMITTED_TO_3DS and messageVersion=1.0.2).

scaStatusReason

While the 3DS-Field transStatus encodes whether an authentication process was successful (Y) or not (N). However, this information does not provided insight into the following interesting aspects:

1. How was a “success” reached, via 3DS (SCA by the cardholder or frictionless/exempted success), direct authorization success or delegated authentication?
2. Why did a transaction/authentication attempt fail (as a final state)?

Again, this code only represents the final authentication outcome of an event.

Fallback 3DS 1.x:

As stated in the table above, all transactions that are handled 
via 3DS 1.x are treated as "successful but without confirmed 
strong customer authentication", and the correct encoding is "0 - Frictionless".

Delegated Authentication:

In case a delegated authentication was performed, use the following encoding (as natural extension to 3DS)

- successfully authenticated: "1"
- unsuccessful (user error/decline/cancel) without subsequent 3DS challenge: "21"
- unsuccessful (user error/decline/cancel) with subsequent 3DS flow: 
provide codes from 3DS flow as stated before.

The system can detect the (final) delegated authentication implicitly 
as combination of  "threeDSFlowIndicator=NOT_SUBMITTED_TO_3DS" 
and the statusReason 1 or 21.

transStatusReason

This field further describes the reason for the status from 3DS 2.x perspective. This is especially useful for non-successful transactions. The
transStatusReason must contain the final reason and should therefore be taken from the same final (3DS) message as the transStatus.

See "EMV 3-D Secure Protocol and Core Functions Specification v2.2.0 / 3-D Secure Data Elements":