Merchant Introduction

​

Charge for an HTTP resource

An x402 resource server advertises payment requirements and uses a facilitator to verify and settle supported payments. Your application still owns resource delivery, pricing, access control and recovery. If you want to pay for a resource instead, start with the client guide. For a first end-to-end example, use the quickstart.

​

Choose your server

Use a complete framework guide for installation, environment variables and a runnable example. Use a manual flow when you need to control the payment lifecycle directly. Batch settlement has separate SDK, funding, authentication and channel-recovery requirements. Do not apply an exact-payment example to it unchanged.

​

Understand the payment flow

The server challenges an unpaid request, accepts a retry carrying a payment authorization, and verifies the selected terms. Settlement and resource delivery must follow the lifecycle required by your integration. See the x402 reference for wire formats and the facilitator introduction for PayAI’s role. HTTP compatibility alone is not payment compatibility: both ends must support the selected network, token and scheme. Check supported networks. Fee sponsorship depends on the payment flow, and end-to-end latency depends on application work, transport and settlement; neither zero network costs nor sub-second settlement is universal.

​

Configure PayAI and prepare production

1. Follow your framework guide’s PayAI facilitator configuration. Review the free allowance and production pricing; batch verification and settlement require authentication from the first request. Public discovery remains available without a key.
2. Keep facilitator credentials on the server. See facilitator authentication for package-based and direct HTTP setup.
3. Configure Bazaar discovery if you want to expose supported discovery metadata. Serving an HTTP endpoint alone does not list it automatically.
4. For variable charges, follow the dynamic pricing guide and validate that the payment authorization covers the accepted terms.
5. Plan for capacity limits, timeouts and uncertain outcomes using the capacity and recovery guidance. A request timeout does not establish that settlement failed.

​

Need help?