For two years the story of AI agents was about capability: what could they understand, plan, and generate. Quietly, in the last few months, the story changed. Agents stopped only recommending and started acting. They check out a cart. They move money between accounts. They send the payment. The demo where an agent buys something on your behalf is no longer a demo, it is a feature shipping in production.
That shift surfaces a question almost no one built for. When an agent pays, three things need an answer: which specific agent was it, was it actually allowed to spend, and can you prove afterward what it did? "Trust our logs" is not a sentence a finance team, an auditor, or a counterparty will accept. And an agent that recommends a bad purchase is an inconvenience; an agent that makes one, unsupervised, is an incident with a dollar figure attached.
Today both Vorim SDKs ship identity and signed-audit wrappers for the major agentic-payment rails. Eleven of them: Stripe ACP, Google UCP, x402, AP2, the PayPal Agent Toolkit, Circle Agent Stack, Skyfire KYAPay, Nekuda, bank rails (ACH and wire via Increase and Column), and sandbox-ready wrappers for Plaid Transfer and Modern Treasury. Each is a thin wrapper that sits in front of the payment. It authorizes and attests. It never holds your keys or moves your funds.
The pattern the rails converged on
The useful thing about building these was discovering how much the industry has already agreed on. Under the branding, almost every agentic-payment rail exposes the same shape: a discrete, signable authorization step that happens before the money moves. x402 has a payment authorization. AP2 has signed Checkout and Payment Mandates. Skyfire mints a scoped token. Nekuda creates a mandate. Bank APIs create a transfer that can require approval. Card networks sign an intent.
That step exists because the whole industry realised the same thing at once: you cannot bake accountability into settlement after the fact, so you separate the authorization from the money movement and make the authorization provable. That separation is exactly where an identity and audit layer belongs. The rail handles settlement. Vorim answers the question the rail does not: is this agent allowed to spend, and can you prove what it did.
What the wrapper actually does
Every integration does the same three things, in a few lines. Before a payment, it verifies the agent holds the transact permission, is active, and clears a trust threshold. If any of those fail, the payment never starts and the denial is recorded. If they pass, it signs each stage of the payment lifecycle to a tamper-evident audit trail, so afterward you can show exactly which agent paid what, on whose authority.
import createVorim from '@vorim/sdk';
import { createVorimX402 } from '@vorim/sdk/integrations/x402';
const vorim = createVorim({ apiKey: 'agid_sk_...' });
const x402 = createVorimX402(vorim, { minTrustScore: 60 });
// A 402 came back. Before paying, authorize the agent:
const auth = await x402.authorizePayment({
agentId: 'agid_abc123',
resource: 'https://api.example.com/report',
amount: 1000,
currency: 'USDC',
});
if (auth.authorized) {
// ... settle the 402 challenge, then record it:
await x402.logPaymentSettled(auth.agentId, paymentId, { resource: '/report' });
}The shape is identical across rails, so learning one teaches you all of them. authorizePayment, authorizeMandate, authorizeOrder, authorizeTransfer, they all run the same gate and sign the same kind of evidence. Each also ships Express middleware in TypeScript and a require_transact decorator in Python, so a resource server can gate a paid endpoint on verified agent identity without rewriting its handlers. Both work with a built-in guard against the confused-deputy problem, where a caller claims to be an agent it does not control.
An honest word on what we did not build
We deliberately did not wrap everything with a logo. Several announced agentic-payment products are not something a developer can actually build against today: Visa's Trusted Agent Protocol is prototype-only under a proprietary licence, Mastercard Agent Pay has no public payment API yet, and Payman is invite-only. Shipping wrappers for rails no one can use would be theatre. For the bank rails that gate production money movement behind KYB underwriting, like Plaid and Modern Treasury, we ship wrappers that run against each provider's self-serve sandbox today and default to a sandbox environment tag, so you can build and test now and flip to production the moment your onboarding clears. We say so plainly in the SDK docs. As the gated ones open up, we add them.
Why this sits under the payment, not beside it
A recurring theme in this space is that the rails, quite reasonably, focus on getting the money to move. Their own framing is often about traceability and observability, but that usually stops at logging a tool call. It does not give you a per-agent cryptographic identity, it does not stop an agent that was never authorized to spend, and it does not produce a signed record a third party can verify without trusting the platform that stored it.
That is the gap Vorim fills, and it is why the wrapper goes underneath the payment rather than replacing it. Keep the rail you already use. Add the layer that proves which agent acted, whether it was allowed to, and what it actually did. As agents move from suggesting purchases to making them, that proof stops being a nice-to-have and becomes the thing that lets you put an agent near money at all.
Everything here is live now: install @vorim/sdk 3.10.0 from npm or vorim 3.13.0 from PyPI, and every one of the eleven rails is a one-line import away. See the integration list in the SDK README, or reach us at team@vorim.ai.
Ready to build with agent identity?
Free plan: 10 agents, 10K auth events/month, full SDK access. No credit card.