Alchemy's latest agent-payment announcement offers a revealing picture of where finance is heading. On September 17, Alchemy said its AgentCard product would integrate Mastercard Agent Pay, combining an agent's identity tools and stablecoin wallet with one-time-use card credentials. A company associated with blockchain infrastructure is using an established card network to help software buy things online. Alchemy says AgentCard is available, while describing Mastercard support in a mixture of current and forward-looking terms. The announcement does not establish universal cardholder or issuer access. Alchemy's announcement
That development makes the debate about AI agent payments more interesting than a prediction about the disappearance of plastic. Software could choose a seller, compare financing and initiate a transaction. Whoever supplies that software may gain influence over where revenue goes and which financial products people use.
Our view at BIG CHANGE is that delegated payment decisions deserve as much scrutiny as delegated spending. A system can buy the right item at the approved price and still choose an expensive way to finance it. It can also save the buyer considerable work by comparing conditions that are tedious to inspect manually. Both outcomes are plausible. The quality of the rules and the incentives behind the recommendation will help determine which prevails.
This is the first of three articles on agents and money. The next examines stablecoins, bank deposits and the choice of payment money. The third follows tokenized assets into treasury and collateral.
The video raises a useful distinction
In a September 3 a16z conversation, host Erik Torenberg speaks with Alex Rampell and Affirm CEO Max Levchin about payment history and the next interface. Levchin is more optimistic about delegating payments than taste-driven shopping. Rampell sees an opportunity once a buyer knows the exact product and wants help finding the seller and payment terms. Their closing discussion also recognizes delivery, reputation and returns as obstacles to simple price optimization. Watch from 52:44.
The earlier Affirm discussion supplies context: its founders describe moving from reducing checkout friction toward financing that influences purchase decisions and builds an ongoing customer relationship. These are interested participants' recollections and judgments, not independently measured proof of what AI will achieve. a16z's description also discloses that it and affiliates may invest in companies discussed.
The distinction is useful for product design. Someone who enjoys choosing a camera may still want software to compare shipping, warranty coverage and repayment conditions after selecting the model. Another customer may delegate a routine replenishment purchase from start to finish. A single permission setting called “autonomous shopping” would handle those preferences poorly.
Mastercard is connecting several parts of the purchase
Mastercard introduced Agent Pay in April 2025. The program combines registered agents, tokenized payment credentials and consumer controls. Its proposed protections include recognizing agent-originated transactions and supporting disputes. The card token is a substitute payment credential. It is not a cryptocurrency or a tokenized investment.
The practical attraction is continuity. A payment system that already connects issuers and merchants can supply part of the machinery needed when software initiates a purchase. That does not automatically resolve whether the agent interpreted the customer's instruction correctly. Mastercard and Google addressed this separate problem with Verifiable Intent in March 2026: a cryptographic record connecting authorization with the agent's resulting action. The March announcement described subsequent integration into Agent Pay; Mastercard's September merchant announcement says Agent Pay uses it.
On September 9, Mastercard introduced Agent Connect and expanded Agent Suite for Merchants. The offering covers merchant product information, cart details and transaction connections. Merchants can choose participating AI experiences while retaining pricing and fulfillment rules. The announcement starts in the United States and describes participating companies' plans; future capabilities remain subject to availability. It also says transactions can use credentials from any network, with Agent Pay supplying additional capabilities for Mastercard transactions.
The sequence matters: a payment credential helps execute a purchase, while a merchant connection helps ensure that the agent is buying an available product on current terms. Neither eliminates the need to check the other. An authenticated purchase of an unavailable item is still a customer-service problem.
Visa, Amex and payment processors are addressing different problems
Visa's Trusted Agent Protocol helps merchants recognize approved agents through signed requests. A retailer normally has good reasons to distrust automated traffic. Identification gives it a way to distinguish a permitted purchasing agent from an unknown bot, without treating every automated request as a customer.
Visa's Intelligent Commerce Connect announcement, dated April 8, 2026, adds payment initiation, tokenization, authentication and spending controls through one integration. It describes support for Visa and other networks, different token vaults and several agent-commerce protocols. At announcement, it was in pilot with selected partners. That evidence supports an integration strategy; it does not establish universal production access today.
American Express makes the responsibility question unusually explicit. Its Agentic Commerce Experiences developer kit separates account enablement, intent information and payment credentials. The page lists those specifications as available from April 14, while agent registration and cart-context specifications remain under development. Its proposed Agent Purchase Protection would cover eligible errors by registered agents when Amex receives authenticated purchase intent. The page still describes the protection as future-facing. Listed conditions include eligible US cards, a return attempt where possible and claim review; subjective instructions such as “best” may not qualify.
The benefit of that specificity is that it exposes a design problem. “Buy a good chair” leaves more room for disagreement than an approved model, maximum total price and delivery deadline. A protection policy has to decide how to handle that difference. Readers should evaluate the terms actually available to them, rather than treat the headline as a blanket guarantee.
PayPal's Agent Ready documentation, updated June 10, describes Braintree paths for both OpenAI's Agentic Commerce Protocol and Google's Universal Commerce Protocol. Adyen Agentic, announced June 16, offers modular APIs intended to let enterprises participate across conversational commerce channels. Its announcement specifies limited availability for US enterprise merchants, with expansion planned. These approaches matter to merchants that want to extend an existing processing relationship instead of building a separate payments operation for every assistant.
The protocols are not interchangeable
The initials can make the market look more standardized than it is. They describe several kinds of coordination, with overlapping capabilities and different adoption requirements.
- Google's Agent Payments Protocol, AP2, uses signed mandates to connect user instructions, a cart and payment. It distinguishes approval with the human present from bounded advance delegation. Its design spans several payment methods.
- The Agentic Commerce Protocol, ACP, developed by OpenAI and Stripe, defines an API-based checkout exchange between buyers, agents and sellers. It helps the parties communicate the transaction.
- Google's Universal Commerce Protocol, UCP, addresses commerce capabilities such as carts, catalog queries and identity linking. Retailers choose which capabilities to implement; support is not automatically identical everywhere.
- Visa's Trusted Agent Protocol concerns recognition of an agent and signed information sent to the merchant. Mastercard's Verifiable Intent concerns evidence of the user's authorization and the action taken.
An implementation can need several of these together. Recognizing the agent does not prove it selected the right product. A complete cart does not prove a customer authorized financing. A signed instruction does not establish that the merchant shipped anything.
Stripe's own account of early deployments emphasizes difficulties such as inconsistent catalog formats and current inventory. Those are useful counterweights to frictionless-checkout demonstrations. Retail integration work continues even when a model can navigate a website impressively.
For a merchant, a sensible interoperability test is concrete: can the same order, variant, price and permission survive the handoff between systems? Can the transaction be reconciled and refunded afterward? Shared terminology is a starting point for that test.
Financing could become a decision made in the background
Consider a hypothetical customer who approves a $900 appliance purchase. Their assistant finds a cash offer, a card reward and an installment plan. The lowest monthly payment may have the highest total cost. A reward may be outweighed by interest. A promotional rate may require repayment by a particular date.
The US Consumer Financial Protection Bureau's explanation of promotional financing distinguishes zero-interest promotions from deferred-interest offers, under which failing to clear the promotional balance can trigger interest attributable to the earlier period. It is a US educational explanation, not a description of every product or country's rules. The distinction illustrates why an agent needs the actual terms, rather than a marketing label.
For this hypothetical buyer, “minimize what I pay” is incomplete. Does it mean total cost, cash due today, avoiding new borrowing or keeping a particular account balance available? Those priorities can conflict. A useful assistant would surface the conflict before choosing a financial obligation.
Our proposed permission design separates buying the item from opening or selecting credit. The customer could allow an existing payment instrument within a budget while requiring a fresh decision for a loan, recurring charge or material change in repayment terms. That is a design recommendation, not a claim that every current product supplies those controls.
There is also a commercial conflict worth examining. An assistant might be paid by the customer, the merchant, a lender or several parties. A merchant can rationally pay for higher conversion while a buyer wants lower expenditure. Readers deserve to know whose objective shapes the ranking. Financial institutions that can explain this clearly have a stronger story to tell than those offering another generic promise of personalization.
A permission boundary needs to survive a messy order
Imagine a small design studio allowing an agent to order a specific printer cartridge from approved suppliers, within a monthly consumables allowance. The instruction seems straightforward until the supplier offers a bundle, shipping pushes the total over the limit, or a timeout leaves the agent unsure whether the first order succeeded.
We would assess that system through the following sequence:
- Record the permitted product, supplier conditions, total cost and expiry of permission. Make substitutions and recurring purchases separate choices.
- Check the final cart against those conditions before payment, including taxes, delivery and any changed terms.
- Enforce limits in the payment or execution system. A reminder in the model's conversation is a weaker control than an actual rejected transaction.
- Preserve one order reference through retries so an ambiguous response can be investigated before another purchase is created.
- Give the customer an understandable receipt and a usable path to cancel, return or dispute the order.
This is a proposed evaluation procedure, not a report of a test BIG CHANGE performed. It deliberately includes an ordinary operational failure. A system that handles a malicious instruction but accidentally orders the same supplies three times has still failed its customer.
The scope of the delegated authority matters as much as the spending ceiling. A purchase below the limit can disclose an address to an unintended merchant or create an unwanted subscription. Clear permissions reduce ambiguity; they do not make every judgment mechanical.
The optimistic case is substantial
Well-designed payment agents could make careful comparison less time-consuming. Small businesses could reconcile routine purchases with orders and invoices more consistently. Customers could retain control over meaningful choices while delegating repeated form-filling and conditional checks.
Existing networks offer a plausible route to adoption because merchants do not have to abandon familiar payment relationships to experiment with a new interface. Protocols and common integrations could also reduce duplicated work. The result would be useful even if customers continued to choose most products themselves.
The opportunity extends beyond shopping carts. Software buying a short burst of computing or a single data request raises different pricing and permission requirements. Mastercard's Agent Pay for Machines announcement, dated June 10, explicitly spans cards and stablecoins. We examine that intersection in the second article, because the form of money changes settlement and recovery choices.
The pessimistic case is about incentives and accumulated mistakes
Removing friction can make a good decision easier to execute. It can also make a bad decision easier to repeat. Individually modest authorizations may accumulate across assistants and services, especially when each system sees only its own allowance.
The institution that controls the agent's shortlist could gain considerable influence over merchants. Sellers may face pressure to pay for visibility or fit the assistant's preferred commercial arrangements. This is a risk to investigate, not an allegation that the cited providers already operate such a system. Useful safeguards would include explanations of ranking, visibility into commercial incentives and meaningful merchant choice.
The broadest risk is that technical evidence of permission becomes difficult for a person to contest. An audit record can show what was signed while leaving a dispute about what the customer understood. Recovery must remain understandable to the person whose money moved.
That gives the industry a more demanding measure of progress than the number of announced partners. We want to see completed purchases that remain correct after returns and exceptions; total customer cost after fees and financing; time taken to resolve mistakes; and results that identify the markets, eligible users and transaction types involved. Merchants also need evidence of incremental value after integration and support costs.
Mastercard, Visa, Amex, processors and agent builders each hold part of that evidence. An account of one real deployment, including a failed transaction and who fixed it, would help readers judge the change far more precisely than another prediction about the size of the market.
