A Zcash payment link is a text that starts with zcash: and carries an address plus, optionally, an amount, a memo, a
label and a message. Wallets turn it into a ready-to-confirm payment, and a QR code is the same text drawn as a picture.
ZIP 321 defines the format and has the status Active. This guide explains each part and what to check before you pay or accept.
Status as of October 13, 2026
Sources: ZIP 321: Payment Request URIs, the README and installation page of the BTCPay Server Zcash plugin, and ZecHub's guide titles, all read on October 13, 2026. We did not install the plugin or test how individual wallets handle these links.
What a payment link contains
ZIP 321 describes the goal as letting wallets build transactions from webpage links or QR codes with minimal manual entry. The
URI starts with zcash:. The address may follow the colon directly or appear as an address parameter, and ZIP 321 says the two
forms are equivalent. Parameters are joined with &.
| Parameter | What it holds | Rule in ZIP 321 |
|---|---|---|
address | A Zcash address, shielded or transparent | Sprout addresses must not be supported; wallets should check the encoding and, if they know the network, the network |
amount | An amount in ZEC | Decimal with a period, no grouping separators, at most 8 digits after the period, not above 21,000,000 |
memo | A message for the recipient | base64url without = padding, at most 512 bytes once decoded |
label | A name for the recipient | Percent-encoded text |
message | A note about the payment | Percent-encoded text |
For example, ZIP 321 treats 50.00, 50 and 050 as the same amount, and rejects 50,000.00, 50. and .5. Percent-encoding
is allowed only in the values of the label, message and other-parameter fields, never in addresses, amounts or parameter names.
A URI that does not follow the grammar must not be accepted.
Memos in a link
A payment link can pre-fill the memo field, the encrypted 512-byte message of a shielded payment. Because the memo is base64url-encoded, you cannot type plain text into the URI. A wallet or invoice tool does this for you. ZIP 321 adds a safety rule: a parser must treat the whole URI as invalid if a memo is attached to a transparent address, because a transparent output has nowhere to carry one. Our memo field guide explains who can read a memo and what fits in it.
Several payments in one link
Parameters that share an index belong to one payment, for example address.1, amount.1 and memo.1. ZIP 321 says implementations
should build a single transaction that pays all listed addresses, and it notes a practical limit: for Sapling-only payments, more
than 2,109 distinct payments might fail. Most readers will never need this; it matters for tools that pay many recipients at once.
The req- prefix
A parameter whose name starts with req- is required. If a wallet does not recognize one, ZIP 321 says it must reject the entire
URI. Unrecognized parameters without the prefix should be ignored. This is how a link can demand a feature, such as the custom
asset parameter, without an older wallet silently paying something different.
Which address to put in a link
Use the address type your wallet shows for receiving. Our address types guide explains transparent, Sapling and Unified Addresses, and shielded vs transparent transactions shows what each leaves on the public blockchain. A link to a transparent address cannot carry a memo and reveals the payment publicly.
Do wallets support it?
We did not test wallets. ZIP 321's own backward-compatibility section says several existing wallets use a similar zcash: scheme,
but typically without the req- rule, without multiple payments, often without the address= form and sometimes without memo
support or base64url decoding. Before you print a QR code for customers, open the link in the wallets your customers use, and
confirm that the amount, memo and address arrive as intended. Our wallet comparison lists wallets
and their shielded support.
Before you pay a link or scan a QR code
A link only pre-fills a payment; you still approve it. Check the address, the amount and the network on the wallet's confirmation screen. If the recipient is a person or business you do not already know, compare the address with one they gave you through a second channel. If a payment does not appear afterwards, see how to check a shielded transaction or balance.
Accepting ZEC as a merchant
There are two broad routes, and we describe what the sources say, not our experience with them.
- Show an address or a ZIP 321 QR code from a wallet you control. This needs no server. You see incoming payments in your wallet, and for shielded payments only the wallet's keys can show them. A viewing key lets a bookkeeper or tool see incoming payments without the power to spend.
- Use a payment server. The BTCPay Server plugin for Zcash says in its README that it "extends BTCPayServer to enable users to receive payments via Zcash". Its README warns: "This plugin shares a single Zcash wallet across all the stores in the BTCPayServer instance" and advises using it only if you are not sharing your instance. It lists the daemon RPC, wallet RPC and wallet directory settings as required, and its installation page says to use a wallet that supports viewing key export, naming YWallet and Zingo as examples. The repository page showed no published releases when we read it, so judge its maintenance yourself. For the node side, our Zebra node guide describes what running a node involves.
Tax, accounting and legal questions about accepting crypto depend on your country and are outside this guide.
What we could not verify
- Which wallets implement ZIP 321 fully; we tested none.
- How well the BTCPay plugin works today, and how many confirmations a shop should wait for; that is each merchant's choice.
- Whether payment-link support differs between wallet versions.
Sources
- ZIP 321: Payment Request URIs, status Active, authors Kris Nuttycombe and Daira-Emma Hopwood.
- BTCPay Server Zcash plugin and its installation page.
- ZecHub: a community guide on the BTCPay plugin, listed here as further reading, not used as a source for the statements above.