Field Notes from Brazil - Volume 11

Lucas Albuquerque Gouveia de Lima is Bytecenture's Brazil-based payment UX researcher. This is the eleventh in a series of Field Notes from our in-market researchers across ten countries.

One-click checkout made it easier for customers to complete a purchase. Agentic commerce introduces a different possibility: allowing software to complete a purchase within limits the customer has approved.

The design problem moves upstream, to the moment the customer defines those limits, and continues after the agent acts.

From a Payment to a Permission

Earlier Brazil Field Notes explored reducing checkout friction through Open Finance and biometrics. In those journeys, the customer still initiates and confirms the payment.

An agent could instead monitor a price, check availability, and buy when agreed conditions are met. "Buy these headphones once the total falls below R$300, including delivery" is a different instruction from "Show me headphones under R$300."

The difference is authority to spend.

Global payment infrastructure is being developed around that distinction. Visa Intelligent Commerce describes agent-specific payment tokens, authenticated instructions, and transaction controls. The Agent Payments Protocol (AP2) defines both purchases the user approves at checkout and purchases an agent can complete under previously approved constraints.[1, 2]

Ant International's Agentic Mobile Protocol (AMP), introduced in April 2026, addresses agentic payments through digital wallets, super apps, and other mobile interfaces. Its stated design combines defined payment authority, visibility into agent activity, and the ability to modify or revoke delegated tasks.[5]

Availability depends on the providers, merchants, and integrations involved. For Brazilian product teams, this is an emerging design problem to evaluate against the payment journeys their products actually support.

Authentication and Spending Permission

Passkeys use cryptographic key pairs to authenticate users. Payment tokens represent payment credentials. A spending mandate defines what an agent is permitted to do.[1, 2, 3]

These layers solve different problems. Authenticating the customer does not automatically authorise an agent to select a merchant, accept delivery charges, or buy a substitute.

Brazil's Pix journey without redirection illustrates the distinction. The published Open Finance flow still has the customer review and confirm the immediate payment using a security credential.[4]

A smoother Pix experience should therefore not be treated as a general permission for an AI agent to spend.

The Interface Becomes a Set of Rules

The checkout screen remains relevant in journeys requiring review. In delegated journeys, more of the UX responsibility sits in configuration and monitoring.

Users need clear rule builders for budgets, permitted products or merchants, delivery conditions, expiry, and situations that require fresh approval. A limit per purchase should be distinguishable from a total budget.

For example, "up to R$300" leaves important questions unanswered: does it include shipping, how many purchases are permitted, and when does permission expire? The interface must turn that broad request into an instruction the customer can understand and approve.

The product then needs to show when the agent is watching, awaiting approval, blocked by a rule, or has completed a purchase.

How to Apply It to Your Product

Information architecture should make automation visible. Extend order history with an "Actions Taken by the Agent" feed that shows what happened, when, which instruction allowed it, and what it cost. Keep the receipt, merchant, and fulfilment details accessible from the same entry.

Place active permissions, remaining budget, expiry, and pause or revoke controls together. Explain that stopping future agent actions does not automatically cancel an order already placed.

During journey-alignment sessions and User Acceptance Testing (UAT), expand beyond form-completion speed. Recruit users with different confidence in automation and ask them to configure a budget, explain what they have authorised, recognise an exception, and stop future activity.

Test changed totals, unavailable products, delivery fees that exceed a limit, failed payments, and attempts to act after permission has expired. Verify that limits are enforced by the system and that the visible state matches what actually happened.

Measure whether people can accurately describe the agent's authority, find the relevant action, and recover when the agent cannot proceed. Confidence should come from understandable controls and evidence.

Without that foundation, a technically authorised purchase can still feel like an unauthorised charge.

References and Sources

  1. Visa Developer. Visa Intelligent Commerce. Source for agent-specific payment tokens, authenticated payment instructions, transaction controls, and the qualification that features remain in development and deployment and may not be available in all markets. developer.visa.com
  2. Agent Payments Protocol. AP2 Specification. Source for direct and autonomous purchase modes, user-approved constraints, and linked checkout and payment mandates. ap2-protocol.org
  3. FIDO Alliance. Passkeys. Source for public-key authentication and the distinction between synced and device-bound passkeys. fidoalliance.org
  4. Open Finance Brasil. User Experience Guide v23.00.00: Pix via JSR. Source for the immediate Pix journey without redirection, including customer review and confirmation using security credentials. Published 27 August 2026. openfinancebrasil.atlassian.net
  5. Ant International. Ant International Launches Open-Sourced Agentic Mobile Protocol to Drive AI Commerce. Source for AMP's mobile-wallet focus, delegated payment authority, visibility, and task modification or revocation. Published 28 April 2026. ant-intl.com
// ENGAGEMENT.OPEN