3DS FAQs

📘

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.

❗️

Liability Shift for US Domestic Transactions

For full liability shift, card network rules imply that all authorizations with 3DS must conform to the following requirements:

• Valid CAVV as received at the end of 3DS
• Card type that is not non-reloadable prepaid
• For Visa, the MCC is not 4829, 5967, 6051, 7995, 6540, 7801, or 7802
• Custom Payment Service requirements:
  • Payment acceptance via mail or telephone
  • Card and cardholder are not at the client location
  • Address Verification Request is enabled in the authorization i.e. cardholder address must be included in the Create Transaction API.

If not for this information, despite an ECI 05/06 for fully authenticated transactions, issuers maybe able to raise a chargeback with reason code 10.4

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?

CAVV Results Code is found 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).

Visa Cards - Exceptions for 3DS

3DS Liability Shift Exceptions for Visa Cards.