Skip to main content
Back to blog
·5 min read·By Tim & Alec·Updated

Why We Built Ovra

We started Ovra because we watched AI agents fail at the simplest thing: paying for something. Late 2025, every alternative meant hardcoding a card into agent context. We decided to build the infrastructure layer that wasn't there — EU-native, API-first, agent-aware from day one.

Founder StoryAI AgentsPaymentsOvraEU Fintech

Bottom line: We started Ovra because in late 2025 the only way to give an AI agent a payment was to paste a credit card into its context window. No EU-native option existed for per-agent virtual Visa cards with programmable policies, scoped credentials, and an audit trail an auditor could read. We built the infrastructure layer that wasn't there — and a year later, every major rail (Visa, Mastercard, Stripe, OpenAI, Google) shipped some version of the same architectural answer at the network level.

We didn't start with a grand thesis about agentic payments infrastructure. We started with a broken demo.

Late 2025. We were building AI agent workflows — the kind where an agent researches vendors, compares prices, and executes a purchase. Standard stuff. The agent worked beautifully up until the moment it needed to actually pay.

That's where everything fell apart.

The moment that broke us

Our agent needed to subscribe to a SaaS tool. Simple task. But to complete it, we had to hardcode a credit card number into the agent's context. Our personal card. In plaintext.

We looked at each other and said: this can't be how it works.

We searched for alternatives. Corporate card APIs that could issue per-transaction cards with spending limits, scoped to one merchant, destroyable after use. Something an agent could request programmatically without ever seeing the actual card number.

It didn't exist. Not for AI agents. Not in Europe.

Existing corporate card platforms were built for humans who log into dashboards. They didn't have APIs designed for autonomous software that needs a card for 30 seconds, with a €50 limit, locked to one specific merchant.

The gap we couldn't ignore

The more we talked to teams building with AI agents, the more we heard the same story:

"We just pass our Stripe key to the agent and hope for the best."

"We have a shared corporate card that three agents use. We can't tell which agent charged what."

"Our agent double-purchased a $2,000 annual subscription because there was no idempotency check."

"We turned off autonomous purchasing because we couldn't control it."

Every team had the same problem: agents that could do everything except pay safely. And the workarounds — shared credentials, manual approval for every purchase, disabling autonomous transactions entirely — defeated the purpose of having an autonomous agent.

What we decided to build

Ovra is the layer between AI agents and the financial system. Not a wallet. Not a billing tool. The infrastructure that answers one question: should this agent be allowed to make this payment?

The core idea is simple: an agent never sees a card number. Instead, it declares what it wants to buy (an intent), the system evaluates that intent against spending policies, and if approved, a single-use virtual card is issued for that specific transaction. The agent redeems the card, the payment goes through, and the credential is destroyed.

We call it attestation-before-access. The agent must prove its intent before it gets access to any financial credential. No shortcuts, no fallbacks. A year after we shipped this, Google's AP2 standardized the same principle at the network level via cryptographically signed Cart and Intent Mandates. Stripe's Shared Payment Token under ACP applies the same scope-and-burn pattern. The architecture turned out to be inevitable.

On top of that: a policy engine for spending rules (limits, merchant allowlists, time windows, approval workflows), real-time transaction monitoring, full audit trails, and an MCP server so agents can request payments through the standard protocol.

Why Europe

We're in Berlin. We chose to build EU-native because:

  1. Regulation is a feature, not a bug. PSD2, GDPR, AML/KYC, and the upcoming PSD3/PSR (provisional political agreement November 27, 2025; PSR application around Q1 2028) force you to build trust infrastructure from day one. That's exactly what agentic payments need.

  2. The card issuing ecosystem is ready. EU-regulated card issuing partners give us virtual Visa cards with tokenized credentials and full compliance out of the box. We don't need to become a bank.

  3. The market is underserved. Most US startups in this space build US-first. European companies deploying AI agents have no native option that's actually compliant with where the regulation is headed.

Where we are now

Ovra is in private beta with design partners across procurement, SaaS management, programmatic advertising, and logistics. The dashboard, the API, and the MCP server (Claude, GPT, Cursor, Vercel AI, OpenAI Agents, LangChain — one URL) all run today on an in-process sandbox card issuer. The same interface flips to real Visa rails when our regulated EMI partnership lands.

The market caught up to the thesis. Juniper Research projects $1.5T in agentic commerce spend by 2030; McKinsey projects $3T–$5T globally. Visa launched Intelligent Commerce Connect in April 2026. Mastercard open-sourced Verifiable Intent in March 2026. The infrastructure layer is no longer an open question — it's a compute race.

If you're building with AI agents and the payment part keeps breaking — that's exactly why we exist.

Join the private beta →

Frequently asked questions

Why did Tim and Alec build Ovra?
They were building AI agent workflows in late 2025 — the kind where an agent researches vendors, compares prices, executes a purchase. The agent worked beautifully until it had to pay. The only option was hardcoding a credit card number into the agent's context in plaintext. They searched for an EU-native, API-first agent payment layer with policy enforcement, scoped credentials, and an audit trail. It didn't exist. So they built it.
Why is Ovra built in Europe?
Three reasons. First, regulation is a feature: PSD2, GDPR, AML/KYC, and the upcoming PSD3/PSR (provisional agreement Nov 2025) force trust infrastructure from day one — exactly what agentic payments need. Second, the EU card-issuing ecosystem with regulated partners gives Ovra virtual Visa cards with tokenized credentials out of the box. Third, the market is underserved — most US startups in agent payments build US-first; European AI teams have no native option.
What does attestation-before-access mean?
Attestation-before-access is Ovra's core principle: the agent must declare and have its intent approved before any payment credential exists. Standard payment APIs hand the agent credentials and run policy checks afterward — by then the money has moved. Ovra inverts this. Intent → policy check → grant → credential. If policy denies, no card is issued. This is the same architectural principle Google's AP2 standardized at the network level for verifiable mandates.
Who is Ovra for?
Teams building AI agents that need to make real payments — procurement bots, SaaS subscription managers, programmatic ad buyers, travel agents, logistics agents. Anyone whose agent currently relies on a shared corporate card, a Stripe key in the prompt, or 'manual approval for every transaction' workflows that defeat the point of autonomy. Ovra makes per-agent virtual Visa cards with programmable policies the default.
How does Ovra integrate with existing AI agent frameworks?
Via Model Context Protocol (MCP) — one URL connects Claude, GPT, Cursor, Vercel AI, OpenAI Agents, LangChain, and OpenClaw. There's also a REST API where every MCP tool maps 1:1 to an HTTP endpoint. Existing agent frameworks plug in without architectural changes. The agent gets a tokenized credential reference; the actual card data never enters its context.