Field note

Payment APIs are having their USB-C moment with MCP

Most payment integrations still look like 2015 - custom code per platform, months-long builds. The Model Context Protocol turns MxN integrations into M+N, and payment platforms are starting to ship it. The promise is real; so are the enterprise security gaps.

Jul 15, 2025 · Navin Agrawal · AI systems · 3 min read

Payment APIs are having their USB-C moment with MCP

Visual brief

Visual brief

Payment APIs are having their USB-C moment with MCP

As of July 2025

The Model Context Protocol is doing to payment integration what USB-C did to cables: collapsing a mess of custom connectors into one standard. The technology is ready enough to matter and not yet ready enough to trust with production money.

Most payment integrations still look like 2015 - custom code for every platform, months-long implementations, and rigid architectures that crack when requirements change. MCP changes the shape of that problem.

MCP in payment systems (as of mid-2025): instead of MxN point-to-point integrations (an AI agent wiring custom code to each payment platform, auth, retry, and monitoring), MCP gives M+N standardized connections - one MCP client per AI system, one MCP server per platform. Why architects switch: faster deployment, model flexibility, one protocol across rails, self-describing JSON, mTLS plus scoped tokens. Milestones: Anthropic open-sourced MCP in Nov 2024; Modern Treasury shipped an MCP server in April 2025; dev tools and platforms adopted through mid-2025. Enterprise security watchlist: token theft, prompt injection, scoped-access and SOC 2 / PCI readiness gaps.
MxN custom integrations collapse to M+N standard connections - the same shape change REST APIs brought a decade ago.

The old way: want your AI to create an ACH payment? Build a custom API wrapper. Need wires? Different code. Real-time payments? Start over. MCP replaces that with one standardized interface - build one MCP server per platform and one client per AI system, and the integrations stop multiplying. Anthropic open-sourced it in November 2024 as “a USB-C port for AI applications,” and by April 2025 Modern Treasury had shipped a payments MCP server with a demo of an agent creating an expected payment from a plain-English instruction. The shape is right.

Integration math

M + N

one MCP client per AI system, one MCP server per platform - instead of building MxN custom connectors that break on change.

Released

Nov 2024

Anthropic open-sourced MCP, "a USB-C port for AI applications"; Modern Treasury shipped a payments MCP server in April 2025.

Not enterprise-ready

Gaps

token theft, prompt injection, and a "keys to the kingdom" risk; missing fine-grained access and SOC 2 / PCI posture (Pillar Security, 2025).

The constraint is trust, not capability. Security researchers (Pillar Security, March 2025) flagged the obvious failure modes early: OAuth token theft, indirect prompt injection, and the “keys to the kingdom” problem where compromising one MCP server opens broad access to financial systems. Through mid-2025, MCP still lacked the enterprise controls banks require - fine-grained access, strong auditability, and a clear SOC 2 / PCI compliance posture.

This feels like the early days of REST APIs: promising technology with implementation gaps that the early adopters will be the ones to solve.

Was this useful?

Choose once.

Filed under

AI systems
Share
Back to Field Notes

Related Posts

View All Posts »
Most AI agents never reach production. Payments is where that gets expensive

Most AI agents never reach production. Payments is where that gets expensive

The widely cited figure is that 88 percent of AI proofs of concept never reach production. Agentic payments inherit that gap, and the teams that cross it are not winning on model selection. They are winning on payments-specific infrastructure that makes an agent idempotent, governable, and rollback-safe at the rail boundary.

Multi-model is the new multi-rail

Multi-model is the new multi-rail

Every payment system routes across multiple rails - ACH fails, traffic moves to wire, and wire is dear for small amounts so you route to RTP. Most AI systems still call one model and hope it stays up. The LLM gateway is the same routing engine payments has run for decades, and it needs the same three things to count.

Agents do the wiring, architects carry the tradeoffs

Agents do the wiring, architects carry the tradeoffs

AI agents are arriving faster than most banking career ladders can adapt, and the market is already rewarding people who work with them. The career moat was never wiring up another API call. It is the judgment calls agents cannot own - which rail to trust, how much latency to spend, who the regulator will be.

AI agents can buy now, and fraud systems were not built for it

AI agents can buy now, and fraud systems were not built for it

Stripe, OpenAI, and Google shipped protocols that let AI agents complete purchases inside a conversation. The rails are already fast enough. The problem is that fraud detection was architected around a human clicking buy on a trusted surface, and agents break that assumption.