Seller SDKs

The seller SDKs implement the ZeroClick billing guard in your backend: they verify that a request really came from ZeroClick, check that the buyer can pay before you do the work, build the refusal responses ZeroClick expects, and report what was used. All four speak the same wire protocol and make the same decisions; they differ only in language idiom. All four are Apache-2.0 licensed.

​

What every SDK does

• Verify first. Every entry point verifies the zc-signature header before anything else. The signature is an HMAC-SHA256 over the raw request bytes. The SDK never checks an allowance for an unverified request.
• Decisions, not exceptions. A guard returns an allow decision with the verified buyer context, or a deny decision that carries the exact response to return: 401 for a bad signature, the 402 payment_required refusal for a business denial, or 503 under a fail-closed outage policy. Malformed configuration and API failures raise typed errors instead.
• Fail open by default. If the allowance check fails without a usable answer, the configurable outage policy decides: allow (default), deny, or throw. A recognized allowed: false is always a 402. The policy applies only after a signature verifies, so an unverified request is never served because the allowance API was down. The SDKs differ in how strictly they classify failures. The Go SDK treats any 4xx from the allowance API (a revoked key, an unknown service) as a hard error, never an outage. The TypeScript and Python SDKs route API errors through the policy. Each SDK’s errors page documents its exact classification.
• Settle on success only. Synchronous usage rides the zc-usage response header on 2xx responses; asynchronous usage goes through reportUsage with a seller-owned, derived idempotency key. No SDK retries automatically or invents idempotency keys.
• Split usage keys. Pass one API key with both usage scopes, or a read key for guards and checks plus a write key for reporting. The split is useful when a separate worker reports usage.
• Encrypt bodies end to end. Every official SDK can decrypt request JWE inside your backend and encrypt the response for the buyer. ZeroClick never receives either private key.

​

Differences that matter

Pick the SDK that matches your backend language. The core guard flow has the same capabilities in all four. If your backend is in another language entirely, the REST walkthrough implements the same contract with plain HTTP.

​

Community SDKs

These are built and maintained by the community, not by ZeroClick. We list them because they work and because they serve languages we do not yet ship for — but they are outside our release process, so treat version upgrades as you would any third-party dependency.

​

PHP

Requires PHP 8.3+. Ships PSR-15 middleware plus Laravel and Symfony bridges, and covers request verification, allowance checks, usage reporting, and encrypted request bodies. The PHP quickstart walks the integration. We ran our shared signing conformance vectors — the same 29 cases every official SDK is checked against, including malformed-header and tampered-body cases — against it, and all 29 agreed. That covers the security-critical core: signature verification. Two things to know before you choose it:

• No stateful account helpers. If you sell accounts and API keys rather than metering per call, you will need to implement those two routes yourself against the reference.
• It carries runtime dependencies (PSR HTTP interfaces, php-http/discovery, psr/clock), where the official SDKs deliberately carry none. They land in your composer.json alongside your own.

Building a seller SDK for another language? Tell us — we will list it here.

​

Get started