Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getovra.com/llms.txt

Use this file to discover all available pages before exploring further.

Pay is one concept — Agentic Pay — with two execution modes. Whichever mode runs, every transaction lands on a transactions row with requireIntent enforced and a full audit trail.
ModeWhen to use itStatus
MPP (Machine Payments Protocol)Merchant returns 402 Payment Required with WWW-Authenticate: Payment. JWE-wrapped network token, server-to-server settle.Code-complete (Phase 7)
CUA (Computer-Use Autofill)Merchant only has a browser checkout. Tokenized DPAN injected into form by a harness — never via the LLM context.Phase 8 (just shipped)
Both modes are sandbox-only today. Real merchant settlement is on the v1.3+ roadmap.

​
The shared lifecycle

1

Intent

Agent posts an intent. Policy engine and risk engine evaluate it. Result: approved, pending_approval, denied.
2

Credential

Either Ovra mints an MPP credential (JWE-wrapped) or a CUA autofill token (single-use, 30s TTL). Both bind the credential to the approved intent.
3

Execute

MPP: agent presents the credential to the merchant via Authorization: Payment. CUA: harness writes the DPAN into the form via CDP Input.insertText — the LLM only sees { status: "filled" }.
4

Settle and audit

Transaction row written, ledger entries posted, webhooks fire (mpp.transaction.completed, transaction.completed), audit event lands.

​
Choose the right surface

REST

POST /intents · POST /v1/mpp/pay · POST /v1/cua/autofill-tokens

SDK

payments.payViaMpp(...), payments.mintMppCredential(...)

MCP

ovra_pay (action: checkout | handle_402 | status | discover)

Dashboard

Pay is developer-driven; the dashboard shows transactions, decisions, audit. No “pay now” button.

​
Quick example — MPP one-shot

The high-level orchestrator handles the 402 round-trip, mint, present, and verify in a single call: 
curl -X POST https://api.getovra.com/v1/mpp/pay \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "url": "https://shop.example.com/checkout/abc",
    "intentId": "int_...",
    "cardId": "ca_..."
  }'
Response (200): 
{
  "credential_id": "mppc_...",
  "merchant_status": 200,
  "receipt": "eyJ2ZXJzaW9uIjoiMSIs...",
  "merchant_body": { "order_id": "ord_42" }
}

​
Quick example — CUA mint

curl -X POST https://api.getovra.com/v1/cua/autofill-tokens \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "intentId": "int_...",
    "cardId": "ca_...",
    "merchantOrigin": "https://shop.example.com",
    "amountCentsMax": 2999
  }'
Returns { aft_id: "aft_...", expires_at: "..." }. Hand the aft_id to the harness — only the harness can redeem it via X-CUA-Harness-Secret.

​
What Pay does not do

  • No direct merchant call from the LLM context. PAN/CVV never enter the model. CUA enforces this at the harness boundary; MPP enforces it via JWE.
  • No live settlement. Both modes use sandbox card data and simulated wallet effects. Live mode opens in v1.3+.
  • No wallet provisioning for Apple Pay / Google Pay / Click-to-Pay yet (the rails exist via the network token service but are not surfaced as a product promise today).

​
Sacred guarantees

  • requireIntent is enforced at every checkpoint — intent, grant, issue, redeem, checkout.
  • A money-moving POST without an Idempotency-Key is rejected with E_IDEMPOTENCY_REQUIRED.
  • Single-use credentials enforce CAS consume — replay returns 402 invalid-challenge, never an oracle.

​
Next

MPP deep-dive

402 challenge format, JWE wrapping, mint + verify endpoints.

CUA deep-dive

Autofill token TTL, harness boundary, Trusted Agent Protocol prep.

Intents

The approval primitive every payment depends on.

Cards

Multi-card per agent, freeze, rotate, network tokens.