#jackmullinkosson_api
1 messages · Page 1 of 1 (latest)
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- jack_connect-applicationfee-checkout, 1 day ago, 10 messages
- jackmullinkosson_api, 6 days ago, 30 messages
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1255595994616172565
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
Hello
The only way you could do this is by setting a custom_field: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-custom_fields
Otherwise you can't pre-fill phone
Got it - so how would you prefill a custom field?
Note: the customer can still change anything that is in a custom_field as they are generally used to collect custom info from your customer
Got it
I was also wondering how I can pass some arbitrary value which won’t be shown to the customer. I want to pass an eventId which I will use in the subsequent webhook which is triggered on successful checkout.
Got it thanks. And metadata is passed with the webhook?
Yep the full object is passed through in the Event which your Webhook handler receives
Okay. Just want to make sure I understand the default_value syntax. I'm in node.js:
custom_fields: {
type: "numeric",
numeric: {
default_value: 8479044099,
},
},
Would that be correct?
Yep looks right to me
Recommend testing it out
You also need key and label
Not sure if you just omitted that
And it is an array
custom_fields: [
{
key: "phone",
label: "Phone Number",
type: "numeric",
numeric: {
default_value: 8479044099,
},
},
],
and is there a way to make it mandatory?
And I believe it is mandatory by default iirc
Okay okay okay
Hold on @leaden thicket
I forgot we changed this recently
What you actually want to do here is create a Customer object and set phone on that Customer
Then pass the Customer object to the Checkout Session creation
I forgot that we now do prefill phone in that case
Sorry for leading you astray with custom_fields above
All good
So before you redirect to Checkout, create a Customer and set phone: https://docs.stripe.com/api/customers/create#create_customer-phone
Then pass that Customer ID to you Checkout Session creation request: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-customer
And if you have phone_number_collection enabled then it will be prefilled
Is there any downside to using the custom field? It's better for my end users to only collect the email and phone number on checkout
Hmm not sure I understand?
I thought the idea was that you already collected phone number here
And you didn't want your user to enter it again
In some cases we won't have already collected the phone nuimber in some cases we will
only want to prefill if we already have it
but don't want to add another step in case we don't have their number yet
That's fine, if you haven't collected it yet then you can just omit the phone paramater when you create the Customer or simply not pass a Customer object at all
There isn't any extra steps here
Your integration handles all of this when you customer clicks your "pay" button
Gotcha. Wouldn't I also want to first check if the customer already exists? Before creating a new one
Yep
I don't think creating a customer beforehand provides any benefit to us
we're storing the customers in our own db
so this would just be two extra unnecessary requests
Overall it is up to you -- if you prefer to use custom_fields then that works too but is a bit of a workaround for the recommended path here.