SCA result

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":

Field NameDescriptionSourceLength/Format/ValueDevice ChannelMessage CategoryMessage InclusionConditional Inclusion
Transaction Status
transStatus
Indicates whether a transaction qualifies as an authenticated transaction or account verification.

Note: The FInal CRes message can contain only a value of Y or N.

Note: If the 3DS Requestor Challenge Indicator = 06 (No challenge requested; Data share only), then a Transaction Status of C is not valid.
ACS
DS
Length: 1 character
JSON Data Type: String
Values accepted:
Y = Authentication Verification Successful
N = Not Authenticated/Account Not Verified; Transaction denied
U= Authentication/Account Verification Could Not Be Performed; Technical or other problem, as indicated in ARes or RReq
A = Attepts Processing Performed; Not Authenticated/Verified, but a proof of attempted authenticiation/verification is provided
C = Challenge Required; Additional authentication is required using the CReq/CRes
D = Challenge Required; Decoupled Authentication confirmed
R = Authentication/Account Verification Rejected; Issuer is rejecting
01-APP
02-BRW
03-3RI
01PA
02NPA
01-PA:
ARes = R
RReq = R
Final CRes = R

02-NPA:
ARes = C
RReq = C
Final CRes = C
For 02-NPA Conditional as defined by the DS.
See Table A. 15 for 01-PA Transaction Status conditions.

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.

Interface ValueCode (internal)MeaningComment
FRICTIONLESS0FrictionlessThree main cases for this code can be identified: (1) - The trx is acquirer-exempted and not send to 3DS (3DSflowIndicator=0) and successfully passes authorization. (2) - The trx is send to 3DS and an exemption is used/accepted with final status according to scheme program rules/EMVCo rules. This could for example happen if [a] - an issuer exemption is used (no challenge is requested by the issuer/ACS, i.e. no intermediate status=C). Final Status=Y. [b] - an acquirer exemption is accepted by the Issuer/ACS. Final status varies ("I","Y","N",...), depending on 3DS message version and card scheme. Note: In specific case even transStatus = “N” can encode an accepted acquirer exemption (see 3DS 2.1 with Mastercard Message extension and transStatusReason =“81”). (3) - The trx is handled (as fallback) with 3DS 1.x and the acquirer/PSP has no way of knowing if an exemption or SCA has occurred.
SCA_SUCCESS1SCA performedThe trx was submitted to 3DS and a challenge was initiated by the Issuer (intermediate status C) and successfully performed by the cardholder. Final Status=Y. (Can be extended naturally to delegated auth if supported.)
TRA_DECLINE2SCAExemption Risk Engine Decline ConfirmationDirect response for an accepted decline based on SCAExemption action code 2 (decline). (usually no 3DS takes place and the trx is declined)
USER_DECLINE_SCA_FAILURE21User Decline/SCA FailureThe trx was submitted to 3DS and a challenge was initiated by the Issuer (intermediate status C) and successfully performed by the cardholder. Final Status=Y. (Can be extended naturally to delegated auth if supported.)
TECHNICAL_SYSTEM_DECLINE22Technical Decline (blameless)Failure that cannot be caused by or accounted to the cardholder. This technical error could for example be: (1) - technical error report by 3DS components (3DS Server, DS, ACS), received as 3DS error message, e.g. 3DS final transStatus="U" with transStatusReason="22" (ACS technical issue). (2) - general connectivity issue between 3DS components, e.g. 3DS Server cannot reach card scheme DS. (3) - internal technical error not connected to EMV 3DS, but related to other systems related to authentication stage (IPG, connection-issue IPG to 3DS, general IT-infrastructure issue, ...).

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":

Field NameDescriptionSourceLength/Format/ValueDevice ChannelMessage CategoryMessage InclusionConditional Inclusion
Transaction Status Reason
transStatusReason
Provides information on why the Transaction Status field has the specified valueACS
DS
Length: 2 characters
JSON Data Type: String
Values accepted:
01 = Card authentication failed
02 = Unknown Device
03= Unsupported Device
04 = Exceeds authentication frequency limit
05 = Expired card
06 = Invalid card number
07 = Invalid transaction
08 = No card record
09 = Security failure
10 = Stolen card
11 = Suspected fraud
12 = Transaction not permitted to cardholder
13 = Cardholder not enrolled in service
14 = Transaction timed out at the ACS
15 = Low confidence
16 = Medium confidence
01-APP
02-BRW
03-3RI
01PA
02NPA
ARes = C
RReq = C
For 01-PA required if the Transaction Status field = N, U, or R
For 02-NPA, Conditional as defined by the DS

Want a quick overview?