search

braintree / braintree_android

Braintree SDK for Android
https://developer.paypal.com/braintree/docs/start/hello-client/android/v4
MIT License
409 stars 235 forks source link

Drop-in UI not showing default payment #23

Closed brycehendrix closed 8 years ago

brycehendrix commented 9 years ago

Using the sandbox, I create a user with 2 credit cards using the drop-in UI. Each time I return the the activity it shows the last added payment method. If I change the payment method in the drop-in UI, I can see the payment method has been updated in the sandbox, but the payment method shown is never updated.

mickeyreiss commented 9 years ago

Unfortunately, the payment method ordering in Drop In does not account for the customer's default payment method. This ordering is determined internally by our API based on a payment method's last updated at and last used at timestamps.

We've received this request a number of times at this point, so we'll think about fixing up this behavior in the near future.

In the mean time, this functionality is not supported by Drop In.

micha-LEAP commented 9 years ago

Honestly, this needs to change. Either the API needs to change the order or the Drop-in needs to change.

hootener commented 9 years ago

@mickeyreiss I hate to spew negativity, but this bug is totally unacceptable. Let's walk through some disastrous use cases that this issue can allow:

I have two cards, an VISA and an AMEX. The VISA is my default. Using your Drop-in UI I set the default to the AMEX because, I dunno, maybe I'm afraid of going over a credit limit on the VISA, or it's linked to a bank account with a really low balance. So, I switch to the AMEX, but your Drop in still shows me, the user, that I'm paying with a VISA. This is frustrating because I want to use my AMEX, but to me, it looks like I can't. So what do I do? I file a bug report to the site that's hosting the thing I want to pay for, which they cannot fix. Or, I just don't give the site my business because their payment form (the one Braintree created, and the site has limited control over) seems sketchy and broken. In both scenarios, the vendor loses.

Another case, recurring billing not handled through Braintree's subscription system, but instead handled by the vendor. Using the same scenario as above, it isn't immediately clear to the user what card may be billed in a recurring fashion. User sets to VISA, but sees AMEX as the 'default' on the drop in. On the backend in BrainTree the default has been set to VISA, because that functionality through the API actually works, but the user sees AMEX. Is the user's VISA or AMEX being charged? BrainTree says it'll be the VISA, but the dropin shows the ''default'', the first card the user sees when the dropin loads, as AMEX. This can result in a nasty surprise if the user thinks they can't change the default from AMEX (which is how it appears to the user) when in truth they are setting the default and it's VISA. If that VISA is linked to a bank account that is dangerously close to overdrafting come time to update their subscription on the vendor's site, then the user is stuck with an overdraft fee they weren't even expecting, who gets to hold the bag for that one? At the best case, I'm getting a bug report and a nasty email, at the worst I've lost a repeat customer and stuck them with an overdraft charge.

Surely you see the issue here? You're conveying a complete misunderstanding to the end user. What's worse, it's completely beyond the control of the vendor to actually fix. We just get to throw up our hands and deal with it. This is unacceptable from a payment processor since you're placing your vendors into potentially negative customer interactions and it's completely beyond their control to do anything about it.

This is compounded by the fact that the PCI compliance burden is greatly reduced by using a Drop-In solution, so in many cases vendors are stuck with your drop in (if they choose to use BrainTree).

You all really need to fix this. Letting the user know correctly which card they're paying for things with is kind of a big deal...

cbetta commented 9 years ago

@hootener we hear your comments. The simplest solution would be this: show a custom UI that shows the user what their currently selected card is, and then only show the drop-in ui to change the card. You can pull all this information from the API, and you don't need to show the drop-in UI every time a transaction is made.

cbetta commented 9 years ago

You can see if a card attached to a user is their default by the default property. See: https://developers.braintreepayments.com/javascript+php/reference/response/credit-card

hootener commented 9 years ago

If this is the official stance from Braintree please provide a functional example of how to achieve it.

cbetta commented 9 years ago

@hootener not sure about official stance, just giving you the options you have. I'd be happy to provide you a code sample. What language are you developing in?

hootener commented 9 years ago

JS + PHP.

cbetta commented 9 years ago

Ok I'll get back to you.

cbetta commented 9 years ago

Sorry took me a while as I havent played with PHP in a while: https://github.com/cbetta/-default-card-example-php. Let me know if that works for you. This is pure PHP+JS but same ideas apply to a UI in Android.

mickeyreiss commented 9 years ago

@hootener Thanks for sharing your detailed use cases. This is exactly the type of feedback that helps us hone in our products. We have teams of developers listening, learning and iterating. I hope you are able to bear with us as we work to improve the situation.

As an SDK developer, I can empathize with your frustrations when our assumptions don't match your product. Unfortunately, Drop in needs to make certain assumptions in order to cater to a wide variety of e-commerce use cases.

This is compounded by the fact that the PCI compliance burden is greatly reduced by using a Drop-In solution, so in many cases vendors are stuck with your drop in (if they choose to use BrainTree).

We have a new product, hosted fields that you may find helpful for this particular aspect. It is a happy medium that reduces your PCI burden while giving you (nearly) complete control of the user experience. (Like @cbetta's solution, this will still require your site to handle the "card on file" flow directly.)

Finally, I can provide a little bit more information about the current behavior. Drop in currently sorts payment methods by last_successfully_used_by if applicable and then by last_updated_at. With this information, is there a way you can still use drop in in such a way that it aligns with your server-side calls to Braintree?

sdmurphy commented 9 years ago

@mickeyreiss Hosted fields? I clicked on your link and it takes me to Javascript. I also went to hosted fields in the Android guide (https://developers.braintreepayments.com/android+java/guides/hosted-fields/overview) and it also says that it is only available for Javascript.

Interestingly I am not having this default payment option problem, but I am having a different UI related problem. Which I will post as a separate issue.

mickeyreiss commented 9 years ago

@sdmurphy Correct, hosted fields is only available for Javascript. This issue is primarily focused on the JS platform (see https://github.com/braintree/braintree_android/issues/23#issuecomment-131877532).

sdmurphy commented 9 years ago

@mickeyreiss Ok, I see it listed as an Android issue.

darklow commented 9 years ago

+1, it is very very confusing for our customers to see not the default method or the one previously selected or the default, but something that was used some time ago.

Our use case and problem for monthly subscription: 1) Added Paypal, charged paypal. 2) After week added credit card, submitted (existing subscription is updated to credit card) 3) But after reload client still sees PayPal in Drop-in UI and he thinks method haven't changed. This is very very bad :(

benface commented 9 years ago

I have to admit, this bug is very disappointing. The Drop-in UI is miles ahead any other checkout solution I've seen in terms of ease of use and integration time, but not showing the default payment method as the default payment method makes no sense. Please fix it soon! (EDIT: I just realized this repo is for the Android version. I'm experiencing this issue in the web version.)

glennjacobs commented 8 years ago

I've been searching for ages to try workout why my Drop-in UI was showing the wrong payment method. Then I stumble across this issue, argh.

I have to say you would definitely expect the Drop-in UI to use the default payment method as the one initially selected. It can't be that hard to update the system to do this, defo needs fixing ASAP.

I'm now going to have to redesign my system to present a custom screen instead which is a pain.

tigerchen commented 8 years ago

+1 this needs to be fixed asap. it is terribly confusing for a customer to change their default payment method and not have changes be saved.

cameronbourgeois commented 8 years ago

+1 Fix ASAP. This issue makes for a very bad user experience.

dfejgelis commented 8 years ago

+1. Terrible UX

LEstefano commented 8 years ago

+1 Please, fix this issue.

mngiess commented 8 years ago

+1 Please, fix this issue.

DobromirZlatkov commented 8 years ago

+1 Please, fix this issue.

oreenge commented 8 years ago

+1 Please, fix this issue.

dhartless commented 8 years ago

Could a setting be added in the control panel (preferably by merchant Id) that would allow us to toggle from the default ordering behavior when the payment methods are displayed?

sdcoffey commented 8 years ago

Hey guys,

Thanks for being patient with us. We've just made a change to the backend which addresses this issue, and we'll be rolling out point releases of the SDKs next week! We really value your input on this, and we'll keep you posted as we roll out new releases with this change.

Cheers

jdutto commented 8 years ago

Hello @sdcoffey, any update regarding the SDK release? In which version will it make it?

By the way, am I missing something or is my problem also valid:

Thanks!

LEstefano commented 8 years ago

Hi @jdutto,

You can establish some parameter when you generate the client token, one of them is "make_default". You can see it here: https://developers.braintreepayments.com/reference/request/client-token/generate/ruby

It works if you create a new payment method through the Drop-UI, but not if you have several and select one which is not the default one. It won't be updated as the default one, at lest if you don't process a transaction in which you define the payment method selected as the default one.

I already asked for this feature, and they said something like if you are only looking to let the customer switch default payment methods, you can also run the Customer.find and this should return all payment methods associated with that customer (credit cards and PayPal accounts). You can display these methods to the customer in any fashion you would like and the run a payment method update call to set the payment method as the default. And I think they don't have any plans to make this accesible from the Drop-In UI.

Regards, Luis

hootener commented 8 years ago

"You can display these methods to the customer in any fashion you would like and the run a payment method update call to set the payment method as the default"

Beware. This does not work with Coinbase. So if you're planning on joining the coinbase beta and accepting bitcoin, you cannot actually use this method (or any method that I've found so far) to set it as the default payment method. I filed an issue about this which was closed since BrainTree has no plans to it anytime soon.

@jdutto There are numerous UI/UX problems with the dropin to be honest. So much so that I would recommend not using it especially if you're planning on working with a recurring billing / subscription model.

lkorth commented 8 years ago

A fix for this just went out in 2.2.4. When constructing a PaymentRequest you can now set PaymentRequest#defaultFirst.