Agent Payments Protocol (AP2): How AI Agents Pay Securely on Your Behalf

TL;DR — AI agents have started shopping on your behalf; but how does an agent make a secure payment for you? The answer is the Agent Payments Protocol (AP2), announced in late 2025 and rapidly maturing in 2026. This protocol lets an agent prove to a merchant and payment network that a real user authorized a specific purchase — without the agent ever touching your banking data. In this piece I explain, from the field, how AP2 works (signed mandates, Checkout and Payment Mandates), its relationship to complementary protocols like ACP, what it means for e-commerce and payment regulation in Turkey (BDDK, KVKK), and what businesses should do starting today.

Imagine a scenario. You tell your AI assistant: "I'm going to Istanbul next week, here's my budget, find a suitable hotel and book it." The assistant researches, finds options, picks one, and... makes the payment. Sounds great. But wait: did that assistant use your credit card? How will the merchant know you really authorized this payment? If there's fraud, who's liable — you, the company that made the agent, the merchant, or the bank?

This is the crux of agentic commerce (AI agents shopping). The traditional payment system is built on the assumption of a human sitting at the screen, entering their card, pressing "confirm." When the agent steps in, that assumption collapses. The agent is neither a human nor a "merchant" in the classic sense. It's neither safe for it to hold the card directly nor practical for it to wait for user intervention each time.

In the field we've discussed this question a lot over the past year, because my e-commerce clients ask "should we be preparing for agentic shopping too?" My answer is clear: you should prepare, but first you must understand how payment becomes secure. AP2 was born precisely to fill this gap. And let me stress: this topic isn't a fad or temporary hype; when the payment world's largest institutions have sat at the table, it's a sign this shift will come sooner or later. The question isn't "will it happen" but "when, and who's ready."

The Agent Payments Protocol (AP2) is a vendor-neutral protocol. Its core function can be summed up in one sentence: enabling an AI agent to prove to a merchant or payment network that a real user authorized a specific purchase.

It was announced in September 2025 with over 60 founding partners — including Mastercard, PayPal, Coinbase, American Express, Salesforce. So this isn't a small startup's experimental idea; it's a standardization effort where the payment world's heavyweights sat at the table. This momentum grew in 2026: in May 2026, the FIDO Alliance announced it had taken in both Google's AP2 and Mastercard's "Verifiable Intent" approach. This signals the protocol moving from a single company's control toward becoming an industry standard.

The core problem AP2 solves: enabling the agent to pay, but doing so without the user needing to manually confirm each time and without the agent accessing sensitive banking data. It strikes the balance between two extremes — on one side the over-cautiousness of "let the agent do nothing, stop and ask at every step," on the other the dangerous convenience of "give the agent the card and let it handle the rest." AP2 opens a middle path based on provable authorization.

At AP2's technical heart sits the concept of a "mandate." Think of it as turning the user's intent into a cryptographically signed, verifiable document. There are two types of mandate, and understanding the distinction is key to understanding the protocol.

Checkout Mandate. Defines what the user wants to buy and under what conditions. For example, "buy this product, up to this price, by this date." This mandate draws the boundaries of the user's intent. The agent cannot step outside these boundaries.

Payment Mandate. Carries the details of the payment itself: amount, payment instrument, timing. This mandate proves the payment authorization, like "pay this amount, from this card, at this time."

Each mandate moves between "Open" and "Closed" states depending on the purchase's status. If the cart is still forming, the mandate is open — intent is defined but the purchase isn't final. When the purchase is finalized, the mandate closes and becomes an immutable authorization record. This state model gives a clear answer to "when did the user actually authorize what."

"

The beauty of this architecture: in a dispute, a merchant or bank can answer "did the user really authorize this purchase?" with cryptographic proof. In the traditional world, this rests on the assumption "the card info was correct, so the user must have done it" — which is no longer sufficient in the agent era. AP2 binds intent to proof.

A frequently confused point here: AP2 isn't an "agentic shopping" protocol on its own. It's actually a payment-consent layer. Other parts of commerce are handled by other protocols, and seeing how they complement each other matters.

ACP (Agentic Commerce Protocol) is the commerce/checkout layer: how the agent talks to a merchant, how it adds a product to the cart, how it runs the checkout process. AP2 is the payment-consent layer: proving the purchase was truly authorized by the user. These two aren't competitors but different layers. A full agentic purchase usually uses both — the agent checks out via ACP and proves authorization via AP2.

There are also protocols like x402, designed especially for machine-to-machine and micro-payments. These focus on HTTP-based payment flows and are useful in scenarios like pay-per-API-call. The ecosystem hasn't settled yet; multiple protocols coexist, and over time it'll become clear which dominate.

My recommendation to businesses is not to lock into a single protocol. The ecosystem is in motion; fully adopting one standard today and ignoring its rivals is risky. Instead, design your payment infrastructure layered and protocol-agnostic so you can adapt whichever standard prevails.

Layer	What it does	Example protocol
Discovery and commerce	Agent-merchant communication, product, checkout	ACP
Payment consent	Proof of user authorization	AP2, Verifiable Intent
Machine-to-machine payment	API/micro-payment flows	x402

Now to the truly critical part, because global protocols hit the wall of local regulation when they come to Turkey, and seeing this in advance is very valuable.

In Turkey, payment services are tightly regulated. Payment and e-money institutions operate under BDDK and related legislation; every new actor entering the payment flow is subject to regulation in terms of authority and liability. Agentic payment inserts a new actor called the "agent" into this chain, and the question is: is the agent a payment service provider, an agent of the user, or an extension of the merchant? This classification determines which obligations you're subject to, and it isn't fully settled yet. So before entering an agentic-payment design, clarifying the agent's role with your legal advisor is essential.

There's also a tension around strong customer authentication. In Europe PSD2, in Turkey the relevant legislation, requires strong authentication (like two-factor) in payments. When the agent steps in, the principle "the user was really there and confirmed" conflicts with the desire for "let the agent operate autonomously." AP2's signed-mandate approach tries to resolve exactly this conflict: the user grants a bounded authorization once (a signed mandate), and the agent acts autonomously within those bounds. But whether this authorization counts as "strong authentication" for regulation depends on the local regulator's interpretation.

On the KVKK side, the agent processes the user's purchasing preferences, payment behavior, perhaps location and time information. This is a new and intensive form of personal-data processing. What data the agent collects, how long it keeps it, and with whom it shares it must be disclosed from the start and, where necessary, tied to explicit consent. Especially in the "the agent decides on my behalf" scenario, transparency principles around automated decision-making come into play.

If you're an e-commerce business, agentic commerce is both an opportunity and a threat for you. The opportunity: in a world where agents discover and buy, being "findable" and "purchasable" by agents is a new channel. The threat: if your infrastructure can't talk to agents, your competitors will sell through that channel while you stay invisible.

Practically, I recommend a few steps. First, structure your product data. For agents to understand your product correctly, clean, structured product data (price, stock, features, conditions) is essential. Second, evaluate whether your checkout flow is open to programmatic access — think about whether you'll support protocols like ACP. Third, on the payment side, track authorization-proof mechanisms like AP2; talk to your payment provider about "agentic payment support."

But my most important advice: don't rush and bind your whole infrastructure to an immature standard. This area moves very fast. Instead, learn with a small pilot, stay protocol-agnostic, and scale your investment as the ecosystem settles. Those who move early but stay flexible win; those who move early and bet on a single horse take on risk.

To bring abstract concepts down to concrete, let me walk through how a typical agentic purchase flows with AP2; it's hard to understand why the protocol is designed this way without seeing the flow. Say the user told their assistant: "auto-order my coffee capsules whenever they run out each month, but don't exceed 500 lira a month."

In the first step the user grants an authorization, which becomes a Checkout Mandate: "this product category, this limit, this recurrence." The user signs this once, explicitly. This is the protocol's most critical moment; because the user's real intent is cryptographically fixed here. In the second step, when the condition occurs (capsules ran out), the agent initiates the purchase but doesn't fabricate authority on its own; it checks the boundaries of the mandate it holds. Is the price under the limit, is the category right, is the frequency appropriate? In the third step the agent runs the checkout process with the merchant (this part is the ACP layer's job), and when it reaches payment a Payment Mandate is produced: "pay this amount, from this card." In the fourth step the merchant and payment network verify these mandates — cryptographically confirming the user really granted this authority. In the fifth step the payment completes, the mandate moves to "closed" state, and becomes an immutable record.

The beauty of this flow is that at each step the answer to "did the user approve this?" is tied to proof. Even if the user isn't at the screen, the signed authorization they gave beforehand carries the legitimacy of that purchase. And if the limit is exceeded — say the capsules' price went over 500 lira — the mandate rejects it, the agent can't make the purchase, and returns to the user. This is exactly how the "autonomous but bounded" balance is struck.

An under-discussed but fundamental issue in agentic payment is the agent's identity. A human's identity is clear: they have a card, an ID document, authentication methods. So what is an agent's identity? Which agent, on behalf of which user, with what authority is acting? Without answering this, secure agentic payment is impossible.

In 2026, the solution on this side is progressing through verifiable identities for agents and the concept of an "agent wallet." The idea: the agent doesn't directly hold the user's banking data; instead it operates on a wallet logic carrying the authorizations (mandates) the user granted. The sensitive details of the payment instrument stay in the payment network; the agent only carries proof that "this user granted this authority under these conditions." So even if the agent is compromised, the attacker reaches not the card itself but only a limited and revocable authorization.

This is a very important design decision for security. In the traditional approach, when you say "give the agent the card," anyone who compromises that agent reaches the card. In the mandate-based approach, the authority is narrow, time-bound, and revocable. The user can say "revoke this agent's authority" at any moment and all mandates become void. The FIDO Alliance entering this area is no coincidence; authentication and verifiable identity are the cornerstone of agentic payment.

Seeing where this technology will first be useful helps you set your preparation priority. Let's look at a few concrete scenarios.

Travel. One of the most mature agentic scenarios. The user gives budget and preferences, the agent assembles the flight, hotel, transfer package and makes the payment in one go. Here mandate boundaries are critical: "total budget is this, must be refundable, on these dates." The travel sector will be an early winner of agentic payment due to high transaction value and complex bundling.

Recurring purchases and subscriptions. Repeating purchases like groceries, consumables, subscription renewals fit the agentic model very well. The user authorizes once, the agent orders periodically, within bounds. The value here is the user not having to bother each time but also not losing control.

B2B procurement. In business-to-business procurement, automatically re-ordering when certain conditions are met is a big source of efficiency. The agent orders from an approved supplier, within an approved price range, when stock drops. As B2B e-commerce grows in Turkey, this scenario is especially interesting.

Micro-payments and the API economy. The scenario where agents use other services' APIs and pay per call is the domain of protocols like x402. This is a layer people rarely see but is rapidly growing in the machine-to-machine economy.

The shared lesson of these scenarios: agentic payment won't arrive everywhere at the same speed. It'll start with high-frequency, low-complexity, clearly-bounded purchases and spread over time to complex, high-value transactions. Determine which scenario your sector is closest to and focus there.

When you one day trial agentic payment, you need to be able to measure "is it working?" There are a few indicators I track in the field. First, the out-of-authorization rejection rate: the share of transactions rejected because the agent exceeded mandate boundaries. If this is low, either the boundaries are well-tuned or the agent works well; if high, there's a disconnect between user intent and agent behavior. Second, the user intervention rate: how often the agent returns to the user asking "do you approve this?" Too high and the autonomy promise falls flat; too low and security risk arises; the right balance varies by product. Third, the dispute and refund rate: how much more or less dispute agentic transactions produce versus classic transactions. If AP2's proof structure works well, disputes are resolved more easily and the rate drops over time.

If you don't set up these indicators from the start, you can't distinguish whether agentic payment truly adds value or is just a show. You can't manage what you don't measure; in a new and risky area like agentic payment, this rule applies doubly.

The most anxiety-inducing side of agentic payment is liability. If an agent makes a wrong purchase — say it misunderstands the user's intent and buys too much, or gets tricked by a prompt injection attack — who's liable?

AP2's signed-mandate structure provides a defense here: if the purchase is within the boundaries of the user's signed mandate, the authorization is provable. If it's outside the boundaries, the mandate rejects it. So situations like "the user approved these conditions, the agent went beyond them" can be technically distinguished. This is a far clearer liability ground than the traditional "the card info was correct" ambiguity.

But technical proof alone isn't enough; trust must be built too. Before granting their agents payment authority, users want to clearly see what that agent can and cannot do. So every product offering agentic payment must give the user clear boundaries (spending limit, category restriction, approval threshold) and full transparency. The answer to "what did the agent buy, why, and how much did it spend" must always be a click away.

"

Prompt injection is especially dangerous here. An agent can be tricked by a hidden instruction on a malicious web page into making an unexpected purchase. So for agents with payment authority, security isn't optional but a mandatory layer. Mandate boundaries, spending limits, and anomaly detection must work together.

For businesses preparing for agentic payment, the most practical first step is asking your existing payment provider the right questions. Because in this shift you usually won't build the infrastructure from scratch yourself; your provider's roadmap will set your pace. Ask your provider: do you support AP2, ACP, or similar agentic protocols, and when? Can you distinguish agent-initiated transactions from classic ones? Do you process authorization-proof (mandate) mechanisms on the verification side? In a dispute, what kind of proof chain do you offer for agentic transactions?

The answers to these questions determine how fast you can move. If your provider is active in this area, you can plan your pilots accordingly; if it's inactive, you either wait or seek alternatives. Also, this conversation shows your provider that demand is coming and accelerates their roadmap — market demand is the strongest force accelerating standard maturity.

There's also internal preparation. Bring your payment, fraud, and legal teams together and put the question "what happens when an agent initiates a transaction in our system" on the table. Most organizations' systems assume there's a human behind the transaction; in the agent era this assumption needs reviewing. This internal preparation is work you can start today, before external standards settle.

However robust the technology, if the user doesn't grant their agent payment authority, none of it matters. So agentic payment's most critical design problem isn't technical but psychological: convincing the user to trust software that spends money on their behalf. From what I've seen in the field, you can only achieve this with radical transparency and clear control.

Radical transparency means: the user must be able to see, a click away at any moment, the answer to "what has my agent done so far, what did it buy, how much did it spend, what authority did it rely on." When the agent makes a purchase, a notification should go out and the reasoning should be explained understandably. The user should be able to ask "why did you buy this product" and get a satisfying answer. A black-box agent can't earn trust when payment is involved.

Clear control means the boundaries are in the user's hands. Spending limit, category restriction, single-transaction ceiling, approval threshold (ask me above this amount), cancel button — all of these should be controls the user can easily set and understand. Most importantly, an "emergency stop" mechanism: the user should be able to freeze all of the agent's payment authority with a single action. This safety valve, paradoxically, makes the user grant the agent more authority; because knowing they can revoke it any moment builds trust.

An interesting pattern I've observed in the field: users start with small, low-risk purchases and gradually increase authority as trust in the agent develops. So design your product to build gradual trust, not "all or nothing." If you ask for large authority on day one, the user recoils; if you start small, earn trust, then expand, you build a lasting relationship.

To be honest, the agentic-payment ecosystem still hasn't settled in 2026. AP2 is in a strong position and stands out with its heavyweight partner list; joining the FIDO Alliance is a major signal for standardization. But it isn't the only player. Different payment networks, tech companies, and consortia are pushing their own approaches. For a period multiple standards will coexist, then the market will converge on one or a few — just as happened historically with payment and identity standards.

This uncertainty isn't an excuse for you but a strategy signal. In an uncertain environment, the right move isn't betting your whole fortune on a single standard; it's learning, staying flexible, and building an architecture that can adapt quickly once the dominant standard is clear. Keep your payment infrastructure decoupled from your commerce layer and protocol-agnostic. That way, whether AP2 or another standard wins tomorrow, you can transition without rewriting your core infrastructure.

There's also the timing question. Those who move too early may waste investment as immature standards change. Those who lag too far miss out on the channel competitors build. The right timing is the "watch, trial small, learn, scale" rhythm. Right now we're in the watch-and-small-trial phase; large-scale adoption will come once standards and regulation settle a bit more. Whoever doesn't miss this rhythm becomes a victim of neither early excitement nor lateness.

Let's look at the big picture. Agentic commerce may be one of e-commerce's next big shifts. Moving from a world where people click and buy directly to one where agents discover, negotiate, and buy affects everything from search engine optimization to payment infrastructure. Just like mobile commerce or social commerce did.

But let's not exaggerate either. This transition won't happen overnight; standards are still settling, regulation is still forming, user trust is still being built. Your job is neither to leap blindly nor to ignore it entirely. Your job is to learn and be ready.

Practically, here's what to do: track protocols like AP2 and ACP but don't lock into just one, make your product and payment infrastructure ready for programmatic access, clarify the agent's role and liability with your legal advisor, design from the start to comply with KVKK and payment regulation, and learn in the real world with a small pilot. Take these steps and you'll be the party that's ready when agents start shopping on your customers' behalf — and that readiness turns into an advantage the latecomers will scramble to catch up to.