Which x402 Products Should Merchants Use for APIs, Services, and Fixed-Price Offers?

Merchants can use five practical product patterns to sell to AI agents: fixed-price product checkout, backend-created hosted checkout sessions, custom order APIs, buyer-entered payment pages, and paid API routes. In GOAT Flow, these patterns appear as QuickPay Products, Checkout Sessions, custom checkout integration, QuickPay custom amount, and Paid API Routes.

They are not interchangeable. A fixed-price report needs a merchant-authoritative product record. A dynamically scoped service needs a backend-authoritative session or order. An API called directly by an agent needs a machine-readable payment challenge and verifiable access result. A tip page can let the buyer choose the amount, but that design is unsafe for automatically delivering a fixed-price product.

The durable selection rule is simple: choose the payment product according to where the authoritative price lives and how the purchased resource is delivered. Content type alone—API, service, or product—is not enough.

x402 Is the Payment Protocol, Not the Merchant Product Catalog

x402 defines an HTTP-native way for a server to state payment requirements and for a client to present payment information. That protocol can support machine payments without forcing every seller to build a conventional account, subscription, or card checkout flow.

However, the protocol does not decide how a merchant creates a product, computes a service quote, manages an order, exposes a checkout page, fulfills a download, or reconciles revenue. Those are product and application responsibilities.

This distinction matters because “an x402 product” can mean two different things:

1. a resource being sold through an x402-compatible payment requirement; or

2. a merchant-facing product that packages pricing, checkout, verification, and operations around that resource.

This article uses the second meaning. GOAT Flow is a useful concrete portfolio because it separates Checkout, QuickPay, and API Payments rather than presenting one universal interface for every sale.

Choose by Authority, Not by the Product Label

Before selecting a product, answer five questions about the offer:

1. Who sets the final price? The merchant catalog, a backend calculation, or the buyer?

2. Where does the purchase begin? A hosted page, a merchant application, or an HTTP request from an agent?

3. Is a merchant backend available? Some paths are designed for a simple link; others require secrets, signing, and order creation.

4. How does the buyer discover the offer? Through a product link, an application UI, or machine-readable endpoint metadata?

5. What evidence authorizes fulfillment? A trusted order state, an authenticated completion event, or a signed payment receipt?

Those questions produce a more reliable product map than the broad labels “API,” “digital service,” and “digital product.”

The matrix also reveals a common mistake: a hosted interface does not necessarily mean weak merchant control, and an onchain transaction does not necessarily mean the application knows what to deliver. Price authority and fulfillment authority must both remain explicit.

QuickPay Products Fit Fixed Catalog Offers

A QuickPay Product is the simplest match when the merchant can define the offer and price before the buyer arrives. The merchant creates a product record with a stable product key, name, description, image, price, availability state, and ordering information. A website, message, agent directory, or campaign can then open the hosted checkout for that product.

This pattern works well for:

• a downloadable research report sold for one fixed amount;

• a fixed bundle of data credits;

• a standardized review or verification service;

• a one-time access pass;

• a digital asset whose entitlement is known before payment.

The benefit is not merely that checkout is hosted. The important property is that the merchant's product record is the price authority. The buyer is choosing whether to purchase a known offer, not proposing how much the offer should cost.

For a simple web page, the checkout can be opened without embedding the merchant's API secret in browser code. That lowers the implementation burden for a fixed catalog. It does not remove the merchant's fulfillment responsibilities. The delivery system should still associate the verified order with the correct product key and recipient, then record whether the report, entitlement, or service was delivered.

QuickPay Product becomes a poor fit when the price depends on live inventory, a changing cart, negotiated scope, measured usage, or a customer-specific quote. Trying to encode every variation as a separate static product creates catalog drift and weakens reconciliation. That is the point where a checkout session or custom order becomes more appropriate.

Hosted Checkout Sessions Fit Dynamic Orders

A hosted Checkout Session is designed for a price that the merchant backend computes at purchase time. The backend can assemble cart items, apply current pricing rules, bind the checkout to merchant-controlled context, and create a signed or authenticated session. The buyer receives an opaque session identifier and completes payment in a hosted interface.

This is suitable for digital services such as:

• a data export priced by selected market, time range, and resolution;

• a report containing several paid modules;

• a service quote based on requested turnaround time;

• a cart containing multiple fixed products;

• a pre-scoped AI task whose price is known after intake but before execution.

The session boundary prevents the browser or agent from becoming the authority for the price. If the visible page says a service costs $20 while the merchant backend created a $2 session, the backend record—not the page text—will drive payment. Merchants therefore need to validate catalog version, quote expiry, currency, recipient, and order context before creating the session.

Hosted sessions trade some presentation control for a smaller payment surface. The merchant still owns quote creation and fulfillment, but the hosted product owns more of the payment interaction. This can be preferable when the merchant needs dynamic pricing without maintaining wallet selection, network prompts, receipt presentation, and payment-status polling in a custom interface.

An expired or stale session should not silently inherit new commercial terms. If price, scope, or delivery timing changes, create a new quote and session. This keeps the payment evidence aligned with the service the merchant actually promised.

Custom Order APIs Fit Merchant-Owned Experiences

Some merchants need checkout inside their own application. They may have a detailed configuration flow, account-based permissions, inventory reservations, compliance checks, or an existing order system. In that case, a custom order API and buyer-side integration provide more control than redirecting every buyer to a generic product page.

The merchant backend becomes responsible for:

• authenticating the buyer or agent when identity matters;

• creating the authoritative order;

• computing and freezing the payable amount;

• keeping merchant credentials away from the browser;

• connecting the payment state to inventory or service capacity;

• deciding when to execute and deliver;

• processing retries, expirations, refunds, and reconciliation.

The advantage is composability. A merchant can make payment one step in a larger product workflow instead of the whole workflow. For example, an enterprise data service might require an agent identity, validate usage rights, create an order for a specific dataset license, receive payment, and then issue time-bound download credentials.

The cost is operational responsibility. A custom UI is not merely a different visual skin. It creates more states that the merchant must make idempotent and observable. If the user refreshes after payment, the application must not create a second entitlement. If a webhook is delayed, the application must reconcile the order rather than assume it failed. If service execution fails after payment, the order needs a recoverable state and an explicit refund or retry policy.

Choose this path when owned business logic creates real value. Do not choose it only because a hosted page looks less branded.

Custom Amount Is a Contribution Surface, Not a Product Price

QuickPay custom amount serves a different commercial purpose. It lets a payer enter an amount, making it useful for tips, donations, voluntary contributions, or loosely scoped payments where the buyer legitimately controls value.

It is not a safe substitute for a fixed-price product page.

Suppose a merchant sells a dataset for $25 but links to a custom-amount page. An agent could submit $0.25, receive a technically successful payment result, and trigger poorly designed fulfillment code. The payment succeeded, but the commercial condition did not.

If a custom-amount payment is connected to any benefit, the merchant must verify the received amount and all associated conditions before delivery. In many cases, it is clearer to create a fixed QuickPay Product or a backend-priced Checkout Session instead.

This boundary is especially important for machine buyers. Human users may infer from page copy that a number is only a suggestion. An agent needs machine-enforceable fields. If an amount is mandatory, encode it as an authoritative requirement rather than as prose around a free-form payment box.

Paid API Routes Fit Machine-Consumed Resources

Paid API Routes are the closest match for services that an AI agent calls directly. Instead of navigating a human checkout page, the agent requests an endpoint. The service communicates the payment requirement, verifies the payment path, and returns the protected resource when the requirement is satisfied.

This pattern fits:

• a fixed-price market-data snapshot;

• a search or enrichment request with a known per-call price;

• a deterministic verification endpoint;

• a downloadable machine-readable artifact;

• a narrowly bounded AI tool whose price is known before execution.

GOAT's current merchant documentation describes Paid API Routes under its current MPP profile, with machine-readable discovery surfaces and signed Payment-Receipt evidence. That qualification matters: MPP is independent, and GOAT's current profile should not be described as the universal x402 wire format.

For the merchant, the route needs more than a price. It needs an enabled merchant configuration, a receiving address for the supported network and token pair, a protected upstream or handler, and a delivery policy. Machine-readable metadata can help agents discover terms, but live payment requirements remain the authority. Static documentation must not override a changed route price, recipient, or supported asset.

Paid routes also need idempotent delivery. If an agent pays, retries after a timeout, and sends the same logical request again, the service should return the existing result or safely resume processing rather than charge and execute twice. A payment receipt proves a payment-related event; the application must still bind it to the intended route, request, result, and permitted reuse.

For variable-cost model inference, a single fixed route price may be insufficient. A merchant can package a bounded tier—such as “summarize up to 10,000 tokens”—or use a different metering architecture. The merchant should not promise arbitrary compute under one low fixed price simply because the route can return a payment challenge.

One Merchant Portfolio May Need Three Products

Consider a hypothetical research merchant with three offers.

Offer A: a company-risk API at $0.03 per request. The response format and maximum work are deterministic. A Paid API Route gives agents a direct machine interface. The route price is authoritative, and the merchant binds the verified payment to one logical request and response.

Offer B: a monthly sector report at $15. The report already exists and has one catalog price. A QuickPay Product gives both human and agent buyers a stable product key and hosted checkout. Fulfillment grants access to that report edition after the order reaches a trusted paid state.

Offer C: a custom diligence run priced from selected jurisdictions, data sources, and turnaround. The price is not known until the buyer submits scope. The merchant backend creates a Checkout Session after validating the quote. If the merchant needs identity checks, contractual acceptance, and an embedded experience, it can instead use the custom order integration.

The offers come from one merchant and may settle into the same treasury, but they should not be forced through one sales surface. Their price authorities and delivery interfaces differ.

That is the practical value of a merchant product portfolio: shared operations without pretending every offer is the same transaction.

One Control Plane Must Sit Behind Every Sales Surface

Choosing checkout or API access is only the front-door decision. A merchant still needs to operate the resulting business. GOAT Flow's current Merchant Guide groups functions around orders and reconciliation, receiving configuration, products and routes, fee balance, API credentials, webhooks, team security, and audit activity.

These functions answer questions that the 402 exchange alone cannot:

• Which product, route, session, or quote caused this payment?

• Has the order been fulfilled, refunded, retried, or disputed?

• Did a webhook fail, arrive twice, or arrive out of order?

• Which API key or team member changed the price or route?

• Does the merchant have the required operational balance?

• Do settlement records agree with application delivery records?

The merchant should assign one internal correlation identifier across the commercial chain where possible:

offer or route -> quote/session/order -> payment evidence -> delivery record -> settlement/reconciliation record

This does not require every component to share one database. It requires the merchant to preserve enough stable identifiers to reconstruct the transaction.

Current public GOAT merchant documentation centers on DIRECT flows. Merchants should also treat the active portal, API response, manifest, and payment challenge as authoritative for supported networks, assets, recipients, fees, limits, and enabled capabilities. A product-page network list or an old integration example is not a safe runtime configuration source.

Fulfillment Is the Final Product Decision

The most expensive error is often not failed payment. It is delivering the wrong resource—or delivering twice—because the application trusted the wrong signal.

Merchants should not fulfill solely because:

• the browser reached a success URL;

• a client claims payment completed;

• a transaction hash exists;

• a webhook arrived without authentication;

• an amount was paid without matching the required product or order.

The exact trusted signal depends on the product. A hosted product or session should resolve to trusted merchant order/payment status. A paid route should verify the payment condition and signed receipt under the current route contract. A custom integration should authenticate completion events and reconcile ambiguous states from the backend.

Failure policy should be part of the offer before launch:

• If payment succeeds but service execution fails, will the merchant retry automatically, issue credit, or refund?

• If a request times out, what idempotency key prevents duplicate charging or execution?

• If a webhook is missed, what reconciliation job repairs the state?

• If the product price changes, when do old sessions expire?

• If the paid asset or network is temporarily unavailable, is there a supported fallback or a clear stop?

An agent should not be authorized to spend without limits, and a merchant should not deliver without limits. Both sides need bounded policies. Payment infrastructure moves value; application rules decide what the value purchases.

A Staged Launch Sequence for Merchants

A merchant can reduce integration risk by launching in stages.

1. Define one offer precisely. Record the item or service, authoritative price, accepted payment configuration, delivery rule, retry behavior, and refund path.

2. Select the smallest suitable surface. Use a QuickPay Product for a known fixed offer, a Hosted Checkout Session for a backend-computed order, a custom integration for an owned workflow, or a Paid API Route for direct machine access. Use custom amount only when buyer-selected value is intentional.

3. Implement server-side fulfillment verification. Keep merchant secrets off the client and bind payment evidence to the exact order, product, or route.

4. Test unhappy paths. Repeat a request, delay a webhook, expire a session, reject an unsupported asset, and simulate payment followed by execution failure.

5. Reconcile before expanding. Confirm that order totals, delivery records, and settlement evidence agree over a real test window.

6. Add discovery and more products. Once one surface is reliable, expose machine-readable API terms or add catalog and dynamic offers without weakening the original authority model.

FAQ

What x402 products can merchants use to sell to AI agents?

Merchants can use fixed-price product checkout, backend-created hosted checkout sessions, custom order integrations, custom-amount payment pages, and paid API routes. In GOAT Flow, these map to QuickPay Products, Checkout Sessions, custom checkout integration, QuickPay custom amount, and Paid API Routes. The correct choice depends on price authority, buyer interface, backend availability, and fulfillment evidence.

Which x402 product is best for selling a fixed-price digital product?

A fixed product record with hosted checkout is usually the clearest fit. QuickPay Products let the merchant define the product key, description, price, and availability before checkout. The fulfillment system should still verify trusted merchant order or payment status before granting a download or entitlement.

How can a merchant charge an AI agent for an API request?

The merchant can protect a machine-facing endpoint with a Paid API Route. The agent requests the endpoint, receives machine-readable payment requirements, satisfies the supported payment condition, and retries or completes the request with payment evidence. The server verifies that evidence and returns the protected response according to an idempotent delivery policy.

When should a merchant use a hosted Checkout Session instead of QuickPay?

Use a hosted Checkout Session when the merchant backend must calculate the final order, such as a dynamic cart, customer-specific quote, or configured digital service. Use a fixed QuickPay Product when the offer and price are already known and stored in the merchant catalog.

Can a custom-amount payment page sell a fixed-price product?

It should not be used as the sole price control for automatic fixed-price fulfillment. A successful buyer-entered payment may be lower than the required product price. Merchants should use a fixed product or backend-created session, or explicitly verify the paid amount and all commercial conditions before delivery.

Does a successful x402 payment prove that the service was delivered?

No. Payment evidence and delivery evidence are separate. The merchant must bind the payment to the intended product, order, route, or request and record the delivery result. Paid-but-failed execution, retries, missed webhooks, refunds, and reconciliation still require application and merchant operations.

The Right Surface Preserves Commercial Authority

The best x402 product for a merchant is not determined by whether the offer is called an API, service, or digital product. It is determined by who sets the final price, where the buyer interacts, whether the merchant runs a backend, and what proof authorizes delivery.

Use Paid API Routes for direct machine-consumed endpoints. Use QuickPay Products for fixed catalog offers. Use Hosted Checkout Sessions for backend-priced carts and services. Use custom order APIs when the merchant must own the complete experience and business logic. Reserve custom amount for payments where the buyer is genuinely allowed to choose value.

That structure lets AI agents become customers without pretending payment solves pricing, identity, fulfillment, or operations by itself. Merchants evaluating these paths can explore GOAT Flow and verify the current portal, asset, network, and integration capabilities before implementation.