---
title: "x402 for API sellers: what it handles and what you still need to build | ZeroClick"
url: https://zeroclick.ai/resources/x402-for-api-sellers
fetched_at: 2026-10-02T07:29:38.158Z
---

# ZeroClick API catalog and pricing

## API reference, endpoint lookup and prices

**[ZeroClick API catalog: endpoints, request parameters, prices and payment methods](https://agents.zeroclick.ai/zcj/5z8a5nggih93/zeroclick/agent/guide).** Tell the seller advisor what you want to accomplish. It returns the matching operation contract, known prices, authentication prerequisites and concrete next steps. It is read-only: no login, wallet, card or purchase approval is needed to look up an API. It never executes a sale.

Available API services: Agent readiness report, Demo booking.

**Suggested next request:** GET [task guide](https://agents.zeroclick.ai/zcj/5z8a5nggih93/zeroclick/agent/guide?goal=URL_ENCODED_TASK). Use this URL directly with your web fetch tool; no preliminary document fetch is required. Include known inputs and desired output in the goal. Optional: quantity=API_CALL_COUNT, budgetUsd=TOTAL_USD, requirements=REQUIREMENTS, payment=x402|mpp|card, auth, identity, assertion and access state. Omit unknowns. Do not equate output items with API calls or guess a call count.

For private task details or known request arguments, POST https://agents.zeroclick.ai/zcj/5z8a5nggih93/zeroclick/agent/guide with Content-Type: application/json. Example: {"intent":"quote","goal":"YOUR_TASK","purchase":{"budgetUsd":"5.00"}}. Replace the task and budget with known facts; budgetUsd is a string. Include known buyerState, paymentCapabilities and arguments. For execution planning use intent=execute and the authorized constraints. Exact fields: [request schema](https://agents.zeroclick.ai/zcj/5z8a5nggih93/zeroclick/agent/schema). GET and POST are alternatives, not mandatory stages.

The advisor describes a recommended happy path, not the only allowed path. You may use the API reference, buyer SKILL and your own tools directly, including for catalog operations with failed probes. Missing guidance or an unverified probe is not a policy refusal. Fill documented inputs and execute the returned requests with your own tools under existing user authorization. Check usage cost AND minimum cash required against the budget. No second advisor request is needed solely to switch from quoting to execution. For needs_input, supply only missing facts. Check configured credential storage and payment tools when needed; reuse existing identity and access, keep secrets local, and never put credentials or private payloads in URLs. Unknown does not mean absent.

Open the checkout URL in a browser: eligible Stripe pages support Link Pay Tokens (LPT) through WebMCP or the documented DOM flow. Follow this storefront's /payment/card.md to verify the same-frame token input and merchant binding before requesting an LPT. Token submission requires payment authorization. If unavailable, privately send the checkout URL to your human to pay.

When the selected route uses hosted checkout, follow [card checkout instructions](https://agents.zeroclick.ai/zcj/5z8a5nggih93/payment/card.md) before requesting a token. LPT goes only to Stripe, never to the advisor or ZeroClick API. Poll the returned statusUrl before using credit or retrying delivery.

Verify delivery; a payment or HTTP 202 is not completion. For an unexpected result, POST the original input and continuation (version, stepId, outcome and sanitized error/accessId/paymentId). Reconcile uncertain payments or writes before retrying. Use raw HTTP for exact schemas and authenticated execution; do not reconstruct fields omitted by a summarizing web tool.

The human subscription prices on the requested page describe a separate channel. Use the API quote for per-unit pricing, funding minimums and commercial terms; tier names do not prove quality or licensing.

For an alternative documented path, use the [buyer SKILL](https://agents.zeroclick.ai/zcj/5z8a5nggih93/SKILL.md) or [full direct workflow reference](https://agents.zeroclick.ai/zcj/5z8a5nggih93/llms-full.txt). Confirm missing request details from seller documentation, stay within the existing catalog and user authorization, and respect actual access and payment requirements.
Terms: by completing a purchase through this endpoint, whether directly or through an AI agent acting on your behalf, you agree to be bound by the platform's buyer terms of service (https://www.zeroclick.ai/legal/buyer-terms-of-service). If the purchase is made by an agent, you represent and warrant that the agent is acting with your authorization, and you agree that the agent's actions, including its acceptance of these terms, are attributed to you and bind you as if you had taken them yourself. Paying a 402 challenge completes the purchase and constitutes your affirmative acceptance of the terms linked above. The link travels in every payment challenge and receipt as `terms`.

# x402 for API sellers: what it handles and what you still need to build

**ZeroClick Team** · September 15, 2026 · 5 min read · [Agent payments](https://zeroclick.ai/resources#payments)

x402 lets a service present payment requirements in an HTTP response so a compatible client can pay and retry the request. It is a payment standard, not a complete customer-account system or a guarantee that the purchased result is useful.

For an API seller, the decision is practical: do you want to operate that payment path yourself, or integrate with a platform that operates it alongside the rest of your commercial service?

**Contents**
- [Follow one purchase](#follow-one-purchase)
- [Know which part you are implementing](#know-which-part-you-are-implementing)
- [Choose the scheme for the workload](#choose-the-scheme-for-the-workload)
- [Implement directly or use ZeroClick](#implement-directly-or-use-zeroclick)
- [Frequently asked questions](#frequently-asked-questions)
- [Start with one offer](#start-with-one-offer)

## Follow one purchase

Consider an illustrative company-enrichment API. A buyer supplies a company domain and wants a structured company record.

1. The client requests the resource.
2. The server responds with `402 Payment Required` and machine-readable payment requirements.
3. The client checks the offer against its supported payment methods and spending authority, then submits a payment payload.
4. The server validates the payment and follows the selected scheme's fulfillment and settlement flow.
5. The buyer receives the API result or a failure it can interpret.

The [x402 introduction](https://docs.x402.org/introduction) describes this request-and-payment exchange.

The commercial promise still needs definition. Does a valid search with no matching company count as a billable result? Which fields are required? Can the buyer retry after a timeout? Payment machinery cannot make those product decisions for you.

## Know which part you are implementing

| Part | Responsibility |
|---|---|
| Buyer client | Read the offer, select a compatible payment path, and act within the buyer's authority. |
| Resource server | State the terms, verify access, execute the service, and return an interpretable result. |
| Facilitator, when used | Help verify and settle payment payloads for supported networks and schemes. |
| Seller product | Define the output, price, usage limits, failure behavior, support, and any durable account. |

A facilitator can reduce payment-infrastructure work without becoming your customer-management or fulfillment system. The [facilitator documentation](https://docs.x402.org/core-concepts/facilitator) distinguishes managed production, self-operated, and development paths. Do not assume a public test facilitator is an appropriate production dependency.

## Choose the scheme for the workload

A fixed-price lookup and variable-cost generation are different offers. x402's [scheme reference](https://docs.x402.org/schemes/overview) names three patterns:

- `exact` — a fixed amount
- `upto` — actual usage within an authorized maximum
- `batch-settlement` — repeated payments accumulated against a reusable channel

For a lookup with a known price, the buyer can evaluate the amount before the request. For variable work, the important question is how the maximum is authorized and actual usage charged. For repeated small calls, settlement overhead and batching may matter.

Use the [API pricing guide](https://zeroclick.ai/resources/price-an-api-for-agents) to define the unit and maximum, then check the scheme, network, wallet, and SDK combination. "Supports x402" alone does not establish that a client can pay for your specific offer.

## Implement directly or use ZeroClick

**Direct implementation** fits a team that wants to own protocol integration and its surrounding operations. Start with the [official seller quickstart](https://docs.x402.org/getting-started/quickstart-for-sellers). Plan for monitoring, retries, supported wallets, price changes, and service failures — not just a successful demonstration payment.

**ZeroClick's managed integration** separates buyer payment handling from the seller API contract. Your backend verifies forwarded requests, checks allowances, fulfills the request, and reports usage. The [integration contract](https://docs.zeroclick.ai/integrate/overview) owns the exact behavior; it should not be confused with the x402 specification.

Neither path removes your responsibility for delivering the promised result.

## Frequently asked questions

### Does accepting x402 create a customer account?

Do not assume it does. A paid request and a durable account are separate outcomes. If the purchase should provision an account, subscription, or API key on your service, define that flow explicitly. ZeroClick documents a separate [account-provisioning integration](https://docs.zeroclick.ai/integrate/stateful-sellers).

### Does payment prove a successful result?

No. Record and verify fulfillment separately. A syntactically valid company record can still be the wrong company. A successful payment can precede a service failure. Your tests need to cover the product result as well as the payment exchange.

### Do I have to choose between x402 and MPP?

Not if you sell through ZeroClick: an Agent Storefront offers both protocols in the same 402 challenge, the buyer picks by paying, and your API never sees either ([FAQ](https://zeroclick.ai/faq#do-i-have-to-choose-a-payment-protocol)). If you implement x402 yourself, MPP documents compatibility paths for certain x402 flows, but not every extension or payment scheme is interchangeable. Read [MPP for API sellers](https://zeroclick.ai/resources/mpp-for-api-sellers) and check the [current compatibility guide](https://mpp.dev/guides/use-mpp-with-x402) for the exact scope.

## Start with one offer

Before adding payment, write down one input, one useful output, a price or spending bound, and the failure policy. The [service-packaging guide](https://zeroclick.ai/resources/package-agent-services) helps make those decisions. Then choose either the official x402 implementation path or the [ZeroClick seller quickstart](https://docs.zeroclick.ai/quickstart).

A successful first integration should leave the buyer with a useful result, not merely a receipt.

## Keep reading

1. [How to price an API for AI agents](https://zeroclick.ai/resources/price-an-api-for-agents)
2. [MPP for API sellers: payment methods, sessions, and implementation choices](https://zeroclick.ai/resources/mpp-for-api-sellers)
3. [How to package your product into a service an agent can buy](https://zeroclick.ai/resources/package-agent-services)
4. [ZeroClick docs: integrate / overview](https://docs.zeroclick.ai/integrate/overview)