This is a really bright idea, in that almost all companies do an absolutely bloody abysmal job of implementing their checkout flow. The median testing budget for it is generally zero, unless you scope the population to "large, savvy ecommerce providers." I love the idea of being able to basically take advantage of the herd effect for optimization, and clearly there are non-linear advantages to the Stripe ecosystem, because getting credential/CC pairs into the system most probably increases systemwide spend on them and that is how both merchants and Stripe make their money.

I'm probably going to try this in Bingo Card Creator in an A/B test against my existing purchase flow at some point. I'll be honest: the likelihood of the average English teacher knowing Stripe does give me a bit of pause with regards to the UX and the prospects of my VA having to answer a lot of "Who is Stripe and why are you telling them my credit card number? Did your Googles get a virus?" emails. Still, seems like it is worth testing. Worse comes to worse, all you do is go back to the pre-existing checkout flow, like whatever Stripe.js integration you're using right now, and then you have full control over the experience.

I have seen and supervised successful redesigns of purchase experiences before. They print money. BCC got a 60% or so lift in purchases using a Stripe-powered checkout back in the day, after some hillclimbing, discovery of synergistic effects, and burning the kinks out of my integration. I think there's likely motivational numbers hiding in a lot of your businesses. You should absolutely be testing them on a regular basis yourselves, but this seems to be a decent stab at a way of doing testing without requiring focus/bandwidth or major traffic [+], which are two major reasons people give me for not testing.

[+] I have noticed many people suggesting "You could do per-account multivariate testing on e.g. whether the Remember Me button is a win or not", and feel obligated to point out "That will probably only work for accounts which are doing, minimally, thousands of transactions a month." The great thing about this is that if you've got only 2k visits a month and 40 purchases if we assume that systemwide performance is a good proxy for your performance (and n.b. that's an assumption which is tractable to measurement) then we can still get solid test results by using the other millions of visitors and hundreds of thousands of transactions flowing through the system every $PERIOD.