Protocol job
ACP structures the agent-to-business commerce flow
Stripe's agentic commerce documentation presents ACP as a way for businesses to support in-context selling through AI agents. The surrounding flow includes product or catalog information, checkout operations, payment handling, and order outcomes. That gives the agent a typed commercial interface and gives the business control over its products, pricing, acceptance, and fulfillment rather than turning the model into the merchant system of record.
ACP should be placed at the commerce layer. It can help move a selected product into checkout and return merchant state, but it is not itself universal proof of principal intent or a settlement rail. The business still verifies the customer or agent context it relies on, the platform evaluates delegated authority, and the payment provider or rail determines authorization and settlement status.
ACP can coordinate what the business is selling and how checkout progresses. It should not be treated as a substitute for mandate enforcement or rail verification.
Bind the checkout to the mandate before presenting payment
The agent should preserve product, merchant, quantity, amount, currency, fees, tax, fulfillment, and return terms as the checkout evolves. Before completion, freeze or canonically digest the exact commercial state and compare it with the principal's mandate. A price change, seller substitution, added fee, different delivery promise, or weaker refund term may require a new policy decision or human step-up.
A successful checkout response must remain distinct from payment and delivery. Record an idempotency key before the effect, preserve merchant and provider references, and retrieve status after uncertain responses. The business order, processor state, rail settlement, and fulfillment event are independent evidence sources. Join them in the receipt and reconciliation system instead of allowing one positive API response to declare the task complete.
| Artifact | Primary responsibility | Must not be assumed to prove |
|---|---|---|
| Catalog or product record | Describes an offered item | Merchant eligibility or user approval |
| Checkout state | Records commercial terms and buyer choices | Payment authorization or settlement |
| Mandate and policy decision | Constrains the exact purchase | Merchant fulfillment |
| Scoped payment token | Carries limited payment capability | That every order term matched intent |
| Order and receipt | Records acceptance and commercial outcome | That a refund reached the principal |
Use scoped credentials without exposing the underlying payment method
Stripe documents Shared Payment Tokens as a mechanism for passing limited payment capability from an agent to a business without exposing the underlying credential. Constraints can include the business, amount, currency, and expiration. This reduces credential exposure, but the issuer and business must enforce the actual limits. Descriptive constraints that no verifier checks are not a financial control.
The agent should request a token only after the exact checkout passes deterministic policy. Keep raw credentials and token-issuance secrets outside the model runtime, bind the token to the intended seller and transaction, and record issuance, presentation, denial, and use. If checkout terms change, do not ask the model whether the existing token is close enough; re-evaluate the order and obtain new authority where required.
- Release the narrowest seller-, amount-, currency-, purpose-, and time-scoped capability available.
- Separate customer and agent identity from possession of the payment token.
- Construct sensitive payment fields inside a trusted credential or adapter service.
- Rotate and revoke credentials independently of the commerce conversation.
- Return references and verification results to the agent instead of reusable secret values.
Make the merchant path observable, reversible, and portable
A merchant integration needs deterministic totals, stable product and order identifiers, idempotent completion, authenticated events, and explicit fulfillment, cancellation, return, and refund states. Support and finance teams need the same joined record as the agent: mandate reference, checkout version, payment attempt, settlement, order, delivery, and recourse. A conversational transcript is not an adequate operations ledger.
ACP and adjacent agentic commerce features can change over time or be offered under limited product availability. Pin the documentation, schema, and provider behavior used by the implementation; label test, preview, and production environments accurately; and avoid presenting one provider's support as universal interoperability. Keep a provider-neutral internal order and authority model so the organization can change adapters without rewriting prior receipts or business policy.
- Test changed carts, expired checkout state, duplicate completion, lost callbacks, and partial refunds.
- Reconcile merchant order, provider payment, rail settlement, and general-ledger records.
- Export mandate, decision, credential reference, order, and receipt evidence in durable formats.
- Define customer support ownership when agent, platform, business, and payment provider differ.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.