Closed ahmetws closed 4 years ago
Hi @ahmetws
Thanks for feedback! I'll bring it to a product design team for discussion.
Alternatively, you can dismiss the dropIn on didSubmit
and handle "busy" UI state on your App's level. Follow this discussion #181
Thanks @descorp,
I'm working with @ahmetws on the same solution.
Ideally for us the SDK would handle this, as otherwise it increases the number of moving parts in our app.
Whilst I agree that handling this manually ourselves would be an option, in our opinion disabling the UI from the user during a crucial purchasing loading phase is something we'd have hoped for out of the box. It saves unexpected work now, and also makes our solution more robust long term.
There is an issue with dismissing the dropin, in that it causes user data to be lost and they have to refill the form again in the case that there is an error they can recover from (i.e wrong card number, expired card, etc). Basically, they have to start all over again. Correct me if we're wrong here.
In the case of paying with a stored payment method, they are also able to press "change payment method" during the process of the payment being made, which also feels wrong and can confuse the user. You can see in the screenshot below.
This means the user can escape the payment processing in two ways:
This feels a bit broken to us from a UX perspective.
(Android handles this a bit nicer, by opening the card form up, so there is no "change payment method" option once payment has been initiated on that platform). Though our Android dev still reports he has no control over the cancel button in that SDK also.
We've got a small amoun of time up our sleeve before this app goes to production (it's a fairly high profile application). We're wondering if there is any scope at all to fast track these features to the SDK?
Is it a small undertaking, or does it require a bit more work than we realise? If we had time we'd dig into the source ourselves to understand.
Might also be worth considering the setup in the following screenshot. After choosing a seperate stored payment method and entering your CCV in the pop up, there is no loading indicators such as is offered when the drop in defaults to a stored payment method on open (as per above screenshot).
This gets the user into a situation where they could make multiple payments if they wanted to.
Again I understand the ability for us to dismiss the modal and show our own loading modal of some sort, but thought this is worth mentioning for the sake of completeness.
Hi @chrispaynter
Great thanks for your contribution! You guys are on fire this week :D
cancel button
That was an easy fix. We will include in 3.6.0!
also able to press "change payment method" during the process of the payment being made
This is already fixed in 3.6.0.
no loading indicators such as is offered when the drop in defaults
This was a bug on our side, introduced in 3.5.0. Easy fix. Will be included in 3.6.0
Just hold on till release. We are planning to let it out before the end of the week.
@descorp that's great, thanks very much for the fast response! 🔥 We really do appreciate it, as does our client, and we look forward to 3.6
Do you think that this is something that might be looked at in the future?
@chrispaynter
yes, loading state for list of "All payments" also added in 3.6.0
ok well that's an incredible result, thanks very much for this @descorp! (and your team)
Hi @ahmetws, @chrispaynter
3.6.0 with a fix is released. Could you verify if everything is working fine for you?
Hey @descorp thanks for this. I'll pass this on to our native guys!
I am going to close this ticket for now. Feel free to reply or post any related issues.
I'm using the dropin component to make a payment. When the user taps on the pay button, the component disables the fields but not the cancel button. User still tap the cancel button and close the modal. It would be good to have an option to disable the cancel button or show an alert before the modal dismissed.