Zum Hauptinhalt springen

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.

Bezahlung ist ein Konzept — Agentic Pay — mit zwei Ausführungsmodi. Egal welcher Modus läuft, jede Transaktion landet auf einer transactions-Row mit erzwungenem requireIntent und vollständigem Audit-Trail.
ModusWann einzusetzenStatus
MPP (Machine Payments Protocol)Merchant returnt 402 Payment Required mit WWW-Authenticate: Payment. JWE-wrapped Network-Token, server-zu-server Settle.Code-complete (Phase 7)
CUA (Computer-Use Autofill)Merchant hat nur einen Browser-Checkout. Tokenisierter DPAN wird vom Harness ins Formular geschrieben — niemals via LLM-Kontext.Phase 8 (gerade ausgeliefert)
Beide Modi sind heute Sandbox-only. Echtes Merchant-Settlement steht auf der v1.3+-Roadmap.

​
Der gemeinsame Lebenszyklus

1

Intent

Agent postet einen Intent. Policy-Engine und Risk-Engine bewerten ihn. Ergebnis: approved, pending_approval, denied.
2

Credential

Entweder mintet Ovra ein MPP-Credential (JWE-wrapped) oder ein CUA-Autofill-Token (single-use, 30s TTL). Beide binden die Credential an den genehmigten Intent.
3

Ausführen

MPP: Agent präsentiert die Credential dem Merchant via Authorization: Payment. CUA: Harness schreibt den DPAN via CDP Input.insertText ins Formular — das LLM sieht nur { status: "filled" }.
4

Settle und Audit

Transaktions-Row geschrieben, Ledger-Einträge gepostet, Webhooks feuern (mpp.transaction.completed, transaction.completed), Audit-Event landet.

​
Die richtige Surface wählen

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

Bezahlung ist developer-driven; das Dashboard zeigt Transaktionen, Decisions, Audit. Kein “pay now”-Button.

​
Schnellbeispiel — MPP One-Shot

Der High-Level-Orchestrator behandelt 402-Roundtrip, Mint, Present und Verify in einem einzigen 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" }
}

​
Schnellbeispiel — 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
  }'
Returnt { aft_id: "aft_...", expires_at: "..." }. Übergib die aft_id an den Harness — nur der Harness kann sie via X-CUA-Harness-Secret einlösen.

​
Was Bezahlung nicht macht

  • Kein direkter Merchant-Call aus dem LLM-Kontext. PAN/CVV gelangen nie ins Modell. CUA erzwingt das an der Harness-Grenze; MPP via JWE.
  • Kein echtes Settlement. Beide Modi nutzen Sandbox-Kartendaten und simulierte Wallet-Effekte. Live-Mode öffnet in v1.3+.
  • Kein Wallet-Provisioning für Apple Pay / Google Pay / Click-to-Pay (die Rails existieren via Network Token Service, sind heute aber kein Produktversprechen).

​
Sacred Guarantees

  • requireIntent wird an jedem Checkpoint erzwungen — intent, grant, issue, redeem, checkout.
  • Ein money-moving POST ohne Idempotency-Key wird mit E_IDEMPOTENCY_REQUIRED abgelehnt.
  • Single-use Credentials erzwingen CAS-Consume — Replay returnt 402 invalid-challenge, niemals ein Oracle.

​
Weiter

MPP-Deep-Dive

402-Challenge-Format, JWE-Wrapping, Mint- und Verify-Endpoints.

CUA-Deep-Dive

Autofill-Token-TTL, Harness-Grenze, Trusted Agent Protocol Prep.

Intents

Die Approval-Primitive, von der jede Zahlung abhängt.

Karten

Multi-Card pro Agent, Freeze, Rotate, Network Tokens.