A wallet isn't the intent. It's almost the opposite!
If you remember the previous version, your customers used their saved card within Checkout. The new version of Checkout lets your customers use whatever payment method is easiest for them, and wherever it is. That's why we're big fans of things like Apple Pay (some have seen a conversion increase of 250%!), local bank payments in Europe, or even saved cards in Chrome (rolling out now).
From its inception, Checkout was designed to be the fastest way to accept payments, and I think it's now faster (and even faster for customers). You can just drop in a single line of code—and that code doesn't have to be server-side. :)
> A wallet isn't the intent. It's almost the opposite!
But isn't that what you just described? Saving your payment details to Stripe (as opposed to just entering your card details like a standard payment processor). Stripe is now essentially a wallet where you store your payment details.
Was it a necessary change to push users out to Stripe to save their payment info? What differentiates that from what was there previously. Was it that the CC info was stored per-domain, rather than per customer across all sites?
To be clear, I think it could be an improvement for a lot of cases - just potentially not mine in particular!
> Checkout was designed to be the fastest way to accept payments, and I think it's now faster
Here's a pretty common scenario that definitely just got more complex to implement: dynamic pricing + instant fulfilment (i.e. selling digital goods online).
So that instantly rules out the "No server-side code" approach. Here's what had to be done in the old version:
1. Import checkout.js
2. User clicks pay + fills out details on Merchant site
3. Merchant js makes a call to Merchant server with Stripe token
4. Merchant server calls Stripe to charge the token
Now:
1. Import checkout.js
2. User clicks pay
3. User has to wait for loading spinner while a Stripe session is generated on the Merchant backend and passed to checkout.js
4. User is pushed out to Stripe website to pay + fills out details
5. Stripe backend calls Merchant webhook
6. Customer redirected to Merchant
7. Merchant server must check with Stripe to see if session was completed and customer has successful purchase.
Overall - that's a more complicated flow for the Merchant to implement, with more room for things to go wrong.
And it's not technically true that the flow will always be faster for users - if the customer had CC details saved in the old version, the flow would have been faster for them (less async calls + no redirect to Stripe).
For a certain segment of Merchant, I think there are definite improvements - but for the one-person operation selling software - PayPal is now the easer to implement option.
But the whole question of "which payment method do you want to use?" is unnecessary complexity if they're sitting there with a card in their hand. Wouldn't it be better to let the front end service handle that question, and then use the appropriate Stripe APIs in the front end?
The whole revelation of stripe was that if a customer was sitting there with a credit card, they just put it there into the same screen and it was done. It was the other crappy products that forced you out into a merchant gateway then back again
I'm never going to send retail customers out a payment gateway with someone else's brand/colors/html, mostly because it's just too confusing to introduce more concepts at that critical stage when they're about to actually make the payment
I'm never going to send retail customers out a payment gateway with someone else's brand/colors/html, mostly because it's just too confusing to introduce more concepts at that critical stage when they're about to actually make the payment
This is one of the concerns we have with SCA. By the nature of the additional authentication steps, they are necessarily hosted off-site in some situations. Handing your customer off to some other service in the middle of your payment flow and hoping they make it back is the only choice you have. It seems likely that this will reduce conversions, just as anything else that lengthens or complicates the payment flow usually does. What we don’t really know yet is how much difference it will make in practice.
This is one of the concerns we have with SCA. By the nature of the additional authentication steps, they are necessarily hosted off-site in some situations.
Is this a necessity though? Couldn't they just enter the 2FA code in the same manner that they enter their card details on the merchant site? i.e. After entering their card details, it will just prompt them for more info if necessary.
I’m not sure exactly what PSD2 requires in this respect without checking it again, but in practice I think all of the major schemes for card payments that actually exist do work that way, so it’s probably beyond the ability of any service like Stripe to avoid at the moment.
If you remember the previous version, your customers used their saved card within Checkout. The new version of Checkout lets your customers use whatever payment method is easiest for them, and wherever it is. That's why we're big fans of things like Apple Pay (some have seen a conversion increase of 250%!), local bank payments in Europe, or even saved cards in Chrome (rolling out now).
From its inception, Checkout was designed to be the fastest way to accept payments, and I think it's now faster (and even faster for customers). You can just drop in a single line of code—and that code doesn't have to be server-side. :)