How to Sell Products to AI Agents With Offers and Payment Links

An agent sends a payment for your product. Your wallet receives the funds. Can you deliver the order? Not necessarily: you may still lack the selected variant, the delivery recipient, or a reliable connection between that transfer and the item being purchased.

To sell products to AI agents, give compatible buyers a clear product offer, a supported payment path, and an order-confirmation process that connects verified payment to delivery. A fixed-price offer can use a hosted product link instead of a new storefront. A changing cart still needs merchant-controlled pricing, and neither route removes your responsibility for fulfillment.

The agent may complete the purchase within its user's spending permissions, or hand checkout to a person for approval. Your offer should work with that boundary rather than assume that every assistant has a funded wallet and unrestricted purchasing authority.

For an existing seller, the useful starting point is one offer that can be purchased and delivered reliably. Keep your website, catalog, and order system where they are. Change the buyer's access to the transaction only where it is needed.

Give the agent an offer it can commit to

A product description tells a buyer why an item is attractive. A purchasable offer must also say exactly what committing to it means. An agent cannot safely turn “premium access available” into a particular license, account entitlement, or service appointment without additional terms.

Start with a stable product identifier. Names change, images are replaced, and an agent may retrieve an older description. The identifier should continue to point to the intended item or variant, while your current terms define what is available now. If two sizes or license tiers lead to different delivery outcomes, do not rely on prose alone to distinguish them.

Consider a hypothetical seller offering a downloadable report. The seller could define the offer this way:

This is an offer-design example, not a payment provider's API schema. License terms, customer identity, and delivery access belong to the merchant's business system. The payment record must be associated with them; it does not create them automatically.

The recipient distinction matters even for a simple download. A wallet address identifies a payer, but your customer may want access in a different account or may be buying for a colleague. Resolve that relationship through an authenticated account or another appropriate merchant process before releasing a private file. An arbitrary payer memo should not grant access to someone else's account.

Make the same terms available to humans and machines. If the agent-readable description promises permanent access while the checkout page sells a monthly entitlement, the problem is an inconsistent offer, not inadequate payment automation. Keep product scope, availability, delivery conditions, and exception handling aligned at the source.

Choose the smallest payment surface

A fixed offer and a dynamic cart have different pricing needs. Use that distinction to decide how much commerce infrastructure you actually need to add.

GOAT Flow QuickPay Products are a documented fixed-price option. The merchant defines a product identifier and a positive decimal price; the buyer or agent selects an eligible chain and token. The product-bound session supplies the authoritative payment amount. Hosted QuickPay does not require merchant API keys just to open the payment experience. These capabilities are described in the current GOAT Flow Merchant Guide.

For a creator with one clearly defined product, this can remove the need to build a new catalog UI, wallet connection, and checkout page. It does not mean that account approval, receiving-address configuration, or delivery operations disappear. The guide requires an enabled merchant, QuickPay capability, an eligible receiving token, and the deployment's fee and limit configuration. Check those conditions in your account before announcing an available payment method.

A dynamic cart needs a different approach. Suppose the price changes with quantity, shipping destination, a discount, or customer eligibility. Your backend should compute the final amount and create an authenticated Checkout Session. The buyer opens an opaque checkout handle rather than supplying the authoritative price from the browser. GOAT Flow's Hosted Checkout documentation distinguishes this route from fixed products and buyer-entered amounts.

That is still compatible with keeping your existing storefront. You can add a checkout handoff to the cart or quoting process you already operate. The important addition is a trustworthy purchase session, not another set of marketing pages.

Custom-amount links are a poor substitute for fixed-product pricing. They make sense for tips, donations, or other amounts the payer is entitled to choose. If a report costs a merchant-defined amount, receiving a buyer-chosen transfer does not establish that the report was fully paid for. Use a fixed product or an authoritative session when payment must satisfy a particular offer.

The tradeoff is concrete: a hosted fixed offer reduces integration work, but it cannot take over business rules that change the payable total. Choose the smaller surface only when the product's terms genuinely fit it.

Make the offer reachable without granting authority

A payment link is an entry point. It is not a guarantee that shopping assistants will discover your product, recommend it, or know how to pay it.

For GOAT Flow QuickPay, the current merchant guide documents a public payment page, an agent.md guide, and a manifest.json capability surface. The manifest lets a compatible client inspect published products and accepted payment configuration. Copy the public links from the target Merchant Portal and check them while signed out. Do not construct a supposed production link by substituting a hostname in a test link.

Your existing product page, documentation, or customer communication can point to that entry point. Keep the product identifier and offer description consistent with the public payment surface. An agent arriving through an old page should still be able to fetch fresh terms rather than pay from a cached price or a screenshot.

Discovery and payment authorization remain separate. The public offer can tell an agent what is available; the buyer's policy decides whether it may buy. A compatible agent may need to check the merchant, total spend, asset, network, and approval requirements before authorizing a transfer. If its permissions stop at comparison or cart preparation, retain a human checkout handoff. Do not interpret lack of autonomous payment as lack of purchasing interest.

GOAT Flow's current public merchant path uses DIRECT ERC-20 transfers: the payer sends the instructed token amount to the merchant-configured receiving address, and Flow observes and matches the transfer. This is not an escrow release or a later merchant payout. Supported assets and limits depend on the active deployment and merchant configuration, so a token symbol alone is insufficient to determine where or how to pay.

The surrounding names describe different layers. x402's HTTP payment documentation explains how a service communicates payment requirements through HTTP 402. x402 is part of an open ecosystem, not exclusive to GOAT, and payment requirements do not replace a product catalog or delivery system. GOAT AgentKit is the agent developer SDK and runtime/action layer; GOAT Flow is the merchant commerce product. Using a Flow product link does not mean rebuilding your business around AgentKit.

Public buyer access must never include your merchant API secret. A buyer needs published capabilities and current payment terms, not permission to change receiving addresses, create arbitrary merchant-priced orders, or access private records. Keep authenticated merchant operations on your backend.

Keep price and availability under merchant control

An agent can read an accurate offer and still reach payment after its terms have changed. Stock may sell out, a promotional price may expire, or a selected destination may require a different delivery charge.

For a fixed QuickPay product, use the server-owned product price and the fresh product-bound session amount, not a price the agent has copied into its own message. The documented client checks the amount against the product price and selected token decimals before broadcast. That protects the payment calculation; it does not resolve your inventory, licensing, or shipping rules.

For a variable order, make the backend quote the authority. Bind the final payable amount to the selected item, quantity, delivery conditions, customer reference, and expiry in your own records. If the offer changes materially, return revised terms for approval rather than silently substitute a different item after payment.

A hypothetical physical-goods seller illustrates the difference. A mug may have a fixed base price, but two mugs sent internationally can have a different total from one collected locally. If the agent knows only the base price, it cannot infer the correct delivered order. The merchant needs to collect the relevant destination and variant, calculate the total, and issue a purchase session against that quote.

Before accepting payment, decide how stock is reserved. A temporary reservation may reduce the chance of taking money for an unavailable item, but unpaid sessions can also tie up stock. Use a bounded reservation appropriate to your order process, and decide what happens if funds arrive after it expires. These are merchant design choices, not promised QuickPay inventory features.

Do not let a payer memo become the entire order contract. Free text can help reconciliation, but “blue mug, express delivery” does not prove that the seller agreed to that variant, shipping service, or price. Store accepted selections in the merchant order record and associate the payment with that record.

Keep sensitive delivery information out of public offer metadata. An agent-readable catalog needs enough detail to evaluate a product, not every customer's shipping address or private account identifier. Gather customer-specific data through the authenticated or appropriately protected path your business uses, and expose only what the buyer needs for that purchase.

Confirm the payment then authorize delivery

The most consequential boundary is on the merchant side. A browser reports success, a wallet displays a transaction hash, and a session page changes state. None of those observations alone tells your delivery system to release a product.

Read payment status through a trusted backend call or an authenticated webhook. For a webhook, confirm the active deployment's event, payload, signature rules, replay protection, and retry behavior before using it. A familiar event name or a JSON field saying “paid” is not authentication.

Then compare the payment evidence with the expected order. Verify the merchant and order identifiers, chain, token contract, amount, receiving address, and transaction identity. Checking only the amount is inadequate: the right number sent in the wrong asset or to a different address does not satisfy the intended purchase. Confirm that the payment maps to the product and recipient your system accepted.

Keep the status models distinct. The current Flow guide lists PAYMENT_CONFIRMED and INVOICED as successful order states for server SDK waiters; a poller may observe INVOICED without first seeing PAYMENT_CONFIRMED. QuickPay session states are separate, and Hosted Checkout has its own lifecycle. Do not make a merchant order wait for a status name that belongs to a different object.

Your business needs a further distinction: paid is not fulfilled. A verified transfer can precede a failed license grant, an unavailable shipment, or a delivery job that has not run yet. Record payment verification and fulfillment progress separately so support can identify what remains owed to the customer.

Make delivery idempotent: repeated evidence for the same purchase must not deliver twice. A practical merchant design stores the payment/order association durably, records a unique fulfillment operation, and lets a worker resume that operation after a failure. For a digital entitlement, repeated processing should find the same access grant. For a shipment, the retry should find the existing dispatch request rather than create another parcel.

External delivery services can fail after accepting a request but before returning a response. Where supported, reuse a stable operation reference and query the delivery service before attempting another dispatch. A local “processing” flag alone cannot prove whether a remote shipment or license issuance happened. If that outcome remains uncertain, hold it for reconciliation instead of guessing.

Also distinguish payment records from cryptographic attestations. The current merchant guide states that the historical signature field in getOrderProof() is an unsigned digest and does not cover status. Do not treat its field name as proof of signed fulfillment authority. Where independent transaction proof is required, inspect the transaction on-chain and validate the relevant transfer details.

Recover uncertain purchases without charging twice

Agent purchases need a recovery path because network failure can interrupt observation after money has already moved. A timed-out status poll is not evidence that no payment was sent.

If the buyer has broadcast a transfer, preserve the purchase intent, session or order reference, and transaction hash. Resume checking that existing transfer. Do not create a new payment simply because the browser closed or the agent lost its response. GOAT Flow's current payer guidance calls for reusing the same idempotency key for retries of a QuickPay intent and warns against rebroadcasting solely because polling or verification failed.

The merchant has a matching responsibility. A retrying buyer or duplicated webhook should reach the existing purchase record. If the order is already fulfilled, return its recorded outcome. If payment is verified but delivery failed, resume delivery recovery rather than ask the customer to pay again.

Late payment requires a different decision. The Flow guide documents reconciliation views for matched, unpaid, and late payments. A transfer arriving after expiry may be real money, yet the original quote or stock reservation may no longer be valid. Put that case into a review path: check whether the original offer can still be honored, and resolve delivery or refund through your actual support process. Do not automatically fulfill against expired terms or label the funds nonexistent because the session expired.

For a mismatched asset, recipient, or amount, stop automatic fulfillment and inspect the evidence. A transaction hash supplied by the buyer is a useful lookup reference, not a verdict. Explain the discrepancy without asking the agent to send another transfer until the existing one is understood. Some mistakes may require manual handling; a product link does not guarantee recovery from every wrong-chain or wrong-address transfer.

Refunds also need an explicit merchant policy and workflow. Do not describe a DIRECT transfer as a held balance that Flow will automatically release or reverse. Validate the purchase and recipient through a trusted support process, record any refund transaction against the order, and keep its outcome separate from the original sale. Those are operating recommendations, not an assertion of an automatic refund feature.

Automatic delivery is useful when the offer and evidence are unambiguous. Manual review is slower but appropriate when a payment cannot be bound safely to current terms or the delivery outcome is uncertain. Treat review as an exception path with an owner, not an unexplained permanent pending state.

Launch one offer with an observable delivery path

Begin with a product whose scope, price, and delivery can be stated without negotiation. A digital item can be suitable if account access is already well controlled; a physical item can work if stock and delivery terms are settled before payment. The selection criterion is operational clarity, not whether the product sounds “agent-native.”

Check the public path while signed out. The product should be visible with the correct identifier and terms, and the copied payment, agent-guide, and manifest links should resolve on the intended origin. Confirm the receiving configuration and eligible payment options in the target account. Publishing readable files is not enough if the account cannot create the intended purchase session.

Before opening automatic delivery, run an environment-appropriate purchase through the actual integration. Separately verify payment matching, recipient binding, delivery, and the order reference returned to the buyer. Test a repeated notification and an interrupted status check. Also exercise an expired quote and a payment that cannot be matched to the intended offer. These are readiness tests to perform, not evidence that your deployment has already passed them.

Keep test and production records separate. Mainnet and Testnet3 credentials, receiving addresses, merchant identifiers, and webhook configuration must not be assumed interchangeable. Validate production delivery and authentication under controlled conditions before removing launch restrictions; success in a test environment does not establish production availability.

Finally, observe the whole purchase. Record whether the offer was reached, a session was created, payment was verified, and delivery completed. A rise in payment attempts does not show that customers received usable products. Conversely, an assistant that hands a valid checkout to a human may still be completing a useful buying journey.

You are ready to expand when one offer has a reliable answer to each operational question: what was agreed, who authorized payment, which transfer satisfied the purchase, and what was delivered. Until then, another storefront or a larger catalog would multiply the unresolved cases rather than make the product more buyable.