Is it possible to reject transaction which haven’t completed 3DS?

Hi @m22878

When configuring “Always trigger 3D Secure” in the Advanced Card Processing tab, the plugin will send the SCA_ALWAYS contingency to PayPal.
This will always trigger a 3DS challenge, and my understanding is that it would fail payments if the 3DS challenge could not be completed (including cases where the card does not support 3DS).

If you can reproduce successful orders despite no 3DS authentication with SCA_ALWAYS contingency in live mode, I recommend enabling Logging from the Connection tab, try it again, and then share your PayPal Payments log files with the PayPal Merchant Technical Support to investigate the response on PayPal’s end.

The plugin is not actively failing orders when 3DS is not successful, as this is normally something the PayPal response decides. So it may be helpful to get some insight from the PayPal MTS in this regard.

Kind regards,
Niklas

I had already contacted Paypal’s support and this is what they said below. Apparently, it works as intended, which is to simply trigger a 3DS attempt on every order, but if the issuing bank doesn’t support 3DS the transaction will be allowed through, anyway!

So, who wants to implement the logic that will actually reject transaction without a successful 3DS as mentioned below?

“You are correct that the SCA_ALWAYS setting is designed to trigger a 3DS attempt on every transaction, but it does not necessarily reject transactions if 3DS hasn’t been successfully completed.

The behavior you described is accurate: if the customer’s issuing bank doesn’t support 3DS, the transaction will still be allowed to go through. The SCA_ALWAYS setting ensures that 3DS is attempted whenever possible, but it does not enforce a strict requirement for 3DS to be completed for every transaction.

If you want to reject transactions where 3DS has not been successfully completed, you would need to implement custom logic in your payment processing flow. This would involve checking the 3DS status for each transaction and programmatically rejecting those without successful 3DS authentication. However, this approach may lead to false declines and negatively impact legitimate customers whose banks do not support 3DS.”

Hi @m22878

Thank you for sharing these details.

Currently, the plugin stores certain card responses as order notes, but these responses don’t necessarily indicate whether 3D Secure was triggered. Although the plugin does store the three_d_secure,?enrollment_status, and?authentication_status?responses from PayPal, these are only available in the plugin log files.

In theory, you could read the logs and implement custom order handling based on this information. However, this approach may not be ideal. A more reliable solution could involve creating a custom module to modify the plugin behavior according to your needs, but this requires advanced development experience.

To simplify the process, I have submitted a feature request to store these responses in the order notes/meta. This should allow for more reliable handling of such use cases. But I’m unsure when something like this could be expected in the plugin.

This could be combined with payment authorizations to capture only payments that successfully triggered 3D Secure automatically. Meanwhile, you can manually review all other transactions before deciding whether to void or capture them. But based on the provided 3DS response, you could determine how to handle such orders with a code snippet.

Kind regards,
Niklas

Hi @m22878,

Just to let you know, our developers are looking into adding more relevant 3DS data to the order meta. So there won’t be any new settings within the plugin, but once this information is stored in the WooCommerce order, you could build custom handling for these orders on top of it.

Individual needs for this may be too diverse for us to provide one solution for all. Still, the plugin includes features like payment authorizations and an API that lets you programmatically capture/void/refund, which could be combined with custom order handling.

But since we didn’t hear back from you, I’ll mark this thread resolved for now. I suggest keeping an eye on the plugin changelog, as this additional order meta may be included in one of the next few updates.
If any questions remain, please reopen this thread or create a new one. Thanks!

Kind regards,
Niklas