tannerhuynh_address-element-country-conflict

[grim nymph]

👋 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/1334186377415495832

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[shut nimbus]

See screen shots. It seems the entire billing address element is not loaded, but the error relates to shipping, but we do not have a shipping address section.

[wind lotus]

Hi there 👋 can you share more context about your integration.

Are you able to share the snippet of code for the implementing our Address Element on your page?
Are you able to share any details about when this occurred, like the ID of the intent being used to render the element? (not the client secret, just the ID)
Do you know what line of code is running from your code when this error arises? Is it during the mounting of the element?

[shut nimbus]

PIID: pi_3QU9HhFKvb6W5GcF1gIJYXtp

Its just a simple integration https://codeshare.io/XLXlAz

Nothing else seems off with the customer, payment intent, and the payment section mounts. So it seems odd that this partictular customer has this issue.

[wind lotus]

Oh, interesting, it's only impacting this one Customer?

[shut nimbus]

For now yes.

[wind lotus]

I'm going to try to do some testing on my side, but is there any chance this snippet is sending an empty array to the allowedCountries parameter?

    allowedCountries: isIntlPurchaseAllowed ? [] : countryCodes,
    mode: "billing",
    display: {
      name: "split",
    },
  }```

I don't *think* that would cause problems even if so, but it's the only thing jumping out at me so far. 

Is there any chance your test page where you're able to reproduce this is publicly available?

[shut nimbus]

I can take a look. That empty array hasn't caused a problem before, but I can take a look. The error related to shipping id is still confusing as we don't have a shipping address element....

[wind lotus]

Agreed, I'm grasping at straws here for a starting point. I'm not finding reports of others running into this so far.

Oh, wait, found one. Are you accepting Link payments?

[shut nimbus]

We are

Does that Link impact the way the Address element/saved payments work?

[wind lotus]

Hm, I see a single mention that this was encountered in the past when working with Link, when a saved address was deleted. Do you know if that was done for this Customer?

Or if any changes were made to the Customer or their Payment Method(s) before this started? Or has this always been the observed behavior when using this Customer?

[shut nimbus]

There was no saved address deleted, it still exists on the customer. I don't recall any changes made to their payment methods.

[wind lotus]

Since it looks like the Payment Element in your screenshot is leveraging our Saved Payment Method feature:
https://docs.stripe.com/payments/save-customer-payment-methods#display-existing-saved-payment-methods
I think whatever is leading to this is related to the Customer's Payment Method rather than the Customer object itself.

But even in the most recent update request for their Payment Method, it looks like a full billing address is present:
https://dashboard.stripe.com/test/logs/req_kDUIzOg6J5c4wL

Out of curiosity, does adding a shipping address to the Customer cause the error to subside? I think this needs to be reviewed by our engineering team, so any details you can provide on how to reproduce this would be greatly appreciated. Along with a link to your test page where we can see this if that's public.

[shut nimbus]

I'll get back to you about the above.

I need to test Link and see if adding a shipping option will fix the issue. We do not have any public URLs for testing atm.

I deleted the users saved payment, and that seemed to have fixed the issue.

Link was disabled, but that wasn't the problem.

[wind lotus]

Hm, so it was something about that Payment Method.

[shut nimbus]

It was a mexico billing address in a US only address element.

[wind lotus]

Aahh, gotcha! Hm, I feel like we could have thrown a better error message there.

I'll take this back to our teams to see if we can improve that.

[shut nimbus]

I think yes, the error message threw me off from the actual root cause.

Thanks for working through this with me!

[wind lotus]

Any time!