Authentication Required

Thank you very much for prividing that link. I think it’s related to the “Authentification required” error, since it’s linked with 3D Secure and Visa (what had our customer).
The producs are of type Braintree Variable Subscription.
I tried every option from Liability Not Shifted but the order still succeed after canceling the transaction.

Hi @tiberiuz3401,

Is it only the Braintree Variable Subscription where you encounter this?

I see you created a similar thread a few weeks ago. Was that issue not resolved when version 3.2.23 was released?

Kind Regards,

I tried to make a payment with a MasterCard on the website and I received the “A general error has occurred with Cardinal” message. Do you know how to solve this problem?

@tiberiuz3401 per my last reply, Cardinal is experiencing an outage. There isn’t anything I can do about that.

Hello, I talked with Braintree support and this is they what told me:

To begin, I noticed that the transaction xxxxxx did not have any 3DS information on the transaction detail page. Also in our logs, it does not appear that a 3D Secure enriched nonce or authentication ID was used to create the transaction as it was a transaction created using the Customer ID.

The 3D Secure-enriched nonce should be used in the transaction()->sale call rather than using the ?payment_method_token?.  By changing your integration in this way, your transactions should be under the scope of PSD2 and you will see fewer 2099 declines. Without changing your integration, as banks update under PSD2 you will see an increase in declines. 

When it comes to 3DS, recurring billing, and the Vault, there are a few things to be aware of. At a high level, you'll need to create your vault flow to achieve the following:
·  A 3DS-enriched nonce must always be passed directly to  transaction.sale() requests in order for 3DS info is to be passed to the issuer
·  If the customer is present for the transaction (whether previously vaulted or not), 3DS verification will need to take place as part of your transaction flow

For first-time recurring payments on a new card 
This scenario would apply when the customer is present and a transaction will take place immediately after card verification:
1. Create a Vault record via customer.create(), customer.update(), or payment_method.create()
2. Create a nonce from the payment method token utilizing payment_method_nonce.create()
3. Run 3DS verification on the nonce by utilizing verifyCard on the client
4. Pass the returned 3DS-enriched nonce to transaction.sale()

· Make sure to pass a transaction_source as recurring_first

For subsequent scheduled transactions:
1. Pass the customer's payment method token to transaction.sale()
· Set the transaction_source as recurring.

Can I ask you if the plugin does every step mentioned here?

@tiberiuz3401 yes the plugin does all that.

If you haven’t done so already, enable 3Ds for vaulted payment methods. That option is in the Credit Card Gateway settings page.

It sounds like you’ve been testing 3DS with a saved payment method but didn’t enable 3DS for saved payment methods.

Kind regards

I checked that setting and it has been enabled before the customer tried to pay.

Hello, I have a few questions:
1. If a customer has a vaulted card and he enters the same card details in the checkout as in the vaulted card, why a new vaulted card is created, even though they contain the same card details?
2. From what I’ve read, when creating a new payment method, it needs a paymentMethodNonce for the 3DSecure. Is that correct?

@tiberiuz3401

1. Because Braintree allows the same credit card to be saved multiple times, unless you have enabled the option to not allow duplicate payment methods. That option is located in the Credit Card Gateway settings page.

2. Yes, that’s correct. And the plugin follows all of the requirements for that.

Hello, I searched inside ‘abstract-class-wc-braintree-paymet-gateway.php’ and found something interesting. All code references are from this file.
I wrote the card details in the card form, so a new payment method would be made. That means that 3DSecure needs a paymentMethodNonce.
This is what the code behave in this scenario:
1. In process_payment function:

if ( $this->use_saved_method() ) {

			$args['paymentMethodToken'] = $this->get_payment_method_token();

		} else {

			$args['paymentMethodNonce'] = $this->get_payment_method_nonce();

		}

Because use_saved_method returns true, the token will be used instead of the nonce, which is not good for 3DSecure.
2. The function use_saved_method return true in
return ( ! empty( $_POST[ $this->payment_type_key ] ) && $_POST[ $this->payment_type_key ] === 'token' ) || $this->payment_method_token; because
$this->payment_method_token is defined.
3. payment_method_token is defined in add_payment_method function at
$this->payment_method_token = $token->get_token();
Since we add a new payment method, it returns a token, which is saved.
But then, in use_saved_method it thinks that the new payment method is a saved one, and returns true. Furthermore, in process_payment the payment method token is chosen instead of the payment method nonce, which affects 3DSecure, since the data sent to bank doesn’t contain the needed nonce.`

• This reply was modified 3 years, 8 months ago by tiberiuz3401.

@tiberiuz3401 look at file includes/gateways/class-wc-braintree-cc-payment-gateway.php and you will see the function use_save_method is overridden and accounts for this scenario.

public function use_saved_method() {
	if ( $this->_3ds_active() && $this->use_3ds_vaulted_nonce() ) {
		return false;
	}

	return parent::use_saved_method();
}

The plugin correctly uses the nonce created from the vaulted payment method.

I understand. Meanwhile, I received another explanations from Braintree support.

As we checked the transaction history of your production gateway for the last 30 days, we were not able to find any transaction with 3DS information, It will be helpful if you provide us with the example transaction ID of 3DS successful transaction.

Also, upon further research, looking at verification aaaaaaa and the subsequent transaction bbbbbbb, I can see that the 3DS-enriched nonce was used during the payment method create request. This means that the nonce was used as part of the credit card verification, rather than the transaction call.

As mentioned in our previous response, I can see from the parameters above that the 3DS-enriched nonce was not passed to the card-issuing bank as part of the transaction, as such the transaction was declined. More importantly, it appears that 3ds was never even attempted for this transaction.

Recommended 3DS Flow for Vaulted Payment Methods
Looking through your gateway, it appears that your transactions are one-off transactions. For customer-initiated (vaulted) transactions, when it comes to running vaulted payment method through 3D Secure, the recommended flow for new customers is:

1.    A customer enters their payment details into your checkout form and a nonce is created
2.    The nonce is sent to the server and stored in the vault
3.    The resulting token is turned back into a nonce using paymentMethodNonce.create()
4.    This new nonce is sent back to the client-side and authenticated using the 3D Secure component verifyCard
5.    The resulting 3D Secure enriched nonce is then sent to the server-side for a transaction.sale() request

I don’t understand why the enriched nonce isn’t passed to the transaction.

Hi @tiberiuz3401,

The plugin follows the steps described by Braintree support. When I perform a test using a vaulted payment method, the enriched nonce is used.

Do you have any custom code on your site that is modifying Braintree in any way? That includes your customization of the three-d-secure.js script.

What is unique about your site setup? Are you purchasing a subscription on the checkout page? Or is it a a regular product?

Kind Regards,

Hi,
I updated the plugin before to 3.2.25, and the Braintree SDK is directly from js.braintreegateway.com/web, version 3.77.0.
I am purchasing only subscription products (Braintree Variable Subscription, provided by this plugin).
From my research, since there is no enriched nonce in the transaction, it means that on transaction()->sale($args) function those $args don’t have that needed nonce. I saw that sale is called in 3 different places in WC_Braintree_Payment_Gateway: in process_payment, process_subscription_payment and process_pre_order_payment.
1. During a checkout with subscription products are all these 3 sale function called?
2. The nonce received from verifyCard in what place is consumed?

Hi @tiberiuz3401,

Ok this makes sense now that I know you’re only using the plugin’s provided subscription product.

In order for a Braintree Subscription to be created, a payment method must be vaulted. So, in method wcs_braintree_before_process_order the plugin saves the payment method. That consumes the 3DS nonce for the payment method and explains why you aren’t seeing it in the transaction call.

Note: this is only when using the Braintree Subscription products. Subscriptions via the WooCommerce Subscriptions plugin work exactly as I have described.

I will need to tweak the logic so the payment method is vaulted during the transaction call and not before. That will prevent the 3DS nonce from being consumed in the credit card verification.

You can reach out to me via the plugin’s Help button so you can assist in testing the update.

Kind Regards,