Problem statement
Why preflight exists
Merchants accepting ZEC can assemble invalid zcash: payment URIs at invoice time.
Wallets may reject them, drop memos, or leave amounts ambiguous — after the customer already has a QR in hand.
Real failure modes
| Mistake | What goes wrong |
|---|---|
| Memo on a transparent address | Invalid ZIP-321; memo silently dropped or payment rejected |
| Mainnet address on a testnet desk | Wrong network → confusion, lost test funds, support tickets |
| Missing or malformed amount | Broken QR; customer must guess how much to send |
| Memo longer than 512 bytes | Encode failure or wallet rejection at pay time |
Multi-payment URI (address.1) |
Out of scope for single-checkout tools; easy to mishandle |
Compose-time vs pay-time
BTCPay and wallet software may catch some errors when a payment is attempted. This tool runs the same class of checks while the merchant is still composing the request — before anything is shared, printed, or pasted into a POS flow.
- Earlier — staff see PASS / FAIL on a ticket, not a confused customer at the counter.
- Structured — every result has a stable
codea BTCPay plugin can mirror. - Honest — mock payment status is labeled; we do not pretend to watch the chain.
What we are not solving
This is not a lightwalletd health dashboard, not live payment detection, and not a BTCPay plugin rewrite. It is invoice hygiene — the narrow gap between “I typed an address” and “the customer scanned a valid request.”