What Is Mastercard Agent Pay? AI Payments and the Merchant’s Role

“If AI shops on a customer’s behalf, does the merchant register its products with Mastercard?” Mastercard Agent Pay is not a place to list products. It is a framework for handling AI payments safely. It can make it easier for customers to delegate payments to AI. Through supported integrations, merchants can receive information that helps them verify the AI and the customer’s intent. The information available depends on the connection method.[1][2]

This article separates the roles of product information, customer permission, and payment for people considering integrations at Japanese online stores. Helping AI find products and enabling a store to accept AI payments require separate preparation.

As of September 10, 2026, official explanations of the framework are available, but we have not confirmed the conditions under which individual merchants in Japan can start using it. This is an introductory explanation based on materials including the October 14, 2025 explanation of the acceptance framework and the June 10, 2026 AP4M announcement. It is not breaking news. The materials reviewed do not specify an implementation version number.[1][2][3]

1. It supports payments, not product discovery

Agent Pay’s main role is to enable AI carrying out tasks for a person to participate in payments in a trusted way. Mastercard identifies transactions by registered AI agents, network tokens, customer intent, and explicit consent as its pillars.[1]

It is expected to reduce the need for customers to enter card details each time or give detailed payment instructions. Merchants, meanwhile, need to determine whether an approved AI agent is accessing their site and whether the customer authorized the purchase. The acceptance framework supports those checks. This is not evidence of measured increases in sales or reductions in customer inquiries.[2]

Consider a customer asking AI to order coffee beans. To learn about the product, the AI needs a separate route, such as search, a product data integration, or the store’s product pages. Registering products alone does not enable Agent Pay payments. Accepting Agent Pay does not mean products will appear in AI services, either.

The diagram below separates product discovery from the roles that support payment. Product information and order processing must also be in place to connect the whole shopping journey.

Agent Pay becomes relevant during checkout, after a product has been found. However, AI verification matters not only immediately before payment but also when the AI accesses the website. The official explanation includes a verification method using a CDN, which handles traffic before it reaches the website.[2]

2. Registered AI, customer permission, and tokens have different roles

Whether an AI agent is an approved participant is separate from whether the customer authorized that purchase. Even if both are verified, payment success is not assured.

Verify that the AI is registered

The Mastercard Agent Pay Acceptance Framework is a framework for merchants to accept AI transactions. The official explanation describes registering and verifying AI agents before allowing them to transact on Mastercard’s network. It makes individual AI agents identifiable and provides a basis for recognizing AI involvement in a transaction.[2]

Registration here does not mean registering a merchant’s products or creating a customer account. It concerns which AI agent is making the transaction. Knowing that access comes from an approved AI agent does not, by itself, give that agent permission to buy any product it chooses.

Verify what the customer authorized

The official explanation uses the term “Purchase intent data” for data that conveys the customer’s intent. It describes this as including cart contents, transaction limits, and the period for which permission is valid. This data may help merchants trace what happened when handling a customer dispute.[2]

However, we have not confirmed that every merchant will see this information in its management dashboard. Merchants need to check what information they can receive and store through their chosen connection method. A record of permission is also not a guarantee against refunds or disputes.

Use tokens to handle payment information

A network token is payment information used in place of the card details themselves. Agent Pay’s explanation describes using registered AI agents and tokens to make transactions traceable and verifiable.[1][2]

The acceptance framework calls the payment information used for AI transactions “agentic tokens.” It describes a method that sends this information to an existing checkout form as a Dynamic Token Verification Code compatible with standard card payment fields. This is payment information, not a product ID or the customer’s permission itself. Its role also differs from API authentication, which authorizes a technical connection.[2]

3. Follow a coffee bean order from start to result

The following is a fictional example for explanation. It does not indicate that transactions under these conditions are available in Japan, nor is it based on testing an actual order or exchange of data.

A customer asks AI to buy one bag of coffee beans with the product ID “BEAN-200” for no more than ¥3,500, including shipping. The currency is Japanese yen (JPY), and permission is valid only for that day. Assume the AI can read the product page and that the necessary connection endpoints and authentication are ready. The IDs and amounts below are illustrative, not official API field names.

Find the store and check the product and total

The AI finds the store through a separately provided search or product information channel. It then checks the price and stock for “BEAN-200” on the store’s product page or through a connection endpoint. The materials reviewed do not confirm that Agent Pay provides a store directory or product search API.

The store shows a tax-inclusive price of ¥2,400 for one bag. The AI provides the shipping address, and the store adds ¥600 for shipping, bringing the total payment to ¥3,000. This example assumes tax is included in the product price and there are no other charges. The shipping-inclusive total is not final until the destination is known.

Suppose the store tracks this checkout as “CHECKOUT-001.” This does not yet mean the order is complete. It is a checkout record that brings together product information, shipping conditions, and the total.

Compare the current order with the customer’s permission

Before the AI proceeds to payment, the product “BEAN-200,” the quantity of one bag, and the ¥3,000 total need to be checked against what the customer authorized. The conditions include the product and quantity, not just the ¥3,500 limit and validity period. The official description of Purchase intent data covers these kinds of cart contents, limits, and periods.[2]

If shipping changes and the total becomes ¥3,600, the purchase falls outside the original permission. Even if the total stays within the limit, changing the quantity to two bags would make it a different order from the one authorized in this example. These are situations that require consent to the changed conditions rather than proceeding under the original permission. However, the materials reviewed do not confirm the screen for obtaining renewed consent or how errors are returned.

Check payment and order results separately

For the method that uses an existing form, the explanation describes a verified AI agent sending payment token information to the card entry fields. This then connects to the merchant’s payment processing. Verification of customer permission and payment approval must be treated separately.[2]

For illustration, suppose the store finalizes the order ID “ORDER-001” after payment succeeds. The checkout ID “CHECKOUT-001” and the order ID are different. Only when the store returns the order ID, one bag of “BEAN-200,” the ¥3,000 total, and the order status to the AI does the AI have the information needed to report the result to the customer.

If payment fails or its result is unknown, the order must not be shown as successful. Merchants also need to handle duplicate orders caused by resubmission and cases where payment has been made but no order record exists. Because specific response fields and retry specifications have not been confirmed, this example is intended only to trace the roles involved in shopping. These materials alone do not establish who creates the permission record or which API passes it to the merchant.

4. Roles that remain with the merchant’s payment provider and website

Even if Mastercard provides the payment framework, the merchant’s payment provider and order system still have work to do. What matters to merchants is not simply the phrase “Agent Pay support,” but what their own setup provides.

Party	Main role	What not to confuse
AI provider	Selects products and proceeds with the purchase according to the customer’s request	AI registration alone does not authorize an individual purchase
Mastercard	Provides a framework for AI registration and verification, and payments using tokens	This is not described as a complete product listing or order management service
Merchant’s payment provider	Supports the merchant’s card payments	Being named as a partner does not establish availability under the merchant’s own contract
Merchant and e-commerce system	Handle products, inventory, shipping charges, orders, shipping, and returns	Successful payment does not remove shipping or after-sales responsibilities
CDN and similar providers	Can verify AI access under the framework	Verifying access is separate from customer consent

Merchants need these roles to connect. Alongside payment provider support, the amount of order information and customer permission data they can receive will inform their decision.[2]

The official explanation describes implementing Web Bot Auth on a CDN to verify AI without requiring merchants to add new code. It also describes a method using existing checkout forms. “No coding” does not mean there is no need to select supported services, configure them, or check how they operate.[2]

Web Bot Auth and HTTP Message Signatures (RFC 9421) are not the same standard. The October 2025 explanation treats Web Bot Auth as a mechanism built on RFC 9421. The materials reviewed alone do not establish its standardization stage or implementation version as of September 2026.[2]

5. AP4M complements Agent Pay for repeated machine payments

Agent Pay for Machines (AP4M) is not simply another name for Agent Pay. It is a service Mastercard announced on June 10, 2026 to support frequent, small payments by machines and AI. The official announcement explicitly positions it as a complement to Agent Pay.[3]

While Agent Pay addresses trusted AI participation in payments, AP4M focuses on ongoing transactions between systems behind the scenes. It is described as allowing organizations to set spending limits and permission rules while supporting the movement of funds through multiple methods, including cards, accounts, and stablecoins.[3]

In the example of ordering one bag of coffee beans, Agent Pay’s support for payment on a customer’s behalf is the first relevant use. By contrast, if AI running a store’s operations repeatedly buys external data or computing resources, that is closer to AP4M’s intended use. This compares their roles; it does not present a setup that a merchant can use immediately.

The AP4M announcement names collaborators working to validate use cases and develop common rules. Even if a payment provider appears among participating or supporting companies, this does not mean the service has been rolled out to all of that provider’s merchants in Japan. Pricing, eligible regions, and availability under different contracts have not been confirmed in the materials reviewed.[3]

6. Japanese merchants can assess product listings and payment support separately

What to investigate	What the official materials confirm	What merchants can conclude
Agent Pay’s purpose	It addresses registered AI agents, payment tokens, customer intent, and consent	It is mainly a payment consideration, not a product listing service
How merchants accept it	Methods using existing checkout forms and deeper integrations are described	This does not establish that every store can use it without configuration
Conditions for use in Japan	Merchant-specific eligibility and application procedures have not been confirmed in the materials reviewed	Production use at an individual store cannot be confirmed
Relationship with AP4M	AP4M was announced as a complementary service for frequent, small machine payments	Its use cases can be considered separately from ordinary online shopping

The materials we could verify were the Agent Pay product explanation, the acceptance framework explanation, and the AP4M announcement. The acceptance framework article says it is being shared on Mastercard Developers and that feedback is being sought to improve it. However, the developer resource linked from the announcement returned a 404 error, meaning the page could not be found, when checked on September 10, 2026. We therefore could not cross-check API endpoints, required fields, or signature formats there. This is not evidence that no public API exists, so this article does not present implementation instructions.[2]

We therefore do not conclude that there is no public API. At the same time, we cannot present a Japan-specific merchant application form, participation approval conditions, supported payment provider contracts, or dashboard procedures as verified.

If the goal is only to help AI find products, there is no need to consider Agent Pay as a place to register them. If a merchant wants to serve customers who delegate payment to AI, the question is whether verification of registered AI, customer permission, payment, and order results can be connected.

Accepting Mastercard card payments alone does not establish that all Agent Pay features are available. Once the conditions for Japan and the scope offered by a merchant’s payment and e-commerce services are clear, the merchant can assess what additional work is needed. For now, the practical outcome for merchants is to separate product listing initiatives from payment support plans.