Zum Hauptinhalt springen
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.
KomponenteOwner
Merchant-API oder Checkout-FormMerchant
Card-Credentials (DPAN, Cryptogram, Expiry)Ovra (server-seitig, verschlüsselt)
Payment-ExecutionDeine 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 sprechen:
1

Intent approved

Standard-Intent-Flow mit gesetztem expectedMerchant.
2

Credential minten

POST /v1/mpp/credentials/mint (oder POST /v1/mpp/pay für One-Shot).
3

Präsentieren

Merchant-Call mit Authorization: Payment <cred>.
4

Verifizieren

Merchant ruft POST /v1/mpp/credentials/:id/verify mit ihrem Merchant-Key.
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):
1

Intent approved

Standard-Intent-Flow mit expectedAmountEuros.
2

Autofill-Token minten

POST /v1/cua/autofill-tokens returnt aft_* (30s TTL, single-use, Intent + Card + Merchant-Origin + Amount-Cap).
3

An Harness übergeben

aft_id an deinen CUA-Harness über deinen eigenen internen Channel — nicht via LLM-Kontext.
4

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

LLM klickt Submit

LLM sieht nur { status: "filled", masked_last4: "1234" }. Merchant settlet.

​
Runtime 3 — Direct API Execute (Legacy)

Für Server-zu-Server Flows wo Ovra das Gateway ist: 
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

LayerSchutz
Intent-FSMrequireIntent enforced; expired Intents abgelehnt
Grant-TTLKonfigurierbar, Default 5 Min.
Credential-TTLKonfigurierbar, Default 5 Min., 24h max
MPP-CredentialJWE-wrapped, single-use CAS-Consume
CUA-Autofill-TokenX-CUA-Harness-Secret-gated, 30s TTL, One-Shot
DPANNetwork-Token, nicht die FPAN
CryptogramSingle-use CAVV — an die Transaktion gebunden
Policy-EngineRe-evaluiert an jedem Checkpoint
IdempotencyRequired auf jedem money-moving POST

​
Runtime wählen

SituationRuntime
Merchant returnt WWW-Authenticate: Payment 402MPP
Merchant hat nur Checkout-FormCUA
Server-zu-Server, du kontrollierst beide EndenDirect API Execute

​
Weiter

MPP

Wire-Flow, Error-Matrix, Merchant-Onboarding.

CUA

Threat-Model, Harness-Grenze, JWKS-Prep.

Bezahlung

Die Pay-Säule-Übersicht.