Agentic commerce for Salesforce merchants: what to build when the buyer is an agent

A customer asks ChatGPT for “a waterproof shell jacket under $200 that ships before Friday,” and three products come back with a Buy button. They tap it, confirm, and the order lands in your Order Management System — except the customer never saw your storefront, never hit your search bar, never touched the funnel your team spent a decade tuning. The buyer, in the moment that mattered, was an agent reading a machine surface you either exposed or didn’t.

That is not a 2027 thought experiment. OpenAI shipped Instant Checkout in ChatGPT on September 29, 2025 and open-sourced the protocol behind it the same day. On July 6, 2026, Salesforce made Agentforce Commerce generally available with three named agents and native ChatGPT integration, and put Google Search and the Gemini app on the near roadmap. The shift is real, it’s here, and it changes the unit of commerce work from “optimize a page a human looks at” to “expose a surface a machine can read and transact against.” This post is about those surfaces — what they are, what you have to stand up, how an agent is allowed to pay, and where Agentforce actually sits in the stack.

The storefront splits into two machine surfaces

For twenty years the job was singular: get a human to your site and move them down a funnel. Agentic commerce splits that job in two, and both halves now live off your domain.

The first surface is discovery — being findable and rankable inside someone else’s assistant. The second is transaction — being buyable without the shopper ever leaving that assistant. Concretely, that maps to two artifacts you own and maintain:

1. A product feed that an agent’s index ingests, so your catalog can surface in a conversation.
2. A checkout API the agent calls to build a cart, price it, and complete an order against your systems of record.

Both are defined by the Agentic Commerce Protocol (ACP), the open standard OpenAI and Stripe co-developed and released under Apache 2.0. It is deliberately not a Salesforce thing — it’s a protocol any storefront can implement, and Salesforce is one of several platforms that support it. Understand the protocol first; understand where Agentforce automates it second. Teams that skip straight to “which Salesforce SKU do I buy” end up unable to reason about what they actually shipped.

The funnel didn’t get shorter. It got relocated to a runtime you don’t own. Your job is no longer to design the path to purchase — it’s to expose a surface clean enough that someone else’s agent can walk it without tripping.

Surface one: the product feed, which is your new SEO

The product feed is how your catalog gets into an agent’s shopping index. Under ACP it’s a structured file — the OpenAI feed spec accepts gzip-compressed .jsonl.gz, .csv.gz, or .xml.gz — pushed to a provided endpoint and refreshed on a cadence you control, as often as every 15 minutes for fast-moving inventory or daily for a stable catalog.

Each product is a record with a required core and a large recommended tail. The required fields are the ones that make price and availability correct; the recommended ones (rich media, reviews, performance signals) are what move you up the ranking. A single item looks roughly like this:

{
  "id": "SHELL-JKT-BLK-M",
  "title": "Storm Ridge Waterproof Shell Jacket - Black, M",
  "description": "3-layer waterproof-breathable shell, taped seams, packable hood.",
  "link": "https://store.example.com/p/storm-ridge-shell?variant=blk-m",
  "image_link": "https://cdn.example.com/img/storm-ridge-blk-m.jpg",
  "price": "189.00 USD",
  "availability": "in_stock",
  "brand": "Storm Ridge",
  "product_category": "Apparel > Outerwear > Rain Jackets",
  "enable_search": true,
  "enable_checkout": true,
  "seller_privacy_policy": "https://store.example.com/privacy",
  "seller_tos": "https://store.example.com/terms"
}

Two flags do the real work. enable_search decides whether the item can appear in an assistant’s results; enable_checkout decides whether it can be bought inside the conversation versus merely linked out to your site. That split is your control surface — you can be discoverable without being transactable while you decide how far to go. Titles cap at 150 characters and descriptions at 5,000, and price carries an ISO 4217 currency code, because the agent renders exactly what you send.

Here’s the practitioner reframe: the feed is SEO, except the ranking function is a black box inside a model provider and the “click” is an autonomous decision. Everything we’ve written about data quality as the thing AI amplifies applies with the volume turned up. A stale price or a wrong availability value in a page title annoys a human; in a feed it produces an agent that confidently sells something you can’t ship, and the failure surfaces as a canceled order and a burned first impression inside a competitor-adjacent chat. Feed freshness is not a nice-to-have. It’s the difference between the agent trusting your inventory and routing around it.

Surface two: the checkout API, where you become the source of truth

Discovery gets you into the conversation. The checkout API is what lets the agent close without handing the shopper off to your site — and it’s the part most teams underestimate, because it means standing up and operating a real, versioned, idempotent API that a third party drives.

The ACP checkout spec is a small, strict REST surface. The agent — not you — orchestrates the calls; you implement the endpoints and stay authoritative on everything that involves money:

POST /checkout_sessions              → create a session from items + buyer
POST /checkout_sessions/{id}         → update items, address, fulfillment choice
GET  /checkout_sessions/{id}         → read authoritative session state
POST /checkout_sessions/{id}/complete → finalize with payment; create the order
POST /checkout_sessions/{id}/cancel   → terminate if not already completed

A session moves through an explicit lifecycle — not_ready_for_payment → ready_for_payment → optionally authentication_required → in_progress → completed (or canceled). Every POST carries an Idempotency-Key header and a dated API-Version header, and every response returns the full, authoritative session state: line items, fulfillment options, and a totals array computed by you. Amounts are integers in minor units — cents, not dollars — so 189.00 USD is 18900. A trimmed response to a completed session:

{
  "id": "cs_9f2a...",
  "status": "completed",
  "currency": "usd",
  "line_items": [
    { "id": "li_1", "item": { "id": "SHELL-JKT-BLK-M", "quantity": 1 },
      "base_amount": 18900, "discount": 0, "subtotal": 18900,
      "tax": 1559, "total": 20459 }
  ],
  "totals": [
    { "type": "subtotal", "display_text": "Subtotal", "amount": 18900 },
    { "type": "fulfillment", "display_text": "Shipping", "amount": 0 },
    { "type": "tax", "display_text": "Tax", "amount": 1559 },
    { "type": "total", "display_text": "Total", "amount": 20459 }
  ],
  "order": {
    "id": "ord_5521",
    "checkout_session_id": "cs_9f2a...",
    "permalink_url": "https://store.example.com/orders/5521"
  }
}

The single most important architectural fact here: the agent never computes the cart. It proposes items and a shipping choice; you return the priced, taxed, inventory-checked truth on every call. Tax, promotions, real-time stock, carrier cutoffs, minimum-order rules — all of it stays server-side, on your side, exactly as it does in your own checkout. That’s the correct boundary, and it’s also the one that makes this tractable: you are not trusting a model to do arithmetic on money. You’re exposing your existing commerce logic through a new door. If your pricing and tax already live behind an API, you’re extending it. If they’re tangled into your web checkout’s front end, agentic commerce is the forcing function that finally makes you separate them.

The part that scares everyone: how the agent is allowed to pay

Letting an autonomous agent spend a customer’s money is the objection every commerce lead raises first, and correctly. The answer isn’t “trust the agent.” It’s a delegated-payment model where the agent never holds anything reusable.

On the ChatGPT/ACP path, Stripe’s mechanism is the Shared Payment Token (SPT). An SPT is a scoped, time-bounded, amount-bounded credential the shopper issues to the agent for one purchase. It is locked to a specific seller, capped at a specific amount, and expires at a fixed time, with all three constraints enforced server-side by Stripe. The customer’s real card details are never exposed to the agent or to you — they stay tokenized inside Stripe. At complete, the agent hands you the token in payment_data; you charge it through Stripe (or another PSP) exactly as you’d charge any tokenized instrument, and if the issuer demands 3D Secure the session returns authentication_required and the flow re-completes with the authentication result. Every token exposes lifecycle events — created, authorized, charged, expired, revoked — so the shopper, the agent platform, and you all see the same state.

The mental model that makes this click: an SPT is closer to an OAuth scope than to a saved card. A vaulted card is a long-lived asset; an SPT is a short-lived contract for one transaction with one merchant. That reframing is what should let your risk team sleep — the blast radius of a leaked SPT is one capped purchase at one seller before it expires, not a reusable card number.

There is a competing camp, and if you sell across channels you’ll likely meet both. Google’s Agent Payments Protocol (AP2), announced September 2025 with 60-plus partners including Mastercard, PayPal, American Express, and Salesforce, takes a mandate-based approach: every agent purchase is three cryptographically signed Mandates — an Intent Mandate (what the user authorized), a Cart Mandate (what the agent assembled), and a Payment Mandate (what gets charged) — carried as W3C Verifiable Credentials. It solves a problem ACP mostly sidesteps: giving card networks a way to prove an agent acted within an explicit, user-signed scope, with non-repudiable evidence after the fact. AP2 also treats bank rails and stablecoins as first-class, though its card-based path is still maturing while its crypto extension is further along.

Don’t let the standards war paralyze you. ACP is what’s live in ChatGPT today and what Agentforce Commerce integrates with now; AP2 is where the payment networks are pushing for auditable authorization. The pragmatic read for 2026: build to ACP because it transacts real orders today, and watch AP2 as the settlement-layer standard your finance and risk stakeholders will eventually ask about by name.

Where Agentforce Commerce actually fits

Everything above is protocol, not product — you could implement ACP by hand against any storefront. What Salesforce sells is the platform that generates those surfaces from data you already keep in Commerce Cloud, plus a set of agents that operate on them. Salesforce announced ACP support with Stripe in October 2025, so an Agentforce Commerce merchant can offer Instant Checkout in ChatGPT without hand-rolling the checkout endpoints, and it’s an AP2 launch partner on the payments side.

The July 2026 GA introduced three agents, and the naming is worth getting right because they do genuinely different jobs:

• Shopper Agent runs the buyer-facing conversation on your own storefront — discovery through checkout and into post-sale service — checking live inventory, confirming carrier cutoffs, and offering store pickup inside a single thread. This is your storefront getting an agent, distinct from the external ChatGPT surface.
• Buyer Agent targets B2B, meeting buyers inside WhatsApp and SMS so procurement can happen through messaging without a portal login.
• Merchant Agent is the back-office one: it lets your team manage catalogs, adjust promotions, and respond to trends in natural language. This is the agent that quietly maintains the feed and merchandising the other two depend on.

All three sit on the stack we’ve mapped before: Commerce Cloud for the transactional core and Data 360 for the grounding and real-time signals. That dependency is the line item that ambushes commerce buyers — the agent licensing looks self-contained until you price the Data 360 footprint underneath it, and a live storefront generating a stream of clickstream and inventory telemetry is not a small one. Read the honest dependency map before you commit a number; a commerce deployment is exactly the profile where the Data 360 bill outweighs the Agentforce line.

The gotchas nobody puts on the announcement slide

Agentic commerce is real and the direction of travel is clear. It also arrives with trade-offs the launch posts skip, and these are the ones we’d raise in a planning session:

You are disintermediated by design. When the purchase completes inside ChatGPT, you lose the merchandising surface — no cross-sell module, no “customers also bought,” no analytics on your own domain for that session, and a ranking function you can’t inspect or A/B test. Salesforce reports strong numbers for agent-referred traffic (it cites AI-referred traffic converting at several times the rate of social), and that upside is real, but the strategic cost is that you’re now a line item in someone else’s interface. Model both sides before you flip enable_checkout on your whole catalog.

Service and returns stay entirely yours. The agent closes the sale; it does not own the relationship after. A return, a warranty claim, a “where is my order” — those route back to your Service Cloud and your Order Management, and the customer who bought through a chat still expects you to handle the aftermath. Budget the post-sale load; it doesn’t shrink because acquisition got automated.

Two standards may mean two implementations. ACP for the OpenAI ecosystem and AP2 for the payment-network path are not interchangeable, and if you need both surfaces you’re maintaining both integrations. Scope that as real engineering, not a checkbox.

The agent’s output flows into your systems. A checkout session driven by a third-party agent is untrusted input reaching your pricing, inventory, and order logic. Everything in our least-privilege guide for agents applies: validate every field, never let agent-supplied data set a price, and keep the trust boundary explicit. The Idempotency-Key requirement is not bureaucracy — a retried or replayed complete call must never double-charge or double-ship.

A chatty commerce agent burns credits. Agentforce meters on Flex Credits or conversations — a standard action runs 20 credits, about $0.10 at the $500-per-100,000 rate. A Shopper Agent that checks inventory, prices a cart, verifies a cutoff, and confirms an order is firing several actions per conversation, and the external ChatGPT checkout is running its own steps on top. The per-action cost is trivial until you multiply it by peak-season conversation volume. Turn on per-action visibility before you scale, not after the invoice.

What to actually do this quarter

Start with the feed, because discovery is the cheap half and it’s reversible: publish a clean, fresh product feed with accurate price and availability, set enable_search on, and leave enable_checkout off until you’ve decided how far into transaction you want to go. That alone gets you findable inside the assistants your customers are already using, at low risk.

Then treat the checkout API as a first-class product surface, not a plugin. Whether you hand-roll ACP or let Agentforce Commerce generate it, the discipline is identical: you are the source of truth for every number, amounts are integers in minor units, idempotency is enforced, and payment arrives as a scoped delegated token you never mistake for a stored card. Instrument the whole path — feed freshness, session completion rates, credit burn per conversation — before peak volume, because the failure modes here are quiet. A wrong availability value or a dropped idempotency key doesn’t throw an error you’ll notice; it produces a canceled order or a duplicate charge inside a conversation you never saw.

The storefront isn’t going away. But for a growing slice of your customers, the first and last thing they touch is an agent, and the surface you expose to it is now the storefront. Build it like one.

Understanding the basics

What is the Agentic Commerce Protocol?

The Agentic Commerce Protocol (ACP) is an open standard, co-developed by OpenAI and Stripe and released under the Apache 2.0 license in September 2025, that defines how AI agents and merchants complete a purchase on a shopper’s behalf. It has two main surfaces: a product feed specification for making a catalog discoverable inside an assistant, and a checkout specification — a REST API of /checkout_sessions endpoints — that lets an agent build and complete an order against the merchant’s systems. It’s the protocol behind ChatGPT Instant Checkout, and Salesforce’s Agentforce Commerce supports it.

How does an AI agent pay without exposing card details?

Through delegated payment. On the ACP path, Stripe issues a Shared Payment Token (SPT): a scoped, single-purpose credential the shopper grants to the agent that is locked to one seller, capped at a set amount, and time-limited, with those constraints enforced server-side. The real card number is never exposed to the agent or the merchant. The merchant charges the token like any tokenized instrument. Google’s AP2 takes a different route — three signed Mandates carried as verifiable credentials — designed to give payment networks cryptographic proof the agent acted within the user’s authorized scope.

Do I need Agentforce Commerce to sell through AI agents?

No — ACP is an open protocol, so any storefront can implement the feed and checkout endpoints directly against its own systems. What Agentforce Commerce provides is a Salesforce-native way to generate those surfaces from your Commerce Cloud catalog and operate them with purpose-built agents (Shopper, Buyer, and Merchant), so you don’t hand-roll the integration. The trade-off is the underlying stack: Agentforce Commerce runs on Commerce Cloud and Data 360, and the Data 360 footprint is usually the larger cost line in a commerce deployment.

---

Standing up an agent-readable commerce surface — a clean product feed, an ACP checkout that stays the source of truth, delegated payment your risk team will actually sign off on? Talk to us. Getting the protocol boundary right before peak season is exactly the kind of work we do.