MENU
AI is already changing how consumers discover and evaluate products online. Adobe Digital Insights found that 39% of surveyed consumers had used AI for online shopping, while AI-referred traffic to U.S. retail sites grew substantially year over year in early 2026. Its analysis of AI traffic to retailers also highlights a broader shift: retailers increasingly need product, pricing, and commerce information that software can interpret as easily as people can.
The next stage extends beyond assisted discovery. Deloitte describes agentic commerce in retail as a progression toward systems that can search, compare, decide, purchase, and eventually transact with other agents. Monetizing that activity requires more than adding payments to a shopping assistant. Platforms need clear commercial units, machine-readable terms, bounded spending authority, reliable completion rules, and payment infrastructure that connects autonomous purchasing with seller revenue.
Agentic commerce spans several parts of the buying journey.
A shopping assistant may help consumers research products. A retailer platform may expose inventory to autonomous agents. A commerce agent may complete the purchase itself. Infrastructure providers may monetize the APIs, data, or services used throughout that workflow.
Each product creates a different commercial unit.
Potential revenue-generating events include:
The platform does not need to expose every internal activity as a customer-facing charge.
A shopping agent could make dozens of catalog queries, compare several sellers, calculate shipping, and check availability before placing one order. The provider may still choose to charge for the completed shopping workflow rather than every underlying API call.
Internal metering can remain granular while customer-facing pricing stays understandable.
Every billable event needs an explicit completion rule.
For transaction pricing, completion might mean successful order acceptance. For a research workflow, it could mean delivery of the requested comparison. For a merchant API, it may be a valid response from a protected endpoint.
Platforms should also define how they handle:
These distinctions prevent technical activity from automatically becoming billable activity.
Agentic commerce products operate at different levels of the customer journey, so one pricing model rarely fits every service.
The right structure should reflect what the platform controls and what customers recognize as valuable.
Recurring pricing works when customers continuously use an AI shopping service or merchant platform.
A subscription could include:
Subscriptions create predictable spending for customers and recurring revenue for providers.
The challenge is workload variation. One user may perform a handful of searches while another continuously monitors prices, compares products, and initiates purchases.
Included usage, credits, or overages can help accommodate that difference.
Usage pricing connects charges to measurable activity.
Possible units include:
This structure is especially relevant for infrastructure sold to developers, merchants, or other autonomous services.
The main challenge is predictability. An agent may decide to query more sellers, compare additional products, or retry parts of the workflow.
Budgets, prepaid balances, and usage limits can keep that activity within an approved financial range.
Commerce platforms can charge when a purchase is successfully completed.
This closely connects revenue with transaction activity and can be intuitive when the service directly participates in checkout or order execution.
It also requires clear rules around:
The provider should determine when the transaction becomes billable rather than assuming every authorization represents final revenue.
Some commerce services create value without operating the final checkout.
A platform might charge for:
Workflow pricing charges for completion of the task.
Outcome pricing can go further by connecting payment to a verified result. It works best when success can be measured objectively and both parties agree on attribution.
Credits provide a useful common unit when a platform contains several paid activities.
A basic product lookup might consume one credit, a deeper comparison several credits, and a complex sourcing workflow more.
Platforms can combine credits with other multiple payment models, such as:
The payment structure can then follow the value and resource intensity of the service rather than forcing every interaction into a single pricing model.
A shopping agent cannot reliably purchase a product when critical commercial information exists only inside a human-oriented storefront.
Relevant information may include:
The objective is not simply to make catalog information searchable. The agent needs enough commercial context to determine whether it can complete the purchase under the user's instructions.
An agent may be allowed to search products without being allowed to buy them.
A production system should distinguish between:
A search credential should not automatically provide financial authority.
Likewise, access to a payment source should not automatically grant permission to use every merchant, product, or paid service available to the agent.
Autonomous commerce requires agents to make some financial decisions without seeking human approval for every purchase.
That does not require unrestricted access to the user's money.
A safer architecture delegates specific authority in advance.
Useful controls include:
A set of card delegation controls can define a finite spending ceiling, duration, optional transaction limits, and revocation.
The underlying card information can remain tokenized while the autonomous system receives only the payment capability required for the approved transaction.
The goal is autonomous execution inside a financial policy the owner has already established.
Retailers are not the only businesses that can generate revenue from agentic commerce.
Shopping agents themselves consume paid digital services while completing tasks.
Examples include:
Those providers need a seller-side monetization model.
A payment and entitlement layer can validate whether the requesting agent has the required payment plan or entitlement before the protected service executes.
This becomes particularly important when fulfilling the request has a meaningful cost.
A provider should not run an expensive model, data query, or search workflow and only afterward determine whether the requesting agent was authorized to consume it.
Payment should remain connected to the product or service being purchased.
For a paid machine-readable service, a practical flow is:
This sequence connects commercial authorization with delivery rather than treating payment as a separate process after the work is already complete.
For services sold directly to autonomous systems, infrastructure for monetizing AI agents can connect programmatic access with pricing and settlement.
The provider still defines the commercial unit.
A product-intelligence API might charge per request. A sourcing service could consume credits. A continuous monitoring product might use time-based access.
Agentic commerce will not use one funding method for every transaction.
A shopping agent purchasing from an established retailer may need a card. A machine-to-machine API may use stablecoins or prepaid credits. A subscription service may rely on an existing entitlement.
Possible funding methods include:
The payment rail should follow the commercial model rather than define it.
A low-value product-data query and a high-value retail purchase have different economics, customer expectations, and risk profiles.
Existing fiat payment patterns can support card-funded workflows, while stablecoin payment patterns provide another path for machine-readable onchain settlement.
The same commerce platform can therefore use different rails for different transaction types without forcing every service into the same funding model.
Transaction volume alone does not show whether an agentic commerce product is profitable.
A shopping workflow may trigger several costs before a purchase is completed.
These can include:
Platforms should connect those costs to the commercial event that produced the revenue.
Useful metrics include:
A commercially successful purchase can still produce poor unit economics if the agent consumes more paid resources than the platform's fee covers.
Providers should therefore monitor revenue and fulfillment cost at the same level used for pricing.
Decide whether the platform monetizes discovery, shopping-agent access, merchant APIs, transactions, paid workflows, or infrastructure.
Keep the commercial unit clear.
Define the event that makes the transaction billable.
Document how failed requests, cancellations, refunds, retries, and partial completion are handled.
Expose prices, accepted payment methods, access requirements, completion conditions, and relevant limits in a format autonomous software can interpret.
Use subscription, usage, transaction, workflow, credit, or hybrid pricing according to the service.
For variable workloads, dynamic payment models can connect charges to request complexity, token consumption, or another provider-defined metric.
Set the maximum spend, duration, transaction count, and funding source an autonomous agent may use.
Keep financial authority separate from normal application access.
Verify entitlement or payment authority before performing protected work, then meter and settle after the operation reaches its defined completion state.
Track revenue, fulfillment cost, agent spending, refunds, and external service costs at the same level used for pricing.
Nevermined provides payment infrastructure for both sides of agentic commerce: services that need to get paid and agents that need permission to spend.
A commerce platform can retain its catalog, recommendation engine, order management, checkout experience, and fulfillment systems while using Nevermined for the commercial controls surrounding paid machine interactions.
Relevant capabilities include:
The seller side determines whether a caller has the payment plan or entitlement required to receive a paid service.
The buyer side determines how much an agent may spend and which funding source it can use.
Keeping these functions separate is useful because the shopping agent, merchant, and paid third-party service may all belong to different organizations.
A commerce platform can therefore monetize its own services while also letting its agents purchase outside resources under bounded authority.
Different commerce resources can have different economics.
A product-data API may charge per request. A premium sourcing agent might use credits. A recurring monitoring service may use time-based access. A more expensive workflow can calculate the charge dynamically according to the work completed.
Nevermined payment plans keep those pricing and entitlement rules attached to the service being sold rather than forcing the entire commerce platform into one billing model.
Agent purchasing should operate under explicit financial limits.
Card delegations can establish a maximum amount, validity period, and transaction count before the agent starts spending. Buyer-side routing can apply a separate hard budget when an agent pays compatible external machine services.
The payment authority remains distinct from the agent's general application permissions.
This allows users and organizations to support autonomous purchasing without surrendering unrestricted control of the underlying funds.
Seller-side paid access and buyer-side spending both create transaction records that need to be reconciled.
The commercial record should identify which agent initiated the transaction, what service was purchased, which pricing rule applied, how much was charged, and whether settlement completed.
This creates a clearer bridge between the technical workflow and the financial system supporting it.
Agentic commerce platforms can monetize subscriptions, API usage, transactions, premium workflows, merchant services, credits, or combinations of these models. The right structure depends on where the platform creates value in the shopping journey. A recommendation service may monetize access or usage, while a platform directly involved in purchasing may use transaction or workflow pricing. The commercial event should be defined before selecting the payment rail.
Agents can transact using delegated authority rather than receiving the underlying card credential. The owner can define a maximum spending amount, validity period, and transaction count before autonomous purchasing begins. A set of card delegation controls can enforce those boundaries while keeping the underlying payment data separated from the agent. The authority can also be revoked when it is no longer required.
No. Autonomous commerce can use cards, stablecoins, prepaid credits, subscriptions, or other supported funding mechanisms. Cards fit existing merchant infrastructure, while stablecoins can work well for machine-readable onchain services. Different fiat payment patterns and stablecoin payment patterns can support those separate transaction types. The appropriate rail depends on transaction size, customer preference, and settlement requirements.
Autonomous systems frequently retry requests after network errors or timeouts, so payment infrastructure needs a reliable way to identify the same logical transaction. Stable transaction identifiers and idempotency controls can prevent a retry from becoming a second purchase. Payment records should also connect the transaction with the responsible agent, service, and original request. This becomes particularly important when no person reviews every individual charge.
Agents need machine-readable information about products, prices, availability, variants, payment conditions, fulfillment, and completion status. They should also be able to determine which credentials or entitlements are required before requesting a protected service. A payment and entitlement layer can connect those commercial access rules to the machine-readable resource. The goal is to let software understand the transaction without relying on a human-oriented checkout flow.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
