Authentication Insights

A data dashboard that allows deep dives into payments authentication data

The Authentication tab provides insight into the Strong Customer Authentication (SCA) process, including 3-D Secure (3DS) and other mechanisms like redirect-based flows. It enables users to analyze where authentications occur, their outcomes, and issuer behaviors.

Authentication (for example, 3-D Secure) typically occurs after the payment method is selected but before the payment service is invoked. Or for alternative forms of payment (for example PayPal) authentication typically happens by redirecting to the payment methods’ environment to finalize authentication. The dashboard allows:

• Understanding the impact of 3DS/SCA rules
• Analyzing friction in the checkout process
• Identifying issuer behaviors and liability shift implications
• Keeping track of conversion across payment methods

The Authentications dashboard filters transactions to shows all transactions including failed transactions. This filtering ensures that all transactions where authentication logic is relevant and observable are displayed.

Modules

The dashboard includes multiple modules to analyze different aspects of the authentication flow.

Module Name	Outcomes / Categories	Relevant data fields
Methods	Card, PayPal, etc.	transaction.method
Authenticated	Succeeded, Authentication Failed, Abandoned	This is obtained by combining the outcomes of the directory response: three_d_secure.response_data.directory_response, three_d_secure.response_data.authentication_response, as well as using error codes canceled_buyer_approval, failed_buyer_approval, missing_redirect_url, incomplete_buyer_approval
Response	Y, N, U, A, R	three_d_secure.response_data.authentication_response
Authorized	Successful, Declined/Failed	status
Liability shifted	Yes, No	three_d_secure.response_data.directory_response, three_d_secure.response_data.authentication_response, three_d_secure.status, three_d_secure.response_data.scheme
Challenge	Challenged, Frictionless, No challenge	three_d_secure.method
ECI	00, 01, 02, 05, 06, 07	three_d_secure.response_data.eci
Issuer name	Name of the card issuer (for example, Chase, Barclays)	payment_method_details.card_issuer_name
Issuer country	Country of the issuer	payment_method.country
Card type	Credit, Debit, Prepaid	payment_method_details.card_type
Scheme	Visa, Mastercard, Amex, etc.	payment_method.scheme
BIN	Top 25 Bank Identification Numbers	payment_method.bin
Country	Country of the transaction	country
Connector	PSP used (for example, Adyen, Stripe)	payment_service_display_name
Flow rule applied	3-D Secure flow rules that were triggered	Authentication flow rules
Currency	Currency used in the transaction	currency
Instrument	PAN, NT, etc. (instrument types)	instrument_type

Module details

Authenticated

Indicates the outcome of the authentication process.

• Succeeded:
  Transactions where three_d_secure.response_data.authentication_response is Y or three_d_secure.response_data.directory_response is Y (frictionless scenario) are included. Lastly, redirect transactions that were authorized (alternative forms of payment are included) are also considered.

• Authentication Failed:
  Transactions with three_d_secure.response_data.directory_response: N, R, U, error code as canceled_buyer_approval, failed_buyer_approval, missing_redirect_url, or in case of failed challenge: three_d_secure.response_data.directory_response: C, AND three_d_secure.response_data.authentication_response: N, R or U. Additionally, redirect transactions that were not authorized are also considered.

• Abandoned:
  Transactions containing incomplete_buyer_approval error code.

• Other fields: Furthermore method, authorized_at and status and are used.

Note on Abandoned Derivation: The “Abandoned” status is explicitly derived from transactions that return the incomplete_buyer_approval error code. This typically occurs when a user starts the authentication process (for example when the user is redirected to a 3DS page) but does not complete it.

Response

Raw 3DS authentication response values three_d_secure.response_data.authentication_response

This is the EMVCo ARes TransStatus:

Raw 3DS authentication response values (three_d_secure.response_data.authentication_response). This corresponds to the EMVCo ARes TransStatus.

• Y -> Authentication / Account verification successful.
• N -> Not authenticated / Account not verified; Transaction denied.
• U -> Authentication / Account verification could not be performed; technical or other problem.
• R -> Authentication / Account verification Rejected. Issuer is rejecting authentication/verification and requests that authorization not be attempted.
• A -> Attempts processing performed; Not authenticated / verified, but a proof of attempt authentication / verification is provided.

ECI (electronic commerce indicator)

The ECI indicates the status of the authentication for specific card schemes.

Mastercard

• 02 -> Successful authentication.
• 01 -> Authentication attempted but could not be completed.
• 00 -> Failed authentication or authentication cannot be attempted because card is not enrolled or issuer is not participating.

Visa

• 05 -> Successful authentication.
• 06 -> Authentication attempted but could not be completed.
• 07 -> Failed authentication or authentication cannot be attempted because card is not enrolled or issuer is not participating.

Liability shift

The liability shift is obtained by checking whether a transaction three_d_secure.status is complete. three_d_secure.eci is one of 01, 06, 02 or 05. three_d_secure.response_data.directory_response is one of the following when the liability shifts either: Y or A, C while three_d_secure.response_data.authentication_response is Y or A.

Card schemes are compared: 3DS scheme should be equal to the payment method scheme. Because of co-badge routing, the following can happen:

3DS done with scheme A. Transaction attempt with scheme A fails. A rule indicates an additional scheme B should be used (assuming the card is co-badged). Transaction attempt with scheme B succeeds. On that second attempt, the 3DS information obtained before isn’t sent, because a different card scheme is being used. Hence, the liability isn’t shifted.

Challenge

Describes the nature of the 3DS interaction using the three_d_secure.method either challenge or frictionless.

Notes

• Gift-card-only transactions are included even if they have no method.