3DS FAQs

JWT lasts 2 hours by default. Could be shorter if you include an exp claim.

10 minutes

The CAVV would be valid for up to 90 days.

Once the lookup response is received with a challenge URL and payload you will have 30 seconds to facilitate the challenge session before it expires.

"A Browser is a dedicated software application for accessing information on the World Wide Web, for example Chrome, Safari, Edge, Firefox. When a user requests a web page from a particular website, the Browser retrieves the necessary content from a web server and then displays the page on the consumer’s screen.

For 3DS, the Browser is a conduit to transport messages between the Acquirer Domain and the Issuer Domain utilizing Browser Fields. A Browser is distinguished from a UI component for example, a WebView, or Custom Tabs, which can be used to display content within an App on a mobile device. The Browser flowis invoked by a Browser whereas the EMVCo specification does not support a UI component within an app therefore invoking the Browser flow."

-EMV® 3-D Secure Protocol and Core Functions Specification v2.3.1.0

Before implementing EMV 3-D Secure (3DS), TabaPay Clients should develop a clear strategy and ensure all necessary processes and monitoring are in place.

1. Define your EMV 3DS strategy and goals

Establish objectives and key performance indicators (KPIs) before implementation.

• Example objectives: combatting fraud, complying with local, or regional regulations.

• Example KPIs: higher authorization rates, less chargebacks, or, increased sales conversion

Defining these objectives early will drive solution design and ensure alignment with business goals.

2. Map your checkout flows

Inventory all checkout experiences (guest checkout, recurring payments, high-value purchases, etc.) to determine where EMV 3DS should be applied.

Optimize EMV 3DS implementation across each flow to minimize friction while maintaining strong authentication.

3. Strengthen fraud monitoring and data sharing

Work with your acquirer to ensure proper fraud monitoring is in place.

Acquirers may provide issuer-reported fraud data that helps measure KPIs, such as fraud-to-sales ratios and approval rates on 3DS vs. non-3DS transactions.

Submit lookup requests with as much data as possible — issuers use this to improve risk models and enable more frictionless authentications.

4. Recommended 3DS use cases

Use EMV 3DS in these key scenarios to enhance security and issuer confidence:

• Guest checkout transactions, where the consumer is not known to the merchant.

• First-time use or high-value and/or out-of-pattern purchases.

• Suspected account takeover cases, such as address changes or credential updates.

TabaPay Clients should ensure that the data sent into authorization is accurate and consistent with the data sent into authentication.
The more, accurate/high quality data clients can provide for 3DS, the better. The more information Issuers have to feed their risk engines will be a driver in frictionless/challenge outcomes so any TabaPay Client interested in driving down challenge rates should be looking to supply as much data as they can.

Per EMV® 3-D Secure Protocol and Core Functions Specification v2.3.1.0 (August 2022) and Cardinal API Requirements

3DS Request Body Parameters

TabaPay Clients should be aware that there are two types of data:

1. Systemic data (i.e. transaction amount, IP address and device) that is captured systemically
2. Manually entered data that are customer input fields
   • Customer input fields have been found to result in a higher rate of error at approximately 3%. When possible, implementing a drop-down menu of required fields for consumers to select their information, and ensuring card-on-file is present can greatly reduce the rate of human error.
   • For addresses, not every country has the same address conventions (i.e. provinces, states, territories). Whenever possible, Merchants should use a dropdown feature to improve accuracy and reduce human error in manually entered data.
   • As a best practice, Merchants should allow card-on-file and consumer pre-filled data to ensure consistent entries for returning customers. This also improves consumer experience.

For information on 3DS response fields, refer to Enriched TabaPay Shield Attributes

There is no guarantee on liability shift, and TabaPay does not control liability shift.  However, performing 3DS assures cardholder authentication by the Issuing bank. 

CAVV Results Code can be found in the Create Transaction API Response. CAVV provides insight into a liability shift for 3DS transactions (i.e. transactions processed with a 3DS payload) Learn More →

We recommend looking at the following Cardinal Documentation for more information -> Consumer Authentication Matrix.

Some additional observations:

1. 02 or 05 - Fully Authenticated Transaction -- TabaPay recommends going ahead with the transaction
2. 01 or 06 - Attempted Authentication Transaction -- TabaPay recommends going ahead with the transaction, and monitor activity.  If post-processing, it results in any untoward activity, you can tweak this logic.
3. 00 or 07 - Non 3-D Secure Transaction -- TabaPay does not recommend going ahead with the transaction 

If the Enrolled equals U or N, it is good to [assume] that the issuer does not participate and you should "not" proceed with "Authorization" because if you do, then you would be held liable, since authentication was not accepted. You can proceed with "Authorization" as that is entirely up to the merchant and how they conduct their business. These are rules that you can use on your Payment Gateway, which is separate from CardinalCommerce Authentication.

If enrollment does equal "Y", then it is best to proceed via a Frictionless Transaction or a Challenge on Authentication and from there if Authentication passes with Status Y, then proceed. If it fails, with a N or a U, then you should not proceed but again, you may do so, but liabality will be on the merchant, not the issuer. 

When there's an error, without a CAVV at the end of 3DS, you can only proceed with ECI 07 (no CAVV) for the transaction. Or re-try.

However, if during a 3DS flow, the issuer is unavailable, the result would usually result in ECI 06 and a CAVV with issuer not present indication. You can proceed with ECI 06 and CAVV for processing.

Specific issues related to the SDK and its functionality, yes. Prior to going live, we recommend the merchant completes all testing/test cases, building logic to handle responses and errors. Once the merchant moves to production, if there are any issues TabaPay would reach out to Cardinal’s support team via a support ticket with the issue and it would be handled on a case-by-case basis.

The merchant would raise the issue with Tabapay which would then open up a support ticket with Cardinal.

This would depend on the issue at hand. For example, if it was a bug fix needed within the SDK, those would come about/be addressed in any upcoming sprints at Cardinal (again, based on the severity or complexity of the issue). When TabaPay opens a support ticket, the SLA's would follow our Cardinal’s SLA procedures.

The Cardinal Mobile SDK for iOS requires iOS 10 (at the minimum) and is compatible with any version later than that. The Cardinal Mobile SDK for Android requires an API level of 21 (Android 5.0, Lollipop, or later) and is compatible with any version later than that.

Yes, Cardinal will continue to support all future platforms/OS versions for iOS and Android.

It depends on the Issuing bank, the cardholder would need to work with their Issuing Bank to setup their 2 Factor authentication preferences.

This is an option. Most user's prefer a text message.

For 3DS test cards look at the following: https://developers.tabapay.com/reference/3ds-test-cases-and-cards

There are numerous scenarios for errors. We don't have specific error flows, but a common scenario would be 1.0 downgrades (in the case of a 1.0 downgrade, TabaPay will return a 207 response code. Please contact [email protected] if you receive any 207 response codes and DO NOT retry).

The Issuing bank actually has the private session with their cardholder and would be controlling the challenge screen if a cardholder is successful or not.

3 attempts. If the transaction fails after 3 attempts of incorrect password being input, the cardholder would then need to re-initiate the transaction.