CipherPay - Yes, another Zcash payment processor. Sorry. (beta)

[Kenbak]

Quick question. If a friend asked you tomorrow “I want to accept ZEC on my website,” what would you tell them?

For donations, sure, paste an address, done. But what if they need to know which customer paid which invoice, automatically, with webhooks to update order status? That’s where it gets complicated fast. Nodes to sync, Docker to configure, viewing keys to export from a separate wallet…

I tried walking a non-technical friend through the existing options. He gave up after 20 minutes. Can’t blame him.

So I built something simpler. It’s called CipherPay.

What is it?

A Zcash payment processor. Like Stripe, but for ZEC. Non-custodial. Shielded-first. No node required.

Register, paste your UFVK, get a working checkout page with webhooks. Five minutes.

Under the hood, CipherPay connects to CipherScan for blockchain data and does trial decryption of Orchard outputs using the merchant’s viewing key. Each invoice gets its own diversified address, no address reuse, no memo guesswork. When a buyer pays, CipherPay picks it up in the mempool, fires a webhook, and confirms when mined. Standard payment flow, same pattern merchants already know from traditional processors.

The tradeoff (might as well be upfront)

CipherPay needs your viewing key. That means the server can see your incoming payments, which invoices got paid, how much, when.

But let’s be real: if you’re a merchant, you already need this data. Bookkeeping. Taxes. Customer support (“did my payment go through?”). Any merchant running a real business is tracking their sales anyway and goes through centralized providers and much less privacy. CipherPay just automates it for Zcash and is non-custodial.

What it does NOT see: your spending, your balance, your other wallets. It’s a viewing key, not a spending key. Your funds are yours, always.

What we don’t collect: no IPs logged, no analytics, no third-party tracking. UFVKs and secrets are encrypted at rest (AES-256-GCM). Old data is purged automatically. And if you don’t trust anyonw, you can self-host the whole stack. Same code, your server, zero trust.

On-chain, payments are fully shielded. Orchard only. Nobody watching the blockchain sees anything.

What’s working right now

Not a roadmap. Deployed. Processing payments.

- Merchant dashboard (products, invoices, POS cart mode, billing)

- Per-invoice diversified addresses (no address reuse, ever)

- Real-time mempool detection + block confirmation

- Webhooks with HMAC signing and replay protection

- ZIP-321 payment URIs — scan QR, wallet opens with amount + memo pre-filled

- Multi-currency (EUR/USD display, rate locked at invoice creation)

- WooCommerce plugin (install, paste credentials, done)

- Testnet sandbox at testnet.cipherpay.app

- Encryption at rest, rate limiting, CORS hardening, automatic data purge

Try it

The testnet sandbox is a full mirror of production. Register with a testnet UFVK, create invoices, send test payments with free testnet ZEC. When ready, switch to mainnet, same code, just update your API URL and UFVK.

I also built a store to prove the whole flow works end to end: 0x00.store. Limited drop tees, ZEC-only, powered by CipherPay. Pick something, pay with your wallet, order confirmed automatically.

Privacy note: for full anonymity when ordering physical goods, use a PO box or conference pickup.

I’m not going to pretend there’s a massive market for this today. The number of merchants who want to accept ZEC is small. Everyone building in this space knows that.

But I think the infrastructure should exist before demand does. When someone asks “how do I accept Zcash?”, the answer should be five minutes, not a weekend of DevOps.

If you try it and something breaks, tell me. If you have ideas, drop them below. I actually read everything and fix things.

Links:

- CipherPay: https://cipherpay.app

- Testnet sandbox: https://testnet.cipherpay.app

- Docs: CipherPay — Private Payments for the Internet

- 0x00.store (live demo): https://www.0x00.store

- CipherScan (the blockchain API behind it): https://cipherscan.app

Kenbak

P.S. If you’re at a Zcash conference and see someone in a [REDACTED] or [ZERO KNOWLEDGE] tee, that’s probably from the store. Say hi.

[Zebraman]

I noticed the GitHub link on cipherpay.app points to a 404.
Also, both of the CipherPay repositories are missing a license file, with the readme only saying “MIT” under a License heading. I’m pretty sure that’s not legally sufficient.

[Kenbak]

Good catch! We were in the process of migrating the repos to a new org. Both the GitHub link and the LICENSE files are now fixed. Thanks for flagging it.

[Kenbak]

A few things shipped since the original post.

Bug fixes on https://0x00.store

The webhook flow had an edge case where stock wasn’t decrementing correctly on certain order types. Fixed. Also cleaned up the order pipeline, duplicate invoice handling is tighter now.

Billing fixes

The billing enforcement was being too aggressivem merchants could get blocked over tiny outstanding balances (fractions of a cent worth of ZEC). Fixed: balances under 0.05 ZEC now carry over to the next cycle instead of triggering settlement invoices. Also extended the new merchant grace period from 3 to 7 days.

Shopify integration

CipherPay now works with Shopify stores. Install the app, add your API key, and customers get a “Pay with Zcash (ZEC)” option at checkout. Payment button shows up on the Thank You page, and the order gets marked as paid automatically when the ZEC arrives.

No Shopify Plus required. Works with manual payment methods on any plan.

If you want to see the flow in action, you can check the test store here: https://cipherpay-test.myshopify.com

(password: cipherpay)

(heads up, the products listed there are not actually for sale, it’s just a demo to show the checkout experience. If you want to actually buy something with ZEC, go to 0x00.store).

Setup guide is in the docs: CipherPay — Private Payments for the Internet

Install link for your own store:

https://shopify.cipherpay.app/api/auth?shop=yourstore.myshopify.com

So that’s three ways to accept ZEC now: custom API, WooCommerce plugin, or Shopify app.

Still building.

[Kenbak]

Hey all, quick update.

Product catalog

Rebuilt the product/price model. Products now support multiple prices across 11 currencies (EUR, USD, BRL, GBP, CAD, JPY, MXN, ARS, NGN, CHF, INR). One-time or recurring. Each price is its own entity, closer to how Stripe models it.

Subscriptions (beta)

CipherPay now supports recurring payments via the API. Create a product with a recurring price (daily, weekly, monthly, yearly) and the system handles draft invoice creation before each billing period. Customers finalize and pay, webhooks fire on renewal and cancellation.

API-only for now, no dashboard UI for managing active subscriptions yet. And some parts of the flow (like failed payment handling and dunning) still require manual merchant intervention.

UI/UX pass

Did a full pass on the frontend. Checkout page is cleaner, timer above the QR, collapsible details, better guidance for buyers on what to expect after sending. Dashboard got invoice filters, a setup checklist, and transaction links to CipherScan. Everything is more consistent across the board. Still more to come, but it’s noticeably tighter.

Spanish and Portuguese

CipherPay is now available in Spanish and Portuguese , landing page, dashboard, checkout, all UI.

Why start with LATAM? They have some of the most active cryptocurrency communities out there. Bitcoin adoption is already strong, and the Zcash community groups in this region are among the most engaged. And Zcash genuinely helps here, private, sovereign, in places where local currencies are inflating.

We want to make privacy accessible globally. A lot of the crypto world speaks English, but if you want to reach new people, breaking the language barrier is the way.

Cipherpay Spanish

Cipherpay Portuguese

A note on quality: translations were done with the help of LLMs. They’re functional but not perfect. If you’re a native speaker and spot errors, awkward phrasing, or better ways to say something, please let us know. We’d love the help.

Docs

Revamped the documentation. Every guide has its own section now, Shopify, WooCommerce, Custom Integration, Product Pages, In-Person POS, Webhooks, Subscriptions, Billing, API Reference, and x402. Easier to follow, easier to find what you need.

Cipherpay Docs

You can also follow us on X: @cipherpay_app (made our debut yesterday)

Still building.

Kenbak

[Michae2xl]

@Kenbak

CipherPay is now available in Spanish and Portuguese , landing page, dashboard, checkout, all UI.

Oh, that’s nice! I will continue the implementation soon on the website. Thank you for adding it.

[Kenbak]

Another update.

Two new open-source packages shipped this week, both focused on making CipherPay programmable.

@cipherpay/x402: Paywall any API with shielded Zcash

x402 is an open protocol for paying for API access via HTTP 402. The existing implementations support Base, Solana, Polygon, all public chains. Every payment is visible on-chain.

@cipherpay/x402 is the Zcash facilitator. It lets any API developer gate endpoints behind shielded ZEC payments. Three lines of code:

app.use('/api/premium', zcashPaywall({

amount: 0.001,

address: 'your-unified-address',

apiKey: 'cpay_sk_...'

}))

Client hits the endpoint → gets a 402 → sends shielded ZEC → retries with proof → CipherPay verifies via trial decryption → access granted.

No one sees who paid, how much, or what they accessed. That’s the difference between x402 on a public chain and x402 on Zcash.

Supports Express out of the box, framework-agnostic adapter for anything else, and dynamic pricing per request.

npm: @cipherpay/x402 Source: GitHub

@cipherpay/mcp — CipherPay for AI agents

MCP (Model Context Protocol) is a standard that lets AI assistants, Claude, Cursor, OpenClaw, any MCP-compatible agent, call external tools natively. Instead of copy-pasting from a dashboard, the AI talks to CipherPay directly.

What an AI agent can do with the CipherPay MCP:

• “Create a $20 invoice” → invoice created, payment link returned
• “Check if invoice CP-3F2A was paid” → confirmed, 0.044 ZEC, 2 min ago
• “What’s the ZEC/USD rate?” → $227.14
• “Verify this x402 payment” → valid, access granted
• Look up product details and prices

Why this matters:

For merchants, your AI assistant can handle payment operations. A customer says “I paid but nothing happened” → the AI checks the invoice status instantly. Need to create an invoice for a custom order? The AI does it conversationally. No dashboard login, no context-switching.

For developers, test your CipherPay integration without leaving your IDE. Create invoices, check states, debug payment flows, all from Cursor or Claude Desktop.

For the ecosystem, this is the start of AI-native Zcash payment infrastructure. The x402 package lets any API accept shielded ZEC payments. The MCP lets merchants and developers manage their CipherPay account from any AI assistant, create invoices, check payment statuses, verify x402 transactions, look up rates.

Both packages work with any existing CipherPay merchant account.

Still building.

Kenbak

[Kenbak]

Hey everyone,

We’ve published a couple of video walkthroughs for CipherPay:

Shopify Setup - Install the CipherPay app, configure it, and test a Zcash payment at checkout. Under 5 minutes.

MCP for AI Agents - Set up the CipherPay MCP server in Cursor. Create an invoice, pay it, and verify the payment, all through natural language. Also works with Claude Desktop and any MCP-compatible client.

Both are also embedded in the docs.

Happy to answer any questions.

[Kenbak]

CipherPay | Update #3

A lot shipped since the last update.

---

UIVK Migration: Principle of Least Privilege

Shoutout to @nuttycom for pointing this out. CipherPay was storing the full viewing key (UFVK) when it only needs the incoming viewing key (UIVK) for address derivation and payment detection.

Fixed. Merchants can still register with either a UFVK or UIVK, if a UFVK is provided, we derive the UIVK server-side and discard the full key. Only the UIVK is stored (encrypted). CipherPay can detect incoming payments but never sees outgoing transactions from your wallet.

Less data stored = less risk.

---

Events & Ticketing

CipherPay now supports event ticketing natively. Merchants can create events with tiers, capacity limits, and sell tickets via shielded ZEC payments.

---

Agentic Payments - MPP

The @cipherpay/x402 package now supports MPP (Micropayment Protocol) alongside x402, two protocols, same shielded payment infrastructure.

---

zipher-cli | A Headless Zcash Wallet for AI Agents

This one isn’t part of CipherPay directly, but it completes the picture on the agent side.

@cipherpay/zipher-cli is a headless Zcash light wallet built for AI agents. It runs locally, manages keys, syncs with the network, and can pay for APIs autonomously, handling x402, MPP, and CipherPay sessions out of the box.

Think of it as the client-side counterpart to @cipherpay/x402. The middleware protects the API. zipher-cli lets agents pay for it. Fully shielded, both sides.

Early beta: npm install -g @cipherpay/zipher-cli

---

Dashboard & Website

Full responsive redesign of the merchant dashboard, mobile sidebar, tab layouts, agentic payments section with session tracking. Landing page modernized. FAQ rebuilt with accordion UX. Checkout UI polished for WCAG contrast compliance.

---

I won’t be able to make it to EthCC this time around, but if you’re there and find a merchant or product that should be accepting ZECm point them our way. Every merchant accepting Zcash makes the network more useful as actual money. The more places you can spend it, the stronger the case that shielded payments work at scale.

Still building.

Kenbak

[thejohnnycrypto]

More payment processors means more reasons to spend shielded ZEC in practice. Curious about the fee structure and whether it handles unified addresses natively. Merchant tooling is where Zcash proves itself as useful money, not just a protocol debate topic. Nice work

[Kenbak]

Fee is 1% per transaction, no monthly fees.

Unified Addresses natively, every invoice gets a unique diversified address derived from the merchant’s viewing key. Fully shielded Orchard only.

[zk_nd3r]

Good to see more Orchard tooling. We’re doing something adjacent with zec-pay: lifecycle commitments on top of the same payment detection pattern.

[nuttycom]

Something I noticed: you should probably eliminate fees that amount to dust; a fee output of 5000 ZAT or less is literally worth nothing (or less than nothing) because the ZIP 317 fee to spend that note is more than the note is worth. You might want to make transactions with fees below some meaningful amount (say 25,000 ZAT - currently ~$0.05) free?

[Kenbak]

Yes. I t

@nuttycom

Something I noticed: you should probably eliminate fees that amount to dust; a fee output of 5000 ZAT or less is literally worth nothing (or less than nothing) because the ZIP 317 fee to spend that note is more than the note is worth. You might want to make transactions with fees below some meaningful amount (say 25,000 ZAT - currently ~$0.05) free?

Agreed. It’s on list for the next update!

Thank you for poinbting that out!

[operational-anxiety4]

The UFVK tradeoff is fair, but I think this opens an interesting direction. Could there be a future version where invoice verification is provable without fully exposing the viewing layer? Some kind of selective disclosure or zk-attested payment confirmation? Either way, this feels good. If this gets even moderate adoption, it could quietly become a usable entry point for merchants.

[Kenbak]

T

@operational-anxiety4

The UFVK tradeoff is fair, but I think this opens an interesting direction. Could there be a future version where invoice verification is provable without fully exposing the viewing layer? Some kind of selective disclosure or zk-attested payment confirmation? Either way, this feels good. If this gets even moderate adoption, it could quietly become a usable entry point for merchants.

Exactly! a wallet could scan locally and send us a zk proof of payment. We verify it without needing the viewing key at all. The primitives exist in the protocol, just needs the right circuit built. On our radar for sure.

The tradeoff: the merchant must have their wallet online and running for payments to be detected. If their wallet is offline, invoices don’t get confirmed. That’s why the current UIVK model exists, CipherPay scans 24/7 on their behalf.

[zk_nd3r]

Yeah, I think that’s the right direction.

UIVK is a reasonable operational tradeoff for always-on invoice detection, but the stronger model is proving settlement without handing over the full viewing layer. Once payment confirmation can be selectively disclosed, you can keep shielded settlement underneath and expose only the business fact you actually need for reconciliation or audit.