#filipe_ewcs-address
1 messages Β· Page 1 of 1 (latest)
π 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/1489282329967984648
π Have more to share? Add more details, code, screenshots, videos, etc. below.
this is a repro
the reason we want to disable autocomplete is because we're using react-native-web and it renders like this, but doesn't seem related to stripe
Essencially, how can we enforce phone number and disable autocomplete, particularly with checkout session elements?
filipe_ewcs-address
@haughty plover let me have a look
yeah I think we just don't support this yet unfortunately π
It'd be a feature request, I recommend reaching out to our support team via https://support.stripe.com/contact/email?topic=api_integration and they can look into prioritizing this
Phone number enforcement does seem to be a documented feature, just not working seemingly?
With phone number collection enabled, Checkout adds a required phone number field to the payment form. If youβre collecting a shipping address, the phone number field displays under the address fields. Otherwise, Checkout displays the phone number field below the email input. Customers can only enter one phone number per session.
What do you mean by "not working correctly" exactly? Like the number is not collected? Or it is but it's not required?
It is implied that the checkout should collect it, it doesn't
I can re-share the repro if needed, buts its as simple as exporting from https://docs.stripe.com/payments/quickstart-checkout-sessions?lang=node and changing the stripe.checkout.sessions.create to include phone_number_collection as true
Hum sorry I'm struggling to follow what you mean π
We've set phone_number_collection to be enabled
The docs say when that's the case, Checkout will collect & require the phone number
But it doesn't seem to be doing that (either - field doesn't appear)
Ah gotcha, those docs are for the hosted Checkout version (when you send them to us) or the Embedded Checkout one (where you render the iframe). It doesn't yet work with Elements with Checkout Sessions
Is there a way to manually add phone number collection, e.g. a specific element?
In elements mode, is it possible to mostly use our own UI, setting data on the checkout via the JS APIs, then using the actual elements for the payment step?
Hello π
I'm stepping in as my colleague needed to go
It probably makes sense for us to use embedded for now and then look at a deeper integration if that is indeed possible. We have been working for the last week or so on moving away from a payment intents-based approach to checkout sessions π
So you want to collect the Cusotmer's phone number as part of your checkout flow and record it in Stripe as part of your Elements with Checkout Sessions integration?
If you have your own UI where you can collect that information, it is possible to supply it to Stripe in two different ways during the Checkout flow
- You can upate the Checkout object with it using the
actions.updatePhoneNumberfunction we describe here: https://docs.stripe.com/js/custom_checkout/update_phone_number
- You can include the Customer's phone number in the confirmation payload by passing the value into the
.confirmfunction here: https://docs.stripe.com/js/custom_checkout/confirm#custom_checkout_session_confirm-options-phoneNumber
I want to make you aware that the feature request has already been filed to add a phone number input to the Address Element when used with Checkout Sessions. We cannot make any guarantees if/when this will be implemented but my colleague has already flagged this to the relevant team.
Nice, thank you π
I think our best path is probably making use of the JS APIs to collect most of the info ourselves with fully custom UI, then only passing to elements for the payment steps
We'll spend some time looking at it, thank you for your time
I think that's the solution you can most easily implement