> ## 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 (Pay)

> Agents zahlen jeden für alles mit gescopten virtuellen Karten.

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.

| Modus                                                   | Wann einzusetzen                                                                                                                 | Status                        |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| **MPP** ([Machine Payments Protocol](/de/concepts/mpp)) | 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](/de/concepts/cua))     | Merchant hat nur einen Browser-Checkout. Tokenisierter DPAN wird vom Harness ins Formular geschrieben — niemals via LLM-Kontext. | Phase 8 (gerade ausgeliefert) |

<Note>
  Beide Modi sind heute Sandbox-only. Echtes Merchant-Settlement steht auf der v1.3+-Roadmap.
</Note>

## Der gemeinsame Lebenszyklus

<Steps>
  <Step title="Intent">
    Agent postet einen Intent. Policy-Engine und Risk-Engine bewerten ihn. Ergebnis: `approved`, `pending_approval`, `denied`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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" }`.
  </Step>

  <Step title="Settle und Audit">
    Transaktions-Row geschrieben, Ledger-Einträge gepostet, Webhooks feuern (`mpp.transaction.completed`, `transaction.completed`), Audit-Event landet.
  </Step>
</Steps>

## Die richtige Surface wählen

<CardGroup cols={2}>
  <Card title="REST" icon="code">
    `POST /intents` · `POST /v1/mpp/pay` · `POST /v1/cua/autofill-tokens`
  </Card>

  <Card title="SDK" icon="cube">
    `payments.payViaMpp(...)`, `payments.mintMppCredential(...)`
  </Card>

  <Card title="MCP" icon="terminal">
    `ovra_pay` (action: `checkout` | `handle_402` | `status` | `discover`)
  </Card>

  <Card title="Dashboard" icon="display">
    Bezahlung ist developer-driven; das Dashboard zeigt Transaktionen, Decisions, Audit. Kein "pay now"-Button.
  </Card>
</CardGroup>

## Schnellbeispiel — MPP One-Shot

Der High-Level-Orchestrator behandelt 402-Roundtrip, Mint, Present und Verify in einem einzigen Call:

```bash theme={}
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):

```json theme={}
{
  "credential_id": "mppc_...",
  "merchant_status": 200,
  "receipt": "eyJ2ZXJzaW9uIjoiMSIs...",
  "merchant_body": { "order_id": "ord_42" }
}
```

## Schnellbeispiel — CUA Mint

```bash theme={}
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

<CardGroup cols={2}>
  <Card title="MPP-Deep-Dive" icon="lock-keyhole" href="/de/concepts/mpp">
    402-Challenge-Format, JWE-Wrapping, Mint- und Verify-Endpoints.
  </Card>

  <Card title="CUA-Deep-Dive" icon="browser" href="/de/concepts/cua">
    Autofill-Token-TTL, Harness-Grenze, Trusted Agent Protocol Prep.
  </Card>

  <Card title="Intents" icon="file-signature" href="/de/concepts/intents">
    Die Approval-Primitive, von der jede Zahlung abhängt.
  </Card>

  <Card title="Karten" icon="rectangle" href="/de/concepts/cards">
    Multi-Card pro Agent, Freeze, Rotate, Network Tokens.
  </Card>
</CardGroup>