#mkoenke
thorn thorn
molten cedar
Hi! Let me help you with this.
granite storm
thank you!
molten cedar
- No
- As you prefer. If you won't be using it, why would you need to keep it?
granite storm
thank you so much, that is helpful. We are trying to consider all edge cases, where perhaps one user moves away from a subdomain, an another user then decides to use that same subdomain at the same time. But if it is already registered, then it seems there would be no reason to delete it and reregister. This is helpful!
Would you happen to know what kind of response we get from Stripe if we try to register a domain that is already registered?
molten cedar
I don't know, but it should be easy to try.
granite storm
ok, yep for sure... no problem, thank you!
I have one more question. On our platform, the way we calculate taxes during a checkout is to create the payment method first, and then use the country and postal code in the Stripe response to know the user's location to determine taxes. We are integrating the payment element with google pay and apple pay. I have noticed it is a requirement to submit the elements instance before creating the payment method. This means that the google/apple interface that pops up can not include the tax amount, because it is triggered by elements.submit(), before we create the payment method. Is there a way around this so that we can also include the tax amount, or at least display it to the user before they pay?
molten cedar
How are you setting the amount on the Payment Element currently?
granite storm
Through the options hash passed to the elements instance
If we were able to create the payment method first, and calculate taxes, we could update the amount in the options hash to reflect the total amount including taxes, then do elements.submit() , and then the google/apple interface would have the correct total including taxes.
molten cedar
You could have the customer select the country before going to your checkout page
granite storm
hmmm, yeah we could... but then we would also need the postal code depending on which country, and that seems to defeat one of the benefits of using google pay/apple pay to make checkout easier for customers so they do not have to input all of their payment information. How does Stripe handle this with their internal tax service with exclusive taxes? It seems like inclusive taxes wouldn't be a problem bc the total is the total.
molten cedar
I understand, let me check.
granite storm
thank you!
molten cedar
Are you following this? https://stripe.com/docs/tax/custom
granite storm
checking now
No, we do not use the address element. We use the information from creating the payment method - the billing details/card information returned in the response
errant quiver
Hi there 👋 jumping in as my teammate needs to step away soon. The flow described here allows you to create a Payment Method before processing a payment, giving you time to inspect details of the Payment Method and take action based on that:
https://stripe.com/docs/payments/build-a-two-step-confirmation
granite storm
Will this allow us to create a Payment Method before submitting the elements instance for the current payment element in use?
errant quiver
You submit the Payment Element to create the Payment Method, then you create and process the Payment Intent.
granite storm
we are doing manual payment method creation, and use the response to get the country and postal code to calculate taxes. The problem is that when there are exclusive taxes, the amount displayed in the google/apple UI will not include the exclusive taxes, so we will be charging a different amount, if we have to submit before creating the payment method- does that makes sense?
errant quiver
Oh, I see, because at the time those prompts are brought up you still don't know the tax details so you can't have updated the amount with that information yet.
granite storm
exactly
errant quiver
Hm, the only idea that comes to mind for that, is to separate the payment method collection and payment processing steps.
Like is shown here, where the UI displayed initially is purely for collecting payment method details, and then a payment is processed later. This may still not be a good fit, as I believe the Google and Apple pay modals display an amount of 0 for them:
https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements
granite storm
I see, will we have issues making a charge if the amount in the apple/google UI is different from the actual charge amount? we do display the taxes after the apple/google UI is closed, so maybe thats ok, as long as we can still charge successfully
errant quiver
Hm, I'm not sure offhand whether Google or Apple have any policies that discourage that, but I could see how it could be confusing to customers. It may be a smoother process if you collect address information before payment information so you can calculate tax sooner in the flow.
granite storm
ok, thank you for your help!
errant quiver
Any time!