x402 Commerce Platforms Compared by the Seller Features They Actually Document

A checkout page can look finished while the sale behind it remains unresolved. A customer has approved payment, the browser has closed, and your service still needs to decide whether to release a report, reopen the purchase or ask for another payment. Choosing an x402 commerce platform by its payment screen does not answer that decision.

The more useful comparison is between four seller promises: a hosted payment interface, a link with defined purchase semantics, a durable record of what was paid for, and a notification contract that your backend can authenticate and recover. A platform may combine them, but none should be inferred merely from the ability to settle an x402 payment.

GOAT Flow, Coinbase Business Checkout and checkout402 document merchant-facing implementations of those promises. PayAI's x402-commerce-checkout supplies a contrasting reference implementation. They are not interchangeable products, and the reference is not a fourth managed merchant service.

This comparison reviews public documentation retrieved on October 26, 2026. It is not a hands-on performance ranking: no merchant account, payment, production webhook or deployed receipt was tested. Features described below remain subject to the provider's account, payment-profile and deployment conditions.

Four Seller Features, Four Independent Contracts

First separate the actors. x402 is the HTTP payment protocol, not a hosted storefront or an order-management product. A buyer's wallet signs or submits payment under the chosen flow. A facilitator can verify and settle a payment and return the result to the seller. The seller still decides what to deliver; the x402 facilitator documentation places that decision at the resource server.

A commerce product adds operational objects around those roles. Its hosted page may collect payment without knowing your customer account. Its payment record may identify a transfer without knowing whether a report was generated. Those are useful services, but they discharge different obligations.

The table is a documentation map, not a certification matrix. "Application-owned" identifies work the integration must supply. "Not established" means the reviewed evidence does not establish the feature, not that the provider cannot offer it.

The practical distinction is not the number of populated cells. It is whether a cell names an interface you can operate. A signed remote notification has a receiver, verification input and recovery policy. A callback inside an SDK has none of those transport properties by itself.

Nor should a "hosted" label erase merchant responsibility. GOAT Flow's Checkout documentation explicitly leaves the application in charge of products, cart, pricing and fulfillment in both hosted and custom integrations. Outsourcing the payment interface can reduce UI work without outsourcing the sale.

Treat each row as a different allocation of engineering work. The first procurement question is therefore which boundary you want the provider to operate, not which vendor appears to have the most complete payment demo.

One URL Can Represent an Offer or a Purchase

A reusable offer and a single purchase may both be shared as a payment link. Their identities are different. One offer can generate many sales; one paid purchase should not become an unlimited entitlement simply because its URL still opens.

GOAT Flow QuickPay documents merchant-created product links, catalog access and buyer-entered custom amounts. That is a different starting point from an authenticated Checkout Session created by an application's backend for its own purchase. Product configuration can control a fixed offer price; an Any Amount payment is appropriate only when buyer-controlled amounts fit the business purpose.

For a fixed-price digital sale, the resulting design consequence is concrete: a payer's reference text cannot substitute for the server's expected price. If someone sends less than the report costs and labels the transfer "full payment," the label does not discharge the purchase. Use an offer or session whose authoritative terms match the sale, then verify the resulting payment against those terms.

Coinbase Business takes a per-purchase approach in its Checkout overview: each checkout accepts one payment and moves to a terminal state. A new transaction needs a new checkout. A seller can distribute that checkout's URL, but should not infer that one completed checkout is a reusable public product offer.

The distinction matters for repeat customers. "Buy another copy" is a new business request. "Resume my interrupted purchase" is not. If both buttons blindly create another checkout, the UI hides the difference while the backend creates additional payment opportunities. A purchase identifier should preserve that distinction before the payment provider becomes involved.

checkout402 exposes the choice directly. Its API reference makes reusable opt-in; the default is single-shot. It also documents that price_usd and pay_to cannot be patched on an existing checkout, and that Idempotency-Key can replay creation rather than produce another checkout. These are separate controls: reuse governs repeat sales, immutable terms protect an existing offer, and creation idempotency governs a retried request.

An integration should not use any one of those controls as a replacement for the others. Creation idempotency does not establish that every buyer of a reusable offer receives a separate customer entitlement. Likewise, changing a product's description is not permission to silently change the terms of a purchase already in progress.

Before choosing a link product, write down its intended cardinality: one URL per public offer, per purchase, or per payment attempt. Then identify what distinguishes two buyers using that URL. If your application cannot make that join, an attractive reusable link may be easier to publish but harder to reconcile than a backend-created purchase session.

HTTP Success Can Precede Settled Payment

The payment profile changes what "success" means. Compatibility with the word x402 is too broad a condition for a fulfillment rule.

Coinbase's agentic payment guide describes an authorize-then-capture flow. Paying x402_url authorizes the payment; Coinbase captures and settles it server-side. The documented settlement predicate is checkout status COMPLETED, not the HTTP response observed by the paying agent. PROCESSING indicates capture has started, not that delivery is authorized. A client needs the advertised auth-capture scheme rather than an assumption that every x402 client supports every checkout.

The failure consequence is easy to miss: an agent can finish its signing interaction while the seller still has an unresolved payment. Returning the goods merely because that interaction succeeded transfers the capture risk into your application. Waiting for the provider's authenticated completion signal avoids that mistake, though the application must now support a pending state rather than only success and failure screens.

Account routing is another condition. Coinbase's paid API integration guide says a checkout is agent-payable only when its create response includes x402_url. A product announcement or sample response is not proof that your account returned that field. Confirm the actual response before making the agent-facing route available.

For GOAT Flow Crypto checkout, the documented public receiving path is DIRECT transfer to the merchant-configured address. That is not Coinbase's authorize/capture model. A submitted transaction hash is a reference to inspect, not a complete fulfillment decision. Tie verification to the expected purchase, recipient, asset, amount and environment; then apply the authoritative status contract for that exact GOAT Flow surface.

Do not normalize different providers' statuses by spelling alone. "Confirmed," "completed" and "invoiced" can describe different objects. A checkout session, an ordinary payment order and a card payment have different lifecycles even within one product. A merchant-facing state model should retain which surface supplied the status rather than flatten everything into an unqualified paid Boolean.

For checkout402, fulfillment mode also matters. Its documented inline, relay and webhook choices do not justify assuming one universal ordering between delivering goods and settling money. Inspect the selected mode before deciding whether a retry repeats payment, repeats work, or retrieves a previously produced result.

The useful comparison question is precise: which authenticated observation lets this application advance this purchase to delivery? A platform that answers that question clearly can be a better fit than one advertising more payment methods but leaving the completion boundary uncertain. This is a decision about available evidence and operational fit, not a claim that one payment scheme is universally safer.

Receipts and Orders Answer Different Questions

Payment evidence answers who paid what. Your business record must also answer what that customer bought and whether the result can be recovered. Calling both objects an "order" obscures the join between them.

GOAT Flow documents ordinary orders, Checkout Sessions and merchant reconciliation views. Its repository merchant guide distinguishes the payment order ID, opaque checkout handle and merchant business reference. It also identifies a potentially misleading proof field: the legacy order proof's historical signature is an unsigned digest, not a cryptographic signature authenticating the full order state. That record should not be presented as equivalent to a separately signed receipt.

The GOAT Flow API Payments documentation describes such a separate artifact in its GOAT-specific MPP profile: a signed Payment-Receipt checked for signature, merchant audience, route binding, expiry and replay policy. The resource server still applies its own access checks. Generic MPP or x402 verifier compatibility is not established merely by the profile's name.

Even valid route proof does not answer every business question. A report endpoint can serve different customers and different input sets. For a service selling customer-specific work, the recommended application design is to bind the purchase to the authenticated customer and saved request, then store the resulting report under that association. A receipt should not become permission to retrieve somebody else's result just because both requests use the same route.

Single-use consumption creates a related recovery issue. If your chosen policy consumes proof before the response reaches the customer, a network interruption can leave payment valid and access apparently exhausted. The application needs a way for the entitled customer to retrieve the already-purchased result without buying again. That is a result-recovery contract, not a reason to disable receipt verification.

Coinbase's hosted checkout gives the seller a persistent checkout ID and status lookup; its integration guide makes the production durability requirement explicit rather than treating the sample's in-memory paid set as sufficient. Keep the provider ID in your own purchase record. A status lookup can recover payment state, but cannot reconstruct customer inputs your application never saved.

checkout402's Payments and Receipts guide describes receipt exports with checkout identity, destination, transaction and delivery status. Keeping settlement and delivery facts separately visible can help locate a paid-but-undelivered purchase. It does not prove that the delivered data was correct, that the customer can still authenticate, or that your own application has retained the result.

This is where a platform's record model becomes a selection criterion rather than a dashboard preference. Ask whether you can join payment, customer and deliverable without guessing from timestamps or matching equal amounts. If two customers buy the same offer simultaneously, amount and route alone are insufficient business identifiers. Preserve the association at purchase creation, before recovery becomes necessary.

Notification Evidence Starts at the Network Boundary

A webhook is useful only if your receiver can distinguish an authentic event from an imitation and can survive receiving it more than once. "Webhook support" without the signed input, identity and delivery behavior is an incomplete comparison dimension.

The Coinbase Checkout webhook guide documents X-Webhook-Signature verification using timestamp, named header information and raw payload. It marks X-Hook0-Signature as deprecated. This is not interchangeable with a verifier that merely hashes the JSON body, even when another provider uses the same newer header name.

GOAT Flow's Merchant Portal documentation describes X-Webhook-Signature: sha256=... as HMAC-SHA256 over the exact raw body, using the endpoint's webhook secret rather than the merchant API secret. It says created_at is a delivery timestamp, not a stable event identifier. It also distinguishes Card payment success from permission to fulfill a purchase that may be held from completion.

There is an assurance qualification here. The repository merchant guide retains a warning dated October 9, 2026 that no deployment-approved production notification sample or versioned webhook contract was checked into that repository. The site now describes a signature contract. Those statements do not establish that webhooks are absent; they establish that public interface documentation and deployment evidence are different things. Obtain the contract and sample matching the environment you will operate before enabling fulfillment.

checkout402's webhook guide documents timestamp-bound raw-body signatures with Ed25519 or an endpoint-secret HMAC option. It describes backoff retries, possible duplicates and no ordering guarantee. It also requires separating test-mode notifications from production sales. Its sample and other snippets differ in payment-ID field notation, so confirm the active payload schema rather than copying a receiver verbatim.

The payment identity matters more than the number of deliveries. Two notifications about one purchase should not grant two entitlements, and a webhook racing with a successful status poll should reach the same final business transition. As a recommended receiver design, authenticate first, durably record the event, acknowledge promptly and process fulfillment idempotently. Keep the provider's confirmed business identifiers; do not invent an event_id or treat a delivery timestamp as one.

Local SDK hooks are a different layer. The x402 lifecycle-hook documentation describes callbacks around verification and settlement. A successful hook can be where an application starts its event work. It is not, by itself, a remote delivery service with endpoint authentication, durable retries and operator visibility.

This distinction changes the build-versus-buy estimate. With a managed webhook contract, the merchant still operates its receiver and fulfillment worker. With a local hook or queued application event, someone must additionally build and operate the outward delivery mechanism. Neither approach is inherently wrong; they allocate failure recovery to different teams.

Follow One Paid Report Through an Interruption

Consider a hypothetical service selling a customer-specific report. This is a design illustration, not an executed transaction or a claim about measured provider behavior. The customer should pay once for one saved request and later retrieve the result even if the original browser disappears.

Begin with a business purchase record that names the customer, inputs and agreed terms. Record the provider's purchase/payment identifier against it. This is application-owned design advice: the exact database schema and state names are not claims about a vendor API.

Now suppose the create response is lost. The service cannot conclude that checkout creation failed simply because it received no ID. Creating another payable object may give the customer a second payment path for the same purchase. Use documented creation-idempotency behavior where available and retain the same logical purchase identity. Coinbase documents X-Idempotency-Key; checkout402 documents Idempotency-Key. Those names and contracts are not portable to an API that does not support them.

GOAT Flow's API guide instead warns that a lost ordinary-order create response can require reconciliation, and that duplicate business-order submission is not an existing-order lookup. In that situation, hold the purchase for reconciliation rather than guessing an SDK method or automatically requesting another transfer. A known broadcast transaction should remain attached to the unresolved purchase while its outcome is checked.

Next suppose the customer approved the agent payment, but capture remains unresolved. Under Coinbase's documented flow, the service waits for COMPLETED. Under a direct-transfer flow, it checks the original transfer and the relevant authenticated order/session completion contract. The customer's UI can show a pending purchase without treating uncertainty as permission to charge again.

Finally, payment completes while the receiver is temporarily unavailable. A later valid notification and a concurrent status check can both discover success. They should converge on one durable delivery operation. If report generation already finished but its HTTP response was lost, the customer's authenticated recovery request should retrieve that saved result. Re-running payment is not a substitute for recovering an already-funded deliverable.

PayAI's x402-commerce-checkout reference makes the ownership boundary especially visible. Its opaque URL serves a browser wallet paywall or a programmatic challenge; after successful facilitator settlement, its hook creates the order and queues an application event. The README explicitly identifies in-memory reference state and a single demo worker, requiring durable transactional storage for production. Treat it as a starting point for an application-owned implementation, not evidence that managed webhook delivery or production persistence is included.

The interruption therefore distinguishes candidates without pretending to benchmark them. A hosted payment provider can reduce payment integration work while leaving report recovery entirely yours. A reference implementation can expose the transition you need to control while giving your team substantially more persistence and operations work.

Select the Contract Your Service Can Operate

For a merchant choosing among these implementations, the best next step is to specify what each provider must hand back to the application, with unresolved conditions attached.

GOAT Flow is a candidate when the intended workflow combines hosted collection, merchant-managed product links and order operations. Its distinction between QuickPay offers and backend-created sessions is useful for separating public selling from application-owned purchases. Carry forward the deployment-specific method settings, completion semantics and webhook evidence requirement; do not turn its documented surfaces into an unconditional availability claim.

Coinbase Business Checkout is a candidate for a per-purchase hosted checkout plus an agent-payable endpoint when the actual account response provides it. The decisive conditions are x402_url presence, a compatible payment client and capture completion. This arrangement can suit a service that already owns customer purchases and results, rather than expecting checkout creation to supply an entire commerce backend.

checkout402 is a candidate when reusable offers and payment/delivery records are central to the selling model. Decide the offer's reuse and fulfillment mode explicitly, then preserve a payment-to-customer association for each sale. Its richer records can reduce reconstruction work, but should not be mistaken for proof that an origin delivered correct goods or that your service has a complete recovery path.

PayAI's reference is relevant when the team wants to own checkout state and settlement-triggered order creation. The cost of that control is not just deployment: durable transitions, remote event delivery and recovery operations need an identified owner. Its public demonstration and repository tests are not evidence that those production obligations have been discharged for your application.

Before accepting any candidate, the procurement record should be able to complete this sentence with concrete interfaces: one offer produces identifiable purchases; one authenticated payment-completion predicate unlocks the correct purchase; one persistent association locates the customer's result; and one recoverable notification path converges on the same fulfillment transition as status lookup.

An unanswered part is a specific integration gap to resolve, not grounds to declare an undocumented feature nonexistent. Select the candidate whose verified contract fits the sale and whose remaining work your team can actually own.

FAQ

Is a reusable payment link the same as an idempotent purchase request?

No. Reuse determines whether one offer can generate multiple sales. Idempotency governs repeated attempts to create or process the same logical purchase. A reusable offer still needs a separate payment-to-buyer association for each sale; a creation retry must follow the provider's actual idempotency contract.

Can I deliver a product as soon as an agent's x402 request succeeds?

Not without checking the selected payment profile. In the reviewed Coinbase Business authorize/capture flow, payment authorization and PROCESSING do not establish completed settlement; the documented predicate is COMPLETED. Other surfaces have different contracts. Use the trusted completion result for that exact purchase, not generic HTTP success.

Does webhook support mean the same receiver can be used for every platform?

No. Signature inputs, secrets, payload identifiers and retry behavior differ. Verify the exact deployment's contract and authenticate the event before acting. A webhook and a status poll about the same purchase should converge on one fulfillment transition; delivery timestamps or repeated notifications must not become separate entitlements.

Is PayAI's reference checkout a managed merchant platform?

It is treated here as a reference implementation, not a fourth managed merchant service. Its documented in-memory state and demo worker do not discharge production persistence or operations requirements. A team adopting it must own durable transitions, event delivery and purchase recovery rather than infer those services from the demo.

Are all fields called signature equivalent payment proofs?

No. GOAT Flow's legacy ordinary-order proof contains a historical signature field documented as an unsigned digest. Its GOAT-specific paid-route profile uses a separately signed Payment-Receipt with defined verification checks. Identify the artifact and its contract before using it as authority, and keep business entitlement checks separate.