# BTCPayServer Zcash Plugin: Opinions on next steps **URL:** \ **Category:** Zcash Apps\ **Created:** [December 8, 2025, 3:07pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734 "2025-12-08T15:07:05Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![machinesunmachine](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/machinesunmachine/32/27149_2.png) [@machinesunmachine](https://forum.zcashcommunity.com/u/machinesunmachine)\ **Post date:** [December 8, 2025, 3:07pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734/1 "2025-12-08T15:07:05Z")
Hi Zcash, The BTCPayServer is a important payment gateway used by [many online merchants](https://directory.btcpayserver.org/). Having a functional, easy-to-implement Zcash plugin available for merchants is a great way for Zcash to increase the number of yearly transactions in ZEC. The [BTCPayServer Zcash plugin](https://github.com/btcpay-zcash/btcpayserver-zcash-plugin) was broken [[github post](https://github.com/btcpayserver/btcpayserver/pull/6535), [forum post](https://forum.zcashcommunity.com/t/grant-application-fix-btcpay-zcash-plugin/50204)], but is currently functional again. @artkor says there are currently seven merchants using it. He’d love to see that number increase to ~fifty merchants. In support of that goal, he thinks the highest priority would be to **implement multi-wallet and multi-store support**. @1337bytes thinks that **implementing mempool notifications** would be an important next step. Do people agree with them / are there other important features that the community thinks are being overlooked? ---
**Author:** ![artkor](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/artkor/32/28573_2.png) [@artkor](https://forum.zcashcommunity.com/u/artkor)\ **Post date:** [December 8, 2025, 4:33pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734/2 "2025-12-08T16:33:25Z")
Hello @machinesunmachine! Thank you for raising this topic here. Both I personally and ZCG as a whole definitely support any efforts focused on developing payment solutions for Zcash. _(If you look ahead, you can also find this reflected in today’s ZCG meeting minutes.)_ It really feels and in fact it truly is the case that Zcash is currently far behind the expected curve when it comes to real merchant adoption and the size of the active merchant list. Still, this is something we can catch up on. BTCPayServer Plugin _(and I think it is very important to explicitly highlight @hanh’s contribution here)_ and ZGo _(thank you @pitmutt!)_ are already quite good tools for experienced users. At the same time, in my view, they are still not good enough for capturing a much broader target audience. Regarding the BTCPayServer plugin and the idea of multi-store support. At the moment, the plugin supports only a single wallet. Even if there are multiple accounts on one server, only the first one can configure a wallet, since the plugin is installed only for the first account. All other accounts work only with the Bitcoin part, and the Zcash plugin is not available to them at all. Why does this matter at all? Let’s say I run a small shop and I want to accept crypto, but I have absolutely no familiarity with things like Docker and so on. I know nothing about them. This means I cannot quickly set this up without the help of a specialist. This is a clear accessibility barrier. But what if we launch a shared public server for such shops? A standard BTCPayServer hosted by the Zcash community. Merchants would simply go to the Zcash domain and register their store. The plugin would already be installed by default for all new accounts. They would just register, choose the preferred server language, set the default currency, enter the viewing key for their wallet (all of this guided by clear UI hints), and then immediately start accepting payments via built-in integrations, for example a simple script or a WordPress module. All popular options are already described in BTCPay’s FAQ. At the same time, we must guarantee their privacy. That is, the server owner must not be able to extract a viewing key from the database without knowing the user’s password. Yes, this is of course not a pure self-custody concept. But it is a very reasonable first step toward expanding the real merchant base. Right now, most services offered by our respected merchants are IT-oriented by nature (we already have several VPS providers alone), and this implicitly assumes a strong understanding of all self-custody steps. But what about a shoe store? A home bakery? An indie cosmetics shop? With the current approach, we simply will not reach them. I would really appreciate your feedback on this. ---
**Author:** ![machinesunmachine](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/machinesunmachine/32/27149_2.png) [@machinesunmachine](https://forum.zcashcommunity.com/u/machinesunmachine)\ **Post date:** [December 8, 2025, 6:14pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734/3 "2025-12-08T18:14:07Z")
For reference, here’s the results of the analysis that my team did of the BTCPayServer Zcash Plugin back in 2023. More development work has been done since that analysis, of course, but I’ve bolded the information we gave then regarding multi-wallet and multi-store support: > - There’s no ZCash section in the wallets area in BTCPay. All other currencies have them as a way to review your wallet / incoming payments / match up invoices / etc. The current implementation shows the ZCash address for purchase. > - ZCash viewing key is essentially hard-coded into the docker compose file, instead of having a settings page in the admin area like all the other currencies. > - **There does not appear to be support for multiple ZCash wallets, like with other currencies.** > - **No support for multiple stores (multiple stores must share the same wallet, as the ZCash plugin hard codes the wallet address into the container).** > - There’s no setup process for ZCash wallets, like there is with other currencies (when creating a new store, other currencies ask you for wallet info and enable/disable currency support depending on how you provide it). > - The method documented by Hanh is either incomplete or out of date, and requires using Hanh’s custom containers and will not work (at least without modification) with non ZCash currencies. The method documented below includes replacement info / code that works with the most recent version of BTCPay and is compatible with other currencies. > - The processes below are the result of a lot of trial and error due to poor / missing / outright incorrect documentation on both the parts of BTCPay and the ZCash plugin. There is zero chance a user without significant IT/dev experience will be able to get things working without new docs / changes to the code. > - We were unable to find any functioning wallet that supports testnet, and so had to run a full zcashd node in order to get some testnet coins to run transactions through. > - Running a testnet node does not appear to work. There’s no official documentation for it, and although we did find a docker container by Hanh that is named as if it supports it, that container crashes immediately on startup. Since Hanh doesn’t mention it anywhere, we’re assuming it’s something else. [[link to original analysis]](https://forum.zcashcommunity.com/t/zcash-based-secure-payment-infrastructure-for-a-privacy-focused-video-conferencing-service/44078/19) @artkor when you were telling me about all this and I was talking to my team about it, at first I was confused. But then it all made more sense to me after I went back to this analysis and remembered there are two separate issues: multi-wallet support AND multi-store support. ---
**Author:** ![1337bytes](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/1337bytes/32/18714_2.png) [@1337bytes](https://forum.zcashcommunity.com/u/1337bytes)\ **Post date:** [December 8, 2025, 7:05pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734/4 "2025-12-08T19:05:57Z")
Hi, thanks for raising this, there’s definitely a lot of work that can be done to increase merchant adoption of ZEC. Multi-store and mempool notifications would be great additions to the BTCPayServer integration. > [@artkor](#): > > At the same time, we must guarantee their privacy. That is, the server owner must not be able to extract a viewing key from the database without knowing the user’s password. Am not sure how feasible this is without an encryption step as I’m guessing that this information would be available on the host’s filesystem/database. Need to look into this more, there’s some information on this here: [Third-party hosting | BTCPay Server](https://docs.btcpayserver.org/Deployment/ThirdPartyHosting/#privacy-concerns) > [@machinesunmachine](#): > > - ZCash viewing key is essentially hard-coded into the docker compose file, instead of having a settings page in the admin area like all the other currencies. This, and the other mentioned issues (other than the lack of multi-wallet/store support) have since been resolved. There is now a testnet faucet, so running a full testnet node to mine some testnet coins shouldn’t be required anymore. > [@machinesunmachine](#): > > He’d love to see that number increase to ~fifty merchants. In support of that goal, he thinks the highest priority would be to **implement multi-wallet and multi-store support**. @1337bytes thinks that **implementing mempool notifications** would be an important next step. Mempool notifications would be a big improvement to the UX of paying using BTCPayServer. This would increase user confidence in the payment process by seeing near-immediate visual feedback that the payment has been recorded. > The invoice is considered “processing”, as soon as it is visible on the blockchain (and mempool). When the invoice reaches the defined number of confirmations, it is considered “settled”. > **[Stores FAQ | BTCPay Server](https://docs.btcpayserver.org/FAQ/Stores/#consider-the-invoice-confirmed-when-the-payment-transaction)** > > BTCPay Server Official Documentation @hanh, would you be interested in applying for a grant to add mempool and multi-account support to `zcash-walletd`, and if so, do you have an idea of how much this work would cost? From my research, it appears that a `notify_block` HTTP callback might be needed for handling the confirmation count update checks on the plugin side. ---
**Author:** ![DexMan](https://avatars.discourse-cdn.com/v4/letter/d/82dd89/32.png) [@DexMan](https://forum.zcashcommunity.com/u/DexMan)\ **Post date:** [July 28, 2026, 3:25pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734/5 "2026-07-28T15:25:22Z")
This plugin must be upgraded to support Zebra now that Zcashd is history: [github.com/btcpay-zcash/btcpayserver-zcash-plugin](https://github.com/btcpay-zcash/btcpayserver-zcash-plugin) ---
**Author:** ![emersonian](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/emersonian/32/42565_2.png) [@emersonian](https://forum.zcashcommunity.com/u/emersonian)\ **Post date:** [July 28, 2026, 5:01pm UTC](https://forum.zcashcommunity.com/t/btcpayserver-zcash-plugin-opinions-on-next-steps/53734/6 "2026-07-28T17:01:55Z")
I have an (untested) PR also that might be useful to someone looking for Ironwood support: > > > This is an AI-written pull request that I have not yet tested with BTCPayServer.… Posting this in case it's of interest to anyone else looking for NU6.3 support in zcash-walletd. > > \--- > > NU6.3 adds the Ironwood shielded pool. Ironwood reuses Orchard's keys, addresses and action encoding, so no new address type is needed — an Ironwood note is received at an ordinary Orchard receiver of a UA. What differs is that Ironwood notes use note-plaintext version V3 (lead byte 0x03) and live in their own commitment tree, and that once NU6.3 activates payments to an Orchard receiver are routed to the Ironwood pool. A wallet that scans only the Orchard bundle therefore stops seeing its own incoming payments after activation. > > \- Bump the librustzcash stack to the ironwood line from crates.io (orchard 0.15, zcash\_primitives/zcash\_proofs 0.30, zcash\_protocol 0.10, zcash\_keys 0.16, zcash\_address 0.13, zcash\_client\_backend 0.24.0-rc.4). Ironwood is not a cargo feature; activation is consensus-height driven, so a plain build is NU6.3-ready on every network. Add nu6\_3 to the regtest LocalNetwork. > \- Update the protos to the versioned lightwallet-protocol: CompactTx.ironwoodActions, TreeState.ironwoodTree, BlockRange.poolTypes (replacing spamFilterThreshold on tag 3), the PoolType enum, and the LightdInfo fields through lightwalletProtocolVersion. > \- Scan the Ironwood bundle: an Ironwood decoder built from the same Orchard FVK but the Ironwood note-encryption domain, positions tracked against the Ironwood commitment tree, and memos recovered from the V6 transaction's ironwood bundle. Spends are matched against both Orchard-family nullifier sets, since a note is nullified in whichever bundle owns its pool. > \- Request poolTypes only from a server advertising LightdInfo.lightwalletProtocolVersion, as the protocol requires: a legacy server may reject or misinterpret tag 3. Against one we fall back to the Sapling+Orchard default and log a warning — the public fleet is still v0.5.1 with no protocol version, so operators must upgrade lightwalletd before the activation height to see Ironwood receives. > \- Record a note's pool in received\_notes and key the uniqueness constraint on (pool, position). Note positions are only unique within a pool's own tree and Ironwood's restarts at zero, so the old UNIQUE (position) would reject the first Ironwood receives and fail the whole scan batch. Existing databases migrate automatically — the pool of an existing row is recoverable from rho without a rescan — so no database reset is needed. > > Also fixes the scan test, which never created its schema and so failed on any clean checkout.