An agent payment should carry less authority than the wallet

Stripe's April 29 description of payments for agents puts human approval before issuing the payment credential. Its Link flow lets an agent request a purchase and receive a one-time card or Shared Payment Token after approval, with scope such as amount, currency and merchant. The agent does not need the user's underlying payment credentials. Stripe's design.

That separation is the interesting part. A wallet represents a continuing relationship with a person and their money. An individual purchase should carry a much smaller permission.

I would start an agent-payment integration by designing the disposable authority, before debating how autonomous the assistant should become. A clever purchasing agent with a broad reusable credential is a different risk from the same agent holding permission for one bounded transaction.

Approval needs a precise object

Imagine I ask an assistant to buy a replacement laptop charger. This is a hypothetical design review, not a transaction I have tested through Link. The assistant finds an option, checks compatibility and asks me to approve the purchase.

What exactly have I approved? The charger, the named seller, the final amount including delivery and a particular order should travel together through the workflow. If the merchant changes after approval, or the basket acquires an accessory, the system needs a rule for whether the previous permission still applies.

A chat message saying yes is easy to produce. Binding that yes to the transaction that actually reaches the payment service is the harder implementation detail. I would make the approved purchase record the object downstream components reference, rather than letting each component reconstruct intent from conversation history.

Stripe's announcement describes the credential and approval boundary. It does not settle every application-specific question about order identity, substitutions or fulfilment. Those remain part of the integration team's design.

A retry is not a second purchase

Now take the less glamorous case. The merchant accepts the order, but the agent's browser loses the confirmation page. The assistant cannot tell whether checkout succeeded and wants to try again. A spending limit can restrict the size of the mistake while still allowing a duplicate order.

My proposed acceptance test would interrupt the flow immediately after payment submission. The agent should reconcile the existing transaction or escalate uncertainty before creating another purchase. A second attempt needs to be associated with the same intended order, with duplicate prevention enforced outside a model's promise to be careful.

That requirement is separate from whether the payment credential is single-use. One credential can be safely exhausted while the surrounding workflow mistakenly requests another one. The approval system therefore needs to understand what has already been authorised, not merely whether another amount sits below a limit.

I would test changed merchants, changed totals, delayed confirmations and user cancellation before adding more shopping autonomy. Each test asks whether the authority still matches the buyer's decision. None requires pretending the agent has become a legal person or that identity and authentication no longer matter.

The public design is also dated evidence. Stripe's April announcement presents additional standing-limit behaviour as future work; it should not be read as proof that every described future control was already available in that release. Product scope belongs in the implementation check.

For an engineering team, the practical win is a transaction that remains understandable after the conversational interface has moved on. The purchase record should explain what was approved, what was attempted and what actually happened.

Give the agent authority for an approved purchase, then reconcile that purchase before granting authority again.