Onboarding
You said yes. Here is everything that happens next.
Seven steps, in the order the seller dashboard runs them. None of them touches your payment code, and none of them puts identity documents in our hands.
1 · Create your account and register your endpoint
Open the dashboard and create your account: the person who answers for it signs in with a passkey. Then you bind the wallet that controls your payTo address; it signs a challenge, which proves the address is yours, and it signs again for every change to it. You register your resource URL and declare your segment.
2 · Verification at the identity provider
The person who answers for your account verifies their identity (KYC) on the identity provider’s page, inside the issuer’s boundary. For an organisation, the company’s details are that person’s declaration; business verification (KYB) is not available on this deployment yet. Raw documents never reach ZadQ: the dashboard learns the outcome and nothing else.
3 · The terms, acknowledged with your wallet
Once you are admitted, the dashboard shows the operator terms in full, with their version and fingerprint. You acknowledge them by signing the text with the same wallet, which shows you exactly what it signs. The attestation is issued only after you do.
4 · Your tier and billing
You choose your tier and set up billing on the billing provider’s hosted checkout; your legal name and payment details stay there. The dashboard shows billing as active once the provider confirms it.
5 · The attestation
You issue the attestation from the dashboard. The issuer signs it on the MintID identity network, binding your payTo address and resource URL to a verified operator at your assurance grade. Your middleware attaches it to every 402 response; payment logic unchanged.
6 · The credential offer, held in your own middleware
The dashboard hands you a one-shot credential offer, created from your approved verification. Your middleware’s holder redeems it, and the credential lives in your own infrastructure, next to the key you already protect. ZadQ never holds a key, a credential or a proof. Where a deployment does not run the credential rail yet, the dashboard says so, and your attestation carries the verdict on its own.
7 · Your first verdict, then re-verification on cadence
A registered verifier checks the attestation and publishes its signed verdict: verified, not verified or unknown. Buyers read it for free. It is re-checked on the published cadence, and the dashboard shows when the last check ran. Your identity verification is reusable for a window, and the dashboard shows when it ends: re-verify before then, there is no grace and no extension. Done in time, the attestation keeps its reference; missed, it is suspended and the status drops to not verified by itself, until you re-verify.
A note on the guarantee deposit
You place no deposit. The guarantee deposit behind your attestation is the issuer’s, on the network; your verdict reads it on every re-check.
What you can do from day one
- Tell your agents: your 402 already carries the invitation to the trust perimeter.
- Publish the identity policy in your 402 response — welcome or preferred — as the developer docs show. Requiring attested agents is a choice you make on your own verifier.
- Read the verdict yourself, the same way any buyer does: for free.
Selling over x402? Let's find out if we fit.
We are onboarding our first partners: API sellers, publishers, marketplaces and regulated platforms.