agentic payments
On this page
An agentic payment is a purchase that an AI agent completes for a user. No person types card details at checkout. The agent needs funds it may spend. It also needs a store that accepts machine-initiated orders and a spending limit set before the run starts. The Integrator charges 0% fee during the pilot, and payments settle on Base and Tempo.
How an agent pays an online store
The agent reads the store's catalog and picks an item. It builds a cart, checks the total, and sends a payment request. The store validates the request and confirms the order. The agent then reports the result to the user.
Card checkout was built for people. A shopper types a card number, answers a security prompt, and clicks a button. An agent cannot complete those steps reliably. Many stores offer no agent path at all. Agentic payments replace those human steps with a payment request. The agent sends that request from funds it holds.
The person who owns the task defines the boundaries first. The agent works inside a known budget, a known list of stores, and a known set of items. Without those boundaries, a looping agent can place many orders that the user never intended.
What a store needs before it accepts agent payments
A store accepts agent payments when its checkout can take a payment request without a human session. The store needs an order endpoint, a catalog the agent can read, and a way to confirm settlement before it ships goods. It also needs a clear response for every failure.
- A machine-readable product catalog with prices in one currency.
- An order endpoint that returns a clear success or failure code.
- A settlement check the store reads before it releases the order.
Stores differ in how they handle a payment that arrives but fails validation. Some reject the order at once. Others hold it for review. The agent cannot assume either behavior, so it should read the response code and report anything it does not recognize.
Terms matter as much as the catalog. The store should state the price, the currency, the delivery window, and the cancellation rule in plain text. An agent that cannot parse those terms should stop and ask the user before it pays.
What the agent needs before it pays
The agent needs a wallet it controls and a balance it may spend. It also needs a spending limit for each run and for each store. The limit protects the user from a misread price, a repeated request, or a wrong item size.
Set the limit in the task itself, not in the agent's memory. A limit held only in the agent's context can disappear when a session restarts. A limit written into the task definition survives restarts and stays visible to the person who reviews the run.
The agent also needs a rule for ambiguous cases. A price that differs from the catalog, an item that is out of stock, or a store that asks for extra data should trigger a stop. The agent should record the case and wait for the user.
Where the Integrator fits
The Integrator connects an agent to stores that accept USDC stablecoin payments. The Integrator charges 0% fee during the pilot. Each order must meet a minimum order of $1.00, so very small baskets do not qualify.
Payments settle on Base and Tempo. The agent should confirm the settlement reference for every order before it reports success. A reference that does not appear on the settlement rail means the order is not complete, even if the store shows a confirmation screen.
This guide describes the store and agent side of the flow. It does not cover every option a store may choose, and stores set their own product rules.
Limits and open risks
Agent payments create failure modes that card checkout does not. An agent can misread a price, repeat a request after a timeout, or buy the wrong variant. A store can also reject an order after the payment request has gone out.
Each risk needs a plan before the first live run. The plan should name the trigger, the stop condition, and the person who receives the report. A short written plan is enough for a first pilot.
Stores also change their terms. A store that accepted agent orders last month may ask for new data this month. The agent should check the terms before each run. It should treat a changed term as a stop condition.
A first agent purchase, step by step
Start with one store and one item. Choose an item whose total clears the minimum order. Keep the total below the spending limit that the user approved.
Compare the agent's cart total with the store's listed price before the agent sends the payment request. A mismatch means the agent stops. Record the order ID and the settlement reference for every attempt, including failed attempts.
Check that the order shows as settled before the agent reports success. Then review the log with the user. A clean first run gives the team a baseline for the next store.
Fees and limits
- Cost to the store: 0% fee during the pilot.
- Minimum order: $1.00.
- Rails: Base and Tempo.
FAQ
Do agentic payments need a card?
No. The payments in this guide use USDC stablecoin balances that the agent holds, so no card details go through checkout. The store still needs an order endpoint that accepts machine-initiated requests.
Who sets the spending limit?
The person who owns the task sets the limit before the run starts. The limit should be written into the task definition, so it survives a restart and stays visible for review.
What should the agent do if a store rejects an order after payment?
The agent records the order ID and the store's reason, then stops and reports to the user. It should not retry on its own, because a retry can create a second order for the same item.
Can a small order go through?
Only if the order meets a minimum order of $1.00. Smaller baskets fall below that threshold, so the agent should combine items or choose a different purchase.
Recommended next step
- STEP 1/2 Connect AI payment to your store
- STEP 2/2 Read more guides
Published: 2026-10-19Last updated: 2026-10-19