I propose to build a payment gateway for e-commerce and charity donations.
By integrating into BtcPay it would leverage their existing user base and expertise in the field.
Challenges include:
Benefits:
While I am overall supportive of adding Zcash support to 3rd-party payment processors, especially open source ones, the proposal lacks the depth and plans for integrating with BTCPay Server. I would like to discuss the following issues with the proposal:
In the technical approach, “It is shielded. A block explorer cannot see the merchant’s transactions” should not be a problem as the viewing keys can be generated to verify incoming z2z payment and then forwarded to merchant’s destination address or held on the viewing key address it self. And memos are for Z-address only, not T-address. T-addrs payments can be verified via a block explorer.
For the block scanner, maybe you can leverage the Zcash Block Explorer which is being funded currently. And leverage ZIP-321 for Payment Request URIs ZIP 321: Payment Request URIs
The complexity could be limited to T-address setup and Z-address viewing key setup, which the new pools should share.
BTCPay Server does not officially support “altcoins” and can remove “altcoin” implementation if it is not maintained. Is it possible to test the waters by connecting with BTCPay Server devs and checking their interest in onboarding a Zcash implementation?
https://docs.btcpayserver.org/Altcoins/
Note: BTCPay developers do not implement alternative coins on request. Adding a new coin explicitly depends on the community and developers of those coins. Furthermore, BTCPay developers do not spend excessive time testing nor maintaining the altcoins. If you’re submitting a PR for a new coin, make sure that your image works. If the altcoin integration is not actively maintained it will be removed from BTCPay.
Downsides of the project need to be expanded to the level of ongoing support post implementation, have you evaluated how was the experience of Ethereum & Monero integrations?
This proposal is heavily tied to BTCPay Server, what is the backup if it is not integrated? What are the alternatives? Can the deliverable be run as a standalone ZcashPay Server instead?
It would be better to see precise estimation for a task of this size, as for gauging interest, the forum is the best to discuss it.
and last, it’s Zcash, not ZCash 
I’m referencing the BtcPay architecture which uses its own block explorer to bridge between the fullnode and the payment server. I know that you can use the ivk to decode incoming transactions but in the context of the existing explorer, it is not available.
The block scanner itself is not a concern. We have libraries that make this trivial to implement. The issue is that it has to fit with the existing chain. This explorer is the bridge with the payment server. It must have the same API and it must be able to run along with the other block explorer.
I’m not sure what you mean by that. If you are talking about only supporting t-addresses for refunds, that could be considered. Also I don’t see why the new pools would have the same z-addr setup but maybe they do. Sprout and sapling don’t have the same address format.
Their position is well known. In short “They welcome new coins but don’t expect them to do the work for you”.
As a platform, it is understandable that they want to check the quality of the code they associate with. This is true for any framework to be honest.
Even if the Monero or Ethereum teams have decided to drop their support for btcpay server it doesn’t mean the same will happen to zcash. In this respect, I don’t see where
the downside is. In any case, as the integration is open sourced, there is an opportunity for another team to take over.
In the past, Anypay has taken a grant to add zcash but dropped it after a year. Now the community doesn’t get anything because the code isn’t available.
Before committing to this project, we’ll do a thorough analysis of the work required. If it is not cost effective, I will cancel (and refund). Though we won’t commit before having a good level of confidence. For example, at this point, I think that t-addr support should be doable at the minimum. This will allow people to pay in zcash privately as long as they use a z-addr themselves (z2t tx). Not as good as z2z or t2z but at least the customer privacy is protected.
To be clear, we will not attempt to build zcashpay server from scratch.
Instead, if we say that they can have zcash payments (in addition to bitcoin) by flipping a switch, this is much better value proposition in my opinion.
Clearly, it is a lot of work. This is not the first time that a payment gateway has been suggested but it is still not available. I’m going to guess that the project difficulty is one factor.
I have done a certain level of research to gauge the feasibility of the integration: It’s hard and it’s made harder because we don’t have full control of the platform. But again, that’s true for any project. We can’t fork btcpay and plug it in because we need to have recognition from the btcpay foundation too. Otherwise merchants will not pick us up.
At this point, I’d like to know how much interest there is in proceeding further from the community and from ZOMG. If there is a lot, then we will start engaging the other team.
Thanks for your interest in this project.
I think this is an important consideration in relation to UX. Enabling current (and future) users of BTCPay Server to simply accept ZEC with just a toggle would be the perfect Trojan horse for Zcash acceptance as a payment network.
It is also acceptable that the first iteration would only enable sending to a transparent address. However, if ZEC is indeed popular among BTCPay Server users then we can try to integrate shielded address. Ideally we want a fully shielded ZECPay Server in the future with ZUSD payment rails (if ECC decides to develop UDAs that is).
Hi @hanh, sorry for the delay in getting back to you. Contrary to what you may be thinking, the ZOMG actually likes this idea a fair bit. We cross-checked with some folks from the ECC and they are also keen on the idea, which is good news since they spend a lot of time thinking about getting ZEC out there in people’s hands/transactions.
However, as you point out, there are questions around the feasibility of this succeeding as designed, given the inherent limitations of the pieces you have to play wth.
Do you think this kind of breakdown for the project makes sense?
Milestone 1 - documentation of how the integration is going to work and the task graph that gets to a working product.
Milestone 2 - documented interfaces with stub implementations, etc.
Milestone 3 - successful integration into BTCPay Server.
At any stage above, we are both free to decide (mutually) that it may not be worthwhile carrying it out to the very end.
Let us know what you think!
It is a useful feature. Is this better than the WooCommerce Payment gateway?
Hi @ml_sudo , I think that works out. I’d like us to clarify the terms of success and expand Milestone 3 into smaller chunks if it’s ok with you.
WooCommerce Payment gateway is a commercial product and they only support bitcoin.
it would be totally okay… and desired! 
Great, please let me know if you need something from me to move forward
Should we collaborate on this? Or were you thinking of doing this later after you get started (it would be ideal to get this out of the way earlier).
Primary goal is to accept payment in ZEC from customers. They must be able to pay from transparent, sprout or sapling addresses.
Secondary goal is to support shielded address for the store. If it is not possible directly, we can auto migrate daily.
Also, the support for ZEC should be well documented and as easy as possible.
The actual tasks breakdown for milestone 3 will have to be defined after we get more clarity about the implementation plan.
Sounds good! Would you be able to update the grant application? We will approve after.
I believe that is only enabled after the grant is approved? (Update is for milestone reporting). For now, you can edit the original grant I guess.
Could you click on “Edit Proposal?” Is that option possible?
@hanh You will need to edit the proposal to update, updates in that context are only available after a proposal has been approved.
“Post a progress update” might clarify that a bit
@tokidoki @ml_sudo @Shawn, Thanks for the clarification. I have edited the proposal as you suggested.
Thanks @hanh. I don’t see the milestones in the revised doc. Would you mind taking another look?
