I've been wondering whether it would make more sense to call this CustomerCenterActionHandler. Then, we would notify whenever an action is performed.

My main concern with this approach is that it moves away from what we have in paywalls, where we have individual callbacks for many actions like purchase/restore started/failed/completed... But I feel since there are going to be more actions here, it makes more sense to do something like that. Wdyt?

That's a good point... Right, I think at some point we will have actions that are no completion actions like feedbackSurveyStarted so we want this to be an action handler. I honestly prefer just having this handler with a bunch of different events that can be handled in a switch statement than a lot of functions like we do in paywalls

It is true that adding a new event to a sealed class is technically a breaking change, but I think it's assumable. It is also true that it's not possible to modify an existing case in an enum (and add more properties) without creating a new event, but that's also an issue with independent functions.

In summary I find it cleaner to use sealed class when we are going to have a lot of potential events.

If we follow my previous suggestion, I would move away from using the Result naming, since this may happen at any point, and even multiple times. I would only keep this naming if we want to return a single result after the customer center closes, but I think I prefer my suggested option. Lmk what you think!

Would it be possible to move this inside the view model? That way we centralize the logic there.

Ideally this calls the view model, which internally calls whatever it needs I think.