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.
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
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.
There is no guarantee on liability shift, and TabaPay does not control liability shift. However, performing 3DS assures cardholder authentication by the Issuing bank.
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
Updated about 3 hours ago