Signal — agentic payments
Payment networks are learning to identify the agent
Software is starting to buy things on a customer’s behalf. For such a payment to be worth trusting, someone has to be able to establish which piece of software is acting, which person it acts for, and what that person allowed it to do. One payment provider has now published a protocol aimed at carrying that information, and says work on an interoperability framework with two card networks has begun.
Primary source published 11 September 2026Evidence checked 19 September 2026
In one line
An agent’s payment is only as trustworthy as its answer to “who are you, whose money is this, and what were you permitted to spend it on” — and one provider has published a protocol that seeks to carry that answer, with a cross-network framework described as work that has begun.
The order nobody at the counter can vouch for
Illustration — fictional
Lucia and her restaurants are invented for this page. No part of the scene below is a report of a real merchant, a real order or a real outcome; it exists only to state the operator problem in ordinary terms.
Picture Lucia, a fictional operator running eleven trattorias across three cities. On a Thursday evening an order lands in the tablet at one of her locations: eight covers, two set menus. Nobody on her team spoke to a customer. No one filled in a form. In this invented scene the order was placed by a piece of software shopping on someone’s behalf — an agent, in the language the payment industry has settled on.
Her floor manager has no way to tell that order apart from one placed by software that is confused, misconfigured, or acting for someone who never approved the spend. The till was designed for a world where a human held the card, so it can report that a charge cleared and nothing more. This page makes no claim about how often any of those cases actually occurs; that is exactly the number nobody at the counter has.
The gap is not invented, even though Lucia is. It is the gap a published agentic-payment protocol sets out to address: when the buyer is software, a payment can only be examined afterwards if it carried something a card number never carried — an account of who was acting, for whom, and within what limit.
What the payment does not currently tell her
- Which piece of software placed this order, and whether it is one her booking channel has ever seen before.
- Which customer it was acting for, and whether anyone can later be asked to confirm that.
- What the customer actually permitted — one order tonight, or a standing arrangement the agent has interpreted generously.
- Who she talks to when the party does not arrive and the charge is disputed three weeks later.
What changed
Plain meanings
- Agent
- Software that acts for a person — searching, choosing and in this case paying — rather than a person clicking through a checkout themselves.
- Wallet
- The consumer payment app money leaves from, such as the ones people already use to pay by phone.
- Acquirer
- The company that processes card payments on the merchant’s behalf and settles the money into the merchant’s account.
- Know Your Agent
- A check on the software itself — which agent it is, who runs it, whom it is acting for and what it is allowed to do — modelled on the identity checks banks already run on people and companies. Described in the cited announcement as the subject of collaboration that has begun, not as a published standard.
On 11 September 2026, Ant International announced the first phase of its Agentic Mobile Protocol (AMP) — an openly published set of rules for how an agent presents itself when it tries to pay. A protocol here means an agreed, documented format that any implementer can read and build against. What each participant implements, in what order, and how completely is a matter for each implementer; this page does not claim to know it, and the announcement does not set it out.
Two parts of that announcement matter to an operator. The first is who is named in it: digital wallets (the apps consumers already pay from) and acquirers (the companies that process card payments on a merchant’s behalf — the merchant’s side of the rail). Ant International says the ten named wallet partners will support AMP during Phase I. The second is what it says comes next: Ant International said it has begun collaboration with Mastercard and Visa on an interoperability framework for Know Your Agent, the agent-side counterpart to the identity checks banks already run on people and businesses.
The direction is the story, and the direction is all the cited evidence carries. Identifying the agent is a question one provider has now published a protocol around and describes as the subject of collaboration with two card networks. On this evidence it is not built into the payment rails, not standardised across networks, and not a precondition for anything; it is an announced intent an operator can watch.
Phase I names ten digital wallets — Alipay, AlipayHK, DANA, GCash, KakaoPay, MPay, TNG eWallet, TrueMoney, Toss and Starryblu — which Ant International says will support AMP during Phase I, alongside seven acquiring partners: Adyen, Allinpay, Checkout.com, Fiserv, Global Payments, Nuvei and Worldline.
A named participant is a participant named in a rollout announcement. It is not a statement that the capability is live for a given merchant, market or checkout, nor that any named party has completed its side.
SourceAnt International11 September 2026
Ant International describes those ten wallets as serving 1.5 billion user accounts.
This counts wallet accounts, not agents, not orders and not completed purchases. It describes potential reach, not activity.
SourceAnt International11 September 2026
AMP has been open-sourced on GitHub, with source code, developer SDKs and technical documentation published for platforms, wallets, acquirers and financial institutions.
Published code is an invitation to implement. It is not evidence that anyone has finished implementing it, and this page has not audited what the published specification requires.
SourceAnt International11 September 2026
Ant International, Mastercard and Visa have begun collaboration on a Know-Your-Agent interoperability framework intended to streamline agent onboarding and identification across networks.
Begun collaboration is the claim made. No completed standard, launch date or coverage commitment is stated.
SourceAnt International11 September 2026
Four questions an operator can ask about an agent-placed order
A card payment has long answered one question: is this card good for this amount? An order placed by software raises three more that an operator would want answered before treating the charge as settled evidence of anything.
Whose checklist this is
This is Obenan’s conceptual checklist for operators, written to make the problem discussable. It is not AMP’s implemented message order and does not describe any protocol’s fields, sequence or wire format. The cited announcement does not set out an implemented message order, so nothing here should be read as one. Whether a given payment can answer any of these questions depends on what the provider and channel in front of the merchant actually supply.
Question 1 of 4
Which agent is this?
An operator would want the order to carry some durable identifier for the software that placed it, rather than for it to arrive indistinguishable from ordinary web traffic.
Without it, every agent looks alike, and a misbehaving one cannot be told apart from a well-behaved one — or shut off without shutting off all of them.
Question 2 of 4
Who is it acting for?
An operator would want a way to reach whoever the agent acted for, whether that is an account, a customer record or a channel-side contact.
Without some route back to a responsible party, a dispute has no counterparty other than the merchant.
Question 3 of 4
What was it permitted to do?
An operator would want the scope of the customer’s permission to be recorded somewhere they can examine, rather than to exist only inside the agent’s own configuration.
Without it, the limit is whatever the agent believes it is, and “the customer approved it” cannot be checked by anyone else.
Question 4 of 4
And what did the authorisation actually establish?
An operator would want to treat a cleared authorisation as evidence about funds, and to keep the first three questions as separate facts recorded separately.
Collapsing the four into “the card cleared” is what pushes the risk onto whoever served the customer.
The four questions are: which agent placed this, who it acted for, what it was permitted to do, and what the authorisation itself established. They are Obenan’s framing of an operator’s problem, not a protocol sequence. Serving the customer is a fifth thing entirely, and no payment proves it.
Each question is cheaper to answer before the money moves than after it. Which of them a given order can answer at all depends on the provider and channel it arrived through.
Where this sits, and where it does not
Collapsing these stages into one event can obscure where risk sits. They are seven, each of which can happen without the next. The cited announcement describes a protocol aimed at two of them — as stages it seeks to support, not as stages it has been shown to deliver.
Organic discovery
An assistant, a map or a search result surfaces the restaurant at all, without anyone paying for that placement.
Not addressed
Paid exposure
The restaurant is shown because a placement was bought. Being shown is not being chosen.
Not addressed
Referral
Something hands the customer onward — a click, a hand-off to a booking channel, a deep link into an app.
Not addressed
Lead
An enquiry arrives that a human or a system could act on: a table request, a quote, a held basket.
Not addressed
Customer approval
A real person agrees to this specific purchase, at this price, under terms they saw. The protocol seeks to make this examinable; the cited evidence does not show it delivered.
Protocol aim
Payment
Money is authorised and settled. The protocol seeks to attach an account of who was acting and on whose behalf; the cited evidence does not show any such record in production.
Protocol aim
Fulfilment
The table is held, the party arrives, the food is served. Nothing in a payment protocol proves this happened.
Not addressed
- Protocol aim
- The announcement describes an aim to carry identity and permission alongside the payment. Aim is what the evidence establishes; delivery is not.
- Not addressed
- Whether an agent finds the restaurant, recommends it, sends a customer, or whether that customer is served, is settled elsewhere.
SourceAnt International11 September 2026
What this evidence does not prove
This page rests on one announcement from one participant. That is good evidence of an announced rollout and of implementation intent. It is not evidence of anything downstream, and reading it as such is the mistake most likely to cost an operator time.
- It does not show that any merchant has switched this on, or that a named wallet or acquirer has completed its side.
- The cited announcement reports no transaction volume. No purchase count, value or growth figure is stated in it, and none should be inferred from wallet account totals.
- The cited announcement reports nothing about whether orders placed this way were served, cancelled or disputed.
- It is not a statement of universal availability. The cited evidence establishes only the named Phase I participants; it does not establish that the option will appear at a given checkout, in a given market, or for a given merchant.
- It does not establish a cross-network standard. The Know Your Agent framework is described as collaboration that has begun, with no published specification, timetable or independent verification alongside it.
- It does not establish any effect on fraud, chargebacks or disputes. The cited announcement reports no such outcome data, and this page has not looked for any elsewhere.
Held to that boundary, the signal is still useful: it tells an operator which question one provider is building around, which is enough to prepare for without treating an announcement as a finished rail.
Independence
Ant International, Mastercard, Visa and every wallet and acquirer named on this page are the subjects of public-source reporting. Obenan has no partnership, endorsement, certification, pilot, integration or special access with any of them, and this page claims none. Everything here is drawn from the published announcement listed under Sources and has not been independently verified.
What to do next
None of this requires a project. It requires knowing the answers before someone asks for them under pressure.
Ask your payment provider one question in writing.
Whether they participate in agent-identification work, and what metadata they will show you about an agent-initiated payment when one arrives. Keep the answer; it dates quickly.
Find out whether agent-placed orders already reach you.
Ask each booking channel, marketplace and payment provider what order-level metadata they expose — channel or source identifier, API client or integration ID, user-agent and bot classification, and any agent or automation flag — then look for orders carrying those markers. Count them for a month before deciding they do not matter.
Record approval separately from payment.
Whatever system holds the order should be able to say who approved this purchase, not only that a charge cleared. Those are different facts and they will be disputed separately.
Give managers a rule for the ambiguous order.
One line is enough: what to accept, what to confirm with a human, and who to escalate to. Consistency across locations is worth more than the exact threshold.
Keep the facts an agent reads about each location correct.
Hours, address, service area, menu and price accuracy are what a buying agent acts on. This is discovery work, not payment work — but it is the part an operator controls today.
Revisit when a standard is published, not when one is announced.
The thing to wait for is a Know Your Agent framework with a published specification and named adopters on your rail — not further statements of intent.
If an agent-placed order arrives at one of your counters tomorrow, the useful question is no longer “did the card clear”. It is “what did this payment tell us about who is buying, and did we write that down”.
Read next
The payment is the last stage. The facts an agent reads before it ever reaches a payment are the part a merchant controls today.
Why merchant-authored truth has to be correct before agentic payments matterHours, availability, policy and price are what a buying agent acts on. This briefing sets out why that layer decides the outcome long before any payment rail is involved.Sources
One primary source, cited for every number on this page. Figures and participant lists are as published by the announcing party and have not been independently verified.