#lil-nasty_best-practices
umbral sonnetBOT
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.
- lil-nasty_best-practices, 6 days ago, 5 messages
chrome parrotBOT
👋 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/1259886342268125285
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
zinc torrent
Hello, are you creating these subscriptions yourself directly? In that case, yes typically you would collect the postal code before creating the subscription, though that usually means immediately before, while taking the rest of their signup info
We have flows where you can render the payment element and such without a client secret. Looking for the docs on those flows now
jade ether
We are directly creating them via api
zinc torrent
Gotcha, in that case you can use these flows
https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription
https://docs.stripe.com/payments/finalize-payments-on-the-server
And you can use this to preview the price as the user changes their address if you want to dynamically show how tax would be applied https://docs.stripe.com/api/invoices/upcoming
jade ether
Looking these over, please don't close the thread yet jic I have any follow-up q's
Is it possible to reuse the postal code from the payment method for tax calculation?
I assume that will be problematic for methods that don't collect billing postal code, right? So we need to collect separately
Our designer doesn't like the idea of having two postal code collection inputs on the same screen, but from everything I can see it's not possible to get around it. We either use the stripe address element or our own address collection separately, but there's no way to utilize postal code reliably from the payment element, right?
zinc torrent
If you use the Address Element, that should let you always collect the postal code. Also I believe the address element should communicate with the Payment Element such that duplicate input fields aren't shown
chrome parrotBOT
jade ether
We're currently not using the address element, we currently just collect postal code and attach it to the subscription, but it seems that it still shows postal code for cards
zinc torrent
Gotcha. So in that vein, it is a common pattern with the Payment Element that when you want a field to always be shown, you tell the Payment Element to never show it and then display your own input
We don't currently support always showing a field, just never and auto (which means "show this field but only when it is required")
So seting that to never and then adding your own postal code input could be a good solution here
jade ether
Is it possible to not show the postal code input for cards though? It would seem like that's not an option
NVM I see it says you must pass that when confirming payment or it will get rejected
zinc torrent
By default, the postal code input will show for cards. I can find how to access that postal code, the issue is that if you have other PaymentMethods, you would need to dynamically show and hide your own postal code field, which would likely be more difficult than always hiding the field and always displaying your own
jade ether
So I could just hide the postal code from ever showing regardless of payment method type and then render our own right below the payment element, which I could use to calculate tax and then also pass along to the confirmPayment step and voila problem solved
zinc torrent
Exactly! I think that is generally the best way to handle this at the moment with the Payment Element
jade ether
For consistency of styling would it be possible to use the address element right below instead of our own custom input, but to only show postal code and country, and to access those values so I can dynamically show the tax amount?
zinc torrent
Unfortunately not. I'm not quite sure why but the only field that the Address Element can hide is the phone field https://docs.stripe.com/js/elements_object/create_address_element#address_element_create-options-fields
I will add to the feedback about allowing other fields to be hidden, as I definitely get why it would be better to just set the Stripe style once, but that is where our capabilities are at at the moment
jade ether
No worries, I think I can get around it by just always hiding postal code, collecting our own and then passing it with confirmPayment/Intent
Is there anywhere to see which fields will cause the payment to fail if they are hidden and not passed to the confirm function?
bitter basalt
Hi there 👋 taking over, as my colleague needs to step away
Is there anywhere to see which fields will cause the payment to fail if they are hidden and not passed to the confirm function?
Not really. It's basically only Zipcode that you would need to worry about though
jade ether
So email/name isn't required for bank account payments?
Looks like when no setting to hide items is passed we get these inputs for bank/pre-auth debit. Which if I understood the docs properly the default is auto, which means it will only show if it's required, so that would mean name/email is required for those payment methods
Just wondering if I force those to be hidden and pass our own data for those as well
bitter basalt
Name is required, but I thought you were talking specifically about the address. Either way, if it's shown in the form, then it needs to be collected (either via the Payment Element, or by you explicitely passing it in), with the exception of email.
jade ether
Oh no, I'm talking about for the payment element
Shoudl work if I hide name, email and zipcode and pass those myself, right?
bitter basalt
Yep
jade ether
Ok, thanks
jade ether
Is it possible if we use the address element to hook into the zip/country value so that we can dynamically display the tax amount?
bitter basalt
I don't understand what you're asking. Can you be more specific?
jade ether
I'm considering just using the address element alongside the payment element (even though it captures unnecessary info) and using that to calculate the tax for display purposes before confirming the payment
But to do that I would need access to the address info so I could hit our server and in turn hit the stripe api to get the tax amount for the given address
bitter basalt
You should be able to listen to the on('change') event and/or getValue to retrieve the address when it's supplied: https://docs.stripe.com/elements/address-element/collect-addresses?platform=web#web-retrieve-address
jade ether
Ok, that makes sense. Would the following be the most seamless method? And would the address info automatically get passed to the payment element because it's in the same elements context?
- Use PaymentElement + AddressElement
- Listen to AddressElement onChange
- Pass address if it's ready to our server and get a test "upcoming invoice" for tax amount
- Display tax amount
- Collect payment info
- Enable submit button
- Submit
bitter basalt
Yep! That looks/sounds right to me
jade ether
Ok, great