Drop-in flips to "vaulted" appearance upon order form submission

Using any of the recent versions of the .js, including the current “official” one from https://js.braintreegateway.com/v2/braintree.js we’re seeing some undesirable behaviour.

It starts off ok. When the (single) checkout page containing the braintree.setup() is called with a clientToken generated on the server without a customerId passed in, the drop-in form appears as it should: with PayPal button and fields for credit card number, expiry and CVV (CID for Amex).

   var dropInOptions = {
        container: 'dropin-braintree',
        onPaymentMethodReceived: insertNonceOnForm
    };
    var clientToken = '<?php echo $_clientToken; ?>';
    braintree.setup(clientToken, 'dropin', dropInOptions);

When the shopper presses “Place Order” on the checkout form, we capture and park the click, then programmatically press the hidden button on the drop-in form to have the nonce generated on our checkout form. We then re-instate the handler on the “Place Order” button to let it do its thing, which is to submit everything on the checkout form (product and shipping details, nonce) to the store. All of this has worked beautifully with a version of the .js dating back to May (we think). It still works with later versions (we tried 2.7.4 and 2.14.0) in that the order gets processed. But there is a major difference: when the checkout form submit occurs, the drop-in changes its look to the “vaulted” appearance, showing the last two digits of the credited card and a “Change payment method” link.

This isn’t so bad when the order goes through, as the shopper will be redirected to some sort of success page. End of story. But it is a major UX issue when the sale is declined and the shopper is left on the page with the drop-in having changed its looks and the original input fields no longer available.

To correct card details, say a CVV/CID, the shopper then needs to either refresh the page (losing all data entered) or using the drop-in vault look add a payment method (which is counter intuitive) and retype all of their card details, as these are not pre-populated. They can then press “Place Order” order a second time (since v2.7.4 will now auto-generate a NEW nonce, yay!) and the order will go through.

Is this behaviour configurable at all?

We much prefer the old behaviour whereby the drop-in retains its original look & feel, however we cannot use versions prior to 2.7.4 because of https://github.com/braintree/braintree-web/issues/20 Versions prior to 2.7.4 return the previously generated nonce, which then gets rejected on the server in the sale() call, for being used twice.

Note that in all this the Vault is off in that no customerId is ever past to the Braintree_ClientToken::generate or Braintree_Transaction::sale() calls.

[RikdeBoer]

Thank you for the code example. Ok, I won’t push any further.

Just this…

If you are talking about backwards compatibility … This never used to be the default behaviour. It is a regression. The default behaviour, months ago, used to be exactly what we all want: to leave the card number, expiry and CVV fields exactly as they were left by the shopper. No erasing. No flipping to a little panel that says “VISA ending in 11”. Just do NOTHING.

Then if there is a gateway error, those fields are still there for the shopper to correct. Then they press “Place order” for a second time, NEW nonce gets generated, order goes through. Happy days.

Does that make sense? Would you agree that this is a better UX than the current behaviour? Do you agree that teardown() is not going to do much for the shoppers and merchants in this scenario?

Final question: when shoppers complain to the merchants that we do business with, may I quote this as the official Braintree response:

“Future versions of braintree.js will likely address these concerns.” “Until such time (release date unknown), refresh the page or re-initialise the drop-in, thereby losing all data entered.”

[crookedneighbor]

@chrisribe I recommend updating to the latest version of Drop-in (1.7.0).

It has a clearSelectedPaymentMethod function that allows you to remove the selected payment method. For your use case, you’d tokenize with drop-in, send the payment method nonce to your server, get the validation error and then call clearSelectedPaymentMethod and add an error message to your page about it.