#john-l_best-practices

1 messages · Page 1 of 1 (latest)

unreal yachtBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1344755512524279962

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

pulsar violet
#

Hello!

Are these options correct given what I’ve provided?

Those links seem relevant to your situation, yes.

Do any of these processes link out or redirect for specific cases?

Yes.

What fields are required for each option? We would potentially hide email, country, zip code, and cardholder name if possible.

The answer here is "it depends" but generally for card transactions we require at least country and postal code at minimum.

Does either solution make it easier to migrate?

Not sure what you mean by "either"? Which specific two options are you referring to?

I’m specifically thinking about users upgrading and being able to use their existing payment method. I’m aware of the allow_redisplay value but not sure if cards added in this old checkout process would have set that or even had the option.

They would not, but you can update those older ones and set that value as appropriate, as long as you have consent to do so from your customers.

unreal yachtBOT
left scarab
#

ahh part of my "what are you working on" was cut off

#

here's the full thing:

We are migrating from a very old checkout.js integration used to purchase a subscription. It shows the outdated modal window to input card details. We want to replace the old modal with a new more native and fresh looking UI and keep the entire process on one page without redirecting offsite. I'm testing EmbeddedCheckout and Payment Elements. It looks like these 3 options are our best bet:

  1. EmbeddedCheckout
  2. Payment Elements w/ Stripe Session
  3. Payment Elements w/ Payment Intents
#

so those 3 options are what i'm referrin to in:

Does either solution make it easier to migrate?

Not sure what you mean by "either"? Which specific two options are you referring to?

young quest
#

Hello, my colleague has to step out. Catching up...

#

It has been a bit since I've seen a Checkout.js integration, refreshing myself on what those look like. I think either would be roughly the same sized change from that but am thinking a bit more. Either should be able to support redisplaying your saved payment methods from your old integration

#

Though as you may have seen, all of your PMs saved that way will have allow_redisplay: 'unspecified' so you will need to update that field on any PM that you want to show up

left scarab
#

For any of these solutions would I have to fetch and build the UI for the payment methods ? Like in the case a user upgrades to a new plan, what is the best way to do this? It looks like the EmbeddedCheckout wouldn't be a good option here and instead we would show the current card/PM and let the user change it which could use EC. However if they keep the same card we would just want to render the current card on the subscription (and maybe others on the customer) and then just include a button to upgrade. Does that make sense?

#

this is what we currently have in place to upgrade

CleanShot_2025-02-27_at_15.05.582x.png
#

and here's how you add a card and then subscribe with the old checkout.js

CleanShot_2025-02-27_at_15.07.382x.png
young quest
#

If you are looking to work with both new and existing subscriptions, that may be a good case to use the Payment Element. The embedded checkout element can only create new subscriptions

left scarab
#

that's what I'm thinking

#

and that leads me to : What would make me use Payment Intent vs Stripe Session? I see the former says it is more advanced, but I don't see a specific feature list or comparison

young quest
#

I am trying to remember if we have a doc that compares the Payment Element to Checkout and such. Basically Checkout wraps Subscription creation so it does some things for you but at the cost of some flexibility. With the Payment Element, your code is doing more but that means you have more control over how things happen and have access to more settings

#

And also there are scenarios like existing subscriptions that the payment element can handle but Checkout can't. So with Checkout you would need to cancel the old subscription after Checkout created a new one

left scarab
#

okay -- thanks... i think i've got it

young quest
#

Awesome, let us know if you run into any further questions!

left scarab
#

oh one more thing... when it comes to redirects or reasons a customer would be redirected, it looks like return_url on the Session is one of these that's required

#

is that true that it has to redirect?

#

later on we might put the entire flow inside a modal so a user can upgrade within their current feature path and we'd prefer not to lose the state

young quest
#

That varies payment method to payment method, but yes some payment methods require it. In stripe.js when you confirm your payment intent, you can specify whether to always redirect or only do so if required
https://docs.stripe.com/js/payment_intents/confirm_payment#confirm_payment_intent-options-redirect
We document whether each PM requires it or not in our payment method type docs
https://docs.stripe.com/payments/bank-debits#api-support
https://docs.stripe.com/payments/bank-redirects#bank-redirects-api-support
https://docs.stripe.com/payments/bank-transfers#bank-redirects-api-support
https://docs.stripe.com/payments/buy-now-pay-later#api-support
http://docs.stripe.com/payments/real-time#api-support
https://docs.stripe.com/payments/vouchers#api-support
https://docs.stripe.com/payments/wallets#api-support