Zum Hauptinhalt springen

​
Verantwortlichkeiten

KomponenteWer stellt bereitHinweise
Browser / SeiteSie oder Ihre Agent-Runtimez. B. lokales Playwright, Browserbase oder ein Chromium, das die DevTools-HTTP-JSON-API exponiert
Checkout-UIHändlerz. B. Stripe, Shopify, Adyen — deren gehostete Checkout-Seiten, nicht die Ovra-Infrastruktur
Karten-CredentialsOvraWerden nur serverseitig aufgelöst, wenn ein Fill Token eingelöst wird
Fill-AusführungOvra APINach POST /checkout/token; nicht per MCP/WebSocket vom Agent zu Ovra, um den Browser „fernzusteuern“

​
Browser-Ablauf — Token → Fill

  1. Intent ist approved und enthält expectedMerchant (erforderlich für die Ausgabe eines Tokens).
  2. POST /checkout/token mit { intentId } liefert ein kurzlebiges, einmal nutzbares opakes Token, gebunden an die Domain dieses Händlers.
  3. POST /checkout/fill mit { token, cdpBaseUrl } — etwa cdpBaseUrl: "http://localhost:9333" (Chrome DevTools-HTTP-JSON-API; übergeben Sie in diesem Payload keine ws://-URL als cdpBaseUrl).
  4. Ovra validiert das Token, löst die Karte intern auf, füllt PAN/Ablauf/CVC auf der Seite und schließt die Buchung ab, wenn der Fill erfolgreich ist.
Der Agent (oder das LLM) verarbeitet nur intentId und das opake token. Er erhält niemals PAN/CVV. Ovra verlangt nicht, dass der Agent eine WebSocket-Verbindung zu Ovra öffnet; beim Fill spricht die API mit Ihrem DevTools-Endpunkt des Browsers.

​
SDK

@ovra/pay ist die empfohlene Browser-Integration: Es beschafft Credentials und führt den Fill in page.evaluate() aus, sodass Kartendaten außerhalb des für den Agent sichtbaren JS-Scopes bleiben.

​
Kosten / Hosting

  • Browser: Ihre Infrastrukturkosten (lokal oder ein gehosteter Browser-Anbieter wie Browserbase).
  • Fill: Arbeit auf Seite der Ovra API; kein separates „CDP-Session“-Produkt aus Sicht des Agents.