#mclowrider_api

1 messages ยท Page 1 of 1 (latest)

twilit driftBOT
#

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

wanton gazelle
#

Hi mossy

lofty mountain
#

๐Ÿ‘‹ Hello!

wanton gazelle
#

Have you been able to look into my request please?

lofty mountain
#

I'm looking, juggling a few other threads.

wanton gazelle
#

Ah ok ๐Ÿ‘๐Ÿพ

lofty mountain
#

Could you elaborate on what the issue is? Events orders aren't guaranteed. What is the issue thats cropping up because of this?

wanton gazelle
#

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.

lofty mountain
#

Are you trying to track the payment method of the subscription or payment methods on the customer.

wanton gazelle
#

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

lofty mountain
#

Or any change to the Subscription.

wanton gazelle
#

That's correct

lofty mountain
#

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.

wanton gazelle
#

That's correct. We store those payment methods. Whichever the last one is.

lofty mountain
#

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.

wanton gazelle
#

We store both in the same field in the DB.

#

Likely because customers usually have one and not the other

lofty mountain
#

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.

wanton gazelle
#

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?

lofty mountain
#

That would also be fairly straight forward. it also sounds like you aren't typically setting a default PM on the Subscription.

wanton gazelle
#

Only when createing it I think, or if the customer set it on the billing portal

#

during renewal. Thats when we see these issues.

lofty mountain
#

Yeah, then probably makes sense to have both,

wanton gazelle
#

Then they are not clashing.

#

Ok thanks. I'll snare this with the teama and raise a new issue if a have any objections

lofty mountain
#

Any time, thanks for the patience, juggling a few threads all event related this moring ๐Ÿ˜›