Verifying inbound messages.
WHAT THE RISK IS
An attacker sending a forged notification claiming payment succeeded.
WHY IT WORKS
Handlers frequently trust the message content.
WHAT TO VERIFY
The signature, computed over the raw body with the shared secret.
WHAT TO BE CAREFUL WITH
Verifying against a parsed and re-serialised body, which changes it Timing-unsafe comparison of signatures Signature verification that can be skipped by configuration
WHAT ELSE TO CHECK
A timestamp within an acceptable window, preventing replay.
WHAT TO DO REGARDLESS OF SIGNATURE
Query the provider to confirm the transaction.
WHY
It is definitive, and immune to any signature implementation error.
WHAT TO RESTRICT
The endpoint, to the provider's addresses where published.
WHAT TO NEVER DO
Expose an endpoint that credits accounts on receipt of a message.
WHAT TO MAKE IT
Idempotent, so repeats are harmless.
WHAT TO RETURN
Success quickly, with processing queued.
WHAT TO MONITOR
Notifications failing verification, which indicate attack or misconfiguration.
WHAT TO LOG
Every notification, raw, including rejected ones.
