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 · Connect your wallet and register your endpoint
Open the dashboard and connect the wallet that controls your payTo address. It signs a challenge, which proves the address is yours: nothing is typed, no account is created. Then you register your resource URL and declare your segment.
2 · Verification at the identity provider
The accountable operator is verified by an identity-verification provider inside the issuer’s boundary, on the provider’s own page: KYC for a person, and KYB for an organisation, its company and its beneficial owners. Where a deployment offers KYC only, the dashboard says so at this step, before anything starts. 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
The guarantee deposit is a vendor’s own money, set aside against buyers’ claims under the Terms, in an account of the vendor’s own with the payment-institution partner; it is never ZadQ’s revenue. Its step is not in the dashboard yet. Until it is, the dashboard asks you for no deposit and the positive claim is withheld: no verdict is presented as backed by your deposit.
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.