Two flavors of “agentic” payment

The most obvious agentic payment is an agent executing a transaction that's already been approved. You sign an invoice, the PO comes into your system, can an agent settle all the details automatically? Yes. Tools like Ramp MCP or Mercury CLI are obvious solutions here. Or switch your invoicing to Agree and have their agents collect funds on your behalf.

But the thing that seems to capture imaginations is the idea that an agent has an outcome in mind, a dollar budget to achieve it, and can autonomously spend that budget in the most effective way on your behalf, with maximum efficiency. This behavior is for both consumers (buying shoes) and businesses (choosing a payroll vendor).

There have been attempts to integrate this on the consumer side. OpenAI's commerce push has so far failed to beat the internet's optimized conversion funnel. So for now I'll focus on the B2B use cases.

The first signs of light: coding agents. I'm starting to see the first signs of agentic payments occur through the lens of coding agents, because coding agents have to interpret a user's request and do a lot of stuff to come up with an outcome. An example of this is Sapiom. Their founder is a member of our ABB community. They've built tech that lets you access paid services (like SMS) under one integration, thereby enabling agent builders to offer more features to their customers without additional setup.

That pattern — the agent discovers the service, pays for the outcome, and uses a wallet controlled by the user — is the core of what I believe the first use case for agentic payments is.

The protocol layer is converging. There are a few specs out there to make this doable. x402, from the Linux Foundation and Coinbase, is the most popular, but there's also the Machine Payments Protocol (MPP) from Tempo. And they're converging.

The core question they're all answering is the same: how does an agent know it has to pay for something? How does it negotiate the payment details, settle the transaction, and gain access to the resource?

Parallel: the first end-to-end case study. Which is why what Parallel shipped this week is interesting. They pieced together the entire end-to-end of the agentic payments stack:

Discovery first. Parallel launched a keyless search MCP — rate-limited free access at search.parallel.ai/mcp, no API key, no account. That lets agents discover them. It lets agents show their humans: hey, I got the job done. The feedback loop is enabled.

Then the rails. In the same week, they wired up both x402 and MPP for pay-per-request access, both implemented via Stripe in a few lines of code. An agent carries a wallet, transacts with Parallel, gets the privilege of higher-volume access.

The pattern we saw with Sapiom — coding agent discovers a tool and uses it — is broadening to more generic vendors like Parallel. And there are others worth watching: atxp.ai, agentcash.dev are all starting to converge into a similar shape: a billing wrapper around a bunch of useful services that makes them dead simple to use.

What agentic payments is for in 2026. The shape of all of this is: payments is for onboarding.

Payments removes the friction of onboarding agents into your services. That's a dramatic simplification of what payments do in the real world, but I think what we're seeing is product-market fit specifically here. Setting up an agent into a service is hard. There are so many steps between people and magic. Payments is reducing that effort and making onboarding seamless so people can live in the joy of building agents without friction.

The broader question of where else agentic payments find utility — usage and recurring billing, peer-to-peer — is TBD. The industry's a little heated on this. We might be a bit overhyped, but the onboarding piece? That's working.

What do you think?