#mclowrider_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1428778431986012263
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi mossy
๐ Hello!
Have you been able to look into my request please?
I'm looking, juggling a few other threads.
Ah ok ๐๐พ
Could you elaborate on what the issue is? Events orders aren't guaranteed. What is the issue thats cropping up because of this?
We listen to customer.updated and customer.subscription.updated to get updates to the payment method but could both these events have changed the payment method? In which case if we get the latest one first we could have store the wrong PM in our database?
How do we ensure irrespective of the order, we get right payments method and the old doent override the new.
We could have the events out of order in our system for some reason but don't have a reliable of determining the latest from source.
Are you trying to track the payment method of the subscription or payment methods on the customer.
yes
Both I think
I think customer.update is fired when the customer's invoice settings change?
but subscription.update when the sub Pm chnages
Or any change to the Subscription.
That's correct
So a Subscription can have a default PM, and if it doesn't, then it falls back on the Customer default PM. So If both exist the Subscriptions default takes precedence.
That's correct. We store those payment methods. Whichever the last one is.
I would say if the Customer.updated comes later, but the Subscription PM has a default set already you wouldn't want to store the follow up event
You might need to make an API call to check the current status of the Subscription on customer.updated if you want to be certain if it's worth saving.
We store both in the same field in the DB.
Likely because customers usually have one and not the other
Probably the simplest solution would be to make an api request, when receiving the update to confirm the current status.
Are you doing anything in your code that might simultaneously update the PM multiple times in a short window?
I guess my question is what issues have arisen from this so far.
It's usually when we receive events at the same time, like the example I shared
Data gets overwritten if both have different payment methods especially if they are processed.
Should we really be storing these fields separately?
So they dont effectively overwrite each other?
That would also be fairly straight forward. it also sounds like you aren't typically setting a default PM on the Subscription.
Only when createing it I think, or if the customer set it on the billing portal
during renewal. Thats when we see these issues.
Yeah, then probably makes sense to have both,
Then they are not clashing.
Ok thanks. I'll snare this with the teama and raise a new issue if a have any objections
Any time, thanks for the patience, juggling a few threads all event related this moring ๐