We've been hard at work on improving the Checkout experience.
Try it out at checkout.stripe.dev ; it will create a mockup for your use case (e.g. typical SaaS plan) and let you see what the UX looks like a typical user in several countries.
Try it out at checkout.stripe.dev ; it will create a mockup for your use case (e.g. typical SaaS plan) and let you see what the UX looks like a typical user in several countries.
Checkout (and for SaaS companies our customer portal: stripe.com/docs/billing/s… ) tries to move as much of the silly cruft of getting the business running to us, so that you can focus on talking to users, building product, and delighting people.
Back during my consulting career I fought like heck to get companies on a cycle of testing and refreshing their checkout flow quarterly. Almost nobody managed to do this. When we looked at git logs, most people hadn't touched it in years.
I get it, believe me: there's always something more pressing to do in the business, and it is usually more fun than *blows horn* form field data entry optimization woooo.
(There are also formidable institutional issues with assigning engineers to care about that sort of thing.)
(There are also formidable institutional issues with assigning engineers to care about that sort of thing.)
Because Stripe has millions of businesses using us and because your success in aggregate is our success, we can justify putting teams of very talented people on the optimization of Checkout every day of the week.
This covers table stakes things which oddly aren't table stakes. Why are checkout flows so #%()#%) bad?! Why would *anyone* force you to declare your credit card type when it is inferable from the freaking number? Why isn't the number typo checked in real time?
We did all that.
We did all that.
But we can go layers beyond that. Things that most companies will say "Uh, edge case, WONTFIX" due to engineering effort required are things we will see thousands of time per day.
Do you sell SaaS internationally? Got any users in Japan? Cool. A surprising portion of them will have *any* checkout break the first time they use it because their IME is set to zenkaku and so their credit card number will look like ４２４２４２４２４２４２４２４２.
If your team hasn't special cased that, and if you do not have an engineer living in Japan I will bet at 1000:1 odds that you have not (go try it if you don't believe me), you'll give the same error you would give if I typed "MY CREDIT CARD" into that box.
We just do the right thing automatically.
Got users in Europe, who are now covered by the Strong Customer Authentication standard, and whose banks may decline transactions if you don't have a special code path covering that interaction? Checkout already has it done.
Got users in Europe, who are now covered by the Strong Customer Authentication standard, and whose banks may decline transactions if you don't have a special code path covering that interaction? Checkout already has it done.
And the cool thing is, as the world gets more complicated over the next 5 years, the payments-related complexity lands on us rather than you.
When SCA launched *a lot* of businesses suddenly had priority:critical engineering tickets filed to do complicated low-value work.
When SCA launched *a lot* of businesses suddenly had priority:critical engineering tickets filed to do complicated low-value work.
For a variety of the unknowable things the future holds, you'll never even see that ticket. Some team at Stripe will have implemented it long before anyone at your company discovers that it is a new regulatory requirement (or new wallet making waves in Southeast Asia, etc).
More details (and, of course, a live demo) here: stripe.com/payments/check…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
