Authentication Insights

A data dashboard that allows you to deep dive into your 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 (e.g., 3-D Secure) typically occurs after the payment method is selected but before the payment service is invoked. Or for alternative forms of payment (e.g. PayPal) authentication typically happens by redirecting to the payment methods’ environment to finalize authentication. The dashboard allows you to:

• Understand the impact of your 3DS/SCA rules
• Analyze friction in the checkout process
• Identify issuer behaviors and liability shift implications
• Keep 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 field(s)
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 (e.g., “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 (e.g., 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:
  We include transactions where three_d_secure.response_data.authentication_response is Y or three_d_secure.response_data.directory_response is Y (frictionless scenario). Lastly, we also consider redirect transactions that were authorized (alternative forms of payment are included).

• 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, we also consider redirect transactions that were not authorized.

• Abandoned:
  Transactions containing incomplete_buyer_approval error code.

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

Response

Raw 3DS authentication response values three_d_secure.response_data.authentication_response

This is the EMVCo ARes TransStatus:

• Y – Fully authenticated
• A – Attempted authentication
• N – Failed authentication
• U – Unable to authenticate
• R – Rejected by issuer

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.

We compare the card schemes: 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 we should use an additional scheme B (assuming the card is co-badged). Transaction attempt with scheme B succeeds. On that second attempt, we don’t send the 3DS information obtained before, because we’re using a different card scheme. 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.