#SenorKarlos
sleek yoke
true comet
Hi, can you share the request id for this update for me? Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
fast pollen
evt_3MFkbiErMl1EMpQJ1xV8YhV8
oh ffs you guys have another API version out 😂 I was still working on 2022-08-01 slowly 👀 and just noticed my webhook still says 2020-08-27 sigh
true comet
I'd need to test this on my end as well. Can you confirm that the following is what you're doing?
1/ Created a subscription/ initial billing address here
2/ Used the billing portal to update the billing address only?
3/ on your charge.succeded event, you're seeing the old address
Is that correct?
fast pollen
for fun, hours later now, I just updated it's subscription on the new session, and the charge webhook sent still has the old addy O.o - evt_3MFo8QErMl1EMpQJ0nyfdZuU
Correct, in stage 2 ofc put through an upgrade charge
So in this try, stage 2 is ENTIRELY just putting through an upgrade charge
true comet
On step 2, you're upgrading the subscription, yeah?
fast pollen
indeed, that's where the charge hooks are coming from
true comet
All right, let me try to reproduce this on my end. Thank you for your patience in advance
fast pollen
no worries, thank you. seeing as everything clears in test mode, the discrepancy is very concerning
Is it maybe because the payment method is tokenized as-was and the update address function only updates the customer object and not associated payment methods?
true comet
Do you see the address change on the customer.subscription.updated event?
fast pollen
no, the only reference to the customer is the id on those objects
while I got ya, related to API changes... I'm trying to test on what I thought was latest lol, how do i get the webhooks to update? I'm passing API version in my integration's declarations
true comet
You can add an endpoint, https://dashboard.stripe.com/test/webhooks/create with the desired API version.
fast pollen
ahh ok. so this whole time I've been sending and receiving 2022-08-01 API calls, but 2020 webhooks. whee learning to develop is fun
I just checked that, and only 2022-11-15 or the old one is available 😮💨
so I guess my next job is checking those changes LOL
back to the original issue, what did you see while recreating it?
true comet
Still testing
fast pollen
ok 🙂
true comet
2** O'Neil Dr E is the updated address right?
true comet
No worries, I'm also getting help on my end for second pair of eyes.
fast pollen
awesome, and back
placid light
Hello! I'm taking over and catching up. @true comet had to run.
Basically what's happening here is the Customer Portal is updating the address at the Customer level, not the Payment Method level. The Payment Method used for the Subscription has its own billing address, which is the one you're seeing on the charge.succeeded Event. There's a separate customer.updated Event which shows the new address being updated at the Customer level: evt_1MFkbBErMl1EMpQJStH6BNno (search for that in your Dashboard).
fast pollen
ok so in the live environment, how is this handled. Tell customers on any address change to also re-add their payment method as an update and delete the old one?
placid light
It's handled the same in live mode, there's no difference in behavior. Taking a step back, what's your ultimate goal here? And where will the original Payment Method on the Subscription be coming from?
fast pollen
What I was testing was what happens when someone moves. I don't need rejected payments and confused customers. Was happy to see that Tax updates automatically
placid light
Let me check something, hang on...
fast pollen
sure
placid light
The Customer Portal can't update the billing address for an existing Payment Method, it can only update the address on the Customer. However, when you originally created the Payment Method in test mode you explicitly set a billing address on it. Instead of doing that you should use the Customer's address instead and leave the Payment Method without billing address details. That way the Customers can update their billing address at will from the Portal.
fast pollen
I created the customer via a checkout session where it asks for all that at once. I'm going to clear this test customer and database entry and fire off a new create, see what that looks like again
placid light
The other option would be to have them remove and re-add their Payment Method in the Portal with the new billing address info.
fast pollen
See when I go thru checkout, this is what I see. Nothing about seperating the custoemr and card addresses, it's just gonna make them together no?
placid light
Ah, gotcha. Yeah, that will save the info at the Payment Method level.
fast pollen
just feels like the 'low code' solution should take care of this eventuality with simplicity no?
placid light
Yeah, it's a bit of a gap we're working on.
It looks like you're forcing billing address collection during Checkout; any particular reason?
fast pollen
so as it stands, I'll have to tell folks to change addy, add card with new addy, delete old (same) card
To ensure they're in Canada mostly, in conjunction with radar rules
also so Stripe Tax can do it's thing
placid light
The postal code is required for cards in Checkout; would that not suffice?
But yeah, I see what you mean. I bumped this issue internally. Sorry this is not ideal right now.
fast pollen
not entirely sure, what I read and know of KYC & GST stuff says I should have the billing addy, but 🤷♂️ 😂
placid light
Anything else I can do to help?
fast pollen
no I guess that would be all 🙂 thank you very much!!
placid light
Happy to help! Have a great weekend!