A paid API needs more than a payment check. Match x402 infrastructure to bounded pricing, verified admission, and recovery of already-paid agent jobs.
An agent pays to extract structured data from a document. Your worker completes the extraction, but the HTTP response disappears behind a gateway timeout. The agent tries again. Should that request create another charge, repeat the extraction, or retrieve the result it already purchased?
That decision belongs in the API design before the first real payment. Otherwise, a successful transfer can leave both parties unsure whether the service owes a result.
Developers can use x402 resource-server SDKs and HTTP middleware, paired with compatible payment clients and either managed or self-operated verification and settlement infrastructure. GOAT Flow provides another concrete merchant path: fixed-price paid API routes using its current GOAT-specific MPP integration profile, DIRECT ERC-20 transfers, and signed-receipt middleware. That profile is not interchangeable with a generic x402 or MPP client. GOAT Network AgentKit is agent execution tooling, not a replacement for merchant payment verification or delivery storage.
The useful launch question is therefore not just which package returns HTTP 402. It is which components can enforce your billable operation, which evidence permits work, and how a caller recovers an already-paid result. Select infrastructure around those obligations rather than expecting payment middleware to define them.
Price A Bounded Unit Of Work
Start with the unit the buyer receives. “One API call” is convenient to advertise, but it can conceal very different costs. A lookup against a cached dataset is not equivalent to parsing a large document, invoking a model repeatedly, and writing a report.
For each paid endpoint, specify the accepted input, maximum work, output, and completion condition. A document extraction route might accept one supported file, cap the number of pages, return a defined JSON schema, and preserve the result for a stated retrieval period. Those boundaries make both pricing and recovery meaningful: retrieving the existing JSON is not a second extraction.
Validate cheap, deterministic constraints before asking for payment. Reject an unsupported file type, an oversized request, or missing required fields before generating a payable offer. Then apply the same constraints again when admitting the paid operation. A buyer must not be able to quote a small input and submit a much larger one after paying.
Consider this hypothetical pricing calculation, not a GOAT fee schedule or a measured customer result. An extraction sells for 0.02 units of a dollar-denominated payment token. Suppose expected processing cost is 0.008, and you allocate 0.003 to payment operations, storage, retries, and support. The remaining contribution is 0.009 per completed sale before other overhead. If processing rises to 0.025 for large inputs, that same price loses 0.008 before overhead. A resource cap changes the economics more directly than a different payment header does.
Use decimal-safe accounting and separate the price shown to a caller from the atomic token amount sent on-chain. For an illustrative token with six decimals, 0.02 token units equals 20,000 atomic units. Confirm the actual token contract and decimals; never assume every asset uses six decimals or native-chain denominations. Avoid floating-point arithmetic for payment amounts.
Current x402 documentation distinguishes exact, where the advertised price is paid, from upto, where the buyer authorizes a maximum and the server settles actual usage. It also documents batch settlement for repeated payments using channels and off-chain vouchers. Support differs by scheme, network, and SDK; those capabilities must match the integration you deploy. The seller quickstart is the relevant starting point for that choice.
A fixed upfront charge is easier to explain and reconcile, but the seller absorbs variation inside the purchased unit. A usage-based scheme can align charges with variable compute, at the cost of usage measurement and more settlement logic. Do not advertise “pay only for tokens consumed” on a fixed-price route unless another verified mechanism actually implements that promise.
Decide how empty results and service failures affect the sale. A valid search with no matches can still be a completed lookup; an unavailable upstream dataset is different. State that distinction in the service contract rather than allowing the model, support agent, or retry library to invent it later.
Pricing check: Can a buyer tell what one payment buys, what exceeds the cap, and which subsequent requests retrieve the same purchase?
Assign The Payment Duties Before Choosing Packages
A paid API has a resource server, a payer client, payment verification, a settlement path, and application storage. Some products combine several of these. None should be assumed to own the whole sale merely because it exposes a payment API.
In a generic x402 integration, the resource server advertises payment requirements and the compatible client supplies a payment payload. The official TypeScript seller examples use @x402/express for route middleware and HTTPFacilitatorClient from @x402/core/server for facilitator communication, with a registered scheme implementation for the chosen network. They also show a Coinbase CDP production facilitator path. These are concrete assembly options, not a promise that every facilitator supports every network or scheme.
A facilitator can verify a payment payload and submit settlement transactions. Verification of an authorization and confirmation of settlement are separate results; choose deliberately when expensive work begins and when its result may leave the server.
A managed facilitator reduces the blockchain operations you run, while adding a service dependency and provider configuration to check. Self-hosting or self-facilitating offers more operational control but leaves you responsible for signer configuration, network connectivity, pending transactions, and reliability. The official documentation distinguishes these deployment paths and identifies the public x402.org facilitator as development/testnet infrastructure, not a default mainnet service. The facilitator documentation explains that responsibility split.
GOAT Flow's public DIRECT path has a different execution boundary: the payer sends an ERC-20 transfer to the merchant's configured receiving address. Flow observes and verifies the transfer; customer funds do not pass through Flow. For paid resources, its current MPP profile uses JSON challenge and verification endpoints, then issues a signed Payment-Receipt that the merchant resource server checks.
This is a specific adapter contract. MPP is an independent protocol; GOAT Flow's JSON endpoints and three-segment receipt are not the generic MPP HTTP credential and receipt formats. The current repository documents no published interoperability result with official MPP SDKs. Use a matching buyer adapter and verifier, or establish compatibility through explicit testing. Do not feed an arbitrary MPP credential to a Flow receipt verifier. The GOAT Flow profile guide defines this boundary.
The repository supplies TypeScript receipt-verification adapters for Express and Fastify and a Go implementation. Its middleware is distributed as source modules; a package name in the repository is not evidence that a registry install command will work. For deployment, identify the exact source or published version you will consume, its license, and the enabled Core environment it requires. Candidate release notes do not prove publication.
Whichever path you choose, keep the division explicit: the payer authorizes spending; the payment infrastructure evaluates evidence and settlement; the merchant application decides what work that evidence buys and records whether it was delivered. Agent-side action tooling can coordinate calls and wallet operations, but it cannot make the seller's missing job database appear.
Infrastructure check: For every dependency, name its role, supported payment profile, failure response, and operator. Leave no “the SDK handles it” answer where two systems have independent state.
Keep The Quote Authoritative From Discovery To Payment
Discovery information helps an agent find a service and understand its advertised price. It should not become a substitute for current payment terms. A cached description can outlive a token change, receiving-address rotation, or price update.
GOAT Flow's merchant guide describes fixed-price protected API routes. Configuration requires an enabled DIRECT merchant, paid-route capability, a supported chain/token pair, and a matching receiving address; route management also has role requirements. These are prerequisites to verify in the target deployment, not entitlements implied by a repository example. The paid-route configuration guide documents that merchant-side setup.
In the Flow profile, the current challenge is authoritative for the exact amount, chain, token contract, recipient, expiry, MAC, and pricing version. The buyer should validate these against its own permitted spending rules, then use the accepted challenge unchanged. Reconstructing the amount from an old manifest or substituting an address from a page description breaks the contract.
The challenge's amount_wei is an exact ERC-20 atomic-unit amount despite its name. Do not convert it as though it were necessarily native ETH or BTC. Record the token contract and chain alongside it so a numerically correct amount cannot be mistaken for payment in a different asset.
Price changes also need a policy for outstanding challenges. Persist the terms that authorized a payment, rather than consulting today's price during recovery and charging a caller again because the route is now more expensive. In the current Flow profile, Core binds the pricing version to the challenge/order. The signed receipt does not carry route_pricing_version, so receipt middleware cannot independently compare that version. If your application needs a versioned service entitlement, preserve the relevant association in trusted application records; do not invent a receipt field.
Keep the public resource URL and its canonical payment route aligned. For example, the illustrative method/path GET /api/data maps to GET:api:data in this profile. Reverse-proxy rewrites and API version aliases can produce a different route at the verifier than the one published for payment. Test the externally requested route against the actual middleware configuration, not only a local handler name.
Origins matter too. Flow's QuickPay-driven client derives endpoints from a trusted payment-link origin rather than accepting arbitrary absolute endpoints from a manifest. A standalone client uses its configured Core origin. Public endpoints do not guarantee browser CORS access: both payment and resource servers must permit the intended browser behavior where applicable.
Quote check: Preserve the accepted terms and identify who may change them. Browser input, cached discovery, and a model-generated destination must never silently override authoritative pricing or recipient configuration.
Admit Work With The Correct Verifier
Payment evidence must be evaluated by a trusted server before it admits valuable work. A browser success callback, a client assertion that it paid, or an unexamined transaction hash is not that decision.
For a generic x402 route, use the verifier for the selected scheme and network, then handle its settlement outcome separately. Do not turn a valid signed payload into a claim that funds have already reached the recipient. If work must run before the final charge can be calculated, define how compute exposure is bounded and what happens when settlement cannot complete.
For a GOAT Flow profile route, the resource server verifies the signed receipt returned after transfer verification. Its configured algorithm and verification key are part of the trust boundary. With Ed25519, the resource verifies using the public key. With HMAC, protect the shared secret; a holder of that secret can generate valid MACs, so key distribution has a different trust model from public-key verification.
The pinned TypeScript verifier checks the signature under the configured algorithm, merchant audience, route binding, and receipt expiry. Route binding accepts an exact canonical identifier or that identifier followed by a colon-delimited suffix. An optional receipt-ID store adds single-use consumption. These are the actual checks in the receipt verifier source, not a claim that every request parameter is authenticated automatically.
Two consequences follow. First, a receipt for another merchant or outside the configured exact-or-colon-prefix namespace must fail even if it represents a real transfer. This is not exact isolation between every endpoint: a canonical identifier such as GET:api:data:premium satisfies the prefix predicate for GET:api:data. Separately priced endpoints with overlapping prefixes need an application-level exact-route check or a non-overlapping namespace policy. Second, a receipt bound to a route does not by itself prove that the submitted document, query, output options, or application job identifier match the purchased operation. Those associations require your application's additional checks.
Do not confuse the profile receipt with the order API's historical proof response. That API has a field named signature which is actually an unsigned Keccak256 digest, and the digest does not cover status. Anyone can recompute it. It is not a signed payment attestation and cannot be substituted for the MPP receipt verification path. The order API reference explains this limitation.
Receipt expiry needs its own operational meaning. It limits admission under that receipt. It does not necessarily mean a legitimately admitted, still-running job loses its purchased entitlement at the same instant. Define a separate authenticated job-retrieval policy, with its own retention period, instead of repeatedly submitting an expired receipt to restart work.
A deployment's accepted chain, token, recipient, and confirmation policy remain material. DIRECT ERC-20 payment on an EVM chain is not a Bitcoin L1 transfer. GOAT Network's Bitcoin-secured positioning does not change the asset transferred or make an API receipt proof of Bitcoin L1 execution.
Admission check: Write down the evidence type, trusted verifier, successful payment condition, required application binding, and what remains unknown. Reject the wrong evidence format even when a field is reassuringly named.
Bind Admission To One Logical Job
Retry safety needs an identity for the logical purchase, not merely for the HTTP connection. The same extraction can arrive through two gateways or reach two replicas. A new transport attempt should not automatically become a new sale.
Persist an operation identifier before payment and bind it to the meaningful request. An application fingerprint can include the merchant, method/path, immutable input reference or digest, processing options, price terms, and output version. Normalize these fields deliberately. Changing a document URL's content underneath a stored URL is a different problem from changing the URL string, so freeze the input or verify its content identity before processing.
Where supported, x402's payment-identifier extension supplies a payment ID and server-managed caching behavior. Its documentation recommends binding that ID to a request fingerprint and rejecting a different request under the same ID rather than returning unrelated cached data or executing again. The payment-identifier reference provides the protocol-side starting point. An identifier alone does not create durable business storage.
For the Flow profile, optional receipt consumption prevents a receipt from admitting multiple new operations. In a multi-replica service, that consumption must be shared and atomic; a process-local set cannot stop another replica from accepting the same receipt. A replay-store outage should block uncertain admission, not bypass the control and perform expensive work.
There is also a crash window that a simple middleware example does not close. If the verifier consumes the receipt and the process dies before persisting a job, a second attempt may correctly fail as already consumed while no worker knows what to deliver. Conversely, storing a job before proving admission could authorize unpaid work.
The following pseudocode illustrates an application-owned admission transaction, not a GOAT SDK API or a tested integration:
The important property is the transaction tying unique admission to a durable job and enqueue record. This can require custom integration of the verifier and your database, rather than a stock consume-before-handler middleware configuration. Alternatively, document and implement an explicit reconciliation path for a consumed receipt with no job. Do not describe either design as an automatic product feature.
Returning a prior job also requires authorization. A caller who guesses an operation ID must not receive someone else's purchased report. Use a payer-bound authentication method or a separately issued recovery capability, scope it to that operation, and avoid exposing sensitive report content in logs or public status responses.
Atomic admission does not guarantee exactly-once external execution. Workers can crash after invoking an upstream system but before recording completion. Make downstream effects idempotent where possible, preserve their identifiers, and reconcile uncertain outcomes before repeating them.
Binding check: One admitted payment creates one durable operation; the same operation with the same input recovers it, while the same identifier with changed input conflicts.
Recover The Paid Job, Not Another Payment
Track payment, work, and delivery independently. An application can record payment as pending or verified; work as queued, running, completed, or failed; and delivery as available or acknowledged. These are illustrative application states, not GOAT Flow API status names.
A transfer can be verified while work is still queued. Work can be complete while delivery is unknown. If those states collapse into a single “success” flag, support cannot distinguish a payment problem from a worker outage or a lost response.
Before broadcasting a Flow profile payment, the buyer should retain enough challenge context to reconcile it. After broadcast, retain the transaction hash and payer information. The profile's SDK supports recoverable post-broadcast errors that preserve challenge and transaction context; resume verification rather than requesting a fresh payment. Its documentation warns that rerunning the payment CLI is not a resume-verification operation.
Follow the endpoint's retry contract. The Flow verification path documents pending-finality and rate-limited responses with backoff, transient server failures, and terminal rejection cases. A missing or malformed receipt is not permission to call the protected route. A verification timeout after broadcast is also not proof that the transfer never happened. Reconcile the existing transaction; do not infer that another transfer is required from a network error.
Separate these payment retries from job retries. Once an admitted job exists, the merchant should continue or recover that job without asking the buyer to purchase the same operation again. A crashed worker may release its lease for another worker to resume, but the resumed worker must inspect previous progress and external effects first.
Return to the hypothetical extraction. Payment is admitted, the application creates job extract-42, and the worker stores the JSON result. The gateway times out before the buyer receives it. The buyer then authenticates to retrieve extract-42; the service returns the stored result, not another charge and not a second extraction. A request with the same operation ID but a different document is rejected as a conflict. This is the recovery contract the API owner designs, not behavior obtained merely by paying on-chain.
For a synchronous endpoint, preserve the response or result reference before returning it when repeat retrieval is promised. For long-running work, an asynchronous job interface can expose status and result retrieval separately. That interface is your service design; payment middleware does not universally provision it. A status response should say whether work is pending, whether a result exists, and whether operator intervention is needed, without leaking another customer's data.
If the admitted task permanently fails, apply the published service remedy. That may be a repaired run, credit, or a separately executed refund, depending on the business policy. A DIRECT transfer does not create escrow or an automatic reversal. Do not promise refunds, webhooks, or merchant payouts as universal infrastructure capabilities without a verified deployment contract.
Keep a support record linking operation ID, challenge/order reference, transaction identity, admission evidence, attempts, and result reference. Log enough to reconcile the sale, but redact private keys, API secrets, bearer receipts, and sensitive input. Recovery should not require the buyer to disclose its wallet key or pay again to open a support case.
Recovery check: Demonstrate how a paid caller retrieves its result after response loss, and how an uncertain transfer is reconciled without a second broadcast.
Make The Launch Checklist Fail On Purpose
A successful test payment proves only one path. Before real agent traffic, test the boundary conditions against the exact client, payment profile, verifier, and application version you will deploy.
Begin with pricing. Oversized or unsupported inputs should fail before payment. A quote followed by changed parameters should not buy a larger job. A price change must not silently overwrite the terms of an admitted operation. Exercise token-unit conversion at small amounts and reject assets or recipients outside the configured route.
Then test admission failures: missing evidence, malformed evidence, invalid signature, wrong merchant, a route outside the accepted namespace, expiry, and a replay reaching another replica. If separately priced endpoints share a canonical prefix, test that overlapping-prefix case too: the stock verifier may accept it, so verify rejection by your additional exact-route control rather than assuming middleware provides it. Disable the shared consumption store and verify that uncertain admission does not run work. If your route intentionally permits multiple reads under one receipt, document that policy instead of assuming optional consumption means universal single-use behavior.
Test the application boundary separately. Kill a process after payment verification and around the admission transaction. Crash a worker after an upstream effect. Lose the completed response. Retry with the same operation identity, then with changed input. Try retrieving the result as an unauthorized caller. The expected outcomes should come from the route specification, not from whichever layer happens to return first.
Check the agent-side controls too. A wallet signer can authorize a transaction; that capability does not prove aggregate budget, maximum amount, or recipient enforcement. At the pinned revision, GOAT Network AgentKit's PolicyEngine evaluates permitted networks, write enablement, risk thresholds, and confirmation requirements. It has no built-in aggregate-budget, amount, or recipient controls in that class. Implement the needed controls elsewhere and test their enforcement rather than treating a runtime label as financial policy. The pinned policy code makes that distinction inspectable.
Agent identity does not repair payment or delivery logic. ERC-8004 is currently a Draft covering agent identity, reputation, and validation; its specification explicitly treats payments as orthogonal. Registration is not proof that a caller is authorized to spend, that an API call was paid, or that the result was delivered. ERC-8004 belongs in a separate trust decision if your service needs one.
Finally, verify the target environment. Keep merchant secrets on trusted servers and signing keys out of command history. Confirm active route entitlement, receiving configuration, accepted assets, and any browser-origin requirements. Pin dependencies or source revisions and check actual distribution before installation. If your system relies on webhooks, confirm its event, authentication, replay, and retry contract rather than copying an event name from a different environment.
This checklist is based on public primary documentation and pinned code inspected on October 12, 2026. It does not certify a live merchant configuration, package publication, interoperable generic MPP deployment, or production integration. Those checks belong to the developer operating the endpoint.
The go-live artifact should be one route specification containing the billable unit and cap, accepted payment profile, authoritative terms, verifier configuration, request binding, durable admission record, recovery authorization, and service-failure remedy. Pair it with a demonstration that an already-paid job remains recoverable after a lost response. That completes the sale the agent came to make.
