OpenClaw + Ovra: The Complete Agent Checkout Flow

OpenClaw agents use a browser. They can navigate to a checkout page, fill in payment details, and click "Pay." But giving an agent your credit card number to type into a form is exactly the kind of thing that goes wrong at scale.

Ovra gives OpenClaw agents a different path: declare intent, receive isolated credentials, complete the purchase, verify the result. The agent never sees a real card number. Here's how the entire flow works.

The setup

You need three things:

1. An Ovra account with at least one agent and a funded wallet.
2. A policy assigned to the agent (spend limits, merchant rules, etc.).
3. An OpenClaw assistant with the @ovra/mcp server connected.

The MCP server exposes 11 tools. For a basic checkout, the agent uses five:

| Tool | Purpose | |---|---| | ovra_policy | Check what the agent is allowed to do | | ovra_create_intent | Declare what the agent wants to buy | | ovra_get_credentials | Get payment credentials for checkout | | ovra_verify_transaction | Confirm the payment matched the intent | | ovra_claim_receipt | Attach proof of purchase |

The prompt

Buy the Notion Team Plan for €79 on checkout.getovra.com

That's it. The agent takes it from here.

Step 1 — Policy check

Before doing anything, the agent checks its policy:

→ ovra_policy

The response tells the agent its constraints:

{
  "maxTransactionEuros": 200,
  "dailyLimitEuros": 500,
  "dailySpentToday": 0,
  "blockedMccs": ["7995", "7801"],
  "enforcementLevel": "enforce",
  "status": "active"
}

€79 is under the €200 per-transaction limit. Daily spend is at €0 of €500. No merchant restrictions apply. The agent proceeds.

Step 2 — Declare intent

The agent creates an intent — a formal declaration of what it plans to buy:

→ ovra_create_intent
  purpose: "Monthly Notion Team subscription"
  amount: 79
  merchant: "Notion"

Ovra evaluates this against the policy, records the intent, and returns a confirmation:

{
  "intentId": "int_abc123",
  "status": "approved",
  "expiresAt": "2026-04-01T15:30:00Z"
}

The intent is approved. The agent has 30 minutes to complete the purchase.

Step 3 — Get credentials

With an approved intent, the agent requests payment credentials:

→ ovra_get_credentials
  intentId: "int_abc123"

Ovra issues a one-time DPAN with a cryptogram and returns a fill token:

{
  "fillToken": "ftok_a8f3...",
  "expiresAt": "2026-04-01T15:30:00Z",
  "last4": "4521"
}

The fill token is an encrypted, opaque reference. The agent can use it at checkout, but it cannot extract the card number, CVV, or expiry from it.

Step 4 — Browser checkout

The agent opens checkout.getovra.com in its browser (Playwright/Chromium) and fills the checkout form using the fill token. The checkout page decrypts the token server-side and processes the payment.

The agent sees: "Payment successful."

From the agent's perspective, it used a token. From the payment processor's perspective, a valid Visa card with a one-time cryptogram authorized the transaction.

Step 5 — Verify

After payment, the agent verifies the transaction:

→ ovra_verify_transaction
  intentId: "int_abc123"

Ovra checks:

• Did a charge arrive for this intent?
• Does the amount match (within tolerance)?
• Does the merchant descriptor match "Notion"?
• Did the charge happen within the grant's validity window?

{
  "status": "verified",
  "amountCharged": 79.00,
  "merchant": "Notion Labs Inc",
  "verifiedAt": "2026-04-01T15:02:33Z"
}

All checks pass. The transaction is verified.

Step 6 — Claim receipt

Finally, the agent attaches proof of purchase:

→ ovra_claim_receipt
  intentId: "int_abc123"
  file: "notion-invoice-april-2026.pdf"

The receipt is stored alongside the intent, creating a complete audit trail: intent → policy check → credentials → charge → verification → receipt.

What the agent never saw

Throughout this entire flow, the agent never had access to:

• The real card number (FPAN)
• The CVV or expiry date
• The DPAN or cryptogram (encrypted inside the fill token)
• The cardholder's billing address

The agent operated with a token. The token worked once. Now it's expired.

What happens if something goes wrong

| Scenario | What happens | |---|---| | Amount exceeds policy | Intent rejected at step 2 | | Merchant is blocked | Intent rejected at step 2 | | Daily limit exceeded | Intent rejected at step 2 | | Agent takes too long | Grant expires, credentials revoked | | Payment fails | Intent stays open, agent can retry (once) | | Wrong amount charged | Verification flags mismatch | | Agent tries to reuse token | Token expired, request rejected |

Every failure mode stops the flow before money moves or flags it immediately after. There's no silent failure state.

The complete audit trail

After the flow completes, the Ovra ledger contains:

15:00:01  Intent int_abc123 created — €79, Notion, agent "demo-agent"
15:00:01  Policy "standard" evaluated — ALLOWED
15:00:02  Grant gra_def456 issued — expires 15:30:00
15:00:02  Credential cre_ghi789 issued — DPAN ****4521
15:00:15  Agent opened checkout.getovra.com
15:00:22  Fill token redeemed
15:00:24  Transaction txn_jkl012 — €79.00, "Notion Labs Inc"
15:00:33  Verification — amount ✓, merchant ✓, timing ✓
15:01:45  Receipt attached — notion-invoice-april-2026.pdf

Every step is timestamped, linked to the intent, and attributable to a specific agent. This is what auditable agent spend looks like.