Skip to main content
End-to-end body encryption is available in production now. ZeroClick relays Compact JWE ciphertext and never receives the private keys that decrypt either body.
ZeroClick terminates TLS at the pay URL to handle routing, identity, and payment. Without body encryption, the proxy receives the application body plaintext. Encrypted calls add a Compact JWE envelope inside TLS. The buyer creates this envelope before the request reaches ZeroClick. The seller opens it after the proxy forwards it. The response follows the reverse path. The seller encrypts the response body for a one-time buyer key. ZeroClick returns the ciphertext, and the buyer decrypts it.

​
The data path

1

The seller publishes a public key

The seller generates a P-256 key pair in its own infrastructure. It publishes only the public JWK through ZeroClick.ZeroClick rejects JWKs that contain private parameters. The seller private key stays in the seller’s key manager or application environment.
2

The buyer encrypts the request body

The buyer reads the active kid and public JWKS from the storefront. It also creates a fresh P-256 reply key pair.The buyer encrypts the body as Compact JWE. The protected header carries the seller kid, original content type, and public reply JWK.
3

ZeroClick processes ciphertext

The proxy can read the protected header without a private key. It validates the fixed cipher suite, seller kid, and public reply key.ZeroClick hashes the original ciphertext for payment binding and zc-signature. It forwards those ciphertext bytes without modification.
4

The seller verifies and decrypts

The seller verifies zc-signature against the ciphertext before decryption. It also checks the buyer’s allowance before it does application work.After an allow decision, the seller selects its private key by kid and decrypts the body inside its own infrastructure.
5

The seller encrypts the response body

The seller encrypts the application response for the public reply key. Only the buyer has the matching private key.ZeroClick relays the response ciphertext. The buyer uses its one-time private key to decrypt the body.

​
What ZeroClick can and cannot see

The proxy still needs transaction metadata to route the call and settle payment. Body encryption changes the body trust boundary, not the entire HTTP exchange. The proxy request record stores the method, path and query, status, identifiers, and a SHA-256 body digest. It has no request or response body field. The proxy cannot log or persist body plaintext that it never receives. It can log or persist visible metadata and ciphertext. Without an endpoint’s private key, retained ciphertext remains unreadable. This is a cryptographic limit, not a logging policy.

​
Wire contract

ZeroClick accepts one body-encryption profile: The fixed suite prevents algorithm negotiation. The protected header is authenticated, so a relay cannot replace the reply key without invalidating the request JWE. The payment challenge binds to a SHA-256 digest of the ciphertext. After a 402, the buyer must retry with the identical JWE bytes.
Do not encrypt the same plaintext again for the paid retry. JWE uses random values, so a new envelope has a different digest.
ZeroClick protocol responses remain plaintext. These include payment challenges and errors produced before the seller decrypts the request.

​
Scope and trust boundaries

  • Body encryption is opt-in for each request. A plaintext request remains plaintext at the proxy.
  • Response encryption is a separate opt-in. The buyer must include a public reply JWK, and the seller must use it.
  • The JWE protects bodies only. It does not hide routes, headers, status codes, timing, length, billing data, or usage quantities.
  • This design protects body confidentiality from the ZeroClick data plane. It does not protect a compromised buyer or seller endpoint.
  • Storefront key discovery trusts the public key that ZeroClick serves for the seller. Buyers can pin a seller key through a seller-controlled channel.
  • The response JWE provides confidentiality, but it is not a seller signature. If the buyer must prove response origin, add an application-level signature.

​
Configure a seller

1

Generate a P-256 encryption key pair

Generate the key pair in the seller’s infrastructure. Give the public JWK a unique kid. Keep the private JWK secret.
2

Publish the public JWKS

In the dashboard, open Stores → your seller → Store settings → Upstream security → Body encryption. Paste the public JWKS.You can also call PUT /v1/sellers/{sellerId}/body-encryption with an admin:write API key.
3

Add the seller-side helpers

Verify the encrypted request before decryption. Check the allowance before decryption. Attach zc-usage before you encrypt the response.

TypeScript

Use decryptRequest and encryptResponse.

Python

Use decrypt_request and encrypt_response.

Go

Use the separate jwe package.

Ruby

Require zeroclick/sellers/encryption.
4

Give buyers the generated guide

Each configured pay URL publishes /encryption.md and /.well-known/jwks.json. The guide contains a working buyer example for that seller.
During key rotation, publish the old and new public keys together. Keep both private keys available until all requests and payment retries drain.