Invalid 3DS2 implementation

This issue I have at least partially solved with the following patch.

Basically it appears to be a mistake/confusion with the implementation of 3D Secure by some banks, insofar as they don't ask for 3D Secure (or Braintree doesn't?) but then they reject payments without it.

The solution therefore is to force it. I'm not sure if this will have knock-on effects for any banks that do not support 3D Secure (e.g. in the US?). But in Europe at least it is a legal requirement and all banks now require 3DS2.

We are still having some people unable to pay, specifically when paying with a saved payment method which was used before the 3D Secure implementation.

After many more investigations I've discovered the problem. There is a bug in the 3DS2 implementation which means although the user has to pass 3DS2, the bank is never told about it. From my tests, it seems that many banks in the UK and Europe still allow payments without 3DS2, as long as the amount isn't too large, which gives the illusion that it is working. But if you actually check in Braintree, you will not see 3DS2 information on the transaction.

The intermittent failures were occurring for amounts over a certain amount (roughly 30 GBP), but some banks were accepting it for larger amounts. After my fixes it works for all banks, the payments don't get rejected for large amounts, and you can see the 3DS2 information in the transaction in Braintree.

The main issue was in Braintree3DSReview::submitPaneForm():

$payment_method = $this->order->get('payment_method')->entity;
// The payment method nonce should be used for this one time purchase and
// the previous tokenized payment method should be kept for future
// purchases.
$three_d_payment_method = $payment_method->createDuplicate();
$three_d_payment_method->setRemoteId($values['payment_method_nonce']);
$three_d_payment_method->setReusable(FALSE);
$three_d_payment_method->save();
$this->order->set('payment_method', $payment_method);

Note the last line sets the payment method back to the same payment method, so it has essentially done nothing. The corresponding place where this alternative payment method should have been used is HostedFields::createPayment():

if ($payment_method->isReusable()) {
  $transaction_data['paymentMethodToken'] = $payment_method->getRemoteId();
}
else {
  $transaction_data['paymentMethodNonce'] = $payment_method->getRemoteId();
}

What is expected is the payment method was set to the non-reusable duplicate, and therefore this nonce will get passed in the paymentMethodNonce parameter to Braintree. But it was never happening.

After fixing this, I found an additional problem that it wasn't accepting the nonce. Braintree was giving the error: "Merchant account must match the 3D Secure authorization merchant account". After digging through Braintree's documentation, it seems that at the time the token is created you must pass the same merchant ID as the one passed during the Transaction: sale() call to Braintree.

If you have multiple merchant accounts (for different currencies), during token creation it will use the default one, and that might be different to the one specified when calling sale() in HostedFields::createPayment(). So I've also added some code which passes the currency code to HostedFields::generateClientToken(). I made it optional because you don't know what the currency is on the PaymentMethodAddForm, but you don't use 3DS on that form anyway so it shouldn't matter.

The final problem was that because a nonce is now being stored as the payment method on the order instead of a remote ID, it means recurring payments (for people using the commerce_recurring module) will fail, because the nonce can only be used once. It may also be a problem if additional payment needs to be taken or refunds.

For this reason, I've had to add another base field called 'payment_method_reusable', which is simply used to save the reusable payment method ID until the payment has been made. It is then restored afterwards, so that when commerce_recurring creates the recurring order it will have the reusable ID. I'm not sure if there could be a better way of doing that without the need for another field.

I would say this is major since 3DS2 isn't implemented properly and payments larger than a certain amount fail.

Sorry, that patch may not apply because I made it against files that have other patches applied. If I get time I'll reroll it against dev.

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

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.