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 form there if Authentication passes with 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 issue.
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 1 month ago