The drop-in interface should show the last used payment method when defaultFirst is false, but it doesn't.
To be more specific, I'm using the braintree drop-in in the following fashion:
function createBraintreeInterface() {
var payload = {
'_token': csrf_token,
};
return $.post('/get-braintree-client-token', payload, function(data) {
clientToken = data.token;
braintree.setup(clientToken, "dropin",
{
container: "payment-form",
defaultFirst: false,
onPaymentMethodReceived: function (paymentMethod) {
// Ajax call to create the sale server-side in a unsettled state
createSale(paymentMethod.nonce, $('#amount').val()).done(function (result) {
brainTree.teardown(function() {
createBraintreeInterface();
});
});
},
onReady: function(integration) {
brainTree = integration;
}
});
});
}
Hi @directrix1, can you provide a description of the behavior you're seeing? When I tested this in sandbox, I wasn't able to duplicate.
The expected behavior is that a customer's payment methods are sorted with the most recently transacted upon payment methods at the top, with the rest of the payment methods sorted by when they were added.
It appears that it happens when selecting a different existing payment method (not entering in a new payment method). I've reproduced this in sandbox by:
@directrix1 Thanks for the info, I can duplicate this behavior. I'll look into this further.
Hi @directrix1,
After some investigation, I've found the root cause.
Each payment method has a timestamp that indicates when it was last used to create a transaction. A few months ago, we made a change so that these timestamps are only updated if more than 24 hours has passed since the previous timestamp. The purpose of this was to help optimize some database operations.
Braintree uses this timestamp to sort payment methods, so the side effect of this optimization is that there is a special case where if a customer creates a transaction with payment method A, creates another with payment method B, then creates yet another with A, and does this all within a 24-hour timespan, then their payment methods will not be sorted with the most recently used.
We will not be fixing this issue because this scenario is unlikely to occur in the real world. However, we will update our documentation to explain that the payment method sorting behavior may deviate in the aforementioned edge case scenario.
Please let us know if you have any concerns.
Yeah, that makes sense, and in the case of most apps will likely be irrelevant anyway. I was starting to wonder if this had something to do with the granularity of the last used timestamp, and I can see the value in that optimization.