--- title: "MPP for API sellers: payment methods, sessions, and implementation choices | ZeroClick" url: https://zeroclick.ai/resources/mpp-for-api-sellers fetched_at: 2026-10-01T16:16:31.897Z --- # 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/bgj641aok9kd/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/bgj641aok9kd/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/bgj641aok9kd/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/bgj641aok9kd/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/bgj641aok9kd/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/bgj641aok9kd/SKILL.md) or [full direct workflow reference](https://agents.zeroclick.ai/zcj/bgj641aok9kd/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`. # MPP for API Sellers: Payment Methods, Sessions, and Implementation Choices [ZeroClick Team](https://x.com/zeroclick) · September 15, 2026 · 5 min read · [Agent payments](https://zeroclick.ai/resources#payments) **Contents** - [Start with the work being purchased](#start-with-the-work-being-purchased) - [Understand the challenge, credential, and receipt](#understand-the-challenge-credential-and-receipt) - [Payment method and payment intent are different choices](#payment-method-and-payment-intent-are-different-choices) - [Decide how much of the integration to own](#decide-how-much-of-the-integration-to-own) - [Frequently asked questions](#frequently-asked-questions) - [Define the offer before opening the endpoint](#define-the-offer-before-opening-the-endpoint) The Machine Payments Protocol (MPP) provides a common way for clients and services to negotiate payment. A service presents a payment challenge. A compatible client responds with a credential. The service verifies it and handles the requested resource. For a seller, MPP is an interface for accepting payment. It is not a reason to rebuild the product around a particular blockchain. The MPP [overview](https://mpp.dev/overview) separates the protocol from the payment methods used beneath it. ## Start with the Work Being Purchased Consider a report-generation service. A customer supplies a document and wants an extracted table. Before choosing payment infrastructure, decide what constitutes the purchase. Is it one completed extraction at a fixed price? A metered processing session? Recurring access with a defined allowance? Those offers impose different limits, failure policies, and expectations. MPP can carry payment requirements. It does not decide whether an extraction is accurate or whether your refund policy is appropriate. ## Understand the Challenge, Credential, and Receipt The [protocol overview](https://mpp.dev/protocol/) describes the basic exchange: 1. A client requests a paid resource. 2. The service returns a payment challenge. 3. The client chooses a supported method and supplies the matching credential. 4. The service verifies the credential and handles the resource request, with payment receipt information where applicable. The challenge tells the client what it must satisfy. The credential supplies the method-specific evidence. The receipt records payment information. It does not establish that the customer's broader task was completed correctly. Keep payment failure, policy denial, and product failure distinguishable. A client must know whether it should change payment, correct its request, obtain permission, or stop. ## Payment Method and Payment Intent Are Different Choices A **method** describes how payment is made. An **intent** describes the payment pattern. The [payment-method directory](https://mpp.dev/payment-methods/) and [intent reference](https://mpp.dev/intents/) document those separately. For a report service: | Offer | MPP intent to evaluate | Decision to make | |---|---|---| | One fixed-price extraction | `charge` | What is included in the one-time payment? | | Repeated metered work | `session` | How are spending, usage, and session closure handled? | | Recurring access | `subscription` | What renews and when does access end? | The current [intent reference](https://mpp.dev/intents/) lists Tempo support for all three and Stripe support for `charge`. A card-compatible one-time purchase does not establish support for a metered session. Verify the selected method and intent on both the server and the buyer client. ## Decide How Much of the Integration to Own A direct implementation can use MPP's [server quickstart](https://mpp.dev/quickstart/server). Use this path when you want to own the payment endpoint and its operating responsibilities. With ZeroClick, the seller integrates its API with ZeroClick's fulfillment and billing contract. ZeroClick's [payment-protocol reference](https://docs.zeroclick.ai/concepts/payment-protocols) describes the specific MPP support in that product. Support elsewhere in the MPP ecosystem is not automatically available in a ZeroClick storefront. This distinction matters when evaluating cards, networks, sessions, and account provisioning. Ask "does this exact implementation support the buyer and workload I have?" rather than relying on the protocol name. ## Frequently Asked Questions ### Is MPP only for agents? No. The protocol can be used by compatible applications and other clients as well as agents. An agent still needs appropriate tools and authority. Exposing an MPP endpoint does not grant it permission to spend. ### Is MPP the same as Tempo? No. Tempo is one payment-method ecosystem within the broader protocol. Treat the protocol, its SDKs, and a particular payment network as separate dependencies. ### Can MPP coexist with x402? Yes. A ZeroClick Agent Storefront offers both protocols in the same 402 challenge, so sellers on ZeroClick do not choose between them. For your own implementation, MPP documents compatibility paths. The [MPP + x402 guide](https://mpp.dev/guides/use-mpp-with-x402) describes wrapping existing integrations and serving compatible clients. The documented bridge uses x402 v2 EIP-3009 `exact` and MPP EVM `charge`. x402 requirements with extensions remain x402-only in the wrapper. Check that scope against your route before selecting it. See [x402 for API sellers](https://zeroclick.ai/resources/x402-for-api-sellers) for the corresponding seller decisions. ### Will a payment preserve the customer's account? Only if the surrounding product implements that relationship. Buying one resource, identifying a caller, and maintaining a customer account are different concerns. When a ZeroClick purchase needs to leave an account or API key on your backend, use the [stateful-seller integration](https://docs.zeroclick.ai/integrate/stateful-sellers). ## Define the Offer Before Opening the Endpoint Write the result, price or spending bound, permitted usage, and failure behavior first. Use the [service-packaging guide](https://zeroclick.ai/resources/package-agent-services) to define the result and the [API pricing guide](https://zeroclick.ai/resources/price-an-api-for-agents) to choose its billable unit and spending bound. Then choose the direct MPP or managed ZeroClick path and verify it with the intended client. Include rejected payment, denied access, and failed fulfillment in the test. Do not test only the successful response. ## Keep Reading 1. [x402 for API sellers: what it handles and what you still need to build](https://zeroclick.ai/resources/x402-for-api-sellers) 2. [How to package your product into a service an agent can buy](https://zeroclick.ai/resources/package-agent-services) 3. [How to price an API for AI agents](https://zeroclick.ai/resources/price-an-api-for-agents) 4. [ZeroClick docs: concepts / payment protocols](https://docs.zeroclick.ai/concepts/payment-protocols) --- **More in Agent payments:** [All resources](https://zeroclick.ai/resources#payments) - [Can AI agents pay with a credit card?](https://zeroclick.ai/resources/can-ai-agents-pay-with-a-credit-card) - [x402 for API sellers: what it handles and what you still need to build](https://zeroclick.ai/resources/x402-for-api-sellers)