Workflow

How it works

A merchant-facing desk that encodes ZIP-321, validates addresses with maintained libraries, prints a thermal-style ticket, and exports data a BTCPay companion can ingest.

  1. Compose or parse

    Enter receive address, amount, memo, label, and message — or paste an existing zcash: URI. The desk supports unified, Sapling, and transparent addresses with explicit network selection.

  2. Run preflight

    Structured checks produce a PASS or FAIL ticket with a checklist. Warnings (e.g. transparent receive, no memo) do not fail preflight; hard errors (memo on t-addr, network mismatch) do.

  3. Share with customer

    On PASS, copy the URI, open the customer pay page with QR, or print the ticket. The pay page is a read-only view of the same validated payload.

  4. Export for BTCPay

    Download handoff JSON matching handoff-v1 schema: preflight checks, payment URI, invoice fields, and explicit ownership disclaimer (compose-time vs settlement).

  5. Status lane (mock)

    Advance unpaid → detected → confirmed locally to demo a merchant workflow. This lane is MOCK — NOT CHAIN. Real detection belongs in BTCPay / zkool integration.

Under the hood

Address engine

Primary path: @elemental-zcash/zaddr_wasm_parser (Rust zcash_address → WASM). Heuristic fallback if WASM fails — always shown on the ticket.

ZIP-321 subset

Single-payment URIs only. Multi-pay query keys are rejected loudly. Memo encoding respects shielded rules.

CLI doctor

Same checks headless: node bin/doctor.js --file fixtures/good-ua.json exits 0 on pass, 1 on fail. Used in CI and merchant scripts.

10-minute reviewer path

Follow the four-step path on the merchant desk (sample buttons + handoff export), then use the reviewer guide on GitHub.

Try on the desk Check reference