Die Aufgabe – und ihre Grenze
TAP hilft einem Händler, signierte Agentenidentität und zugehörigen Kontext an seiner Web- oder API-Grenze zu prüfen. So kann eine Integration Agentenzugriffe anders behandeln als unbekannte Automatisierung. Die Identitätsprüfung bleibt von der fachlichen Kaufentscheidung zu unterscheiden.
Nicht dafür gedacht: Kein vollständiges Commerce-Datenmodell und kein pauschaler Nachweis, dass jede Agentenhandlung vom Kunden erlaubt ist.
Wie es sich in den Stack einfügt
- Arbeitet über bestehenden Web- und API-Protokollen.
- Kann Commerce-Protokolle ergänzen, ohne deren Warenkorb- und Bestellsemantik zu ersetzen.
Release und Arbeitsfassung getrennt
- Veröffentlichter Stand
- Keine eigenständige Releaseversion verifiziert
- Arbeitsfassung
- Kein separater Draft hier ausgewiesen
Eine eigenständige aktuelle semantische Spezifikationsversion wurde in den geprüften Quellen nicht belastbar festgestellt.
- Lizenz / Bedingungen
- Visa Developer Center Terms und TAP Product Terms; keine MIT-/Apache-Lizenz.
Originalbedingungen prüfen ↗ - Quellenprüfung
- · Kein Installations- oder Konformitätstest
Ein konkreter Ablauf
Die Schritte ordnen die Rolle des Protokolls ein. Sie sind kein ausführbarer oder getesteter Quickstart.
- Ein Agent sendet einen signierten Zugriff mit dem vorgesehenen Kontext.
- Der Händler prüft Signatur, Herkunft und Gültigkeit nach der Spezifikation.
- Eigene Geschäftsregeln entscheiden, welche Daten oder Aktionen zugelassen werden.
SDKs und Implementierungswege
Die Einträge unterscheiden Bibliotheken, Modelle und Beispiele. Paketnamen sind Upstream-Einstiege, keine hier getesteten Installationsempfehlungen. Prüfen Sie vor der Integration die exakte Version und deren Spezifikationsunterstützung.
Visa TAP Sample-System
Artefakt: Sample: FastAPI/Streamlit, Node-Proxy und React-Frontend
Paket / Modul: Kein eigenständiges universelles npm/PyPI-TAP-SDK verifiziert
Version & Kompatibilität: Sample-Stand statt allgemeiner SDK-Reife
Visa-spezifische Bedingungen beachten; Demo nicht als Produktionsintegration ausgeben.
Was für den Betrieb offen bleibt
- Ein öffentlich sichtbares Repository ist nicht automatisch permissiv lizenzierter Open-Source-Code.
- Visa-Onboarding, Produktbedingungen, Schlüsselverwaltung und operative Zulassung gesondert klären.
Eine offene Spezifikation erteilt keine automatische Erlaubnis für Zahlungen oder Verkaufskanäle. Testmodus, Benutzerfreigabe und Produktionszulassung bleiben eigene Schritte.
Originalquellen
Redaktioneller Stand: . Ein Versionsstand gilt für die genannte Spezifikation oder Bibliothek, nicht automatisch für andere Sprachpakete. „Nicht verifiziert“ bedeutet nicht „existiert nicht“.