Skip to main content
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 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.