Earlier quoted context omitted.
> Why isn't it removable? Well, I tried to outline the thinking above, but we're not absolutely attached to it either. If there is some reason it's bad for your customers, we'd love to talk. Can you drop me an email? I'm patrick@stripe.com.
What if you could request a semver range for the checkout js file? That way vendors could opt in to fixes, enhancements or major changes and be confident in the level of volatility in UX for their customers.
Stripe Checkout
131–140 of 214 posts
Re: Stripe Checkout
#132Stripe Checkout is nice, but unfortunately it's not suitable for us, since the "Remember me" checkbox cannot be hidden. "Remember me" is confusing for users. What is being remembered? By whom? When you're dealing with users who may already be concerned about whether it's secure to enter their credit card number into your website, I feel like the "Remember me" box is just adding another layer of confusion and concern.…
[Tl;dr on the below: the changes we make to Checkout are designed to increase our merchants' revenue. If a change doesn't do that, it will be reverted.] The confusion point you cite was our biggest concern in building the "Remember me" functionality. On the one hand, it's clearly good for our merchants* if customers don't have to constantly retype their card details. On the other hand, it'd be bad if we were scaring…
It still doesn't matter if Remember Me is better for merchants or not. What matters is whether the merchant wants to be able to hide that feature or not. If they choose to shoot themselves in the foot, it should be their choice.
There are only a few actually plausible reasons why a service would prevent turning this feature off. A nanny mentality (we know what's best for you), which is insulting to the merchant/s. Or because Stripe is pushing something primarily for their benefit, and all the 'explanations' are nothing but rationalizations to make that smell better, the merchant's wishes be damned. Both scenarios are bad.
Re: Stripe Checkout
#133Re: Stripe Checkout
#134Re: Stripe Checkout
#135Now if they only did same/next day payouts. The founder once said this was possible if you emailed him. I emailed him and got zero response, from him or anyone else, so I'm guessing they are only doing this for super high volume merchants.
Oh no, I'm sorry. I've no idea what happened. Want to try my personal email? patrick@collison.ie.
Re: Stripe Checkout
#136I suppose your site still needs to have SSL in order to use Checkout?
Re: Stripe Checkout
#137Earlier quoted context omitted.
That philosophy works fine with merchants who hope for repeat sales from the same customer. But what about subscription payments (what I use Stripe for). A remember me button doesn't make sense there, as they are never re-entering the data to make another purchase. Perhaps you didn't test it with enough variety of merchants?
We definitely tested it with merchants who take subscription payments. But, yeah, the considerations are different, I agree. The primary motivating use case for Checkout was "standard" checkouts rather than subscription flows (even though it works well for the latter). I suspect we'll take a look at redesigning that flow entirely at some stage, with a product that may look quite different to Checkout.
My 2 cents.
PS. If Checkout is an experiment still, I would highlight that on documentation. One can't expect people to go and read announcement blog posts dating back a year.
Re: Stripe Checkout
#138Re: Stripe Checkout
#139Re: Stripe Checkout
#140Earlier quoted context omitted.
The canvas element is only used on Chrome as it has a hard time rendering animations above a big CSS radial-gradient. The whole animation is just using DOM elements, CSS transitions/animations and requestAnimationFrame. And yes, entirely handmade :)
If the code is modular enough, would you mind open sourcing it (or blogging about how you developed it)?