Invalid 3DS2 implementation

Good thinking, I've changed it to use setData() instead.

This can't be committed until 🐛 Allow specifying merchant id when generating client token. Fixed is resolved (similar changes to the generateClientToken()) are implemented there.

Hi, the issue linked to on the last comment was committed, does this mean this patch can now be reviewed again?

Our site currently is not accepting any 3D Secure payments either through stable or dev release on commerce 3.6.

Many thanks

Thanks for your work on this Rob.

Our client has been reporting payment failures due to the same issue.

The patch in #8 applies cleanly to 8.x-1.4 so we are going to apply this to our live site. I will report back once we know if we are seeing a reduction in the amount of payment failures due to 3DS or not.

As stated in #10, the issue referred to in #9 has been fixed and merged. Now that has been done can we commit and merge the patch to 8.x-1.x-dev?

Hi Jerome, we have been using patch #8 for 9 months now and aren't getting the failed payment reports any more.

I'm surprised more people haven't reported this - broken 3DS2 implementation is pretty major. But it is up to the banks to reject and for small amounts most will allow without 3DS2. We were seeing almost every transaction over £50 be rejected by certain banks, and that no longer happens with patch #8.

Despite hundreds of people per month being rejected, only 1 or 2 of those would bother to email us to say it wasn't working, so perhaps a lot of site admins are unaware of the problem. You'd have to pay attention to the number of unsuccessful transactions in Braintree and consider it an issue.

Updated patch.
Many of the changes made it into the module. This patch includes the remaining change.
I am not sure I fully understand why the original code created the $three_d_payment_method and not used it so hoping this will solve my issue.
Also storing the $payment_method against the order and restoring it does not feel like the best way to do this but if it works so be it.

<?php
-    $this->order->set('payment_method', $payment_method);
+
+    $this->order->set('payment_method', $three_d_payment_method);
+    // We will need to change the payment method back after payment so that
+    // recurring orders or failed payments won't use the nonce.
+    $this->order->setData('payment_method_reusable', $payment_method->id());
?>

and

<?php
       $transaction_data['paymentMethodNonce'] = $payment_method->getRemoteId();
+      $order = $payment->getOrder();
+      $reusable_payment_method_id = $order->getData('payment_method_reusable');
+      if ($reusable_payment_method_id) {
+        $order->set('payment_method', $reusable_payment_method_id);
+        $order->save();
+      }
?>

Hello, i can confirm i had some 3ds2 verification fails before applying the patch for big transactions.
Same people could buy after applying the patch at #13.
Kind regards.

Tested #13 on Drupal 10.2.3 and 8.x-1.5 of this module and it seems to work, can see the 3DS data on the Braintree transaction now, which wasn't there before.

Thanks, all!

Note: the last patch handles some, but not all 3ds2 issues.

Additional work is included in the MR that was created and merged in.

Automatically closed - issue fixed for 2 weeks with no activity.