AI Agent Payments for Merchants: When to Accept, Hold, and Fulfill a Purchase

Accepting an AI agent's payment is not the same as authorizing delivery. A merchant must establish three separate facts: this buyer may make this purchase, the payment evidence belongs to that purchase, and the selected payment route permits release. If one remains unknown, keep the order pending or held rather than treating a generic success signal as permission to fulfill.

GOAT Network's commerce and payment product, GOAT Flow, provides QuickPay, Checkout, and API Payments for these situations. Its supported wallet paths require an authorized, compatible payer. Its Card interfaces should not be confused with universal unattended agent card spending.

Receiving money is not the entire acceptance decision. In GOAT's documented Card flow, PAYMENT_CONFIRMED can still leave fulfillment on hold. A failed service is another separate outcome. The merchant must distinguish permission to buy, payment confirmation, platform completion, and actual delivery.

Documentation reviewed: October 21, 2026. The examples below are hypothetical, and the acceptance tests are proposed requirements, not purchases executed for this article.

Define the Purchase Before You Enable Agent Payments

An agent recommending your product has not made a payment. An agent preparing a checkout for a person has not necessarily received authority to charge that person's card. An authorized wallet client can execute a supported transfer, while a delegated-payment integration can use a specific credential within its permitted scope. These are different buyer capabilities.

For AI agent payments for merchants, start with one purchased unit and one supported payer. “Sell a report” is incomplete: which report version, at what price, with which access rights, and to which recipient? “Charge for an API call” also needs an answer about invalid inputs, unsuccessful work, retries, and the result the buyer owns after paying.

Do not allow the client to choose the authoritative amount or replace the merchant's receiving details. If stock, scope, shipping, or price changes, establish the revised purchase before requesting fresh authorization. Payment for one offer must not silently become acceptance of another.

Separate the layers in procurement discussions. A wallet manages assets and signing authority. A card credential participates in a supported card-processing arrangement. x402 defines an HTTP payment interaction. Hosted checkout is a purchase/payment interface. None, by itself, supplies every other layer.

Whatever channel supplies the buyer, the merchant still needs evidence that the particular buyer may authorize this purchase. Referral or channel membership is not that evidence.

Accept Wallet Payments Against Trusted Offer Terms

Suppose a merchant sells a particular research report for 5 USDC. This is an illustrative price, not a GOAT fee or a live product. The offer should identify what the buyer receives and make the supported payment terms available to the intended client. The agent's operator must have allowed that purchase; merely possessing a wallet does not establish an unlimited budget.

GOAT's QuickPay offer and payer flow publishes configured products and machine-readable payment information through a merchant-provided entry. A compatible agent can make an authorized Crypto payment; Card buyers use the supported Stripe interaction. Merchant setup and selected payment methods apply. The entry makes the offer understandable after the buyer reaches it, not automatically discoverable in every external shopping channel.

Before transfer, the buyer should validate the merchant and offer source, amount, asset, network, receiving address, and validity period against the intended purchase. A token symbol alone is insufficient to identify an asset on a particular network. A quote should not be accepted merely because its numeric price looks familiar. The client also needs the necessary balance and any applicable network-fee capability, or an explicitly supported mechanism that handles those fees.

The merchant has separate work: an approved/enabled collection setup, receiving configuration for the active environment, and an association between the business purchase and the payment attempt. Buyer software should not receive merchant API secrets. A wallet client signs as the payer; it does not become the seller's privileged order-management client.

For the hypothetical report, record the purchased version, permitted recipient, quote, and payment reference before delivery. When payment is confirmed through the configured trusted path, those records identify what can be released. If the buyer changes the report selection or asks for extra data, treat that as a purchase-scope question, not a reason to reuse unrelated payment evidence.

An interrupted transfer needs the recovery procedure described below: retain the known payment context and investigate the original outcome, rather than interpreting a missing success screen as permission to charge again.

Card Checkout and Delegated Card Spending Are Different Integrations

An existing card checkout can support an agent-assisted purchase without supporting unattended card execution. The agent may select the item and prepare the order, while the customer opens the payment interface and completes confirmation or authentication. This can be an appropriate commercial experience; it simply has a human handoff.

GOAT's Card and checkout integration contract keeps purchase terms on the merchant backend and Card details/authentication in Stripe's secure components. Card access requires the relevant merchant, connected-account, and deployment setup. The presence of that interface does not establish that GOAT accepts a delegated credential from an arbitrary agent. Merchant pricing, order ownership, and fulfillment remain outside the buyer's control.

Specific delegated-card systems have a different contract. Stripe's seller documentation for Shared Payment Tokens describes grants targeted to a seller with usage and expiry constraints. The seller must support the documented processing path. Expired or revoked authority must not be treated as a valid new purchase. Token deactivation can also reflect consumption or resolution, so it is not itself a successful-charge signal.

That is more specific than “an agent has a card.” The merchant needs to know who issued the credential, which business it targets, what amount/use is allowed, how it is processed, and which result proves payment. Do not put a delegated token into an ordinary card form or assume that a provider's support for one token format establishes support for another.

OpenAI's commerce concepts distinguish an open protocol from approved access to Instant Checkout in ChatGPT. Its delegated-payment description uses a one-time request with a maximum amount and expiry, a supported payment service provider, and a token passed to the merchant. The merchant retains charging, risk decisions, and fulfillment; OpenAI is not the merchant of record. None of this establishes GOAT's participation or compatibility.

Choose the path your buyer can actually complete. Retaining a human Card handoff may avoid an unnecessary integration change, but it will not satisfy a requirement for unattended purchasing. Conversely, automating payment does not eliminate buyer authority or merchant acceptance checks. Configure a supported delegated route only after its credential and processing requirements have been demonstrated for the intended merchant.

Charge for API Usage Through the Actual Payment Profile

For a data API or tool, define the paid operation before protecting the endpoint. One payment might buy one successfully generated report, a particular dataset snapshot, or one permitted execution. It should not ambiguously buy every retry, every possible query, or unrestricted access to a route containing private customer data.

The x402 seller quickstart shows server integration with configured paid routes, receiving terms, and facilitator support. Verification, settlement, and business execution must follow the selected adapter. Its Next.js wrapper, for example, documents settlement after generating a successful response. Do not assume every x402 integration settles before the handler runs, or that payment and delivered output form one atomic transaction.

GOAT's API payment integration paths distinguish Custom Integration, where the merchant owns authentication, pricing, order association, and delivery, from a receipt-gated profile for protected requests. A matching client and configured payment route are prerequisites. Payment verification does not replace private-data authorization or validate every business input.

Compare infrastructure by the part it supplies. Reference SDKs and facilitators can support payment enforcement and settlement, while a merchant product may add orders and operating records. thirdweb's technical x402 documentation describes a paid-resource stack with specific network and token-authorization requirements. Those details are more useful for acceptance design than a broad “any token” headline. Check the intended asset, authorization method, resource, and server/client combination rather than infer universal support.

Circle Agent Stack separates agent wallets, controls, service discovery, and payment components. Funding a controlled USDC wallet addresses buyer readiness; it does not alone configure your seller's protected endpoint or retail checkout. If the payment component changes verification or when funds become available, your release policy needs to reflect that difference.

For a hypothetical paid report API, persist the approved input and purchased result definition with the payment attempt. A request for a different customer's report must fail authorization even if some payment has been made. Reusing a route receipt for a materially different or more expensive query must not bypass business checks. Where middleware consumes a single-use receipt before the handler, a handler failure needs an explicit recovery design; deleting the consumption record is not a sound refund strategy.

This is why “add HTTP 402” is not a complete merchant instruction. Select and test the actual route, method, asset, verifier, and result-release behavior. A protocol name does not prove two implementations exchange the same evidence or have the same failure semantics.

Release the Order Only After the Correct Completion Check

The release rule belongs on the merchant backend. It must identify the business purchase, obtain evidence from the configured trusted source, match the payment terms, and check whether that route permits fulfillment. A customer-supplied transaction hash, screenshot, callback, or unrelated order ID does not satisfy those requirements by itself.

Consider a hypothetical store order with a real Card charge and a duplicate-payment conflict. In GOAT's documented DIRECT Checkout flow, PAYMENT_CONFIRMED is not universal permission to ship. A Card order can remain held; the associated order must reach INVOICED, or its Checkout Session report COMPLETED, before applying the remaining business checks. Those are different status models, not interchangeable strings. A waiter returning at payment confirmation does not establish that the hold has cleared.

Bind the identifiers through the backend. The merchant first records its own order and known checkout reference; Card initialization creates the associated payment order. Look up that association through the trusted session path rather than accepting a different payment order ID from the browser. Then compare expected value and ownership. This prevents proof for one successful purchase from unlocking another.

Three Decisions After a Successful Payment Signal

Use release, hold and reconcile, and recover delivery as application decisions, not invented provider status names. A success event must be interpreted in the context of the purchase it belongs to.

A Card payment is confirmed, but the order is held. Do not ship from the payment event. Read the bound session/order through the trusted backend, check the object-specific completion condition, and resolve the hold through the supported operating path. The next action is not another charge: the original payment can already be real.

A paid API request fails an access check. Money or a valid route receipt does not authorize another customer's data. Reject the unauthorized resource request. Separately determine whether the implementation consumed the proof and whether the buyer retains a recoverable entitlement or needs the applicable return-of-funds process. GOAT's documented two-phase middleware can commit on non-5xx responses, including 403; a rejection is not proof that consumption or payment rolled back. The access decision and the payment recovery decision therefore need separate records.

The report was generated, but the response was lost. A durable result and its authorized recipient can support recovery of the same purchase. Verify that entitlement before returning it; do not run the task or charge again simply because the buyer retries. If no recoverable result exists, investigate failed delivery rather than labelling the purchase fulfilled from its payment alone.

These hypothetical cases produce different merchant actions despite all containing a payment-success signal. For each decision, retain the purchase reference, the trusted evidence consulted, the release condition or reason for withholding, and the existing delivery outcome. Keep raw credentials and sensitive payment handles out of that decision record. These are application-owned records, not additional GOAT API fields.

Receipt validation also depends on the specific profile. The GOAT Flow integration guide explicitly says its current MPP profile is not the standard MPP Challenge/Credential/Receipt HTTP wire exchange. It describes its own challenge, transfer, verification, and signed Payment-Receipt extension. A generally compatible-looking MPP client is not evidence that this exchange works. Check trusted issuer/key, relevant scope and replay/expiry policy through the supported verifier rather than accepting a buyer's assertion.

There is also a difference between a payment being accepted and its proceeds being available under a settlement contract. Circle's Nanopayments explanation describes Gateway-backed signed payments that are verified against balance, followed by later batched onchain settlement. Recipient access to funds follows finalized settlement. This is not the same evidence as a separate finalized wallet transfer for every request, and it does not establish GOAT compatibility.

A merchant can evaluate such a design, but should explicitly decide whether delivery relies on verified platform acceptance or requires later settlement availability. Record that assumption with its provider conditions. Do not label both “instant final settlement” or treat cryptographic authorization as proof of completed delivery.

Recover the Purchase Without Charging or Delivering Twice

Payment creation, transfer submission, status reads, service execution, and customer delivery can fail independently. A recoverable design needs durable associations, not only a long retry loop. Keep the original purchase identity, trusted quote, provider identifiers, known transaction/verification context, and delivery outcome together.

If order creation times out, first determine whether the provider created the original payable order. A duplicate business reference is not necessarily an API that returns the existing result. If a transfer was broadcast, retrying verification differs from sending value again. If payment is confirmed but execution failed, resolve the purchased entitlement rather than require another payment simply because the first result is unavailable.

Suppose the hypothetical report API successfully generates its result but the buyer never receives the response. A retry should be able to recover the entitled result through an appropriately protected mechanism. Persisting the result or its delivery state before claiming completed delivery helps make that possible. A guessed public purchase ID is not adequate access control for private results. These are merchant application requirements, not a claim that a shared payment record automatically guarantees exactly-once execution across systems.

GOAT's merchant operations and recovery documentation describes authenticated webhook handling: preserve the raw request bytes, validate the active HMAC signing contract before parsing, enqueue durably, and process idempotently. A correctly signed payment-success event can still precede permission to fulfill a held Card order. Polling and event delivery can both observe the same purchase, so the business must prevent duplicate release.

Return-of-funds operations are separate too. Eligible GOAT Card refund requests undergo review and processing; approval is not a completed customer credit. Its Card dispute evidence is handled through the connected Stripe Dashboard. Those workflows do not reverse a Crypto transfer. Expiration or cancellation is not a refund; a Crypto return requires its own verified transfer. Do not promise one universal dispute or reversal policy across the methods you enable.

Maintain separate payment, platform-completion, delivery, and return records. Reconcile in the correct environment, currency and mode; a test result is not live revenue. A report showing funds collected is not necessarily a bank payout, net profit, or proof the customer received what was purchased.

The seller also retains product obligations. Physical goods require stock and fulfillment decisions; services need a definition of acceptable work; data needs appropriate usage rights and access. Tax, support and policy responsibilities should have owners. This payment design is not a legal conclusion that a protocol removes any applicable business obligation.

Turn Readiness Into Evidence, Not a Setup-Time Promise

Use one proposed purchase as the acceptance test. Record what is sold, who may authorize it, the enabled merchant environment, the chosen payer client, payment terms, release condition, and the person or system responsible when the outcome is unknown. Pin the actual integration/profile versions and active configuration in the test record; do not copy a static network list or sample token address into production.

For the hypothetical 5-USDC report, obtain the actual configured offer, approved buyer authority, one transfer attempt, trusted confirmation and the matched delivery record. Then test an unsupported asset or insufficient funds and an interrupted status response after submission. The expected behavior must include refusal or reconciliation, not an automatic second transfer. An agent-readable file alone does not prove payment or external shopping-index placement.

For an existing-store Card order, require evidence of backend-priced checkout, the actual customer-authentication or supported delegated-token path, the bound payment order, and platform completion. Include a held-payment case and a duplicate event. A green popup and even an authentic payment-success notification should not pass a test whose requirement is permission to fulfill.

For a paid API operation, record the unpaid request, the exact implementation's payment requirement, buyer authorization, verification/settlement behavior, and the returned result. Test a changed input, replayed proof, concurrent delivery attempt and lost response. Include the authorization-rejection case above: determine whether the paid receipt is consumed and how the entitlement is recovered. Perform access and input checks before consumption where required by the design. Ask which actions happen before settlement and how paid-but-failed work is recovered. An example assembled from incompatible clients and receipt formats does not demonstrate a working integration.

None of these transactions or failure tests was executed for this article. They define evidence the merchant and its implementers should obtain. Documentation can establish intended contracts; it cannot prove that a particular account, client, network, and release handler work together in production.

Finish the review with one explicit release rule for the chosen route and a named recovery owner. If the team cannot explain why this evidence authorizes this order, or what happens when payment succeeds but delivery does not, the collection path is not yet ready for unattended fulfillment.

FAQ

Can a merchant accept only Card payments without configuring a Crypto wallet?

For a supported GOAT Card-only setup, a Crypto receiving wallet is not required. Card access, a ready connected Stripe account, and the deployment's payment configuration still apply. This is a seller setup option, not proof that every agent can autonomously use a card.

Does offering USD and token prices mean the platform converts between them?

No automatic conversion should be assumed. GOAT QuickPay documents a shared numeric product price for enabled Card/Crypto options without automatic USD-to-token conversion. Check that each enabled quote represents the intended value; a number such as five does not make every token equivalent to five dollars.

Must the agent create a customer account with my business?

Some public offers and paid resources can avoid a separate customer signup. That does not remove payment authority, protected-data access rules, delivery entitlement or recovery records. Choose an accountless path only when its supported authorization and retrieval model fits the product you are selling.