#xzel_api

1 messages ¡ Page 1 of 1 (latest)

robust abyssBOT
#

👋 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/1232174418919166033

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

iron tartanBOT
spark mauve
#

In the Checkout Session creation, e.g. https://dashboard.stripe.com/test/logs/req_eF29gW0FOlFVJ8, I don't see customer being set in request, which was different from your claim:

We already have a user portal and create stripeCustomerId's to pass into their checkout sessions.

If customer (Stripe customer ID) isn't set, new customer will always be created.

scenic bough
#

Yes this is a no friction session

spark mauve
#

What is no friction session?

scenic bough
#

Ah so this we want to offer on our homepage

#

where a user doesn't need ot make an account

#

I had thought stripe would make a single customerId per email or something along those lines

#

and then once they made their account I could pull their userID via the email, which I can do

#

Obviously there are a few edge cases outside of that single flow

#

Which is really my question becasue I wouldn't think I'd be the only person trying to offer a quick/no account sign up as well as tying them to my own customerID

spark mauve
scenic bough
#

Beautiful

spark mauve
#

I'd recommend giving it a try in test mode

scenic bough
#

ah wait lol this would also not work for me because users can have multiple subscrptions

#

I saw a few previous posts asking similar questions. In theory I could delete the subscrption and create a new one that doesn't have a billing component on the "master" customerID, but I would assume I'd be dangling the other payment methods

spark mauve
#

If you want to create a subscription under a single customer, the steps will be:

  1. Create a Stripe customer that corresponds to your own customer ID
  2. Create the Checkout Session with customer ID set in Step 1

This will always allow Checkout Session to link to the specific customer without creating a new one

scenic bough
#

Yep that is currently what I have implemented. So there isn't a good way to do a no account method and have stripe tie them together

#

I can't hijack the stripe flow I'm assuming?

#

and inject my own customerId at some point?

#

I would have to do that at session creation and thus need an account made

spark mauve
scenic bough
#

2 types of session requests: 1) user account isn't made - helps increase checkout conversion rate b/c decreases friction 2) user account is made, I create and assign them a stripe user id

scenic bough
#

that one is with an account already created

iron tartanBOT
spark mauve
#

I see! If (1) is used, then a new customer will always be created regardless whether the email address has been used before if customer isn't set.

I'd recommend collecting email address in your system first, then create a customer ID against it. Regardless whether the customer has an account or not, it will always use the same Stripe customer ID

scenic bough
#

doi that makes sense thank you lol

#

So some friction will be necessary and I'll have to put another http call in front of the checkout session

#

which isn't the end of the world in my opinion

glacial seal
#

Hi @scenic bough I'm taking over this thread

scenic bough
#

in theory I could also not use a session create call and do everything fully managed with only the API

#

and create and or find the stripe customer ID before sending off the rest of the data

#

I don't love handling CC info myself even just in transit but that would also not be the end of the world

#

Hi Jack

glacial seal
#

Feel free to let me know if you have any follow-up questions

scenic bough
#

Will do. I think have at least the start of a solution going. If you don't mind leaving this ticket open I'm going to talk with my team tomorrow and see if these work arounds will do.

#

I don't really want to ditch the checkout session flow at the moment as it will take a lot more work re-creating and making sure things are secure. So if I can get by just asking for an email and then rendering the checkout session, I'll do that.

#

I guess my only concern would be allowing people to just type in emails and possibly see if an stripe customer ID was made... so maybe that won't work either

glacial seal
#

The thread will be closed after some time. Feel free to come back again tomorrow and use the button in #help to create a new thread.

scenic bough
#

Do you have any recommendations for this? I would assume this is somewhat of a common problem no?

glacial seal
#

perhpase you want to have a email verificaiton and login system for you app, so that you can ensure only logged in and verified customer is able to proceed.

scenic bough
#

Yes we have that, we also wanted to try to do a no hassle checkout which would then flow into account creation

#

I think we will just have to find a balance, like forcing a user to put their email in first, and then punting them to account creation if one is already made

#

or login

glacial seal
#

You can ask them to login first, once logged successfully, create a checkout session with the customer ID, the checkout page will prefill the customer's email on the page and make the email field uneditable.