Better interface for `Event` class.

[taylorchasewhite]

My team and I are getting started with the stripe documentation/API in the .NET environment, and really would like to see a better way to interact with various event types.

For instance, it would be great to have an interface that allows you to access CustomerId without casting for/checking against the different types of events. You could add other properties that are commonly on events to an IStripeEvent interface as well.

For reference, the use case I am attempting to accomplish here is to track "important" events like a payment method being deleted, and taking some automatic application action like emailing our client's customer rep, or flagging the customer in the database, etc.

There are a variety of events that we might want to do this with, and it would be nice to access common properties like "CustomerId" without needing to explicitly cast to and access the customer in each type.

---

Secondly, it would be nice to be able to have an enum indicating the different event types, rather than (or in addition to) string constants provided from the Events class (though this is probably better split off as a separate issue).

[richardm-stripe]

Hello @taylorchasewhite, thank you for the suggestion.

I agree that the types surrounding the event interface could be a lot better. We have been considering improvements to the event interface in all our libraries, based on the theory that if you are specifying that you are listening only for a specific event, the type you receive should be able to reflect the properties expected to be on the payload for that event without any casting involved.

Unfortunately there'd be quite a bit of internal infrastructure work we'd need to do in order to generate the proper definitions to make this work, and I don't think this is something that would materialize soon, but I will mark this as "future" and leave the issue open.

[AraHaan]

I actually wish there was a high-level version of the Event class myself where basically it operates on enums for the event type instead that hides the fact that they are strings underneath of it.

Also, it seems that the AI failed to pull request in Events.CustomerSubscriptionPaused and Events.CustomerSubscriptionResumed despite the webhooks page when you select those to events showing .NET code suggesting that it exists in both the latest stable nuget packages and the latest beta on nuget.org.