#tyson-subscription-events
1 messages · Page 1 of 1 (latest)
Try using --override option on the stripe cli:
https://stripe.com/docs/cli/trigger#trigger-override
Or --add
https://stripe.com/docs/cli/trigger#trigger-add
depending on the resource
e.g.
stripe trigger payment_intent.succeeded --override payment_intent:customer=cus_123
sweet
hi with subscriptions, what events should i track to amed my data base on my end let cusotmers know their cutomers payment has failed, i have looked at the docs and there is so many possibles ones to go for. my understanding is, subscriptions create invoices and invoices have payment indents, should i track events related to invoice? should i just display
I am working out a minimal system for this
if i am only using whats neccerary
Hi there 👋 that largely depends on what you're looking for, and what other flows exist in your integration that may trigger similar events.
You could listen for events at various levels, including Subscription, Invoice, Payment Intent, or Charge
i am thinking of using, invoice.updated and using is states of paid, open, invoice.payment_failed status
to deal with this and define?
That would probably be a good approach, listening to invoice.updated to be notified of changes on Invoice objects, and also listening for invoice.payment_failed events to be notified of payment failures.
I am basically creating the box that is in stripe the green one that says active if active and the same for invoices,
looks like this
Principally all i need is to show to my clubs who has paid and who hasn't paid
tyson-subscription-events
So maybe using subscription status and have logic for when that changes? and Subscrption status i.e. invoice.updated and logic for each status?
what does invoice.payment failed give me over invoice.updated, if when it is open. i can provid a feal that turns the icon red and says reqired action ect
Will theroetically i only need the status and creation events to keep track of all this?
to prevent like 7 webhooks having to be created
Sorry, I'm not sure what is being asked here. If you want to track the status of Invoices then invoice.updated is a good option, if you'd rather track Subscription status then customer.subscription.updated would be a better fit (likely including customer.subscription.created also).
Not much, both events return an Invoice object, just the event type adds more context to why you're receiving the event.
That is up to how fine grain you want your tracking to be, I would suggest running through a test of your flows and see what events are generated when you do. That will give you a good idea of what events are available and when they're triggered in your process.
This is the spec,
So being super specific, are events that satisfy these capabilities?
Yes, customer.subscription.created, customer.subscription.updated, customer.subscription.deleted, invoice.created, invoice.updated
Not sure how fine grain you want your Invoice monitoring to get, invoice.payment_succeeded and invoice.payment_failed could be useful.