Agentic Payments Readiness Report 2026 — by Pink Agentic AI Payments

Version v1.3 · Published 2026-09-28 · Updated 2026-10-02 · Publisher: Pink Agentic AI Payments (by PinkWallet)

Published by Pink Agentic AI Payments (by PinkWallet) — the approval layer between AI agents and company money: plain-language rules, per-agent budgets and human approvals decide each payment before it executes. Agents connect via MCP or REST. Try the free public sandbox: https://agentic-sandbox.pinkwallet.com (test credentials, no real money moves) · Product: https://pinkwallet.com/agentic/ · Examples: https://github.com/Pink-Agentic-Payments/sandbox-examples

As of v1.3, Pink Agentic AI Payments is included as a row in the dataset — self-scored by the publisher under the same 7-dimension methodology used for every other company, labeled “publisher; self-scored; sandbox stage” in every table. See “How Pink Agentic AI Payments compares” below.

How Pink Agentic AI Payments compares

Pink Agentic AI Payments is the publisher of this report, and is scored as a row in the CSV under the identical methodology applied to the other 16 companies — it is labeled “publisher; self-scored; sandbox stage” throughout, and every claim below carries a source link and a verbatim quote in data/agentic-payments-readiness-2026.csv, verified with scripts/quote_checker_pink.py (log: evidence/quote-check-v1.3-pink.csv, 26/26 checked quotes passed).

• Pink is one of 4 companies in the dataset (of 17, including the publisher) with a clear “yes” on both D5.1 (configurable spend limits) and D5.2 (human confirmation / one-time credentials) — the others are Circle, Crossmint, and PayPal.
• Pink is one of 2 companies with a company-hosted MCP server whose own docs confirm it can initiate payments — not just read or search — on both D2.1 and D2.2: it can initiate payments (a single-use card or bank transfer) in the sandbox with test credentials, no real money moves; the other company is Stripe.
• Pink has a self-serve developer sandbox (D4.1 ✓, 11 of 17 companies do) — a workspace can be created with a single POST request, no sales call.
• Pink is one of 2 companies with both a card rail and a bank/ACH rail documented for agent-initiated payments (D6.1 and D6.2 both “yes”) — the other is Skyfire. In Pink’s sandbox this is a single-use test-BIN virtual card or a sandbox ACH transfer object with a reference number.

Guardrail depth. What Pink’s rules engine documents (we did not check whether other vendors in this dataset document the same things — this is what Pink’s own docs state, not a claim that others lack it):

• Per-agent monthly budgets and single-payment caps, plus a company-wide daily ceiling across all agents — policy-rules-reference
• An ordered list of rules, checked top to bottom, first match decides, anything uncovered is blocked by default — policy-rules-reference
• Named approvers or an n-of-m quorum (e.g. “2 of 3 executives” for payments over $50,000) — policy-rules-reference
• Two fraud signals checked before amount tiers: the payee changed bank details in the last 7 days, and the invoice number was already paid in the last 90 days — security-model
• Single-use credentials locked to the payee and the amount, expiring 15 minutes after issue — security-model
• Agents can be paused in one tap — pinkwallet.com/agentic/

Where Pink is behind:

• No self-described support for x402, AP2, ACP, or Mastercard Agent Pay (D3, all “no”).
• Early access — docs state “Sandbox live... Production is not yet available” (D1.2: partial).
• No published production pricing (D7.2: pricing not found).
• Identity/compliance screening (KYA, OFAC) is not documented in the pages reviewed (D5.3: not verified — a research-coverage gap, not a confirmed absence).

What's new in v1.2 (2026-09-29)

Added 3 providers — Mollie, Square, Tempo (13 → 16 providers, 42 scored rows + 1 informational row). This is additive only: every v1.1 row is unchanged, and the v1.1 git tag/release still points at the original 13-provider/185-row snapshot.

• All 3 new providers have an official, vendor-hosted MCP server (mcp.mollie.com, mcp.squareup.com, mcp.tempo.xyz) — vs. 6 of 13 in the v1.1 baseline.
• Only 1 of the 3 (Tempo) documents a genuine configurable spend cap: wallet access keys carry independent per-key spending limits plus a --max-spend flag and --dry-run cost preview.
• 0 of the 3 self-declare x402/AP2/ACP/Visa TAP/Mastercard Agent Pay integration. Tempo instead pushes its own "Machine Payments Protocol" (MPP, co-authored with Stripe) — recorded as an informational D3.x row, not scored under the fixed D3 list.
• All 3 publish some pricing info (Mollie/Square reuse their standard card rates; Tempo is the first provider in this dataset scored pricing: agent-specific, with published sub-cent per-request fees) — vs. 2 of 13 in v1.1.
• The 3 additions lag the v1.1 median on protocol self-declaration (0 of 3 vs. 8 of 13) but lead on pricing transparency (3 of 3 vs. 2 of 13 "some pricing" / 11 of 13 "not found").

What's new in v1.3 (2026-10-02)

Added the publisher, Pink Agentic AI Payments, as a self-scored row (17 rows) under the identical 7-dimension methodology used for the other 16 companies. No other company's data changed. See “How Pink Agentic AI Payments compares” above and evidence/quote-check-v1.3-pink.csv (26/26 quoted claims passed).

Key findings (v1.1, 13 providers)

1. Every provider in this sample has shipped something agent-facing, but "official, money-moving, self-serve" all three at once is rare. Only a handful of checks land on all three at once — for example Circle's agent-wallet-policy skill (D5.1/D5.2, github.com/circlefin/skills) and Stripe's stripe_api_write MCP tool gated by human confirmation (D2.2/D5.2, docs.stripe.com/mcp.md).
2. MCP servers are proliferating, but most are read/search tools, not payment tools. Mastercard's, Circle's, and Checkout.com's officially documented MCP servers are explicitly scoped to service discovery, code generation, or query/void operations (D2.2) — e.g. Mastercard's toolkit README: "The Mastercard Developers Agent Toolkit allows popular agent frameworks (currently Model Context Protocol - MCP) to integrate with Mastercard Developers for service discovery and integration guides" — while Stripe and Airwallex are the two vendors in this sample whose official docs explicitly discuss a money-movement permission boundary for their MCP server (D2.2).
3. x402 and ACP tie on self-described adopters in this sample (four each); AP2 has none. Circle, Coinbase, Crossmint, and Stripe self-describe x402 support in their own docs/repos (D3.1); Stripe, Adyen, PayPal, and Checkout.com self-describe ACP support (D3.3); no vendor in this sample self-describes an AP2 integration in its own official docs as of 2026-09-28 (D3.2).
4. Human-in-the-loop confirmation is documented, but by name, for a minority of vendors. Stripe requires human confirmation before certain write actions ("Stripe requires human confirmation before it takes certain stripe_api_write actions, such as refunds and outbound payments", D5.2), and Circle's spend-limit changes are OTP-gated (D5.2, github.com/circlefin/skills). For most other vendors in this sample, D5.2 is "not verified" rather than confirmed absent.
5. Self-serve developer access (no sales call) is the norm for the API/SDK layer, not for the payment-rail layer. Nine of the thirteen vendors show a "yes" or "partial" on D4.1 (self-serve sandbox), largely because general developer portals are open; the same vendors are far more often "not verified" on D6 (which rails an agent can actually move money over).
6. Pricing for agent-specific usage is essentially undisclosed. Eleven of thirteen vendors show "pricing: not found" on D7.2 for an agent-specific rate; the other two (Circle, Stripe) explicitly reuse their general processing/product pricing rather than publishing an agent-specific rate card.
7. Two claims from the v1.1 draft did not survive a same-day re-check and were downgraded before publication: Stripe D6.1 (card-rail settlement for agent-initiated ACP payments — the earlier "yes" was an inference, not a quoted statement, so it is now "not verified") and Wise D7.1 (the docs page could not be re-fetched to confirm login-free access, so "partial" was downgraded to "not verified"). See the changelog below.

These findings describe the original 13-provider v1.1 sample only and were not recomputed against the 16-provider v1.2 set.

Conflict-of-interest disclosure

This report is published by Pink Agentic AI Payments (by PinkWallet), a company building agentic-payments products. As of v1.3, Pink is a row in the scored CSV, self-scored by the publisher under the same methodology applied to the other 16 companies, and labeled “publisher; self-scored; sandbox stage” in every table and row so readers can weight it accordingly. All checks are tied to a public evidence URL and a verbatim quote; the raw scoring data (CSV) is published under CC BY 4.0 so any third party can audit, reproduce, or dispute a finding. Try the free public sandbox (test credentials, no real money moves): https://agentic-sandbox.pinkwallet.com. If you believe an entry is inaccurate, see "Corrections policy" below.

Methodology

We evaluated 16 payment and financial infrastructure providers against 7 dimensions, each broken into 2–4 binary or ternary checks (23 distinct check types; some checks don't apply to every company, e.g. a card network isn't scored on its own card rail). v1.3 added the publisher, Pink Agentic AI Payments, as a self-scored row under the same methodology (16 providers + the publisher).

The seven dimensions:

• D1 — Agent API/SDK: is there a publicly documented, agent-specific SDK/toolkit (D1.1), and is it GA or still beta/preview (D1.2)?
• D2 — MCP server: does the company itself (not a community project) host an MCP server (D2.1), and does its documentation state whether that server can move money or is read/search-only (D2.2)?
• D3 — Agent payment protocol support: does the company's own documentation or repo self-describe support for x402, AP2, ACP, or Visa TAP/Mastercard Agent Pay? A protocol's own operator (Visa for TAP, Mastercard for Agent Pay) is not scored against its own protocol.
• D4 — Developer sandbox: is there a self-serve signup/sandbox, or does access require contacting sales?
• D5 — Guardrails: configurable spend limits (D5.1), human-confirmation or delegated/one-time credentials (D5.2), identity/compliance screening such as KYA or OFAC (D5.3).
• D6 — Payment rails: card (D6.1), bank/ACH/wire (D6.2), stablecoin/crypto (D6.3) — specifically for agent-initiated payments, not the company's general product.
• D7 — Documentation and pricing transparency: can the core agent docs be read without login (D7.1), and is pricing for agent-specific usage public (D7.2)?

Evidence rule: every check is tied to an evidence URL (the company's own domain or official GitHub org — never a search-engine summary or a third party naming the company as a partner) and, for every "yes" or "partial" result, a verbatim quote copied from that source. Checks that could not be resolved are marked not verified — this is not the same as "no." A page returning 403/404/526, requiring login, or simply not yet deep-dived into its sub-pages is recorded as "not verified," not scored as absent. All fetches for this v1.1 pass were performed on 2026-09-28.

Evidence states used in the CSV: yes, partial, no, not verified, not applicable, and for D7.2 specifically: pricing: agent-specific, pricing: general rates, pricing: not found.

Results

Legend: ✓ yes · ◐ partial · ✗ no · ? not verified · – not applicable/no data

Pink Agentic AI Payments appears as the first row in both results tables below (labeled publisher; self-scored; sandbox stage). All other rows are unchanged from v1.2.

D1–D2, D4–D7 (sub-checks shown in order, separated by "/")

D5 order is limits / human-confirmation / identity screening. D6 order is card / bank / stablecoin. D7 order is docs-without-login / agent-specific pricing.

D3 — self-described protocol support

Note: Adyen also self-describes support for UCP (Universal Commerce Protocol), a protocol not in the original four-protocol methodology; see the CSV row D3.x UCP. Tempo similarly self-describes its own "Machine Payments Protocol" (MPP, co-authored with Stripe) rather than any of the four listed protocols; see the CSV row D3.x MPP.

Company notes

Pink Agentic AI Payments (publisher; self-scored). Publicly documents an agent-specific REST API and a company-hosted MCP server (agentic-sandbox.pinkwallet.com/mcp) that can initiate a single-use card or bank transfer, gated by per-agent monthly budgets, a company daily ceiling, ordered rules with default-block, and named-approver/quorum holds; self-describes no x402, AP2, ACP, Visa TAP, or Mastercard Agent Pay support; is in early access with a public self-serve sandbox, and does not publish production pricing. Identity/compliance screening and stablecoin rails are not documented in the pages reviewed for this check.

Airwallex. Documents a dedicated AgentOS MCP endpoint (mcp.airwallex.com/mcp) with an explicit "no money-out actions by default" statement and human approval required for write tools, but the skill set is labeled beta rather than GA, and access requires OAuth against an existing production account rather than a fresh self-serve sandbox.

Skyfire. Built around an agent-specific identity/token system (KYA) with self-described per-agent spending limits and funding across cards, ACH, and USDC — the most fully self-described guardrail and rail set in this sample outside Circle — though its MCP server and protocol-support pages were not deep-dived this round.

Payman. Positions itself on its homepage as agentic-AI banking, and its GitHub org contains a documented Genie MCP bridge, but its technical documentation subdomain (docs.paymanai.com) returned HTTP 526 on every fetch attempt this round, leaving most guardrail and rail checks unverified rather than resolved.

Crossmint. Self-describes x402 client support, scoped/revocable card allowances, and one-time/encrypted agent credentials, plus non-custodial stablecoin agent wallets — a broad set of agent-specific guardrail and rail claims backed by verbatim quotes from its own docs.

Visa. As the operator of Visa Intelligent Commerce/Trusted Agent Protocol, is treated as not applicable for other companies' protocols; its own protocol page and a dedicated MCP server for integration guidance are both self-serve and publicly documented, but specific spend-limit and human-confirmation mechanisms were not found in the pages fetched this round.

Mastercard. Its GitHub-hosted Agent Toolkit is public and MIT-licensed, and Mastercard's own investor-relations release describes Agent Pay for Machines as settling "across cards, accounts and stablecoins" (mastercard.com/global's press page itself 403s to every fetch method we tried, including a browser-rendered check), but developer.mastercard.com is JavaScript-rendered and returned only page titles to this round's fetches, leaving several checks (guardrails, self-serve sandbox) unresolved.

Adyen. Self-describes support for both ACP and UCP checkout flows for merchants, and its agentic-commerce documentation is public without login, and it publishes an official MCP server (docs.adyen.com/development-resources/mcp-server); other protocols, guardrail mechanisms, and specific agent-scenario rails were not found in the pages fetched this round.

PayPal. Its Agent Ready / ACP integration guide documents card, Apple Pay, and Google Pay as supported payment methods with transaction-amount validation and single-use payment references, and PayPal's official docs state it "developed an MCP server" for merchants (corrected 2026-09-28; the first version said it did not host one), while D1.1's specific SDK details were not directly verified this round.

Checkout.com. Hosts an official MCP server described as supporting payment status queries, voids, and payment-link management (a partial, not full, money-movement scope), self-describes ACP support, and offers a self-serve test-account signup, but guardrail and rail-specific pages were not found in the content fetched this round.

Circle. Its open-source circlefin/skills repo documents per-transaction/daily/weekly/monthly agent-wallet spend limits, OTP-gated limit changes, an x402 seller-integration skill, and stablecoin payments via Circle Wallets — the most fully evidenced guardrail set alongside Skyfire — though several protocol checks (AP2/ACP/Visa-MC) were not found in the repo docs.

Stripe. Documents an MCP server with an explicit write/read tool split, human confirmation required before certain write actions such as refunds, x402 and ACP support, and stablecoin payments over MPP/x402; a same-day re-check could not find a verbatim statement that ACP payments settle over card rails specifically (D6.1), so that check is now "not verified" rather than "yes."

Coinbase. AgentKit's README states "Every AI Agent deserves a wallet," and its Agentic Wallet CLI documents per-session/per-transaction caps, built-in OFAC screening, and USDC support across five chains; it does not describe card or bank rails for agent wallets (both explicitly "no"), and its Mastercard-Agent-Pay partner mention was downgraded to background-only because Coinbase's own docs don't self-describe that integration.

Wise. The clearest "not built for this yet" profile in the sample: the developer-portal URL used in this check returned 404, no MCP server, agent-specific SDK, or self-serve agent sandbox was found, and most other checks are "not verified" because Wise's general merchant-API sandbox is not agent-specific evidence under this methodology.

Mollie. Has an official MCP server (mcp.mollie.com), a separate open-source Agent Toolkit library, and "Agent Skills" for coding assistants — the most layered agent offering of the three new providers. Guardrails are real but soft: Toolkit docs mandate a human confirm any fund-moving action, but there's no configurable numeric spend cap. No protocol (x402/AP2/ACP/Visa TAP/Mastercard Agent Pay) self-declared. Self-serve signup confirmed. No agent-specific pricing; standard card rates (1.8–3.25%) apply.

Square. Official remote MCP server (mcp.squareup.com, Block-hosted, explicitly labeled Beta) bridges AI assistants to the full Square REST API. Permission model is binary (a DISALLOW_WRITES flag) rather than scoped by default — remote mode inherits whatever OAuth scopes the user grants, not an agent-specific restriction. No spend-limit mechanism, no KYA/OFAC mention, no protocol self-declared. Self-serve signup confirmed; pricing reuses Square's standard published card rates.

Tempo. The strongest guardrails of the three new providers: wallet access keys carry independent, per-key spending limits, plus a --max-spend cap and --dry-run cost preview on every agent request — the only one of the three with a genuine configurable spend cap. Its own MCP server is documentation-search-only (no money-out capability). Tempo pushes its own "Machine Payments Protocol" (MPP, co-authored with Stripe) rather than x402/AP2/ACP, so it scores zero on D3 by the letter of the method despite being agent-payments-native by design.

What this means for teams deploying AI agents

1. "Has an MCP server" is not the same as "agents can spend money through it." Check D2.2 specifically — several officially documented MCP servers in this sample are explicitly read/search-only or capped at void/query operations.
2. A protocol partner announcement is not the same as a self-described integration. This report only counts a company's own docs/repo naming a protocol; press-release partner lists (e.g. Mastercard's 30+-partner Agent Pay announcement) are excluded per v1.1 rule 4, and two prior "yes" entries (Coinbase, Crossmint on Visa TAP/MC Agent Pay) were downgraded on that basis.
3. "Not verified" is a research-coverage gap, not evidence of absence. A large share of this table's cells are "?" because a page was JS-rendered, gated, or simply not deep-dived this round — treat them as open questions to ask a vendor directly, not as a "no."
4. Guardrail specifics (spend limits, human confirmation, compliance screening) are the least-documented dimension across the sample. If spend control is a requirement for your deployment, expect to verify D5 directly with each vendor rather than relying on marketing language like "enterprise-grade security."
5. Self-serve access and agent-specific pricing are two different questions. Most vendors let you start building without a sales call (D4), but almost none publish an agent-specific rate card (D7.2) — budget for a sales conversation before production spend, even where the sandbox is open.
6. Re-verify before you build. This is a point-in-time snapshot (accessed 2026-09-28); two claims changed between v1.1's draft and this publication after a same-day re-check (see changelog), which is itself evidence that this space is moving fast enough to warrant checking primary sources yourself.

Corrections policy

This report and its underlying CSV are published under CC BY 4.0. If you are one of the companies covered, or have found a page we misread, misquoted, or missed, submit a correction with: the check ID, the URL, and the exact text you believe supports a different result. Verified corrections will be applied and logged in the changelog below, with the original entry struck through rather than silently removed.

Changelog

v1.3 (2026-10-02): Added the publisher, Pink Agentic AI Payments, as a self-scored row (245 rows total: 228 from v1.2 + 17 for the publisher) under the identical 7-dimension methodology used for the other 16 companies. No other company’s data changed. Evidence: evidence/quote-check-v1.3-pink.csv, mechanically verified 26/26 quoted claims PASS via scripts/quote_checker_pink.py.

v1.2 (2026-09-29): Additive release. Added 3 providers: Mollie, Square, Tempo (13 → 16 providers; 185 → 228 rows: 42 scored rows + 1 informational D3.x row for Tempo's Machine Payments Protocol). Every v1.1 row is unchanged; the v1.1 tag/release still points at the original 13-provider/185-row snapshot. All 3 new providers have an official, vendor-hosted MCP server. 1 of 3 (Tempo) documents a configurable per-key spend limit. 0 of 3 self-declare x402/AP2/ACP/Visa TAP/Mastercard Agent Pay. All 3 publish some pricing; Tempo is the first pricing: agent-specific row in this dataset. Evidence: evidence/quote-check-v1.2-additions.csv, mechanically verified 48/48 quoted claims PASS via scripts/quote_checker.py.

2026-09-28 (post-publication correction 2): D2.1 "Official MCP server" corrected for 3 vendors. Adyen (was "not verified"), PayPal (was "no") and Crossmint (was "not verified") each publish an official MCP server on their own docs or GitHub; all three are now "yes" with verbatim quotes. PayPal D2.2 changed from "not applicable" to "not verified". Found while cross-checking this report against our payment MCP servers comparison. No other scores changed.

2026-09-28 (post-publication correction): Key finding #3 originally said x402 had "more self-described adopters than AP2 or ACP." The table itself shows x402 and ACP tied at four each (x402: Circle, Coinbase, Crossmint, Stripe; ACP: Stripe, Adyen, PayPal, Checkout.com). The headline now says so. No scores changed.

v1 → v1.1 (2026-09-28): - Stripe D6.3 (stablecoin rail): downgraded from a "yes" recorded in v1 to "not verified" pending a targeted re-check of the specific sub-page (v1.1 re-fetch did not reproduce the earlier evidence trail). - Coinbase D3.4 (Visa TAP/Mastercard Agent Pay): downgraded from "counted via secondary source" in v1 to not-scored/background-only — Coinbase is one of 30+ partners named in a Mastercard press release, and per v1.1 rule 4 ("protocol support must be self-described"), Coinbase's own docs don't self-describe this integration. - Crossmint D3.4 (Visa TAP/Mastercard Agent Pay): similarly downgraded — the prior "supports Visa Intelligent Commerce/Mastercard Agent Pay" record traced back to a search-engine summary, not an officially opened source page, so it no longer counts as evidence under v1.1 rule 4. - Evidence-state taxonomy expanded from three states (verified / secondary source / inaccessible) to five (verified / secondary source / not deep-dived / inaccessible / not applicable), to distinguish "we didn't get to this page yet" from "we tried and failed." - D2.2 clarified to separate documentation/code-generation MCP tools from money-movement MCP tools, after finding several vendors' "official MCP" is scoped to read/search only.

Post-v1.1 cleanup (2026-09-28, this publication): - Normalized the result column to a fixed vocabulary (yes / partial / no / not verified / not applicable / three pricing: states for D7.2); all free-text qualifiers moved to the notes column. - Replaced 34 verbatim_quote cells that held research notes (several in Chinese) with verbatim quotes re-extracted from the official evidence URL; translated all remaining Chinese working notes into English. - Stripe D6.1 (card rail under ACP) downgraded from "yes" to "not verified": no verbatim statement could be found on re-fetch that ACP-settled agent payments specifically use card rails; the earlier "yes" was an inference. - Wise D7.1 (docs accessible without login) downgraded from "partial" to "not verified": the docs.wise.com/api-reference fetch was truncated and could not confirm login-free access with quoted text.

2026-09-28: quote audit, 20 rows corrected, 0 downgraded. A mechanical checker (pm_quote_check.py) fetched every cited evidence_url for the 80 yes/partial rows and tested whether each verbatim_quote literally appears on that page; it flagged 11 quotes whose text was not on the cited URL, 8 pages the checker's plain-script fetch could not load (JS-rendered or bot-blocked), and 1 quote that matched only partially. All 20 were re-researched: 15 rows were corrected (11 evidence_urls moved to the specific official page that actually carries the exact sentence, 11 quotes corrected; some rows needed both) and the remaining 5 received verification notes only (e.g. Stripe's self-serve-signup quote moved from docs.stripe.com/agents to docs.stripe.com/mcp.md; Mastercard's Agent Pay quotes moved from the 403'd mastercard.com/global press URL to Mastercard's own investor.mastercard.com release of the same announcement), and several quotes were trimmed or corrected where the original text was a paraphrase, an ellipsis stitching two non-adjacent sentences, or crossed an HTML-tag boundary that inserted a stray space (Checkout.com, Coinbase, PayPal). The 8 pages that block plain-script fetching (Skyfire's product page; Mastercard's investor-relations release) were independently confirmed with a browser-rendering fetch and are marked "verified via WebFetch 2026-09-28" in their notes. No score changed as a result of this audit — the underlying claims held up, only their citations needed fixing — except that Mastercard's payment-rail quote is now sourced primarily rather than via a Yahoo Finance reprint, and its exact wording changed from "bank accounts" to "accounts" (see Mastercard company note above). Re-run result: python3 pm_quote_check.py → OK 72, FETCH_FAIL 8 (all WebFetch-verified), NOT_FOUND 0, PARTIAL 0, up from OK 60 / NOT_FOUND 11 / FETCH_FAIL 8 / PARTIAL 1 before this pass.

Data

The full scoring dataset (245 rows, 16 providers + the publisher × up to 23 checks) is published alongside this report as a CSV under CC BY 4.0: agentic-payments-readiness-2026.csv.