I'm worried about you all and SCA
If you use Stripe, there is no way you haven't heard about the changes that SCA (Strong Customer Authentication) will bring.
I just looked over a few implementations of people who claimed to have done their SCA work, and found that after September 14, their payments will probably get rejected. The docs for this are super obfuscated, migrating is hard!!
I just spent pretty much all of summer getting SCA ready with three apps. The implementations for those were pretty heavy (Connect platforms, subscriptions, off-session payments), so while I'm not a pro and super worried about failing SCA myself, I do believe I have some insights now.
Some facts for you upfront:
- SCA will start in September in Europe. Banks may block payments if a two-factor authorization is not possible -> you're losing revenue
- Banks may also ask for subscriptions to be re-authorized. Stripe has tools for this, but they don't work with some Connect platforms. Make sure you know how to bring people back online!
- You will have to get rid of your Checkout popups and migrate to version 2.
- You will have to update your Stripe Elements implementation
- You might need to update your Stripe SDK and their Billing implementation
- Stripe Charges do not exist anymore and will fail with SCA
- If you're not charging people immediately, you will have to build a new way to tokenize the cards (PaymentMethod API) and might need to bring people back online, once you're charging.
I'll check the comments here, so just shoot if you have questions. If you haven't started the SCA migration yet - do it. It's pretty serious (if you're looking to keep your customers in EU)
Personally, I would advise:
If a redirection doesn't pose a problem in the payment flow for your business, I strongly recommend using their new checkout. It is no longer an overlay but a payment page hosted by Stripe fully compliant with all necessary features. This saves a lot of time and work.
I'm not sure anymore but I don't think it's compatible with Stripe Connect at the moment.
+1
Did this, works like a charm!
I like how professional it looks as well: no need to add "secured with stripe" anymore, just create a button and dynamically redirect your user to Stripe with JS. Even simpler than the custom form I used to have.
Definitely agree! You also get a nice looking order page out of it, definitely recommended.
While the "Client Integration" (redirect via JS) does not support many features, with the server-side integration (redirect via Backend), it supports pretty much anything that the custom flow would.
For a variety of reasons, 2/4 of the apps I migrated are running with Elements/Stripe.js. Happy to help there too.
Using Stripe Element, the migration is really a little more annoying. Before we even talk about SCA Compliance, we need to modify our integration to use the Payment Intent API.
I only regret the fact that when they announced this new API, they did not "force" migration a little because with the new law in Europe, it is a race against time for those who had not even made this change.
It really depends a lot on the integration. If you're using Stripe Billing already, you can update your API endpoint and just need to process the token generation and customer handling a little differently, and can keep the rest of the integration pretty much the same. There are also built-in recovery options. If you've been using the low-level Charges API, you need to migrate to Payment Intents, which is, as you said, a "little" more annoying.
It's also a better alternative if you're just collecting payment information for later (off-session), because checkout seems like a, well, checkout page.
I agree. I saw that people, especially in the US, procrastinated this a little. Now there's one more month until everyone needs to be updated, and the docs are pretty difficult to navigate if you have a custom integration.
Can I ask how you handled checkout.seasion.completed i.e fulfillment for new checkout? From what I can see the only way to complete a checkout is using webhooks? Redirection to success url does not constitute successful payment?
I used the webhooks. It's kind of annoying for local development though. I used ngrok to get the callbacks locally then you have to do some juggling to match up where the hell this charge is coming from.
Not sure if this is the best solution but basically I
That is exactly right. You need to listen for the webhook after the redirect to confidently know if a charge has succeeded.
In this case I also think the new Stripe Elements with Setup Intents is handled a little better, but for one-time charges, you should use Checkout and listen to the webhook.
Thanks both, it’s a far cry from the old checkout where could just drop a script on the page. Far less non-dev friendly too! Win for 3rd party apps that can re-simplify 😀
Some weeks ago we re-wrote our payment flow to leverage new Stripe Checkout, which takes care of SCA. I shared some technical details here: https://mkdev.me/en/posts/how-to-use-new-stripe-checkout-with-ruby-on-rails-application
Hi -dqmonn, I'm trying to migrate my checkout and I'm having a lot trouble.
I'm more specifically trying to integrate the checkout server side but I'm having trouble passing the session ID from the client side to server side.
Is this something you think you could provide guidance on?
I would really appreciate any help from anyone!
Hey Bissy, definitely.
Your issue sounds like a rather simple one - feel free to ping me with more details. If you're not using one of their SDKs for your programming language already, that will help a lot.
There are already a few threads on IH about SCA, and it really is quite confusing. Even Stripe support has given me some confusing information.
The tricky and confusing part for me, a non-EU business, is do I need to do this. The answer is pretty much yes and no. The types of transactions between non-EU businesses and EU customers are called "one-leg transactions" and don't technically apply to SCA regulations. That said, some EU banks may apply SCA regulations globally according to Stripe support.
So if you have EU customers, even if your business isn't in the EU, and you use Stripe and you can upgrade to the new payments flow, you probably should. This is Stripe's recommendation.
Yes, exactly. The tricky part is that there is no information and no strict rules on how banks will deploy SCA. The same way that, in theory, you should only need to authorize a recurring payment once at setup - a bank might decide to require SCA after every 6th or 12th consecutive charge, which is why you need to have a recovery flow.
I suspect 'one-leg transactions' are going to be handled similarly.
Thanks for the heads up!
Right now none of the tech projects I'm responsible for have direct Stripe integrations, but I do take money through Stripe via 3rd parties like Podia...
Do I need to worry about any of this?
I don't think so, you'd likely get a message from Podia if you would have to take any steps, but if the payment processing is on their side, they will do the hard work for you. There is more work involved if you're somehow saving cards for later or have a custom checkout flow/integrations.
Great, thanks. I’m glad I’m not responsible for making any of those changes :)
Yeah, Stripe's APIs really became hard to navigate compared to a year ago. I'd recommend any resourceful maker to take the small pricing hit and go with Recurly, Memberstack or whatever.