Teaching agents to pay — Anna Spysz, Stripe
Agent checkout needs more than payment tools: enforce user-set limits outside the agent, expose structured merchant data, honor cancellation, and log every decision.
The demo uses **UCP** as a shared interface for agents and merchants. Stores expose a capabilities manifest and structured catalog; checkout uses a **shared payment token**, so the agent receives a token rather than the raw card number.
Put spending and token validity checks at the payment provider, not inside a prompt. Also disclose the agent, show fees, honor stop or cancel, reject totals above the user's maximum, avoid pressure tactics, and keep auditable decision logs.
The demo uses **UCP** as a shared interface for agents and merchants. Stores expose a capabilities manifest and structured catalog; checkout uses a **shared payment token**, so the agent receives a token rather than the raw card number. Put spending and token validity checks at the payment provider, not inside a prompt. Also disclose the agent, show fees, honor stop or cancel, reject totals above the user's maximum, avoid pressure tactics, and keep auditable decision logs. The hostile-salesperson example shows that a **system prompt can materially alter behavior**, even when the transaction plumbing is unchanged. These safeguards are presented as a practical checklist, not evidence that every manipulation or commerce failure is covered.
This turns payment safety into both a protocol and behavior problem. UCP structures merchant capabilities and shields raw card data, while provider-side limits, cancellation, disclosure, and audit logs constrain execution. The hostile-salesperson demo confirms that unchanged payment plumbing cannot neutralize prompt-driven manipulation, so transaction controls and behavioral policy must be enforced separately.