UCP & Agentic Commerce einfach erklärt

UCP steht für Universal Commerce Protocol. Es ist ein offener Standard, den Google im Januar 2026 gestartet hat, mitentwickelt unter anderem mit Shopify, Etsy, Wayfair, Target und Walmart. Dazu kommen über 20 weitere Partner, darunter Zahlungsanbieter wie Stripe, Visa, Mastercard und Adyen. Die Spezifikation ist Open Source unter der Apache-2.0-Lizenz. Jeder Shop darf sie umsetzen, ohne jemanden zu fragen.

UCP beschreibt die Bausteine eines Einkaufs als sogenannte Capabilities, also Fähigkeiten:

• Discovery: Wie findet ein Agent heraus, was ein Shop kann?
• Katalogsuche: Produkte suchen und Details abrufen.
• Cart: Warenkorb füllen und Preise berechnen lassen.
• Checkout: Eine Kauf-Session anlegen und abschließen.
• Identity Linking: Kundenkonto verknüpfen (per OAuth), damit Adressen und Treuepunkte funktionieren.
• Payment: Bezahlen über sogenannte Payment-Handler, zum Beispiel Wallets.
• Orders: Bestellstatus und Lieferung verfolgen.

Transportiert wird das Ganze auf drei Wegen: klassisch per REST-API, per MCP (Model Context Protocol, die Werkzeug-Schnittstelle vieler KI-Assistenten) oder per A2A (Agent-to-Agent). Dieser Shop startet mit REST.

Die ganze Spezifikation: ucp.dev

Jeder UCP-Shop legt an einer festen Adresse eine Visitenkarte ab: /.well-known/ucp. Ein Agent muss also nichts raten. Er ruft diese eine URL auf und weiß danach, welche Sprache der Shop spricht.

curl https://stayhypd.de/.well-known/ucp

{
  "ucp": {
    "version": "draft",
    "services": {
      "dev.ucp.shopping": [
        { "transport": "rest", "endpoint": "https://stayhypd.de/api/ucp/v1" }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.catalog.search": [ … ],
      "dev.ucp.shopping.cart": [ … ],
      "dev.ucp.shopping.checkout": [ … ],
      "dev.ucp.shopping.order": [ … ]
    },
    "payment_handlers": {}
  },
  "keys": []
}

• version: welche Fassung der Spezifikation der Shop spricht.
• services: wo die API liegt und über welchen Transport (hier REST).
• capabilities: was der Shop kann, zum Beispiel dev.ucp.shopping.checkout, dev.ucp.shopping.cart, dev.ucp.shopping.catalog.search und dev.ucp.shopping.order. Der Agent gleicht das mit seinen eigenen Fähigkeiten ab.
• payment_handlers: welche Bezahlwege ein Agent direkt nutzen darf. Bei uns noch leer, siehe Status.
• keys: öffentliche Schlüssel, mit denen signierte Nachrichten geprüft werden können.

„Ich brauche Protein-Snacks für nach dem Training und etwas für morgen früh nach einer langen Nacht.“

Das sagt ein Mensch zu seinem Assistenten. Der Agent macht daraus vier Schritte gegen diesen Shop:

1. Visitenkarte lesen

Der Agent prüft, ob der Shop UCP spricht und wo die API liegt.

GET https://stayhypd.de/.well-known/ucp

2. Katalog durchsuchen

Er sucht gezielt nach dem Anlass, nicht nach Werbetexten. Filter wie diet, exclude_allergen oder max_price sind kombinierbar.

GET /api/ucp/v1/catalog/search?goal=training

{
  "products": [
    {
      "id": "core-vitamin-d3-k2",
      "title": "CORE — Vitamin D3 + K2 Tropfen",
      "product_type": "supplement",
      "protein_per_serving_g": 0,
      "allergens": [],
      "variants": [
        {
          "sku": "C2B-VDK-01",
          "price": {
            "amount": 1990,
            "currency": "EUR"
          },
          "availability": "in_stock"
        }
      ]
    }
  ]
}

Preise kommen als ganze Cent-Beträge mit Währung, Verfügbarkeit als festes Wort. Nichts davon muss ein Agent aus Fließtext herauslesen.

3. Empfehlung holen

Noch einfacher: Der Agent schickt den ganzen Satz. Der Shop erkennt die Anlässe (Training, Morgen danach) und antwortet mit passenden Produkten, Begründung und Bundles.

POST /api/ucp/v1/recommend
Content-Type: application/json

{
  "text": "Protein-Snacks für nach dem Training und etwas für morgen früh nach einer langen Nacht",
  "limit": 5
}

4. Checkout vorbereiten

Der Agent legt eine Checkout-Session mit SKUs und Mengen an. Er schickt keine Preise mit. Die rechnet der Server.

POST /api/ucp/v1/checkout-sessions
Content-Type: application/json

{
  "line_items": [
    {
      "sku": "C2B-VDK-01",
      "quantity": 2
    },
    {
      "sku": "C2B-MAG-KOMP-01",
      "quantity": 1
    }
  ]
}

{
  "status": "requires_escalation",
  "totals": { "total": { "amount": … , "currency": "EUR" }, "tax_included": true },
  "continue_url": "https://stayhypd.de/checkout/session/…"
}

requires_escalation heißt: Jetzt ist der Mensch dran. Der Agent zeigt dir den Link, du siehst Warenkorb, Preise und Versand im normalen Checkout und bestätigst die Zahlung selbst.

Ein Mensch erkennt einen Proteinriegel am Foto. Ein Agent sieht kein Foto. Er braucht Felder. Wenn ein Feld fehlt, kann er die Frage seines Menschen nicht beantworten, und dann empfiehlt er einen anderen Shop.

• SKU und Varianten: Was genau landet im Warenkorb? Einzelriegel oder 12er-Box?
• Preis und Grundpreis: in Cent, inklusive MwSt., pro Variante.
• Bestand: Lieferbar, knapp oder ausverkauft. Ein Agent bestellt nichts, was es nicht gibt.
• Nährwerte: pro 100 g und pro Portion. „Mindestens 20 g Protein“ ist so eine Filterfrage.
• Allergene und Ernährungsform: „ohne Milch“, „vegan“, „glutenfrei“ als feste IDs statt Freitext.
• Was, für wen, wann: kurze, eindeutige Sätze, die eine KI direkt zitieren kann.
• Pflichthinweise: Koffein, Nahrungsergänzung. Der Agent muss sie weitergeben können.

Bei STAYHYPD liegen alle diese Daten in einer einzigen Quelle. Shop, Suchmaschinen-Markup, llms.txt, Sitemap und die Agent-API lesen dieselben Felder. Ändert sich ein Preis, stimmt er überall gleichzeitig.

• Der Server rechnet Preise neu. Immer. Was ein Agent oder Browser als Preis mitschickt, wird ignoriert. So kann niemand einen Rabatt „erfinden“.
• Der Mensch bestätigt die Zahlung. Der Agent bereitet vor, bezahlt aber nicht selbst. Erst mit einem angebundenen Payment-Handler und deiner ausdrücklichen Freigabe könnte sich das ändern.
• Health-Safety-Layer. Fragt jemand nach einem medizinischen Thema, sagt die API dem Agenten ausdrücklich: Das sind Lebensmittel, keine Arzneimittel, bitte auf ärztlichen Rat verweisen. Verbotene Gesundheitsversprechen werden nicht ausgeliefert.
• Bestand und Menge werden geprüft. Unbekannte SKUs fliegen raus, Mengen werden auf den Lagerbestand gedeckelt.
• Rate Limits und keine Admin-Rechte. Die öffentliche API kann lesen und Sessions anlegen. Preise, Texte oder Bestände ändern kann sie nicht.

UCP-ready nach dem Draft-Stand der Spec, noch nicht gegen offizielle Conformance-Tests geprüft; Payment-Handler folgen.

Was heute funktioniert:

• UCP-Profil unter /.well-known/ucp
• Katalogsuche, Produktdetails, Empfehlungen, Warenkorb, Checkout-Session und Bestellstatus per REST
• OpenAPI-Beschreibung, llms.txt und strukturierte Daten (Schema.org) auf jeder Seite

Was noch fehlt:

• Offizielle Conformance-Tests
• Payment-Handler für Zahlung direkt durch den Agenten
• Signierte Requests und Identity Linking
• MCP- und A2A-Transport

Die Spezifikation ist selbst noch in Bewegung. Wir ziehen nach, sobald sich Teile stabilisieren.