Frequently Asked Questions

CipherPay uses Zcash shielded transactions exclusively. On the blockchain, all payments are fully encrypted, no outside observer can see the sender, receiver, amount, or memo. However, CipherPay (as the payment processor) does see the transaction details because it performs trial decryption using your viewing key. This is the same trade-off as any payment processor: Stripe sees your transactions too. The difference is that the blockchain layer is completely dark.

When using the hosted service, CipherPay can see: your Unified Full Viewing Key (read-only, cannot spend funds), payment amounts, and product names. We cannot see the buyer's wallet balance, other transactions, or identity. We never hold your ZEC — payments go directly to your shielded address. No shipping addresses or buyer PII are stored.

Self-host CipherPay. The entire codebase is open-source. When you run your own instance, only your server holds the viewing key, and CipherPay (the company) sees nothing. You get the same features — mempool scanning, trial decryption, webhooks, with zero third-party data exposure.

No. CipherPay uses a Unified Full Viewing Key (UFVK), which is read-only. It can detect incoming payments but cannot create transactions or move your ZEC. Your spending keys never leave your wallet.

No. Generate a dedicated wallet exclusively for your CipherPay store. This isolates your commercial transaction history from your personal finances. If the server is ever compromised, an attacker would only see your store's sales history, not your personal net worth or other transactions. Sweep funds from your store wallet to cold storage regularly.

1. Create a brand new wallet (using Zodl, Zipher (coming soon), or Ywallet) dedicated to your store. 2. Export the Unified Full Viewing Key (UFVK) from that wallet. 3. Use that UFVK when registering on CipherPay. 4. Periodically sweep received funds to your main cold storage wallet. 5. Never reuse this wallet for personal transactions.

Yes. You can update your payment address anytime from the dashboard settings. For security, this requires re-entering your dashboard token. New invoices will use the new address. Existing pending invoices keep the address they were created with.

Not in the current version. Changing the UFVK requires the scanner to keep the old key active until all pending invoices are resolved. For now, if you need to rotate your viewing key, create a new merchant account. UFVK rotation is planned for a future release.

Each invoice gets a unique payment address derived from your viewing key (UFVK). CipherPay scans the Zcash mempool and new blocks, performing Orchard trial decryption on shielded transactions. When a payment is detected to an invoice's unique address, it is automatically matched — no memo required. This provides sub-minute payment detection, often within seconds.

Each invoice gets a reference code for identification purposes. It is included in the Zcash URI as an informational memo, but payment detection does not depend on it. CipherPay matches payments by their unique cryptographic address, so the buyer just scans the QR code and sends. There is nothing to copy or type.

CipherPay accepts payments within 0.5% of the invoice price to account for wallet rounding and network fee differences. If a payment is significantly underpaid, it is ignored and the invoice remains pending. The buyer would need to send the correct amount.

By default, 30 minutes. This window locks the ZEC/EUR or ZEC/USD exchange rate at the time of invoice creation, protecting both the merchant and buyer from price volatility. If the invoice expires, a new one must be created (with a fresh rate).

Merchants authenticate via a dashboard token (cpay_dash_...) exchanged for an HttpOnly session cookie. The token is hashed with SHA-256 before storage, a database breach doesn't leak credentials. Sessions use Secure + SameSite=Lax cookies, preventing XSS cookie theft and CSRF attacks. API keys (cpay_sk_...) are also SHA-256 hashed and used for server-to-server integrations.

The "penny exploit" (sending 0.00001 ZEC to trigger a confirmation) is blocked by server-side amount verification with a 0.5% slippage tolerance. Webhooks use HMAC-SHA256 signatures with timestamps, preventing both forgery and replay attacks (5-minute replay window). Changing the payment address requires re-authentication with your dashboard token.

No. CipherPay does not collect or store shipping addresses, names, or any buyer PII. It is a pure payment processor. Merchants who need shipping information should collect it through their own store and integrate with CipherPay via webhooks for payment confirmation.

Yes. CipherPay is fully open-source. Clone the repository, configure your environment variables (UFVK, CipherScan API URL, database), and run the Rust binary. It works with SQLite for local development or PostgreSQL for production.

A server with Rust installed (or use the Docker image), access to a CipherScan API instance (public testnet/mainnet endpoints work), and a Zcash wallet to generate your UFVK. The minimum requirements are modest, the Rust binary is lightweight.

No. CipherPay has a 1% fee on each payment. Later, subscription tiers with rate limits and premium features are planned. Self-hosting will always remain free.

That's the plan. When subscription tiers launch, you'll be able to pay for your CipherPay subscription using CipherPay itself, using fully shielded ZEC payments. Dogfooding at its finest.

x402 is a protocol that revives the HTTP 402 "Payment Required" status code for programmatic payments. When an AI agent or automated client requests a paid resource, the server responds with 402 and includes payment terms (price, address, chain). The agent pays and retries the request with proof of payment. CipherPay acts as the Zcash facilitator — verifying shielded payments so your server doesn't need to understand Zcash internals.

CipherPay uses the same trial decryption mechanism as invoice detection. When your server calls POST /api/x402/verify with a transaction ID, CipherPay fetches the raw transaction from the Zcash network, attempts to decrypt its Orchard outputs using your viewing key (UFVK), and checks if the decrypted amount meets the expected threshold. The sender's identity remains fully private — only the payment amount and recipient are verified.

No. The agent just needs a Zcash wallet with funds. It sends ZEC to your payment address and includes the transaction ID in its request. Only the resource server (you) needs a CipherPay account to call the verify endpoint. The agent is completely anonymous.

CipherPay is the facilitator for Zcash-to-Zcash payments specifically. For other chains (USDC on Base, ETH, SOL), the resource server would use a different facilitator. The x402 protocol supports multiple chains in the "accepts" array, so a server can offer several payment options. AI agents with multichain wallets (e.g. via NEAR Intents) can swap tokens and pay on whichever chain the server accepts.

No. x402 verification is free. CipherPay provides it to drive Zcash adoption for AI and programmatic payments. Revenue comes from the existing invoice-based payment processing. The x402 facilitator and the invoice checkout system serve different use cases — x402 is for programmatic API access, while invoices are for human-facing e-commerce.