A valid webhook signature doesn't mean you haven't handled it already
A webhook can have a valid signature and still be a duplicate. This distinction was explored using a free sample of the Stripe Digital Seller Kit. The sample includes PHP files for webhook signature checking and a signed download-link helper. Local tests were conducted on PHP 8.5.4 without real Stripe requests or payments.The core webhook test revealed that both calls to a verify_webhook function returned the event. This occurred because the bodies and signatures matched, and the timestamps were within the allowed five-minute window. The provided signature checker does not retain memory of previously processed events. Modifying the body or exceeding the timestamp limit correctly resulted in rejection, demonstrating checks for signature integrity and recency.However, these checks do not prevent duplicate event processing. Handling duplicates requires a separate mechanism to track already fulfilled orders. A race condition can occur if two requests arrive simultaneously, where both might see no prior record before either writes. To prevent this, the check and recording of fulfillment must be atomically protected, perhaps using database transactions or file locks.The full Stripe Digital Seller Kit reportedly offers separate duplicate-safe order handling, which was not tested in this analysis. The download-link helper was also tested and validated correct behavior for valid tokens, incorrect IDs, wrong secrets, and expired links. These tests do not cover broader functionalities like refund handling or download counts. The author emphasizes testing "same valid event twice" separately from "bad signature" to avoid confusion and ensure correct duplicate handling.
verify_webhookfunction returned the event. This occurred because the bodies and signatures matched, and the timestamps were within the allowed five-minute window. The provided signature checker does not retain memory of previously processed events. Modifying the body or exceeding the timestamp limit correctly resulted in rejection, demonstrating checks for signature integrity and recency.However, these checks do not prevent duplicate event processing. Handling duplicates requires a separate mechanism to track already fulfilled orders. A race condition can occur if two requests arrive simultaneously, where both might see no prior record before either writes. To prevent this, the check and recording of fulfillment must be atomically protected, perhaps using database transactions or file locks.The full Stripe Digital Seller Kit reportedly offers separate duplicate-safe order handling, which was not tested in this analysis. The download-link helper was also tested and validated correct behavior for valid tokens, incorrect IDs, wrong secrets, and expired links. These tests do not cover broader functionalities like refund handling or download counts. The author emphasizes testing "same valid event twice" separately from "bad signature" to avoid confusion and ensure correct duplicate handling.