Two endpoints are open by design and verify a signature instead of an account: `kessai_worldline.webhook` and `kessai_client.notice`. Both carry a private `sayOnce()` helper, and both write down the rule it exists for: > The log is the one thing a stranger can still fill after being turned away, at whatever rate it can send, so saying this every time would make the warning the payload. An operator needs to learn that something is knocking, and needs to learn it once. Both then apply it to the refusals that come *before* any work, and to none of the refusals that come after. The ones that come after are the only ones an unauthenticated caller reaches, because the ones before them are where a caller over the request limit is turned away. So the lines that are collapsed are the lines the request counter already bounds, and the line that is not collapsed is the one it does not. ## What one address can write on the webhook `WorldlineWebhookController::refuseBeforeAnyWork()` collapses the flood refusal and the address-list refusal. Everything past it is written once per request: - **The unconfigured-webhook warning** (`getHelper()` answers NULL). `kessai_engine.payment_account.worldline` ships `webhook_key_id: ''` and `webhook_secret_key: ''`, so this is the state of a site that has installed the module and not yet been given its provider credentials. Nothing is verified before it, so any POST from anywhere writes a row. - **`Worldline webhook rejected: @message`**, in the `unmarshal()` catch. A body with no signature header is refused there, so this too is a row per POST, and `@message` is the SDK's own text about headers and a body the caller supplied. With `flood.per_source` set to *n*, one address writes up to *n* rows in a window where the helper exists to make it one. `n` is chosen to let a busy provider through, so it is not a small number; the helper exists precisely because "how many requests this site answers" and "how many times it says so" are different questions. `FloodGuard::isFirstRefusalInWindow()` says as much: > Refusing costs nothing to say once and a great deal to say every time. ## The client's notice route `NoticeController` collapses the flood, unknown-account and address-list refusals, and `refuseNotice()` writes a line every time. Its one caller reachable without the shared secret is the signature failure. The account uuid that selects the secret travels in the address and is not a credential. ## And the payer's return route, found by auditing the fix `WorldlineReturnController` collapses its flood refusal and does not collapse the RETURNMAC mismatch below it. Same shape exactly: the counter turns a caller away in front of the first, the second sits past it, so what bounded the second was the return limit alone. A payer who kept their return link and comes back to it after the session moved on reaches that branch on every reload, and the second line says nothing the first did not. Weaker reach than the webhook's, because it needs the per-payment return token, and the same rule. ## Collapsing by caller is not enough `sayOnce()` keys the window on the caller alone, so the first thing written about a caller is the only thing that caller gets. These endpoints refuse for more than one reason. `NoticeController::refuseNotice()` carries seven refusals behind one message, five of them past the signature and so reachable only by a host that proved itself. One of those is the payment-of-another-account refusal this class holds the body to the address for. A single forged notice sent first spends the window, and that refusal is made and written down nowhere. The webhook is the same: a site told it has no credentials at all, then given a webhook secret pasted wrong, says nothing about the 400s that follow. And on the return route the two refusals answer the payer identically, so the log is the only thing that tells them apart. ## And the window never ends under a caller that does not stop `FloodGuard::consume()` registers whatever it answered, which is right for the request counter: it bounds work already done. The log slot inherited it and should not have. A row carries the time it was written and the reader counts rows inside the window, so a row per ask keeps pushing the window forward: one line at the moment a flood begins and silence for as long as it runs. `docs/limits.md` says once per period. ## Not this one The verified-but-wrong-account warning in `resolvePaymentForCreated()` stays loud. It is behind a held signature, so it cannot be reached by a stranger, and its docblock says why it must be said every time. ## What this is not With request limits off, which is how they ship, nothing is collapsed anywhere, and `isFirstRefusalInWindow()` documents that as the honest meaning of the switch being off. This is about the site that has turned them on, which is the site that has decided it cares. ## Proposed resolution - Collapse the two `handle()` warnings in `WorldlineWebhookController`, `NoticeController::refuseNotice()` and the RETURNMAC mismatch in `WorldlineReturnController` through the `logOncePerCallerPerWindow()` each controller has. - Key the window on the caller **and which refusal it is**, never on anything read off the request: a reason a caller can vary is a line a caller can multiply. - Register the log slot only when something is about to be written, so a caller that keeps knocking is told of again each window. - A test per endpoint proving a second, different refusal is still written; and cases on `FloodGuard` itself, which had none. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)