Alipay Agent Pay: Preserve User Authorization Across an Agent Purchase

“Order lunch for the team” sounds like one instruction. In practice it contains a choice of merchant, quantities, delivery details and a final payment decision. An assistant can prepare those details, but the payment experience must preserve what the user actually approved. Alipay Agent Pay is relevant at that transition from conversation to an authorized transaction.

Research boundary: public official materials reviewed November 1, 2026. We did not sign a merchant agreement, open a payment capability or place an order. The workflow below is conceptual.

The platform and the merchant have different jobs

The product page describes agent platforms on one side and goods or service providers on the other. It emphasizes a sequence of intent, authorization, payment and returned evidence, with experiences spanning desktop, mobile and devices.

For the lunch order, the agent platform owns the conversational task and presentation of the order. The merchant owns its offer and fulfillment. The payment integration connects those responsibilities, but cannot repair an ambiguous order after money moves. If “for the team” does not specify the recipients or acceptable total, clarify before payment rather than asking the payment layer to infer intent.

Conceptual successful-purchase path. Fulfillment follows a successful payment result; a pending or failed payment requires separate handling. Payment and fulfillment remain separate records; no screenshot or live payment is represented.

Confirmation must refer to the final order

A useful confirmation shows the merchant, items, total, delivery details and any continuing obligation. If availability changes after that screen, retain the old version and decide whether the new terms require approval. The application should not treat a broad conversational request as permission for any later substitution.

The official positioning stresses user authorization. That should not be rewritten as a promise that every product variant allows unlimited unattended purchases. The precise authorization scope, expiry and exceptional steps depend on the selected integration and its current documentation.

Result handoff is where support problems appear

A buyer may complete payment on a phone while the agent runs in a desktop or cloud session. If the conversation loses its connection, the merchant’s order may still exist. The application needs a stable relationship between task, merchant order and payment result.

Our recommendation is to distinguish pending, paid and fulfilled states in the user interface. After a timeout, query the existing transaction through the approved integration before creating another order. This is a design requirement to evaluate, not a claim that all Alipay Agent Pay adapters implement an identical retry API.

Participant	Responsibility to make explicit
User	Approve the actual purchase terms and relevant authority
Agent platform	Preserve task context, order version and state transitions
Merchant	Publish an accurate offer and handle fulfillment or cancellation
Payment integration	Return a verifiable payment outcome through the supported flow

Merchant access is not supplied by a prompt

The developer entry and product onboarding links lead into technical integration and capability activation. Installing an integration skill or generating code should not be described as having completed merchant eligibility, signing or production enablement.

Before choosing this route, establish which party is onboarding: an agent platform, a merchant selling ordinary goods, or a provider charging for digital resources. Ask for the supported transaction flow and current commercial requirements for that party. Public product messaging is not a substitute for the account’s actual access state.

Separate shopping from metered API payment

Machine Pay focuses on paid digital resources and usage-based service calls. Agent Pay’s shopping flow should not be collapsed into that metering model, even though both sit within Alipay’s AI-payment offering. A lunch order involves inventory and delivery; an API call involves resource access and usage evidence.

For this directory, Agent Pay is a consumer-authorized commerce entry point. The reference page links to current official materials. Evaluate success by whether the buyer, merchant and assistant agree on the same order and payment state, not merely by whether a conversation can display a payment button.