#dash_customer-address-restriction

1 messages ยท Page 1 of 1 (latest)

fossil sirenBOT
#

๐Ÿ‘‹ 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/1248691632417800203

๐Ÿ“ Have more to share? Add details, code, screenshots, videos, etc. below.

random geyser
#

I should say also that most of the 'Stripe' part of my app is built and I use the API.

undone elm
#

Hi ๐Ÿ‘‹

So you are not using any Stripe product on your client-side? How are you collecting payment method information?

random geyser
#

I am indeed using Stripe. I'm using the Payment Element, which has a button to select the country, and it is a big list of them. Right now there is no way to block someone from some non-US country from signing up.

undone elm
#

You could block it on your front-end by detecting the change in the dropdown value.

random geyser
#

Ok, let me give that a try. Thanks. It would be nice if the dashboard had some "list of countries to allow selling to" type of input. There are tax consequences for selling.

#

That didn't work. No matter what I do with the country drop-down, even if I fill out the whole form and submit it with a different country, that onChange event only gives me:

  elementType: 'payment',
  complete: false,
  empty: false,
  collapsed: false,
  value: { type: "card" },
}```
#

I'm looking into addressElement.getValue() to see if that will work.

undone elm
#

Damn I thought we made more of that info available. Address Element will definitely include the full address in the value: property

#

I have a test version up now I just checked.

#

If that makes sense for your integration that is a good approach.

random geyser
#

That didn't work. When I try to get the addressElement, I get undefined, whether I put the code in the change handler for the payment element or in the submit function. I did:

        console.log("event =", event);
        if (event.complete) {
            const addressElement = elements.getElement('address');
            console.log("addressElement=", addressElement);
            const value = await addressElement?.getValue();
            console.log("value=", value);
        }    
    }

and always get undefined for the addressElement.

#

I do get the event complete message.

#

I'm using React and use hooks, so I have this for elements:
const elements = useElements();

#

Of course I have a PaymentElement, not an AddressElement, but I was thinking the latter was inside the former.

undone elm
#

Of course I have a PaymentElement, not an AddressElement, but I was thinking the latter was inside the former.
Sorry that doesn't make any sense to me. They are separate and distinct input elements but they can be used together to collect information from customers.

Also I have the following in my test integration

this.addressElement.on('change', (e) => {
            console.log(e);
          })

and it shows the complete address for each change I make

random geyser
#

I'm using the <PaymentElement /> component, and it creates the GUI with the card input, expiry date, cvc value, country and zip code inputs. I'm not using an <AddressElement /> anywhere.

#

I'll give the AddressElement a try and see what happens.

undone elm
#

Ah, okay yes that would be entirely different behavior

random geyser
#

If I use both <PaymentElement .../> followed by an <AddressElement .../> it works. I get inputs for the full address, and if I change anything, I get the callbacks, so I know the country.
So that is a good possibility.
I had seen in the Stripe docs that in order to compute taxes, they needed a good address for a customer. The PaymentElement only narrows things down a bit using postal codes. I had wondered how they got additional address information, and I guess the answer is that they don't have it unless I use the AddressElement as well (though they get some location data by the IP address).
One of my competitors uses just the CardElement, so not even a zip code is entered, just card details. How is tax information figured out in that case? That's why I was thinking there was some other way to limit the countries allowed to just the US.

undone elm
#

They likely are not getting very fine-grained tax calculations. We calculate tax as best we can with the data we get.

However, they may also be collecting more details from their Customers at some point and saving that info the address property: https://docs.stripe.com/api/customers/object#customer_object-address

This will be used in tax calculations if the billing_details for the Payment Method don't have a complete address. https://docs.stripe.com/api/payment_methods/object#payment_method_object-billing_details

#

Also, if you are using Stripe automatic tax, we can fall back to using the IP address of the request in the absence of everything else

random geyser
#

Yes, I was aware of all that. My billing_details only ever had country and zip code since I was using just the PaymentElement. So now that can be fixed with AddressElement.
I tried once before to set the automatic_tax.enabled flag in the subscription and it gave me some error. It was a while back so I don't recall what it said. Maybe that's not a writable parameter, just a read-only one. I think I have automatic tax enabled in the Dashboard, though.
I haven't launched the product yet, so once I do I'll be adding tax registrations as I need to.
Thanks for your help.

undone elm
#

Happy to shed what ๐Ÿ’ก I can ๐Ÿ™‚

fossil sirenBOT
undone elm
#

I'm gonna close this thread but you're welcome to ask any new questons in the #dev-help channel
๐Ÿ‘‹