Accept Payments from AI Agents: A Merchant Implementation Guide

Begin with the channel and the product

A merchant does not accept an abstract AI payment. It accepts a particular payment attempt for a particular offer. The buyer may use an assistant to open an ordinary checkout, complete a supported shopping-channel flow or pay for an API resource. Your first decision is which of those journeys fits your product and customers.

Consider Cedar Research, a fictional merchant selling a downloadable report. In this teaching example the report's quoted product amount is $29, and the buyer permits a one-time purchase up to $35. The merchant needs to make the edition and license clear, calculate the payable amount and deliver access to the correct buyer. The amounts illustrate the workflow rather than a provider price or a transaction we executed.

Do not infer the payment route from the discovery route. An agent can find Cedar through search and send the customer to the website. Another agent can find a machine-readable paid endpoint and request access directly. Both interactions involve an assistant, but the merchant's integration and the customer's approval experience differ.

Compare three acceptance routes

A conventional card checkout can serve an agent-assisted buyer through the merchant's existing payment integration. The checkout still needs to present the correct purchase terms and complete any required customer interaction. Browser automation should not be treated as permission to bypass payment-provider controls or the buyer's approval.

A commerce-channel route exposes a defined checkout contract to the supported surface. In ACP, the merchant returns checkout session information and processes completion through the documented flow. The merchant's payment integration and order system remain significant parts of the architecture. The existence of that specification does not prove that a particular store is admitted to the channel. [1]

An x402 route fits a paid API or digital resource. Coinbase describes a request flow in which the buyer sees the price, pays and obtains access without a separate checkout page. Its facilitator verifies and settles payments. That payment flow is distinct from a full retail catalog, return policy or customer support workflow. [2]

Choose the route that the intended buyer can actually use and that your team can support. A digital endpoint may be a good fit for request-based payment. A store with complex shipping choices may benefit from an established checkout. Do not replace working purchase rules simply to describe the integration as agent-native.

Make the offer unambiguous and payable

Give the product a stable identifier and specify the deliverable. For Cedar, the agent needs the report edition, file format, license and delivery conditions. If there are separate personal and team licenses, expose them distinctly. An assistant should not have to infer the license from a marketing paragraph after payment.

Calculate the current total from authoritative merchant data. If the product amount is $29 and an illustrative applicable addition is $2, the checkout total is $31. That fits the buyer's $35 ceiling. If the amount changes to $36, the agent needs a new decision under the applicable authority rules. The arithmetic is simple, but the system still needs to compare the final terms at the right boundary.

Specify when the quote or reservation stops being valid. This can be your merchant implementation's rule rather than a universal protocol feature. The important operational question is what happens when an agent returns late: retrieve current terms, reuse an existing valid checkout or start a new one. Avoid silently collecting an old quoted amount for a changed product.

Know where the money should arrive

Before accepting payment, identify the merchant's receiving account or wallet through the chosen provider configuration. Verify the destination through an authorized operational process. Do not trust payment instructions copied from a product description or returned by a model as a substitute for your server's configured destination.

For a card route, understand the provider's payment object and its financial lifecycle. For an onchain route, understand the supported asset, network, destination and verification or settlement mechanism. Do not assume that a similarly named token on a different network pays the intended order. Provider-specific requirements should come from current documentation and account configuration.

Keep customer-facing amounts and accounting references consistent. If you offer different payment routes, clearly identify the currency or asset used in each quote. A dollar-denominated teaching example is not a promise that every provider accepts dollars or that every token payment has identical fees and settlement behavior.

Bind authority to the actual order

The buyer's instruction should describe the purchase scope. A one-time report order is different from a recurring data subscription. A $35 maximum is a limit, not a requirement to spend $35. If the assistant changes the seller, item or renewal terms, it must re-evaluate whether the existing authority applies.

Record an approval or policy reference alongside the appropriate checkout and payment references. Keep sensitive payment credentials in the provider-supported handling path. Support needs evidence explaining the action, not a raw card number or an entire personal conversation stored in an order log.

The merchant should also decide what to do when human interaction is required. An authentication challenge or changed purchase term may need the buyer to return. Provide an honest pending state and a specific next action. A bot should not turn a missing approval into a fabricated success message just to complete a task.

Verify the result before granting access

The order system should rely on the payment route's authoritative outcome. A successful HTTP response from an unrelated page or a chat message saying “paid” is insufficient. Check the appropriate provider result, signature or settlement information using the documented mechanism for that integration.

Then grant the entitlement for the purchased report. Keep the delivery reference connected to the original order so a retry does not create another charge. A verified payment with pending delivery is a recoverable state. A second purchase should not be the default answer to a broken first delivery.

For paid API responses, define the resource's result and error behavior before launch. If generating the report fails after payment, decide whether the existing purchase permits retrieval, regeneration or a support resolution. Communicate that behavior to the buyer. The payment protocol alone does not make the resource generation step succeed.

Treat timeouts as unknown outcomes

Imagine the payment completes and Cedar creates the order, but the agent loses the response. The safe next step is to retrieve the existing attempt through the supported interface. A new completion call should follow the documented retry behavior and preserve the original business operation. Do not create a new payment because the model cannot see the last response.

Use a stable reference for the business action and distinguish it from individual network requests. A request identifier helps trace one call; an order or attempt reference helps resolve the purchase. Your exact implementation can differ, but operators need to understand which retries represent the same intended action.

Event handling needs similar care. Verify provider events, deduplicate them as appropriate and avoid moving an order backward when an older update arrives late. Keep a recoverable exception when a payment and fulfilment record disagree. These are recommended implementation controls, not evidence that any provider has already configured them for your store.

Build the first acceptance record

For the Cedar example, the success record should identify the quoted report, its total, the applicable buyer authority, the verified payment reference and the delivered entitlement. The failure record should explain a specific unresolved step. Keep both narrow enough for a support operator to understand without reconstructing a long chat.

Test a changed price, an unsupported item, an expired checkout, a lost completion response and a delivery outage. Use safe provider-supported test methods. Write down the expected result first, including whether the agent stops, retrieves status or requests a human decision. This guide recommends those tests; it does not claim to have performed them for a named merchant.

Reconcile the accepted payment to the merchant account as well as to the customer order. A successful buyer-facing message does not show that your accounting records contain the correct net amount or reference. Keep the provider settlement or wallet transaction reference available to the appropriate operator, and record any actual fees separately from the order price. If multiple payment routes are offered, use a consistent order identity while preserving each route’s own financial evidence. This is an implementation recommendation, not a claim that every protocol supplies an accounting ledger.

• Illustrative receipt: order O-31; checkout C-31; report edition R-current; personal-use license; USD total $31; approval A-35; payment reference P-31; delivery entitlement E-31.
• Illustrative unresolved receipt: the same O-31 and P-31, with delivery pending and case S-31. No new payment is requested.

Add an agent-facing digital offer route where it fits

Agentify Commerce provides a catalog of digital offers and a USDC/x402 purchase route in which payment goes directly to the merchant wallet. It links digital orders with payment and delivery and provides separate test and live routes. Those capabilities make it relevant to Cedar's digital report scenario, custom stores and eligible connector work.

Agentify is affiliated with this guide. Apply the same requirements to it as to any other option: the offer must be accurate, the authority must fit, the payment record must be traceable and the buyer must receive the promised digital output. This description does not imply support for physical shipping, every currency or every shopping channel.

Use the checklist to assign remaining work, then launch one bounded product and route. Expand after you can explain both successful orders and exceptions. Accepting an agent payment is useful when it produces an accountable purchase outcome for the buyer and the merchant, rather than an isolated payment confirmation with no delivery path.