> ## 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.

# Checkout-Runtime

> Wie Agents die Zahlungsausführung beim Merchant orchestrieren.

Die Checkout-Runtime definiert wer was während einer Zahlung tut. Ovra issued immer Credentials. Der Merchant settlet immer via eigenen Acquirer. Dein Agent wählt eine von drei Runtimes um sie zu verbinden.

| Komponente                                  | Owner                               |
| ------------------------------------------- | ----------------------------------- |
| Merchant-API oder Checkout-Form             | Merchant                            |
| Card-Credentials (DPAN, Cryptogram, Expiry) | Ovra (server-seitig, verschlüsselt) |
| Payment-Execution                           | Deine Agent-Runtime                 |

PAN und CVV gelangen in keiner Runtime in den Agent-Kontext — die Credential-Grenze wird von JWE-Wrapping (MPP) oder der Harness-Grenze (CUA) erzwungen.

## Runtime 1 — MPP

Für Merchants die [MPP](/de/concepts/mpp) sprechen:

<Steps>
  <Step title="Intent approved">
    Standard-Intent-Flow mit gesetztem `expectedMerchant`.
  </Step>

  <Step title="Credential minten">
    `POST /v1/mpp/credentials/mint` (oder `POST /v1/mpp/pay` für One-Shot).
  </Step>

  <Step title="Präsentieren">
    Merchant-Call mit `Authorization: Payment <cred>`.
  </Step>

  <Step title="Verifizieren">
    Merchant ruft `POST /v1/mpp/credentials/:id/verify` mit ihrem Merchant-Key.
  </Step>
</Steps>

Server-zu-Server. Kein Browser. Settlement passiert beim Acquirer des Merchants; Ovra schreibt die `transactions`-Row auf Verify.

## Runtime 2 — CUA

Für Merchants die nur ein Checkout-Form haben ([CUA](/de/concepts/cua)):

<Steps>
  <Step title="Intent approved">
    Standard-Intent-Flow mit `expectedAmountEuros`.
  </Step>

  <Step title="Autofill-Token minten">
    `POST /v1/cua/autofill-tokens` returnt `aft_*` (30s TTL, single-use, Intent + Card + Merchant-Origin + Amount-Cap).
  </Step>

  <Step title="An Harness übergeben">
    `aft_id` an deinen CUA-Harness über deinen eigenen internen Channel — nicht via LLM-Kontext.
  </Step>

  <Step title="Harness löst ein + füllt">
    Harness ruft `GET /v1/cua/autofill-tokens/:id/redeem` mit `X-CUA-Harness-Secret`, holt DPAN, füllt Form via CDP `Input.insertText`.
  </Step>

  <Step title="LLM klickt Submit">
    LLM sieht nur `{ status: "filled", masked_last4: "1234" }`. Merchant settlet.
  </Step>
</Steps>

## Runtime 3 — Direct API Execute (Legacy)

Für Server-zu-Server Flows wo Ovra das Gateway ist:

```bash theme={}
curl -X POST https://api.getovra.com/checkout/execute \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "intentId": "int_...",
    "targetUrl": "https://api.merchant.com/charge"
  }'
```

`targetUrl` muss HTTPS und SSRF-safe sein. Ovra resolvet Credentials, executet den Merchant-Call via PCI-Proxy-Forward-Pull, returnt das Ergebnis.

## Sicherheits-Layer

| Layer              | Schutz                                              |
| ------------------ | --------------------------------------------------- |
| Intent-FSM         | `requireIntent` enforced; expired Intents abgelehnt |
| Grant-TTL          | Konfigurierbar, Default 5 Min.                      |
| Credential-TTL     | Konfigurierbar, Default 5 Min., 24h max             |
| MPP-Credential     | JWE-wrapped, single-use CAS-Consume                 |
| CUA-Autofill-Token | `X-CUA-Harness-Secret`-gated, 30s TTL, One-Shot     |
| DPAN               | Network-Token, nicht die FPAN                       |
| Cryptogram         | Single-use CAVV — an die Transaktion gebunden       |
| Policy-Engine      | Re-evaluiert an jedem Checkpoint                    |
| Idempotency        | Required auf jedem money-moving POST                |

## Runtime wählen

| Situation                                        | Runtime            |
| ------------------------------------------------ | ------------------ |
| Merchant returnt `WWW-Authenticate: Payment` 402 | **MPP**            |
| Merchant hat nur Checkout-Form                   | **CUA**            |
| Server-zu-Server, du kontrollierst beide Enden   | Direct API Execute |

## Weiter

<CardGroup cols={2}>
  <Card title="MPP" icon="lock-keyhole" href="/de/concepts/mpp">
    Wire-Flow, Error-Matrix, Merchant-Onboarding.
  </Card>

  <Card title="CUA" icon="browser" href="/de/concepts/cua">
    Threat-Model, Harness-Grenze, JWKS-Prep.
  </Card>

  <Card title="Bezahlung" icon="credit-card" href="/de/concepts/pay">
    Die Pay-Säule-Übersicht.
  </Card>
</CardGroup>