Why?

On the back of my work in DEVSDK-3085, we're adding support for non-verified webhook handing to the managed handlers. There were two key design stipulations:

1. It should be impossible to handle a webhook on the with-verification handler without supplying a signature header. As a result, we have to be very careful about overwriting/mixing our handle methods and if/when we call the signature verification methods.
2. The without-verification handler should feel like an implementation detail (where possible). Users should feel like they're interacting with "The" event notification handler

To that end, the main entrypoint for the non-verified handler is a new method on the client and a static method on the with-verification handler. The non-verified handlers are public in each language so users can interact with them normally, but the intention is that they're not something the user thinks much about on their own.

Design wise, the exact implementation varied between languages, but the general idea was the same. I moved all the generated on_* methods onto a private base class, then added sibling handlers for the "with" and "without" verification paths. That way they each have distinct handle methods and it's impossible for a caller to see the "wrong" one. If we had used inheritance, then the child would have the parent's handle signature exposed, which is confusing (even if we overrode it to always error).

What?

• Add StripeEventNotificationHandlerWithoutVerification class and associated constructors, docstrings, and client methods
• add tests
• update examples

See Also

• Original handler PR: Add EventNotificationHandler #1653
• Non-verified event parsing: add/adjust event parsing helpers #1855