Delivery-Optionen waren in Shopify bislang Blackboxen mit einem Preis, einem Label und einem Code. Wer im Checkout mehr steuern wollte, musste sich mit dem begnügen, was Shopify von sich aus mitlieferte: Versandart, Kosten, geschätzte Lieferzeit. Ab API-Version 2026-10 hat sich das geändert. Delivery Customization Functions können nun Metafields lesen, die direkt an Delivery-Optionen hängen — über den Aufruf metafield(namespace:, key:) auf jedem Eintrag in cart.deliveryGroups.deliveryOptions.
Das klingt nach einer Randnotiz aus dem Changelog. Es ist mehr. Denn zum ersten Mal können Händler und App-Entwickler eigene Daten an eine Versandoption hängen und diese Daten im Checkout-Laufzeitkontext wieder auslesen — ohne Umweg über externe APIs, ohne zusätzliche Netzwerklatenz. Für den deutschsprachigen Markt ist das relevanter als für viele andere Regionen, weil hierzulande weniger Kreditkarten- und mehr Rechnungskauf-Logik im Checkout liegt, und weil Speditions- und Packstation-Szenarien eigene Regeln brauchen.
Was genau in der Function-Input-Struktur passiert
Delivery-Optionen im Cart-Graph sind ab 2026-10 nicht mehr atomar. Jede Option im deliveryOptions-Array trägt jetzt einen Metafield-Zugriff mit sich. Der Aufruf verlangt Namespace und Key, also zum Beispiel metafield(namespace: "custom", key: "lieferscheinnummer"). Zurück kommt das Feld als typisierter Wert oder null, wenn nichts hinterlegt ist.
Praktisch heißt das: Eine Delivery Customization Function kann jetzt Bedingungen prüfen, die vorher nicht prüfbar waren. Ausschlussregeln für bestimmte Versandarten anhand eines eigenen Kunden-Segments. Preisaufschläge, die an ein Frachtklassen-Metafeld gekoppelt sind. Optionen, die nur erscheinen, wenn ein Warenkorb ein Gefahrgut-Flag trägt. Nichts davon braucht mehr eine Datenbankabfrage im Checkout.
Wer bislang versucht hat, so etwas über cart.attributes oder ein separates App-Metafeld zu lösen, kennt den Schmerz: Die Werte hängen am Warenkorb, nicht an der Versandoption. Bei mehreren Delivery-Groups — etwa Split-Shipments aus verschiedenen Standorten — wurde es schnell widersprüchlich. Die neue Struktur löst das, weil das Metafeld dort sitzt, wo die Entscheidung fällt.
Warum Händler jetzt handeln sollten, obwohl kein Handlungsbedarf besteht
Shopify schreibt in den Release Notes ausdrücklich: keine Aktion erforderlich. Bestehende Functions funktionieren weiter wie bisher. Wer nichts tut, bricht nichts.
Das ist die technische Wahrheit und die betriebswirtschaftliche Untertreibung. Denn die eigentliche Frage ist nicht, ob bestehende Setups weiterlaufen, sondern ob Händler den neuen Kontext nutzen, um ihre Checkout-Conversion zu heben. Der deutsche E-Commerce hat hier einen konkreten Nachholbedarf: Laut dem EHI-Online-Monitor stagniert die Abbruchquote im Checkout bei rund 70 Prozent über alle Sortimente. Ein relevanter Teil dieser Abbrüche passiert auf der Versandkosten-Seite. Wer dort differenzieren kann — nach Kundengruppe, nach Warenkorbklasse, nach Region —, hat einen Hebel, den reine Rabattlogik nicht ersetzt.
- Speditionsversand lässt sich an eine Frachtklasse im Warenkorb koppeln, statt pauschal bei 50 kg abzuschalten.
- Rechnungskauf-Optionen können auf Metafields wie Bonitäts-Segment oder Bestandskunden-Flag reagieren, ohne dass eine externe Schnittstelle im Checkout antwortet.
- Packstation- und Wunschtermin-Auswahl lässt sich an einen DHL- oder DPD-spezifischen Service-Code binden, der am Versandprofil hängt.
Der Punkt ist nicht, dass diese Szenarien vorher unmöglich waren. Sie waren umständlich, fragil und langsam. Jetzt sind sie Teil des Function-Inputs und damit deterministisch auswertbar.
Welche Architektur sich für DACH-Händler anbietet
Wer Delivery Customization Functions heute selbst schreibt oder bauen lässt, sollte die Metafield-Vererbung sauber aufsetzen. Der entscheidende Ort ist nicht der Checkout, sondern das Versandprofil und die dahinterliegende App-Logik. Metafields müssen auf der Delivery-Option selbst liegen — nicht auf dem Cart, nicht auf dem Kunden.
In der Praxis bedeutet das eine zweistufige Architektur. Eine App oder eine Backend-Funktion befüllt die Delivery-Option-Metafields beim Erzeugen der Versandrate, typischerweise über eine Carrier-Service- oder Delivery-Customization-Kette. Die Function liest sie später im Checkout und trifft Entscheidungen. Wichtig: Metafields auf Delivery-Optionen sind nicht frei beschreibbar aus der Function heraus. Sie sind Input, nicht Output. Wer schreiben will, braucht einen Cart-Transform oder eine nachgelagerte Order-Bearbeitung.
Die Function wird zum Leser, nicht zum Schreiber. Das ist eine Einschränkung — und zugleich der Grund, warum die Struktur konsistent bleibt.
Für Händler mit hohem Anteil an B2B-Bestellungen im DACH-Raum ist das besonders interessant, weil Rechnungskauf und individuelle Versandkonditionen dort die Regel sind. Die Option, Kunden-segmentierte Raten im Checkout zu zeigen, ohne ein eigenes Rate-Service im kritischen Pfad zu betreiben, reduziert Latenz und Fehlerquellen.
Was das für Apps und Agenturen bedeutet
Die Änderung verschiebt die Grenze zwischen „Shopify-Bordmitteln“ und „App-Logik“ ein weiteres Stück. Delivery-Customization-Apps wie ShipMagic, Advanced Shipping Rules oder regionale Anbieter können nun Funktionalität anbieten, die vorher nur mit tiefen Checkout-Modifikationen oder Shopify Plus Scripts möglich war. Scripts sind seit 2025 für neue Kunden nicht mehr verfügbar; Functions sind der de facto einzige Weg, den Checkout zu individualisieren.
Agenturen sollten die Migration als Anlass nehmen, ihre Delivery-Logik zu inventarisieren. Konkret: Welche Versandentscheidungen hängen heute an cart.attributes? Welche davon gehören eigentlich an die Delivery-Option? Wer das sauber trennt, gewinnt Wartbarkeit — und kann später leichter auf Shopify Plus Checkout Extensibility wechseln, wo ebenfalls metafield-basiert gearbeitet wird.
Ein Randdetail mit Architekturfolgen: Metafield-Zugriffe in Functions unterliegen denselben Berechtigungsregeln wie überall im Admin GraphQL. Namespaces, die einer anderen App gehören, bleiben tabu, es sei denn, es gibt eine explizite Freigabe. Wer Metafields auf Versandoptionen schreibt und liest, sollte denselben Namespace nutzen und nicht zwischen „custom“ und einem App-Namespace mischen.
Wie funktioniert der Zugriff auf Metafields in der Praxis?
Der Aufruf ist schlicht. Innerhalb der Function-Laufzeit lässt sich für jede Delivery-Option ein Metafield mit Namespace und Key abfragen:
option.metafield(namespace: "meine_app", key: "frachtklasse")
Zurück kommt ein Objekt mit value und type oder null. Der Typ richtet sich nach der Definition im Metafield-Definition-Store. Wer mit Zahlen arbeitet, sollte die Typisierung ernst nehmen — ein als single_line_text_field gespeicherter Wert lässt sich nicht ohne Casting als Zahl verwenden. Wer mit JSON arbeitet, muss die Metafield-Definition entsprechend setzen und die Deserialisierung selbst übernehmen.
Ein häufiger Stolperstein: Metafields, die erst zur Laufzeit entstehen — etwa durch eine Carrier-Service-App, die die Option dynamisch erzeugt — sind nur dann sichtbar, wenn sie vor der Function-Ausführung geschrieben wurden. Die Reihenfolge im Checkout-Graph ist deterministisch, aber nicht beliebig verschiebbar. Wer Delivery-Customization-Functions mit eigenen Metafields kombiniert, muss die Kette Carrier-Service → Delivery-Customization → Checkout sauber planen.
Was Händler in den nächsten Wochen tun sollten
Der pragmatische Weg für die meisten DACH-Händler: Delivery Customization Functions inventarisieren, prüfen, ob eine Metafield-basierte Bedingung den Checkout messbar verbessert, und wenn ja, mit einer einzigen Regel starten. Ein Frachtklassen-Aufschlag ist ein guter Pilot, weil er sofort sichtbar wird und keine Bonitätslogik braucht.
Shopify Plus-Händler mit eigenem Checkout-Stack sollten parallel prüfen, ob ihre Metafield-Definitionen überhaupt auf Delivery-Optionen verweisen können. Die API erlaubt es, aber die Metafield-Definition muss die richtige Owner-Typ-Bindung haben. Das ist Dokumentationsarbeit, keine Programmierarbeit — und genau die Sorte Vorbereitung, die später Wochen spart.
Wer jetzt nichts tut, verliert nichts. Wer jetzt eine saubere Metafield-Struktur aufsetzt, hat sie, wenn der nächste Checkout-Umbau ansteht — und das wird er, spätestens wenn Shopify Plus Checkout Extensibility zur Pflicht wird.