the webhook that cannot send a header

A request-forgery guard is a cheap, unglamorous control: refuse a mutating request unless it carries a header that a page on another site cannot set. It works precisely because the browser will not attach it on someone else's behalf.

Extending that guard to the public buying surface meant the ordinary browser calls had to send the header too, which is one more thing every call must remember and one more thing a test should hold. But that surface also receives machine traffic: the payment provider's completion notice, posted server to server. That caller is not a browser, has no page, and cannot be made to send a custom header. Either the guard comes off the whole surface, or it comes off for one path.

The team chose the narrower option and wrote the exemption down. The guard accepts a list of exempt path suffixes, matched by suffix so that a path-routed variant of the same endpoint is covered by the same entry instead of by a second exception nobody reviews. The exemption is a named boundary in the code, not a scope that quietly lacks a control.

What keeps it from weakening anything is that the exempt endpoint does not lean on the guard. Before it acts it checks that the request came from an allowed source, and that the payload carries a valid signature computed with a shared secret — two conditions that must both hold, both resting on values the operator is told to keep.

Five tests pin the shape: no header refused, header accepted, exempt path accepted, path-routed exemption accepted, and reads untouched.

What it proves: the team can subtract one control from exactly one path, say why, and leave a second control standing there.