Introduction

What if purchases could be made on a customer’s behalf by an agent that understands what they need, when they need it, and how to execute the transaction?

In this scenario, the Card Member doesn’t explicitly add items to a cart or tap “Buy Now.” Instead, an agent could recommend options and complete a purchase using an American Express account, based on permissions defined by the Card Member.

This shift challenges a core assumption of how payments work today.

Traditional systems are built around user actions where a person browses, decides, and executes each step of a transaction. As agents begin to act on behalf of users, that interaction model may no longer hold. In a more autonomous agentic AI system, instead of repeatedly translating intent into action, the user defines intent once, and the agent continuously evaluates context, makes decisions, and executes when conditions are met. This is the new model the Amex Agentic Commerce Experiences (ACE) Developer Kit is designed to enable—bringing intent-driven, agent-powered transactions onto the American Express network with trust and control.

The Core Challenge

This evolution introduced a complex problem: how do we help ensure that any agent taking delegated actions is explicitly authorized, controlled, and accountable?

How can an agent acting on a customer’s behalf prove it has the required authority to make purchases? How can guardrails be set for the agent’s actions? Who is accountable if the agent makes a mistake? These questions require the payment ecosystem to adapt for agent-powered transactions.

The Capabilities Required

As we explored these challenges in building the ACE Developer Kit, it became clear that enabling AI-powered payments required a new set of capabilities.

  1. Establishing Trust

Trust begins with a clear, explicit setup: the Card Member provides their payment instrument for agents registered with Amex, completes issuer authentication, and defines controls on how that instrument can be used. This interaction model is supported by capabilities such as agent registration and account enablement, which help create a verifiable relationship between the Card Member, the agent, and the payment instrument.

  1. Representing Intent

At the time of purchase, the agent may play a role in both discovery and execution—recommending what to buy, selecting from relevant merchants, and completing the transaction. These decisions are guided by natural language instructions that express the Card Member’s intent, which ultimately helps determine what is purchased, how much can be spent, and with which merchants.

With that in mind, we built an interaction model where intent captures qualifiers such as:

  • What should be purchased
  • Where it could be purchased from
  • How much can be spent
  • When additional approvals are required

Intent helps define the boundaries within which the agent can operate, and the ACE Developer Kit helps make those boundaries enforceable in practice.

  1. Enforcing Boundaries

Delegation often involves enforced constraints, including spending limits, merchant restrictions, frequency controls, and conditional execution. These are applied at execution, helping to ensure agents operate within defined boundaries.

  1. Securing Execution

At the payment authorization stage, payment credentials are designed to be used in a limited and controlled manner; actions are tied to verified intent, while execution is auditable and traceable.

The ACE Kit seeks to achieve this through:

  • Scoped payment credentials
  • Short-lived authorization artifacts
  • Strong verification mechanisms

In this way, the agent can complete a payment within a defined framework.

How This Works in Practice

When these capabilities come together, an adapted model of payments emerges. In the ACE Developer Kit, this interaction model is implemented through a sequence of coordinated steps.

Intent is first captured and stored as a structured contract. At the time of payment credentials issuance, Amex generates a scoped credential tied to that intent.

Before a payment credential is generated, the ACE Kit is designed to validate:

  • That the intent is still valid
  • That constraints are satisfied

Partner Integration and System Architecture

Partner Integration Model

The ACE Developer Kit is designed to integrate with partner environments without requiring fundamental changes to their existing payment infrastructure. Partners interact with the Kit through a combination of synchronous APIs and asynchronous notifications. API-driven interactions allow partners to initiate enrollment, create intent, and request payment credentials, while event-driven notifications provide updates on state transitions such as authentication completion or transaction outcomes. This dual model allows partners to operate in both request-driven and event-driven environments, depending on their architecture.

In a typical flow, the partner initiates a request to create or update an intent. Amex evaluates the request, applies risk controls, and determines whether criteria are met to permit execution. Scoped payment credentials are then issued and used by the merchant to process the transaction through existing payment rails.

Security Protocols and Design Patterns

Security is a foundational element of this architecture and is implemented across all stages of the lifecycle.

All API interactions are authenticated using OAuth and mutual TLS, ensuring that each request is associated with a verified partner or agent identity. This allows access to be scoped, monitored, and revoked as needed.

Sensitive payloads are encrypted using industry-standard encryption mechanisms, helping ensure account details and credentials remain protected in transit. Additionally, payment tokens and dynamic credentials are used to limit the exposure of payment data.

The platform follows a zero-trust model with respect to client input. No request is accepted based solely on client-provided data. Instead, each step is validated using signed artifacts that bind to a specific intent. These artifacts are short-lived and include protections against replay, ensuring that requests cannot be reused or forged. This combination of authentication, encryption, tokenization, and verification allows ACE to enforce strong security guarantees without introducing unnecessary friction for developers.

Supporting Scale Across Partner Ecosystems

As adoption grows, the ACE Developer Kit is designed to scale and be interoperable with different standards and models with different industry protocols supporting varying levels of delegation and controls.

By decoupling intent and credential issuance, and keeping the transaction processing the same for merchants, ACE avoids dependency across components, allowing each to scale independently. This approach enables partners to onboard incrementally, extend their use cases over time, and operate at scale without requiring changes to the core model.

Developer Experience and Integration Simplicity

While the ACE Developer Kit enforces complex validation and security guarantees, the integration model is intentionally designed to remain straightforward. Developers interact with a small set of well-defined capabilities: enrollment, intent creation, credential retrieval, and lifecycle management. These capabilities map cleanly to existing application flows, reducing the need for custom orchestration logic.

To simplify integration, in the future, the platform will provide supporting tools such as SDKs, Agent Skills, an MCP server, and reference implementations. These abstractions encapsulate common patterns, allowing developers to focus on building user experiences rather than managing low-level details. Structured error responses and consistent request and response patterns ensure that integrations are predictable and easy to debug.

This balance between strong guarantees and simple integration is critical for enabling adoption at scale.

What We Learned

As we worked through these challenges, a few principles became clear.

  • Delegation should always be explicit and verifiable, rather than implied.
  • Intent should capture the user’s goal in a way that can be enforced.
  • Payment credentials should be scoped to the intent.

These principles shaped how we approached the problem.

Conclusion

The ACE Developer Kit brings a new payments model to life—providing developers with the capabilities to enable secure delegation, enforceable intent, and controlled execution on the American Express network.

Developers can explore the APIs, integration patterns, and supporting tools on the American Express developer portal: https://developer.americanexpress.com