Common questions on 3DS card verification for TabaPay Developers


Critical Data Elements

TabaPay Clients must note that despite ECI 05 or 06 (fully authenticated) with a good cryptogram the issuer may still dispute with a 10.4 reason code. One way to mitigate this is to make sure to send the cardholder address in the Create Transaction API along with the 3DS payload that includes ECI, XID, and 3DS Cryptogram.

More details here.

What does TabaPay recommend clients do at the end of 3DS and if the transaction must be processed?

02 or 05 - Fully Authenticated Transaction -- TabaPay recommends going ahead with the transaction
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.
00 or 07 - Non 3-D Secure Transaction -- TabaPay does not recommend going ahead with the transaction

How should we treat Enrolled = U or N?

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 Y, then proceed. If it fails, with a N or a U, then you should not proceed. You may do so, but liabality will be on the merchant, not the issuer.

Does 01 or 06 guarantee liability shift?

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

How do I know liability shift is guaranteed?

TabaPay will soon be adding CAVV Results Code in the Create Transaction API Response. This field would provide insights into liability shift for 3DS transactions (i.e. transactions processed with a 3DS payload) See CAVV Results Code here: https://developers.tabapay.com/reference/cavv-results-code

Visa Cards - Exceptions for 3DS

3DS Liability Shift Exceptions for Visa Cards.

CAVV Not Present05 or 06Not protected when ECI is 05 or 06 and a CAVV is not present in authorization.

Transaction gets reclassified. ECI to 07.
Non-Reloadable Prepaid06Not protected when card type is a non-reloadable Visa prepaid card.

Transaction get reclassified. ECI to 07.
Visa Fraud Monitoring Program05 or 06Not protected if they have been identified in the program.
Visa 3-D Secure Fraud Monitoring Program (US)05 or 06Not protected if they have been identified in the program.
Custom Payment System (CPS) Requirements (US)05 or 06Not protected if transaction does not meet CPS requirements.

Transaction gets reclassified. ECI to 07.
Merchant Restricted Merchant Category Codes (MCCs)05 or 06Not protected if they are in one of the following MCCs:

- MCC 4829–Wire Transfer/Money Order
- MCC 5967-Direct Marketing-Inbound Teleservices
- MCC 6051-Non-Financial Institution- Foreign Currency, Money Order (not Wire Transfer), Travelers' Cheques
- MCC 7995-Betting, including Lottery Tickets, Casino Gaming Chips, Off-- Track Betting and Wagers at Race Tracks
- MCC 6540 - Non-Financial Institutions: Stored Value
Card Purchase / Load
- MCC 7801 - Government Licensed On-Line Casinos
(On-Line Gambling)
- MCC 7802 - Government-Licensed Horse/Dog Racing