#naveed-web3auth_best-practices
elder tendonBOT
👋 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/1389107095361683600
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- naveed-web3auth_best-practices, 6 days ago, 67 messages
verbal radish
this is an event for sub schedule updated
evt_1RfZBtImFOsfVEtUDrl2TlLg
for the one triggered via stripe dashboard itself i dont have it on me atm
but u can assume our admins could also trigger a downgrade via dashboard directly by scheduld update
i dont want to trigger email for that scenario
are there any design patterns for that
also i have to ensure that i dont send an email for "upgrade" scenario
it seems to determine if something is an upgrade or downgrade i need to compare previous attributes
it does seem a bit cumbersome
and the logic seems complex
i was thinking of metadata as an alternative
devout gulch
Yes metadata is a viable solution 👍
verbal radish
Issue is that when a user on the dashboard upgrades their plan once the downgrade phase has completed the metadata gets copied over to the next phase
so if i use metadata i may mistakenly send email for downgrade again as the sub schedule update call will be called again
so if u go from Scale -> Growth -> downgrade completed (but sub schedule not yet released) -> Upgrade back to scale
above is the scenario im talking about
devout gulch
Sorry I don't really follow. Let's say
- You downgrade your customer from Scale to Growth. Here you have the previous attributes = Scale, the new attribute = Growth, so you know this is downgrading. You can set a metadata to tell if this is from your SDK request (otherwise it will be coming from your Dashboard)
- Now you upgrade your customer from Growth back to Scale. Now you have previous attributes = Growth, new attribute = Scale, so you know this is upgrading.
verbal radish
Right if i am using previous attributes detection logic as well rather than solely relying on metadata that works
i was trying to find a way to rely solely on metadata
if i have to use previous attributes detection i need to store a map of growth or scale product items to know that the price items correspond to which, unfortuntely i cant even rely on lookup keys as that information is not presetn in the event payload
devout gulch
If you call Retrieve Price API you will get the lookup_key, but I agree that's one more roundtrip
verbal radish
yeah i might face rate limits
devout gulch
Retrieve Price API shouldn't change much over time, so you can cache its result, for example
and invalidate cache when you call Update Price API
verbal radish
hmm interesting
the invalidation can be triggered even if admins modify via stripe dashboard itself?
so a webhook event to watch out for that?
devout gulch
Yep like price.updated
verbal radish
i see
devout gulch
I totally hear you that the logic of checking previous_attributes is cumbersome. Yes it isn't straightforward
But it's currently the most reliable field for knowing the diff on each coming event
verbal radish
Yes no doubt using the event payload itself to decipher what happened is probably the most scalable approach and it is much more declarative
I guess the way to look at it is stripe's responsibility is only to communicate what happened on its system
nothing less nothing more
I heard that i can use the request field which will be null if auto generated via subscription updates on dashboard?
devout gulch
I wouldn't recommend, since Dashboard can also generate a request id. That field is null only means it's from an automatic batch
