Spring Data's save() turns the duplicate-webhook guard into a silent row update

Start with the case where nothing throws. ProcessedEvent's primary key is the provider's event id, so your code assigns it and it is never null. Spring Data uses that to decide whether the entity is new, and with no `@Version` field to tell it otherwise, `save()` calls `merge()` instead of `persist()`. Merge loads the existing row and updates it. No constraint is violated, the catch block never runs, and the repeated event is applied a second time ^[10].

The other failure needs two deliveries at once. Both reach the insert, and one does get the duplicate-key error. That exception travels back through the repository's own transactional proxy, which marks the transaction rollback-only, and PostgreSQL has aborted the transaction anyway ^[11]. You catch it, return normally, and Spring throws `UnexpectedRollbackException` at commit ^[11]. The caller sees a 500, and Stripe retries a failed delivery for up to three days ^[12].

The replacement is a native query. `INSERT ... ON CONFLICT (event_id) DO NOTHING` returns the affected row count: 1 means this handler claimed the event, 0 means it was already processed, and a duplicate never raises ^[14]. `process()` returns early on 0, otherwise it calls `applyEffects` in the same transaction, so effects that throw roll the claim back with them ^[15]. Concurrent deliveries are safe because the second insert waits for the first transaction to finish and then inserts nothing ^[16].

None of that helps if the signature check is wrong, and the requirement there is the raw bytes. Verify before parsing, with the body bound to a String ^[5]. Re-serialise a DTO and the JSON comes back with different key order, whitespace or number formatting, so verification fails; Stripe's documentation says any change to the raw body makes verification fail ^[6]. When it fails that way, the post says, someone "temporarily" turns it off ^[6]. The signature also covers a timestamp, and Stripe's libraries reject anything older than five minutes by default ^[7]. Setting the tolerance to 0 disables the check ^[7]. A server clock more than five minutes out will reject events that are genuine ^[19].

For the trap to bite, two things have to hold, and the walkthrough names both: the id is assigned in your code, and the entity has no `@Version` field ^[10]. For the fix to transfer, the database has to support `ON CONFLICT`; the schema given is PostgreSQL, with `event_id text PRIMARY KEY` and a `timestamptz` column, and the query is marked `nativeQuery = true` ^[13][14][20]. The post is a walkthrough and does not include measured duplicate rates. Event-id dedupe also covers only one class of repeat, the same event arriving twice: one change on the provider side can produce two events with different ids, so applying the same change twice has to be harmless in the effects themselves ^[17]. The handler stores the claim, returns 200, and runs the slow work afterwards ^[18].