Which x402 Payment Protocol Entry Point Fits Your Application?

You can access the x402 payment protocol through the official x402 documentation, specification, open-source repository, and language SDKs. There is no required x402 account, single gateway, or mandatory infrastructure provider. A seller starts with server middleware for an HTTP route or MCP tool. A buyer starts with an x402-aware HTTP or MCP client and a wallet signer. A facilitator supplies payment verification and settlement services, while an edge or agent platform may package those functions for its own runtime. Broader agent-commerce stacks can add wallet policy, merchant operations, identity, and onchain execution around the protocol.

The important distinction is that access to the protocol is open, while access to a production payment service may require provider credentials, supported networks, and operational setup. Installing an SDK gives an application the protocol logic. It does not automatically give the application a funded wallet, a production facilitator, order records, refund handling, or permission to make unrestricted payments.

Which Official x402 Entry Point Matches Your Role?

The authoritative starting points are maintained by the x402 Foundation: the protocol documentation explains the request flow, the specification defines the message format, and the open-source repository contains reference SDKs and examples. The code is available under the Apache 2.0 license.

For a new integration, use the current v2 materials. Version 2 uses modular packages, CAIP-2 network identifiers, and the PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE headers. Older tutorials may use v1 package names or the X-PAYMENT header. Mixing those examples with v2 middleware is a common reason a paid retry continues to receive HTTP 402.

The official repository currently exposes several access paths:

This table is an access map, not a compatibility guarantee. Package names, supported networks, payment schemes, and provider requirements can change. Pin versions and verify the exact combination before deployment.

The next decision is not which provider has the longest feature list. It is which side of the exchange your code owns.

A single application can perform more than one role. An agent marketplace, for example, may pay upstream data providers while charging downstream agents. It should configure the buyer and seller paths separately. Using the same wallet, credentials, retry logic, and database state for both directions makes authorization and reconciliation harder to audit.

The Seller Entry Point Is the Billable Boundary

A seller is the resource server that owns the paid API, file, model call, content endpoint, or tool. Its server integration must do more than return status code 402. It must publish a machine-readable requirement containing the price and accepted payment conditions, accept the client's payment payload on the retry, verify that payload, settle it when required, and bind the result to the requested resource.

For an existing TypeScript API, the natural starting point is the framework package that matches the server. An Express application can use the Express integration; a Hono service can use the Hono integration. Python and Go applications can start with their respective official SDKs. They do not need a JavaScript proxy solely to participate in x402.

The payment gate should sit at the billable boundary. Protect the route that creates the paid value, not an unrelated health check or every route under the same host. For an asynchronous job, create a durable order before starting work and return a job identifier. For a metered result, define whether payment covers an invocation, a token allowance, a completed result, or a maximum authorized amount.

Server middleware does not replace merchant state. The application still needs an idempotency key, a record connecting the requirement to the order, delivery status, settlement evidence, and a remedy when payment succeeds but execution fails. The protocol can establish that a payment condition was satisfied; only the service can establish that the customer received what was purchased.

The Buyer Entry Point Ends at Authorization

A buyer application needs an HTTP or MCP client that recognizes a payment requirement, constructs the correct payload, and retries the original request. In TypeScript, the official access path includes wrappers for fetch and Axios. The application also registers the network-specific payment implementation and provides a signer backed by a wallet.

That signer should not be treated as a general-purpose tool available to a language model. The client can parse the requirement, but a deterministic authorization layer should decide whether to pay. It should constrain approved hosts, routes, recipients, networks, assets, and schemes; enforce per-request and task budgets; and reject expired or changed quotes. Replay checks, duplicate-payment detection, human approval for new sellers or unusually large amounts, and a stop condition after repeated service failures complete the minimum control boundary.

The correct result of an out-of-policy request is a rejection or escalation, not an automatic increase in the agent's authority. x402 can automate payment handling within a defined policy. It does not mean an AI agent can spend without limits.

Client integration also does not prove seller identity. Before signing, an agent may need to bind the requested domain, recipient wallet, service identity, price, and delivery terms. Payment authorization and service trust are related decisions, but they are not the same decision.

What Does a Facilitator Add to an SDK?

The x402 protocol allows a resource server to verify and settle directly. It can also delegate those operations to a facilitator. A facilitator commonly exposes verification and settlement interfaces so every merchant does not need to implement chain-specific validation and transaction submission.

For early testing, the public facilitator at x402.org provides an account-free testnet path for supported combinations. It is not a mainnet production endpoint. A production application must select a compatible hosted facilitator or operate its own. Coinbase Developer Platform is one hosted option, but using Coinbase is not a requirement of the open protocol.

Evaluate a facilitator against the complete payment tuple: protocol version, payment scheme, network, asset, signer format, facilitator authentication, verification semantics, and settlement semantics. Every field must align to produce a deployable payment path.

Support must match at two independent layers. The SDK must be able to construct the selected payload, and the facilitator must serve the same network, asset, and scheme. A successful package installation says nothing about that production match, so check both capability sets explicitly.

The facilitator is also not the merchant backend. Verification does not create a product catalog, deliver an API result, issue a service credit, send a webhook, or reconcile revenue. Those responsibilities remain with the application or a separate merchant platform.

Workers and MCP Tools Change the Integration Surface

Some developers do not need to integrate x402 at a conventional origin server. Cloudflare currently documents x402 paths for HTTP content, MCP tools, and agent clients in its Workers and Agents environment. Its MCP tooling includes paidTool for assigning a price to selected tool calls and withX402Client for an agent-side client that can react to payment requirements.

This runtime-specific route is useful when the billable resource already lives in a Worker or MCP server. It avoids forcing a separate web framework into the architecture. The same production boundaries still apply: the client needs a wallet and approval rule, the seller needs a facilitator or direct verification path, and the application needs to correlate payment with exactly one tool execution.

MCP discovery introduces another distinction. A tool description can tell an agent what the service does, while the x402 requirement tells it what payment is required. Neither alone defines a complete commercial contract. A paid tool should make the billable unit, output conditions, timeout behavior, and retry policy machine-readable enough for the agent to decide whether one call is worth purchasing.

An Agent-Commerce Stack Adds Responsibilities Beyond x402

Reference SDKs are sufficient when a team already has a wallet layer, merchant backend, and delivery system. A broader stack becomes relevant when those surrounding responsibilities are also missing.

GOAT Network AgentKit is one such access path for agent-facing applications. It plugs into an existing agent or application; it is not where the x402 protocol itself is hosted. Current GOAT documentation separates a payer-side x402 plugin with five payment actions from an x402 merchant plugin with 30 operations covering areas such as merchant authentication, orders, balances, API credentials, payment status, webhooks, and audit records. Its execution runtime also documents policy evaluation, input validation, retry, idempotency, timeouts, and metrics.

That makes GOAT AgentKit relevant when the application needs x402 payment actions together with wallet operations, bounded execution, merchant administration, framework adapters, optional ERC-8004 identity functions, or programmable onchain actions. It is excessive for a seller that only needs to place a fixed price on one mature API route.

The boundary matters: GOAT provides one integrated implementation environment around x402, while the x402 Foundation remains the authoritative protocol and reference-SDK source. x402 is not exclusive to GOAT Network, and developers can combine reference components, hosted services, edge runtimes, or self-hosted infrastructure according to their requirements.

Production Compatibility Checklist

Before connecting real funds, write down the deployment as one matrix rather than testing each component in isolation.

Run an unpaid request first and inspect the requirement. Then test an approved payment, a rejected budget, an expired quote, a duplicate retry, an unsupported network, a settlement timeout, and a paid request whose service execution fails. A successful happy-path demo proves only that the components can communicate. Failure testing proves whether the application can charge or pay without losing control of money or delivery state.

The shortest answer to “where can I access x402?” is the official x402 documentation and repository. The useful answer is role-specific: install server middleware to charge, a client and signer to pay, a compatible facilitator to delegate verification and settlement, and only the surrounding infrastructure your application does not already own.

Frequently Asked Questions

Where can I access the x402 payment protocol?

Start with the official x402 Foundation documentation, specification, and open-source repository. Use the reference SDK for your language and application role. The protocol does not require a single x402 account or one mandatory provider.

Which x402 package should a seller use?

A seller should use the server integration that matches its runtime, such as the official Express, Hono, Fastify, or Next.js package for TypeScript, or the official Python or Go SDK. The seller also needs a verification and settlement path plus its own delivery and order logic.

Which x402 package should a buyer use?

A TypeScript buyer can begin with an x402-aware fetch or Axios wrapper and the appropriate network package. Python and Go have official SDK paths as well. Every buyer also needs a wallet signer and explicit spending controls.

Do I need Coinbase to use x402?

No. Coinbase Developer Platform operates a hosted facilitator, but x402 is an open protocol. A resource server can use another compatible facilitator or verify and settle payments itself.

Can I test x402 without creating a provider account?

Yes, for supported testnet combinations, the public x402.org facilitator provides an account-free testing path. It is testnet-only and should not be treated as a production mainnet service.

Is an x402 facilitator mandatory?

No. It is optional, although it can reduce the chain-specific work required to verify and settle payments. Self-verification gives a team more control but also makes that team responsible for payment validation, transaction submission, monitoring, and failure handling.

Can I use x402 for MCP tools or Cloudflare Workers?

Yes. Cloudflare documents runtime-specific integrations for paid HTTP content, paid MCP tool calls, and x402-aware agent clients. Confirm the runtime package, facilitator, network, and asset combination before production use.

When does GOAT Network AgentKit make sense for x402?

It is relevant when an application needs x402 payer actions plus adjacent capabilities such as wallet actions, runtime policy controls, merchant orders, balances, API credentials, webhooks, optional agent identity, or onchain execution. A simple paid endpoint may need only the reference SDK and a facilitator.

Does installing an x402 SDK let an AI agent pay automatically?

It lets the application handle the protocol programmatically, but payment should remain subject to deterministic authorization. Wallet permissions, approved recipients, budgets, network and asset rules, quote validation, and escalation conditions must be defined separately.