4 ms·

I quite like Stripe - but them forcing the recent switch to Checkout V2 has me a bit miffed. Previously it was super simple to add dynamic card payments to a s

I quite like Stripe - but them forcing the recent switch to Checkout V2 has me a bit miffed. Previously it was super simple to add dynamic card payments to a site - just drop the JS in, make a call to your server and then call Stripe from your server. Done. And it's all done in a popup on the same page (so no context switching UX for the user). Now it seems they've killed the simplicity of that in favour of a more PayPal-like experience - where the user gets pushed out to the Stripe website to checkout. And it becomes more complex to implement too - due to everything being async and webhook based. At this point I think Paypal might actually be easier to implement for a certain class of simple one-off payments (although their sandbox servers are cripplingly slow). I'm a little bit skeptical of this change because I think it's partially a strategic play by Stripe (with the smokescreen of SCA-compliance + Apple Pay support) to become more of a user-facing online "wallet", rather than just a behind-the-scenes payment processor.

edwinwee 7y ago
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. :)
- ENGNR 7y ago
  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
  - Chris_Newton 7y ago
    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.
    - GeneralTspoon 7y ago
      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.
      - deleted 7y ago
        [deleted]
      - Chris_Newton 7y ago
        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.
- GeneralTspoon 7y ago
  > 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.

edwinwee 7y ago

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. :)

ENGNR 7y ago
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
- Chris_Newton 7y ago
  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.
  - GeneralTspoon 7y ago
    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.
    - deleted 7y ago
      [deleted]
    - Chris_Newton 7y ago
      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.
GeneralTspoon 7y ago
> 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.