fix: the hosted payer page refused every link and accused the merchant
Round 8's refusal treated a 404 from the invoice lookup as "your server says it never issued this". A static host 404s every path it does not have, and the page is published on GitHub Pages - so every legitimate payment link was refused, with an accusation that the merchant had forged it. The flagship demo did not work at all. A 404 is evidence only once a watcher is known to be answering, so presence is probed on the payer route's own CORS terms, and /healthz now carries that grant instead of being blocked exactly where it was needed. Three more, all the same shape - the fix landed on the case it was shown: - A refusal wrapped in a generic envelope was still read as "may have been submitted". Round 8 stopped taking the first code for UNRECOGNISED codes and left it live for known-but-not-pre-submission ones, so UNKNOWN_ERROR around USER_REFUSED_OP locked the payer out while telling them they had dismissed the prompt. A pre-submission code anywhere in the error now wins. Codes sent by name are understood, and a cyclic or throwing error object can no longer escape the classifier - it used to throw from inside the catch that builds WalletActionError, losing the submitted flag entirely. - The store key gained a terms digest with no migration read, so a payer mid-payment when the widget updates found no record of a broadcast that had already happened and paid again. The old key is read and carried forward, and the amount is normalised through the same parser the matcher uses: "2.50" and "2.5" were one invoice to matchesInvoice and two keys to the store. - Both create-failure paths deleted by id with no identity check, while the write path 20 lines below carried the guard. A create that failed after its id had been released and reused deleted the live invoice holding it, freeing an address a payer's link still pointed at. 172 tests; the six new guards verified by breaking them, including one that needed a visit counter because a catch-all was masking the failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B
bongbongcrypto committed
22768abf4ccc10b094cf8b389304eda87f4640d7
Parent: 54d3011