Mastercard Agent Connect for merchants: they standardised your catalog, not your money

What Mastercard announced on September 9, 2026

On September 9, 2026, Mastercard launched Agent Connect. The pitch is simple and genuinely useful: instead of building a separate technical connection to every AI assistant, chatbot and shopping surface that might send a buyer your way, a merchant integrates once. Through that one connection, an agent can search the merchant's products, assemble a cart, and move the shopper toward a payment the shopper authorises.

Alongside it, Mastercard expanded its Agent Suite for Merchants. As PYMNTS reported, the suite helps businesses make "merchant-defined information – including product details, pricing, availability and fulfillment options – accessible across models, platforms and agent experiences." Mastercard's framing for why: "Consumers are increasingly relying on AI-powered assistants to discover products, compare options and decide what to buy."

Chief Product Officer Jorn Lambert put the strategic view more bluntly, per crypto.news: "AI agents will change the buying interface again." Mastercard also announced work with Anthropic on a commerce-agent blueprint pairing Claude models with Mastercard's payment capabilities, so merchants can build shopping agents inside their own channels rather than only renting someone else's. (We covered the open-source half of that story when Anthropic shipped Claude Commerce Agents on September 2 — a shopping brain with, deliberately, no wallet in it.)

On the money side, the piece that carries authorisation is Agent Pay, which uses tokenized permissions to verify that a customer actually approved an agent before a purchase completes — separating an authorised transaction from an agent doing something the shopper never asked for. That builds on Agent Pay for Machines, the June rollout backed by 30-plus firms including Stripe, Adyen, Checkout.com, Coinbase, Cloudflare, Global Payments, OKX, Ripple and the Solana Foundation, which we analysed from the API provider's side.

Give it credit first: the seller finally got invited

Three weeks ago we wrote that 26 companies were writing the agentic payments standards and not one of them was a seller. Agent Connect is the counter-example, and it deserves to be recorded as one. It is aimed squarely at the business on the receiving end of the transaction. Mastercard's own positioning is that merchants keep control of branding, pricing and the customer relationship rather than being reduced to a fulfillment step after an agent has already closed the sale.

That is the right problem. When a machine does the comparing, the merchant's shop window stops being a shop window. Whoever owns the interface owns the comparison, and whoever owns the comparison sets the terms on which you get compared. A merchant with no machine-readable presence at all isn't losing the comparison — they're not in it.

So: one integration instead of twelve, live inventory instead of a stale scrape, structured product data instead of an agent guessing from HTML. All of that is work worth doing, and there's a real number behind the urgency. Mastercard's research found 31% of merchants plan to invest within a year in automated product search and comparison. That's a third of the market putting budget behind being findable by machines.

Now read the other three numbers

Published in the same research, and much less quoted:

• 46% of merchants named pricing and the final price the customer pays as the function they are least willing to let AI agents handle.
• 26% plan to invest in automated checkout completion — noticeably fewer than the 31% investing in discovery.
• Nearly 50% put multi-merchant bundling, autonomous checkout, or dispute management in the "later or never" bucket.

Line those up and a shape appears. Merchants are enthusiastic about being found by agents, cooler about being paid by them, and roughly half have decided that the dispute consequences of agentic commerce are a problem for later.

The first two are a rational reading of where the value is. The third is the one that doesn't survive contact with the rail.

Why "dispute management: later" isn't an option a card merchant has

On a card rail, disputes are not a feature you adopt. They are a property of the instrument. A card payment is a pull: the merchant presents a credential and asks an issuer to advance money the buyer does not hold at that moment. Because the money moves on a promise, it can be un-promised — and the window for that is measured in months, commonly up to 120 days from the transaction and longer in specific scenarios under the card network rules.

An agent does not shrink that window. If anything it stretches the ambiguity inside it. When a human clicks buy, the "did you authorise this?" question has one obvious answer. When software assembled the cart, picked the variant, and executed inside a mandate the shopper set three weeks earlier, the same question has several plausible answers — and the merchant is the party holding the goods, the shipping cost and the burden of proof. We went through who ends up carrying that in agentic commerce chargeback liability.

This is exactly why the card world is building an intent layer. EMVCo's draft agentic payments framework, published September 1 and open for comment until September 30, proposes "Intent Services" — a shared, stateful registry where participants can register and retrieve what a consumer authorised, before, during and after a transaction. Read plainly, that is a system for producing better dispute evidence for purchases that remain disputable. It is competent engineering for a real problem. It is also months of specification, then implementation, then issuer adoption away.

So the honest summary of a merchant's September 2026 position is this: you are being asked to invest now in being discoverable by machines, and to defer the part where machines paying you is safe — while the deferred part is the only one you cannot actually defer.

The catalog was always the easy half

Here is the structural observation worth taking away from the Agent Connect launch, and it isn't a criticism of Mastercard — it's a description of what can and cannot be standardised by a card network.

A merchant's catalog is information. It is already in a database. Publishing it in a machine-readable form is an integration project with a clear finish line: agents can now read your products, prices, availability and fulfillment. Hard work, but bounded work.

A merchant's money is not information. It is a claim, routed through an acquirer, funded by an issuer, governed by network rules, and reversible for months. No integration layer changes that, because the reversibility isn't in the integration — it's in the instrument. Agent Connect can make you findable by every shopping agent on earth and your merchant discount rate, your settlement timeline and your dispute exposure will be identical the day after.

There's a second cost that gets underweighted. A live feed of product, price, availability and fulfillment "across models, platforms and agent experiences" is a new operational surface you own. Every price change, every stockout, every shipping-cutoff edit now has to propagate to surfaces you don't control, and a mismatch between what an agent quoted and what you'll honour is a customer service problem at best and a dispute at worst. Merchants who said they won't hand over pricing should notice that publishing a live, machine-queryable price to every comparison agent is a pricing decision — it's the one where margin actually goes.

The offer that is also the payment

There is a format where discovery and payment are the same message, and it has been shipping in production all year.

When a client requests a paid resource, the server answers with HTTP 402 Payment Required. That response carries the price, the accepted networks and schemes, and where to pay. The client signs a payment for exactly that amount and retries. The resource comes back. That's it — one round trip, no feed to synchronise, no registry to join, no network to integrate with. x402 is an open, neutral standard, contributed by Coinbase and now governed by the x402 Foundation at the Linux Foundation.

Notice what the 402 is, in the vocabulary of the Agent Connect announcement. It is merchant-defined information — your price, your terms, your resource — expressed in a form a machine reads natively. It is a catalog entry and a checkout in one response. And because the agent pushes a signed payment rather than presenting a credential, the authority to spend is the amount signed. There's no mandate state for four parties to look up, because the remaining budget is just the wallet balance.

The consequence for a seller is the part that matters: settlement is final on confirmation. Nothing to dispute, nothing to defer to "later or never."

Where Payzum sits — and where it doesn't

Payzum is the middleware/proxy in front of your existing API. It is not the facilitator — settlement runs through an external facilitator, currently Coinbase's. You do not implement a protocol, and you do not rewrite an endpoint.

In the dashboard you configure the endpoint you already have, the API key or bearer token it already expects, and a price per route. Payzum publishes an x402 URL, answers the 402, handles settlement through the external facilitator, and then proxies the paid call to your real endpoint using your own key. The agent's USDC on Base goes non-custodially to a wallet you control — Payzum never holds it. Confirmations on Base are typically around two seconds.

For the human-approved side of agentic commerce — the cart an agent builds and a person confirms — the relevant products are ordinary Payzum ones: hosted checkout, payment links and buttons, invoices with expiry and overpayment detection, and subscriptions. Non-custodial, optional auto-conversion to USDC or USDT for volatility, and no chargebacks, because there is no acquirer in the path to reverse anything. For a physical counter, the POS generates a fresh QR per sale, with PIN cashiers and per-cashier analytics.

One honest boundary: Payzum is crypto-only. We accept crypto and settle in crypto. If what you need is an AI agent paying with a tokenized Mastercard credential and funds landing in your bank account, Agent Connect and Agent Pay are the right products and we are not a substitute for them. The two tracks answer different questions.

How to put a price on an endpoint, step by step

1. Pick the resource. An API route, a dataset query, a model endpoint, an MCP tool, a report behind a login. Anything a machine consumes and a human currently buys through a sales process.
2. Configure it in Payzum. Paste the endpoint URL, add the API key or bearer token it expects, set a per-call price. No code, no protocol implementation, no redeployment of your service.
3. Publish the x402 URL. Payzum returns the 402 with your price to any agent that calls it, settles through the external facilitator, and proxies the paid request to your real endpoint with your key.
4. Watch it settle. USDC on Base arrives at your own wallet address. Signed webhooks fire on payment events, and the full audit log shows every call that was paid for.

Who this is actually for right now

Agent Connect is built for retail catalogs, and for retail it will matter — eventually, at the pace consumer trust allows. We looked at that pace in the agentic commerce trust gap: 85% of consumers will let an agent shop, roughly one in ten will let it pay without them. But if you look at where agents are actually spending money today, the ticket sizes tell you it isn't groceries. Public x402 settlement data has averaged in the low tens of cents per transaction — the signature of machines paying for API calls and inference, not people buying sofas.

So the businesses with a real 2026 opportunity here are the ones selling something a machine consumes directly:

• API and data providers. A pricing feed, a compliance check, a geocoder, a market-data endpoint. Today it sells through an annual contract and a sales call — both of which an agent working inside a session budget cannot complete. A per-call price makes you reachable in the same request that discovers you. More on the mechanics in x402 pay-per-API-call.
• SaaS and tooling with an MCP server. If you've exposed tools to agents already, you've done the hard half. The missing half is a price on the call instead of a signup form the agent will simply leave.
• Publishers and research shops. Metered access to an archive or a report, priced per document, with no subscription for a machine to negotiate.
• Online sellers who also want the human side clean. An agent-assembled cart that a person confirms, paid with a hosted checkout or a payment link, settles in seconds to your wallet with no 120-day tail behind it.

Agent Connect vs a paid endpoint: the comparison

The honest counter-arguments

"Most of my customers are humans with cards. This is irrelevant to me."

For most merchants today, that's simply true, and we're not going to pretend a hardware store should rewire its payments around AI agents. Agent Connect is the sensible move for a retail catalog, and card acceptance is going nowhere.

The narrower claim is this: if part of what you sell is consumable by software — an API, a dataset, compute, a tool — that part has a channel available right now that requires no committee, no comment period and no issuer adoption. It's additive. Putting a per-call price on an endpoint doesn't remove a single card payment from your existing business.

"Finality cuts both ways. If an agent buys wrong, I'd rather there be a chargeback."

That's a fair objection and it's the strongest one against our position. For consumer goods with refund expectations, reversibility is a genuine consumer protection, and on-chain finality means the recourse is your refund policy rather than a dispute process. We say that plainly because it's true.

Where the argument flips is ticket size. Nobody disputes a $0.002 API call — the cost of processing the dispute exceeds the transaction by orders of magnitude. On per-call machine commerce, reversibility is a cost you pay on every transaction for an option no one will ever exercise. Match the rail to the good.

"Isn't Payzum just another middleman standing between me and the agent?"

Payzum sits in the request path — that's what a proxy does — but not in the money path. The USDC settles to an address you control, not into a Payzum balance, so there is no float, no payout schedule and no account review that can hold your revenue. And the lock-in is low by construction: you keep your endpoint, your API key and your wallet. If a different protocol wins, what changes is a gateway configuration.