Skip to main content
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.
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:
Response (200):

​
Schnellbeispiel — CUA Mint

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.