Fixed the Permit2 payment window bug. pay.ts now caps the signed deadline at the earlier of quote expiry minus five seconds and the challenge’s timeout minus five seconds. Invalid windows raise PaymentRefusal before the daily spend reservation. The mock enforces the 300 second limit, and imd_pay explicitly includes a submit 4xx error code.

I checked the live API with GETs, a free check, and a free quote and 402 challenge; the saved challenge backs the new test. No live payment was submitted. The changelog lists each change and retains the experimental label.

npm test passed all 31 tests in a temporary copy with the project’s existing dependencies installed.

Review complete. The findings file holds four entries, three low and one informational, and no tracked file was changed.

What I checked and found correct

• Deadline against the live challenge. A fresh free quote and 402 from api.imd.fun today match the saved fixture exactly: 600 s quote lifetime, 300 s maxTimeoutSeconds. The code signs min(expiresAt - 5, now + 295), which satisfies both documented server rules (before quote expiry, not past now + window).
• Other signed fields. I installed the x402 SDK version the server pins (2.27.0) and compared its exact-scheme Permit2 construction with signPayment field by field: same spender proxy constant, same Permit2 domain, identical witness types, checksummed addresses, decimal nonce and deadline strings, validAfter "0". The QuoteApproval domain, types and message match the live docs and the openapi x-imd-quote-approval block, and the canonical JSON hashing is equivalent to the documented canon. Both the spender and Permit2 have code on mainnet. Payload keys are exactly the documented set, so the strict parser should not reject anything.
• Caps. The per-request cap is applied to the same amount that goes into permitted.amount, the day ledger is reserved atomically before signing, and I found no input, action, or runs value that signs more than the capped total.

Findings, by severity

1. Low, src/pay.ts:382. If signing throws after the daily reservation (a challenge whose requesterScopeHash or quoteHash is not valid hex, which verifyChallenge never checks), nothing is sent but 0.5 IMD of the daily cap is consumed and the order is locked for retry. Reproduced on the mock.
2. Low, src/pay.ts:207. A quote with 11 s left is signed with a 6 s Permit2 deadline, submitted, and reserved. That cannot settle on chain, so the predictable result is payment_failed plus a burned allowance. Reproduced on the mock.
3. Low, tests/mock-server.ts:270. The mock enforces only the upper bound. A payment with deadline 0 is accepted with HTTP 202, so the suite would not catch a regression that the live server refuses.
4. Info, src/pay.ts:204. The prescribed 5 s margin tolerates at most 5 s of client clock drift, and each refused attempt still spends the daily allowance. This follows the task's formula, so it is a scope note, not a defect.

Nothing rose to medium or higher. The existing suite builds and passes all 31 tests.