AP2: Approvals, payment and customer experience for brands

AP2 for brands: who can buy, who can pay, and who helps when something fails?

A shopping agent does not automatically deliver more revenue for your brand. It becomes useful when customers spend less effort on recurring or complicated purchases without losing control of their money. Product selection, approval and payment must work together. This is where AP2 matters: as a protocol for authorizing agent-mediated payments, not as a ready-made sales channel or a replacement for a good customer experience.

For you as a CMO, the essential question is therefore not, “Are we already doing AP2?” It is, “Which purchasing task can we improve through verifiable consent?” Answering that requires a specific use case, clear decision rights and a service process that works after an unsuccessful checkout. Establish those conditions first and you can assess integration proposals on their merits, rather than mistaking a technical announcement for a dependable business model.

What AP2 v0.2 actually describes

The AP2 v0.2 specification describes roles, verification responsibilities, Checkout and Payment Mandates, and associated receipts. AP2 operates as a security feature within a commerce protocol. Catalog APIs, checkout updates and the specific communication interfaces between participants are outside that scope. This distinction matters for planning: support for a mandate does not create a complete shop, reliable product advice or a functioning returns operation.

The Google announcement about AP2 provides context for the initiative and its ecosystem. It does not demonstrate that every platform, payment provider or merchant currently offers the same production capabilities. The linked v0.2 specification is the basis for the technical explanation here. Ask suppliers to identify their supported version, payment methods, regions and operating conditions. A general claim of being “AP2-ready” is not enough to support procurement or a launch decision.

Two mandates, not blanket purchasing permission

The Checkout Mandate provides the Merchant with evidence that the Shopping Agent is authorized to purchase the assembled checkout. The Merchant supplies a signed checkout, and the closed mandate is cryptographically bound to that particular checkout. For your brand, this means approval must refer to an identifiable purchase, not simply a reassuring summary in a conversation. Variants, quantities, prices and conditions must be available reliably in the commerce system.

The Payment Mandate concerns authorization to pay for that checkout. It is also bound to the specific checkout and verified by the designated payment participants. The two mandates work together but serve different purposes. Permission to select products is not automatically permission to make any payment. Equally, access to a payment credential should not be treated as agreement to every subsequent basket change. Reflect this separation in your architecture, approval copy and internal allocation of responsibility.

Roles make responsibility visible

The specification distinguishes the Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor and Trusted Surface. The Shopping Agent discovers products, assembles the checkout and executes the purchase. The Credential Provider verifies authorization to access payment credentials and scopes their use. The Merchant verifies purchasing authorization for the particular items and is responsible for the integrity of inventory, pricing and merchant discounts. The Payment Processor checks authorization of the payment credential for that checkout.

The Trusted Surface is the trusted interface for informed consent and the creation of user-signed mandates. It must be non-agentic. Required validation and processing must also happen in deterministic code under the specification, even when a role otherwise operates agentically. One organization can perform several roles or delegate responsibilities; that does not remove the associated duties. Ask for a responsibility matrix, not a presentation in which an unspecified “AI” appears to do everything.

Direct: approval of the specific purchase

In Direct mode, the person sees the closed checkout and explicitly approves it and its payment. This is a natural starting point if your brand initially wants to test selection assistance and faster purchase preparation. An agent might identify suitable refill products and prepare a basket. Before completion, the approval interface shows the purchase and the payment to be authorized. This is a hypothetical example, not a reported customer result.

An honest comparison is important. The specification notes that this kind of flow can often be replaced by a conventional e-commerce journey in which the Merchant and Trusted Surface communicate directly. AP2 is therefore not automatically the most economical answer for every assisted checkout. If your existing shop performs the same task more clearly and at lower cost, the pilot should have to compete with that alternative. Novelty on its own is not a customer benefit.

Autonomous: constraints rather than unlimited authority

In Autonomous mode, the person approves conditions for a later purchase and its payment in advance. Open Checkout and Payment Mandates represent that permission. Within the authorized boundaries, the agent can subsequently sign closed mandates using its agent key. Verifying parties still receive closed mandates, with the supporting authorization chain establishing trust. Autonomous operation does not mean that consent disappears or can be reconstructed after the event.

A hypothetical use case would be replenishing a precisely identified consumable below an agreed total amount within a short period. A different product, higher price or changed delivery date might require fresh approval, depending on the conditions actually authorized. The specification recommends making open mandates valid for the shortest period that still allows the task to be completed. For your brand, understandable boundaries matter more than an impressive promise of autonomy.

Start with a purchasing task, not a channel

A suitable pilot offers recognizable customer value and relatively few exceptions that are difficult to assess. Consider whether customers repeatedly need the same item, can distinguish variants clearly and can express meaningful price limits. Purchases driven by individualized suitability, extensive advice or rapidly changing conditions may be less suitable starting points. This is a selection heuristic, not a claim that particular categories are inherently prohibited or already supported.

Define the intended improvement in advance: fewer abandoned repeat purchases, less effort for existing customers or fewer avoidable service contacts. Also state who the pilot is not for. If success means only the number of agent interactions initiated, your team is measuring activity rather than value. A narrow use case with an identifiable outcome provides a better decision basis than a broad experiment without clear expectations for customer experience and commercial performance.

Put decision rights into the operating model

Specify what customers decide, what the agent may execute and what your brand commits to provide. Are substitutions allowed? Does the budget include shipping? Who decides when a price changes? Can an order be split? These are not details to resolve immediately before launch. They determine whether an understandable permission later turns into an unexpected purchase, and whether the resulting experience matches your promise to customers.

Every exception also needs an internal owner. Marketing owns the value proposition and clear communication, commerce owns purchasable offers, payment teams own payment integration, and support owns problem resolution. Security, privacy and legal specialists assess their respective requirements. Name someone authorized to approve pilot operation and someone empowered to stop it when warning signs appear. The responsibility matrix should also identify which decisions suppliers make and which remain explicitly with your organization.

Product data is part of the experience

An agent can select only as well as your data explains the differences. Product identity, variant, pack size, availability, price components, delivery options and return conditions must be consistent. Attractive copy cannot compensate for contradictory variant identifiers. Test not only whether the agent finds an item, but whether it hands the correct purchasable offer and the applicable conditions to the checkout system.

AP2 does not standardize all this data work. Connect the pilot to a specific quality process: which source is authoritative, when do changes propagate, and when does a previous selection become invalid? More complex ranges also need a boundary between verified product properties and promotional interpretation. For related transparency questions, see our article on AI labeling in content production. Labeling does not replace accurate product information or meaningful consent to a purchase.

Good approval UX explains the consequence

An approval should offer more than a button marked “Confirm.” It should explain what will be purchased, the total amount, the seller and the material conditions affecting the decision. In an autonomous flow, it must also explain which future decisions are permitted and when the person will be asked again. Describe the practical effect in everyday language rather than relying on the technical name of a mandate.

Test comprehension through realistic tasks. Can participants explain which substitution would be allowed and which purchase would remain outside the permission? Do they confuse a recommendation with an order? Can they find the route back to a manual decision? These answers matter more than an attractive screenshot. A compact interface must not conceal important limitations. Also plan clear post-purchase confirmations so that customers do not first discover their agent has acted through an account charge.

Failure handling needs a designed path

Plan separately for declined authorization, unavailable products, changed prices, technical interruption and an uncertain payment status. A timeout does not necessarily mean that payment failed. Before an agent retries, the integration process must be able to check the existing status. Customers need a clear message: completed, not completed or still being investigated. Unfounded success messages are as harmful as premature instructions to make the purchase again.

Replay and duplicate processing belong explicitly in technical acceptance testing. Check how your implementation recognizes reused evidence, handles repeated requests for the same purchase intent and reconciles orders with payments. The mandate architecture is not blanket proof that every integration solves these problems completely. Test delayed responses and events arriving in an unexpected order. Define a safe stop and a human resolution route when the status cannot be established reliably.

Refunds and service cannot be afterthoughts

Authorization does not automatically explain how a return will work. Your brand still needs rules for cancellation, partial returns, refunds, failed delivery and disputed orders. Decide who can initiate a refund, how its status becomes visible and how duplicate refund processing is prevented. Distinguish technical payment status from the commercial decision about whether a refund is owed and how much should be returned to the customer.

Customer service should be able to understand the order, relevant consent, payment status and previous handling without exposing unnecessary sensitive information. Receipts and mandates can provide evidence; their practical usefulness depends on integration, access and retention. Rehearse a case in which someone says, “I did not mean to order that.” Your team then needs a comprehensible explanation and an escalation route, not a statement that an agent supposedly did everything correctly.

Total costs, not isolated checkout costs

Look beyond integration and payment fees to data maintenance, approval design, testing, monitoring, training, service and ongoing changes. Supplier migration, additional infrastructure and manual exception handling may also matter. Ask which services are included in a proposal and which are charged separately. A low technical transaction price can become expensive if unclear permissions generate additional customer contacts and investigation work elsewhere in the organization.

Model different volumes and failure assumptions without presenting them as market forecasts. A hypothetical calculation can show the adoption level at which a pilot would need to cover its recurring costs. Document assumptions about contribution margin, returns and support effort. The right decision may be to improve product data and manual approvals first. That preparatory work is not an innovation failure; it may simply be the most commercially sensible next step for your brand.

Measure whether the business actually benefits

Connect usage data to business outcomes. Alongside successful completion, measure abandonment at approval, repeated consent requests, uncertain payment statuses, duplicate orders, refunds and service contacts. Consider contribution margin after relevant incremental costs rather than gross revenue alone. Compare similar purchasing tasks and customer groups where possible: a different basket or an additional discount campaign may influence results more strongly than the new checkout logic itself.

Before launch, define what development would justify expansion, revision or a stop. Small samples do not support sweeping success claims. Complement quantitative measures with conversations about whether people understood their control. A shorter purchase journey is not a success if it creates unexpected orders. For a CMO, the meaningful outcome is a defensible balance of additional value, trust, costs and long-term customer relationships, not merely the visibility of a new technology.

Security and legal review remain separate work

Cryptographic binding and distinct verification responsibilities are important building blocks, not universal security guarantees. Assess key management, trust relationships, permissions, monitoring and the handling of compromised components. Even formally valid approval can arise from a confusing interface. A protocol alone does not evaluate every question of product suitability or every risk in your particular operating environment, and its implementation still needs scrutiny.

Similarly, a mandate does not replace legal review. Contract formation, consumer information, privacy, payment requirements, retention and dispute handling depend on factors including the market, business model and implementation. Address these with qualified advisers for your situation. This article is not legal advice. Do not treat technical evidence as an automatic determination of liability or refund entitlement, and do not promise customers general legal protection simply because AP2 is involved.

Questions marketing and commerce teams ask

Do we need autonomous purchasing immediately? No. A Direct pilot may be useful if it improves a concrete task. Still compare it with an optimized conventional checkout. Autonomy is one possible design, not an inherent indicator of quality or commercial maturity.

Can an agent pay without any approval? That is not the authorization model described here. In autonomous operation, bounded permission is given in advance; in direct operation, the particular purchase is approved. You must test which boundaries your integration actually represents and enforces.

Is AP2 already available everywhere? The cited sources do not establish universal availability. Check specific partners, versions, regions and payment methods. An announcement is not a substitute for successfully testing your own end-to-end flow under the conditions in which it will operate.

Does AP2 solve returns and complaints? Not as a complete service product. Mandates and receipts can support evidence. Your processes, responsibilities and systems must still perform reversal, resolution and customer communication, including cases where different participants hold different parts of the relevant information.

What should happen when something is uncertain? The agent should not creatively exceed the approved boundaries. Define interruption, renewed approval and handover to a person. That fallback must be reachable and carry the existing case forward, rather than forcing the customer to explain everything again from the beginning.

Keep payment evidence separate from content provenance

If you explain the shopping journey using AI-generated demonstrations, distinguish payment approval from disclosure of the content. Our article on AI marking in production covers that separate responsibility. Correctly labelled video does not make a payment flow safe, and a verified payment mandate says nothing about the video’s provenance. Review the approval record, confirmed order status and any required content notice on their own terms. This prevents one technically impressive assurance from being used as evidence for an unrelated claim.

What Now?

Start with a purchasing task you can evaluate, not a promise of unlimited automation. Our glossary entries explain AP2, agentic commerce and agentic checkout. Your subsequent decision should rest on concrete working documents, not simply a list of potential partners or a general statement that your brand intends to experiment with agents.

• Narrow the purchasing task: Choose an understandable use case with a clear comparison journey and name the expected customer benefit.
• Document decision rights: Separate purchasing authority from payment approval, assign roles, and define limits and renewed consent.
• Test data and interfaces: Examine purchasable product information and understandable approvals together, including realistic exceptions rather than only successful demonstrations.
• Prepare operations: Rehearse timeouts, replay, duplicate orders, refunds and human handover before a public launch exposes customers to unresolved failure paths.
• Make the commercial decision: Evaluate results including service and total costs, and expand only when the additional value is defensible.

If you want to assess architecture and integration readiness, start with Tech. To evaluate a specific pilot together, use Contact. The objective is not maximum autonomy. It is a purchasing experience whose benefits, consent and responsibilities your brand can explain even when the transaction does not go according to plan.