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, product names, and shipping information you attach to invoices. We cannot see the buyer's wallet balance, other transactions, or identity. We never hold your ZEC — payments go directly to your shielded address.

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 Zingo, YWallet, or zcashd) 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.

CipherPay continuously scans the Zcash mempool and new blocks using your UFVK. It performs Orchard trial decryption on every shielded transaction to check if it's addressed to your wallet. When a match is found, it reads the encrypted memo field to identify which invoice was paid. This provides sub-minute payment detection — often within seconds of the buyer sending the transaction.

Each invoice gets a unique memo code that the buyer includes in their Zcash transaction memo field. This is how CipherPay matches a payment to a specific invoice. The QR code and Zcash URI automatically include the memo, so the buyer doesn't need to type it manually.

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 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.

Shipping data is stored in the database and only accessible to the authenticated merchant. The public checkout API never exposes shipping information. After the configurable data purge period (default 30 days), shipping data is automatically overwritten with NULL — if the database is compromised months later, there's nothing to steal.

The Next.js frontend enforces strict CSP: default-src 'self', frame-ancestors 'none' (prevents clickjacking), form-action 'self', and connect-src scoped to the API domain. X-Frame-Options, X-Content-Type-Options, and a strict Referrer-Policy are also set.

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.

The current version is free for all users. Subscription tiers with rate limits and premium features are planned for the future. Self-hosting will always remain free.

No. CipherPay does not take a percentage of your sales. The planned monetization model is a flat subscription fee for the hosted service. Your revenue is your revenue.

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