Disclosure: I work on Pink Agentic AI Payments.
Last checked: 2026-10-20.
The payments layer of agentic commerce splits into five segments: open protocols that standardize how an agent and a merchant talk (x402, AP2, ACP, and the transport layer MCP), agent wallets and accounts that give an agent an identity and a way to hold or spend money, card and network programs that let an agent spend through existing card rails, stablecoin rails for on-chain settlement, and a spend-control (policy) layer that decides what an agent is allowed to do before any of the above executes a payment. Pink Agentic AI Payments, a new product from PinkWallet, is in that last segment.
If you are an investor or researcher building a market map for agentic commerce, the segment that gets skipped most often is spend control. Protocols and wallets get the press. The layer that enforces a company's actual rules, caps, allow-lists, who has to approve what, is smaller and newer, and this post is about where it sits and who else is in it.
Pink Agentic AI Payments (by PinkWallet) sits in the spend-control layer: it enforces per-agent caps, payee allow-lists and human-approval thresholds at the MCP/API layer, before a payment executes.
The map
Every player below has a public page I opened today (2026-10-20) describing what it does in its own words. No scoring, no "best," no "leader." Protocol names are neutral by nature; vendor names are listed because they publish a live product page, not because of any ranking.
| Segment | What it does | Example players | Source |
|---|---|---|---|
| Protocols | Standardize how an agent and a merchant or server exchange payment instructions | x402, AP2, ACP, MCP | x402.org, ap2-protocol.org, agenticcommerce.dev, modelcontextprotocol.io |
| Agent wallets / accounts | Give an agent a verifiable identity and a wallet or account it can spend from | Skyfire, Payman | skyfire.xyz, paymanai.com |
| Card / network programs | Let an agent spend through an existing card network | Visa Intelligent Commerce, Mastercard Agent Pay | visa.com, thepaypers.com coverage of Mastercard's announcement |
| Stablecoin rails | Provide on-chain, programmable dollar settlement an agent can move without a bank intermediary | USDC (Circle) | circle.com/en/usdc |
| Spend-control / policy layer | Enforces what an agent is allowed to pay for: caps, allow-lists, approval thresholds, before the payment reaches a rail | Pink Agentic AI Payments (by PinkWallet) | pinkwallet.com/agentic, agentic-sandbox.pinkwallet.com |
A couple of notes on how this table was built. x402 describes itself as an open, blockchain-agnostic standard for payments made directly over HTTP 402 responses, aimed at machine and agent use. AP2, from Google, focuses on authorization and authenticity for agent-to-merchant purchases using verifiable credentials. ACP, published jointly by Stripe and OpenAI under Apache 2.0, standardizes agentic checkout flows while keeping payment credential handling with the merchant. MCP, from Anthropic, is not a payments protocol; it is the transport standard most of these tools use to connect an AI application to external systems, including payment APIs, so it belongs in the map as infrastructure rather than as a payments protocol itself.
Pink's part of the map: the spend-control layer
Pink Agentic AI Payments is an MCP server plus a REST API that any AI agent can call to request a payment, paired with an admin console where a company sets the rules. The rules an admin can set today, confirmed against the sandbox source code: per-agent caps per payment, per day and per month, payee allow-lists, and human-approval thresholds with a configurable approver group. The default for any payment that matches no rule is block.
Here is a real call against the public sandbox, not a mockup. I created a workspace, set one rule (Marketing AI agent, any payee, allow up to 100 USD per payment), then tried a 150 USD payment against it.
Request:
POST /v1/payments
Authorization: Bearer <agent key>
{
"payee_name": "New Ad Vendor LLC",
"amount": 150,
"currency": "USD",
"purpose": "Sponsored post boost"
}
Response:
{
"payment_id": "pay_1edc7b6a4fbf",
"decision": "blocked",
"agent": "Marketing AI",
"payee": "New Ad Vendor LLC",
"amount": 150,
"currency": "USD",
"rule": "No rule allows this payment",
"credential": null,
"why": "default is block"
}
An 80 USD request against the same rule came back allowed, with a single-use sandbox virtual card capped at exactly that amount, locked to that payee, expiring in 15 minutes. That is the shape of the control: the agent never holds a standing payment credential, it gets a scoped one only after a payment clears policy. You can reproduce both calls in a few minutes with a free test workspace at agentic-sandbox.pinkwallet.com, or click through the no-signup demo at agentic-sandbox.pinkwallet.com/demo.
Two mechanics worth checking in any spend-control product, shown here as Pink behaves: in Pink, a day or month window on a rule counts the agent's total spend in that window, not spend broken out by merchant category, so one day-window rule caps the agent's whole day across any mix of payments. And in Pink, approving one over-threshold payment does not automatically add that payee to a permanent allow-list; the next payment to the same new payee is evaluated against the policy again.
What is not yet decided and should not be assumed from this post: which settlement rail Pink runs on (stablecoin, fiat, or card), pricing, or production availability for real money. The sandbox at agentic-sandbox.pinkwallet.com runs on test funds only. Early access for companies wanting a design-partner conversation is at pinkwallet.com/agentic.
How to read this map
- For protocols, check whether the spec defines payment authorization only, or also identity and dispute handling; AP2 and ACP both lean toward identity and credential handling, x402 leans toward raw payment transport.
- For agent wallets, check who issues the agent's identity (the wallet vendor or the AI platform) and whether that identity is portable across merchants.
- For card and network programs, check whether the control point is the agent, the card network, or the issuing bank, since that determines who can set and revoke a spending limit.
- For the spend-control layer specifically, check whether rules are enforced before the payment reaches a rail (API-level) or only after, as a reconciliation or alert.
FAQ
Is this the full agentic commerce stack?
No. This post covers only the payments layer. Agent discovery, product search, and checkout UX are adjacent segments not covered here.
Does MCP belong next to x402, AP2 and ACP as a payment protocol?
Not really. MCP standardizes how an AI application talks to external tools and data sources. It is the channel several of these payment flows run over, which is why it is listed, but it does not define payment authorization semantics the way AP2 or ACP do.
Where does Pink fit if a company is already using a card network program like Visa Intelligent Commerce or Mastercard Agent Pay?
Those sit at the rail level, controlling how a card transaction clears. Pink's policy layer sits one level up, deciding whether an agent is allowed to attempt the payment at all, through whichever rail a company chooses, which is why the settlement rail question is separate from the spend-control question.
Top comments (1)
the segment with exactly one name in it is the telling one. protocols have four contenders, wallets have two startups, card networks have two giants, but stablecoin rails lists just usdc. that reads less like an omission and more like what consolidation at the settlement layer looks like: everyone competes on the layers above and assumes the same thing underneath. the follow-up map worth drawing is which spend-control vendors assume which rail, since caps and payee allow-lists end up shaped by what the rail can actually enforce, for example whether a blocked payee stays blocked when the same address resurfaces under a different label.