Authenticating a webhook establishes something about its delivery. It does not establish that every resulting business action is valid.
Imagine a completed payout followed by an older processing event. A handler that overwrites status by arrival order can move the dashboard backwards even though both messages are genuine.
Verify, persist, then process
Authenticate the delivery using the provider's documented signing contract. Persist the accepted event durably, acknowledge receipt after that commit, and let a worker validate the business action.
Bind the event to the instruction
- Match provider, environment, merchant account, and tenant.
- Map the provider reference to the exact internal payment attempt.
- Compare amount and currency for the same payment leg using exact units.
- Interpret the event according to the provider's documented meaning.
Quarantine mismatches for review. Resolve uncertain outcomes through trusted provider evidence.
Protect transitions and financial effects
An old processing message must not undo a confirmed completion. Legitimate returns and reversals need explicit transitions and linked correcting entries.
Deduplicate delivery identifiers and protect the actual financial operation. Separate events may describe the same business effect. For a single database, state, balanced journal entries, and the processed-event record should commit consistently. Across separate services, use durable delivery and an idempotent financial interface.
The release test is broader than a valid signature: replay events, reorder them, change economic details, and prove that one valid financial effect remains.