Agentic Commerce: Payment Product Readiness

A customer asks an assistant to buy something. Before the merchant accepts payment, several questions need precise answers: which item, at what total price, under whose authority, and what happens if the assistant loses the response after the order is accepted? A fluent shopping conversation does not resolve these questions.

Start with one buying task and its exceptions. A merchant needs an order it can fulfill; a PSP needs a valid payment instruction and evidence; the customer needs to understand and control the commitment. The checklist below is a proposed operating design, not a claim about a deployed personal project.

Separate intent, identity and payment authority

Record the instruction in terms the system can enforce: permitted merchant or category, item constraints, quantity, maximum total including delivery and tax, currency, expiry and whether customer confirmation is required. Decide what changes require fresh approval. A different delivery address or substitution may matter even when the price is unchanged.

Agent identity is another check. Visa’s Trusted Agent Protocol specification describes signed requests and verification mechanisms. Validating a request signature should not become a blanket entitlement to spend: the merchant must also check the authority and constraints relevant to the action.

Mastercard’s agentic payments overview discusses consumer intent, agentic tokens and authentication. Confirm the actual provider implementation, supported market and integration requirements rather than treating different frameworks as interchangeable.

Make checkout authoritative

The merchant should calculate the current total and validate stock, delivery options and purchase conditions. An agent’s remembered price is not a quote. Expire stale sessions and expose a clear route back to the customer when the final offer no longer matches their instruction.

OpenAI’s checkout specification defines a programmatic checkout interaction with the merchant. Its key concepts distinguish the merchant’s responsibilities from the agent platform’s role. Use the specification version agreed with the integration partner and test the endpoints against the merchant’s actual order model.

For credential handling, Stripe describes Shared Payment Tokens as a way to support agent payments without exposing underlying credentials to the agent. Token support does not replace authorization, capture, reconciliation or customer-service decisions. Keep raw payment credentials out of model prompts and ordinary application logs.

Match Each Protocol To Its Job

These mechanisms answer different questions. They can be composed in a partner integration, but they are not interchangeable standards or proof of automatic interoperability.

Version check, 24 October 2026: the ACP changelog identifies API version 2026-01-30, including a breaking change to payment handlers. The AP2 specification identifies v0.2 and requires exact mandate vct matching, including the schema-version suffix. Pin the contracted versions, handler capabilities and partner profile before testing compatibility.

AP2 v0.2 defines shopping-agent, credential-provider, merchant, merchant-payment-processor and trusted-surface roles. Validation must use deterministic code, and the trusted surface is non-agentic. Catalog and commerce APIs are outside AP2's scope; its documented UCP compatibility does not establish an ACP integration. These are role and version boundaries, not competing settlement rails.

One possible purchase trace makes those boundaries concrete:

1. The merchant verifies the agent's TAP signature for its domain and request, then applies its own rate and access controls. This is agent recognition, not spend approval.
2. The customer authorizes bounded AP2 mandate constraints through a trusted non-agentic surface. The agent assembles the specific merchant checkout; the merchant validates the offer and its match to the mandate. Record the exact AP2 mandate vct schema version used.
3. A compatible ACP checkout integration carries the merchant's current order and selected payment flow. The configured credential provider or PSP supplies a checkout-scoped token or credential, such as a compatible Shared Payment Token arrangement; the processor makes the payment decision.
4. Reconcile order acceptance, payment authorization/capture/settlement and fulfillment as separate states. A valid agent signature, mandate or token is not a receipt for goods or services.

This is a role map for product design, not a claim that ACP, AP2 and TAP currently share one certification path or work together without partner implementation and onboarding.

Design the uncertain outcome before the happy path

Maintain distinct records for the customer instruction, checkout, order and payment attempt, linked by stable identifiers. Track authorization, capture, cancellation, fulfillment and refund separately. An accepted order is not evidence of settled funds, and a payment timeout is not evidence of failure.

Use an idempotency key for the relevant mutation and retain its request fingerprint and result for an appropriate period. After a timeout, retrieve the existing state before attempting another purchase. Define behavior when the same key arrives with different parameters. Webhook handlers also need deduplication and a way to handle delayed or out-of-order events.

Do not let the model improvise recovery. Deterministic application code should decide which transitions are allowed, when a retry is safe and when a person must investigate.

Work through one purchase

This is an illustrative test case, not a production result. A customer authorizes one office monitor costing no more than AED 900 including delivery, from an approved merchant, with confirmation before purchase.

The merchant returns AED 880 and an estimated delivery date. The customer confirms that offer. The service records the approved checkout version and submits the order once. The connection then times out.

The correct next step is to query the existing order and payment using their identifiers. If the merchant confirms acceptance, show that order rather than creating another. If the amount later changes to AED 920, stop and obtain new approval. If stock disappears, do not silently choose another model. Each branch should leave evidence that support can understand without reading an entire conversation.

Refunds and disputes belong in the first release

Decide who can request cancellation, whether fulfillment can still be stopped, how partial refunds are calculated and which original payment the refund references. Apply the merchant’s policy and the provider’s capabilities. Do not promise that an agent request reverses an irreversible fulfillment action or guarantees a refund.

Retain the accepted offer, customer approval, authority constraints, order version, payment references and fulfillment evidence under a defined retention policy. Give support a human escalation route. Agree dispute handling with the acquirer or PSP; an agent transcript alone does not establish liability or satisfy every evidence requirement.

A revocation and partial-refund trace

Synthetic test case, not a production result. The customer revokes future purchasing authority after an AED 880 order was accepted. A permitted partial refund later becomes necessary. The application must distinguish the two actions.

Do not create a second refund because the first response was lost. The refund action needs its own valid authority; revoked purchase permission does not confer recovery permission. Keep customer complaints, merchant service resolution and payment disputes distinct. None of this trace assigns scheme liability or guarantees that goods already shipped can be recalled.

Run a bounded product and program pilot

Product owns the target task, customer policy and success measures. Engineering owns state transitions and recovery. Risk and security review delegated access and abuse. Operations accepts support and reconciliation procedures. The program lead tracks partner readiness, dependencies, unresolved decisions and the release evidence.

Evaluate expired authority, price changes, malicious product descriptions, duplicate requests, lost responses, delayed webhooks, partial refunds and attempted purchases outside scope. Measure successful authorized orders, duplicate commitments, incorrect confirmations, exception handling time and missing evidence. Separate model task performance from payment reliability.

Start with a narrow merchant and product cohort, explicit transaction limits and a stop mechanism. Expand only after owners accept the observed results and residual risks. Availability and commercial eligibility must be confirmed with the selected providers for the intended market.

FAQ

Does an authenticated agent have permission to buy?

Not automatically. Verify the applicable customer authority, purchase constraints and payment requirements as well as the agent identity.

Should a timeout trigger another purchase?

First retrieve the existing order and payment state. Retry only under the integration’s idempotency and recovery rules.

Can a small team start without autonomous spending?

Yes. Prepare a checkout for explicit customer confirmation, then evaluate the complete order, payment and support lifecycle before considering broader delegation.