Shopify Insights

Shopify Checkout Extensibility: Guide für Entwickler

23. März 2026 · 5 Minuten Lesezeit

Mark Chang

Founder & CTO

Wer schon länger auf Shopify entwickelt, kennt die alte Methode zur Checkout-Anpassung: checkout.liquid öffnen, hoffen, dass beim nächsten Shopify-Update nichts bricht, und akzeptieren, dass Shop-Pay-Kompatibilität praktisch ausgeschlossen war. Diese Ära ist vorbei.

Shopify Checkout Extensibility ist das neue Fundament, und für Entwickler verändert es alles: wie Checkout-Anpassungen gebaut, ausgeliefert und gewartet werden. Hier ist, was du wissen musst.

Was ist Checkout Extensibility?

Checkout Extensibility ist Shopifys Framework für Checkout-Anpassungen über ein modulares, App-basiertes System, anstatt Template-Dateien direkt zu bearbeiten. Es ersetzt checkout.liquid vollständig und ist heute der einzige unterstützte Weg, den Shopify-Checkout anzupassen.

Es besteht aus vier zentralen Tools, die zusammenarbeiten:

Checkout UI Extensions: Einbinden benutzerdefinierter UI-Komponenten an definierten Extension Points im Checkout-Ablauf
Shopify Functions: Erweiterung oder Ersatz von Shopifys serverseitiger Business-Logik (Rabatte, Versand, Zahlung, Warenkorbvalidierung)
Web Pixels: Tracking von Kundenereignissen für Analytics und Werbung in einer gesandboxten, datenschutzkonformen Umgebung
Branding API: Programmatische Kontrolle über das visuelle Erscheinungsbild des Checkouts, über den Checkout-Editor hinaus

Warum Shopify checkout.liquid abgekündigt hat

Die Probleme mit checkout.liquid waren bekannt. Anpassungen waren eng mit dem Checkout-HTML verknüpft, was bedeutete, dass jedes Shopify-Plattform-Update ein potenzielles Breaking Change war. Es war inkompatibel mit Shop Pay. Es konnte nicht sicher getestet werden. Und es verhinderte, dass Händler von Shopifys laufenden Performance- und Sicherheitsverbesserungen profitieren konnten.

Die Migration verlief in zwei Phasen:

13. August 2024: checkout.liquid für die Schritte Kontaktdaten, Versand und Zahlung deaktiviert
28. August 2025: checkout.liquid, Script-Tags und Additional Scripts für die Danke- und Bestellstatusseiten deaktiviert

Wer die Danke- und Bestellstatusseiten noch nicht migriert hat: Diese Frist ist bereits abgelaufen. Bestehende Legacy-Anpassungen auf diesen Seiten werden nicht mehr gerendert.

Checkout UI Extensions: Der zentrale Baustein

UI Extensions ermöglichen es, benutzerdefinierte UI in den Checkout-Ablauf einzubinden. Sie funktionieren über ein System von Extension Targets, vordefinierten Slots, an denen die Komponente gerendert werden kann.

Zwei Arten von Targets:

Statische Targets: gebunden an bestimmte Checkout-Schritte wie Kontaktdaten, Versandmethodenauswahl und Bestellübersichts-Positionen
Block Targets: rendern an jeder Stelle im Checkout und sind immer sichtbar, unabhängig davon, welche Schritte aktiv sind (z. B. für Bestellnotizen oder globale Vertrauensabzeichen)

Wichtige technische Details:

Extensions werden standardmäßig mit Preact aufgesetzt, Hooks wie useState und useEffect sind direkt verfügbar
Die UI wird über Polaris-Webkomponenten via Remote DOM gerendert, kein beliebiges HTML. <script>-Tags oder CSS-Overrides sind nicht möglich
Extensions laufen in einer isolierten Sandbox, kein Zugriff auf sensible Zahlungsdaten oder das Checkout-DOM
Alle Komponenten übernehmen automatisch die Branding-Einstellungen des Händlers - Schriftarten, Farben, Eckenradius, für ein konsistentes Checkout-Erlebnis
Entwicklung mit der Shopify CLI, erforderlich für Generierung, Entwicklung und Deployment von Extensions

Was sich damit bauen lässt:

Upsell- und Cross-Sell-Blöcke
Benutzerdefinierte Felder (Geschenknachrichten, Bestellnotizen, Lieferhinweise)
Vertrauensabzeichen und Treuepunktanzeigen
Adressvalidierung und individuelle Versandmethoden-Nachrichten
Nachkauf-Umfrageseiten
Lokalisierte Inhalte für mehrsprachige und Mehrwährungs-Stores

Shopify Functions: Backend-Logik ohne Server

Functions sind WebAssembly-basierte Module, die auf Shopifys Infrastruktur laufen und es ermöglichen, Shopifys native serverseitige Logik zu ersetzen oder zu erweitern. Sie gehören zu den leistungsstärksten Teilen des Extensibility-Frameworks für Entwickler mit komplexen Anforderungen.

Was Functions heute leisten können:

Rabattlogik: gestaffelte Rabatte, Bundle-Preise, Kauf-X-Erhalte-Y-Regeln, Mindestbestellwert-Aktionen
Versandanpassungen: Versandoptionen anzeigen, ausblenden, umsortieren oder umbenennen, basierend auf Warenkorbinhalt, Kunden-Tags oder Geografie
Zahlungsanpassung: Zahlungsmethoden bedingt ein- oder ausblenden (z. B. Nachnahme bei digitalen Produkten ausblenden)
Warenkorbvalidierung: Checkout blockieren, wenn bestimmte Bedingungen nicht erfüllt sind (Mindestbestellmengen, eingeschränkte Produktkombinationen)

Functions werden in Sprachen geschrieben, die zu WebAssembly kompilieren, JavaScript/TypeScript ist dabei die gängigste Wahl für Shopify-Entwickler. Sie werden schnell ausgeführt, ohne Cold Starts und ohne eigene Infrastrukturverwaltung.

Web Pixels: Tracking ohne Script-Tags

Einer der größten Schmerzpunkte in der checkout.liquid-Ära war das Conversion-Tracking. Benutzerdefinierte Script-Tags im Additional-Scripts-Feld waren die einzige Option, fehleranfällig, schwer zu debuggen und oft in Konflikt miteinander.

Web Pixels lösen dieses Problem durch eine gesandboxte Umgebung für das Tracking von Kundenereignissen. GA4, Meta, Google Ads und andere Plattformen bieten inzwischen kompatible Pixel-Apps, die dieses Framework nutzen. Für individuelle Tracking-Anforderungen ermöglicht Shopifys Customer-Events-System den Aufbau von Pixel-Extensions, die bei Standard-E-Commerce-Events mit Zugriff auf strukturierte Checkout-Daten feuern.

Was das konkret für Entwickler bedeutet

Die Vorteile:

Update-sicher by Design: der Extension-Code ist vom Checkout-HTML entkoppelt. Wenn Shopify die Plattform aktualisiert, funktionieren Anpassungen weiterhin
Als Apps verteilbar: einmal bauen, für beliebige Händler deployen. Öffentliche Apps können im Shopify App Store gelistet werden; private Apps lassen sich auf bestimmten Stores installieren
Shop-Pay-kompatibel: Extensions funktionieren auf allen Checkout-Oberflächen von Shopify, einschließlich des beschleunigten Shop-Pay-Flows
Über 860 Extensibility-basierte Checkout-Apps existieren bereits im Ökosystem, mit umfangreicher Dokumentation und Community-Tooling

Die Einschränkungen, die man kennen sollte:

Kein beliebiges HTML oder CSS: die Arbeit erfolgt innerhalb von Polaris-Komponenten; Abweichungen von den Branding-Einstellungen des Händlers sind nicht möglich
UI Extensions für Kontaktdaten-, Versand- und Zahlungsschritte sind nur für Shopify Plus verfügbar: auf niedrigeren Plänen sind Anpassungen auf Danke- und Bestellstatusseiten beschränkt
Gesandboxte Umgebung: kein Zugriff auf das Checkout-DOM, keine globalen Web-APIs. Wer bisher auf DOM-Manipulation gesetzt hat, muss den Ansatz grundlegend überdenken
Functions erfordern WebAssembly: JavaScript kompiliert problemlos, aber die Laufzeitumgebung unterscheidet sich von dem, was die meisten Entwickler kennen; lokales Testen erfordert die Shopify CLI

Customer Account Extensions: Was 2025 neu ist

In Shopifys Summer 2025 Edition wurden die Checkout-Extensibility-APIs auf den Kundenkontobereich ausgeweitet. Entwickler können jetzt direkt im Kundenkonto-Dashboard benutzerdefinierte Bereiche, Tabs und Tools einbauen, Treuepunktanzeigen, vergangene Bestelldetails, Abonnementverwaltung, ohne ein externes Portal oder eine separate Storefront zu benötigen.

Das ist eine bedeutende Erweiterung für Agenturen, die Treueprogramme, Abo-Flows und B2B-Self-Service-Portale auf Shopify aufbauen.

Erste Schritte

Der empfohlene Einstieg für Entwickler, die neu mit Checkout Extensibility arbeiten:

Shopify CLI einrichten, sie ist für die gesamte Extension-Entwicklung erforderlich
Die Checkout UI Extensions Dokumentation auf Shopify.dev für die aktuelle API-Version lesen
Den Checkout-Anpassungsbericht im Shopify Admin nutzen, um zu prüfen, welche Legacy-Anpassungen noch migriert werden müssen (admin.shopify.com/store/DEIN-STORE-NAME/settings/checkout/customizations-report)
Mit dem ersten Extension auf der Dankeseite beginnen (Checkout Extensions gehören zu dem, was wir täglich bauen - mehr zur Shopify App Entwicklung), geringere Komplexität, auf allen Plänen verfügbar, ideal um das Extension-Modell zu verstehen, bevor man Plus-exklusive Checkout-Schritte angeht

Fazit: Der alte Weg ist Geschichte, der neue ist besser

Checkout Extensibility ist kein Workaround und kein Kompromiss, es ist eine grundlegend bessere Architektur für Checkout-Anpassungen. Die Einschränkungen, die zunächst limitierend wirken (kein beliebiges CSS, kein DOM-Zugriff), sind genau das, was Extensions update-sicher, performant und sicher macht.

Für Entwickler ist das die Reifung des Shopify-Ökosystems. Das Tooling ist solide, die Dokumentation ist umfassend, und es wächst eine Bibliothek an Patterns und Referenz-Apps. Wer noch checkout.liquid-Code für einen Kunden pflegt, sollte jetzt mit der Planung der Migration beginnen - bei der Umsetzung im Theme hilft unsere Shopify-Entwicklung.

Ein gutes Beispiel für das, was mit Extensions und eigenen Konfiguratoren möglich wird, ist der Bundle Builder, den wir für Simple Pledge gebaut haben.

Sichere dir eine kostenlose Beratung

Kompetente Beratung, zugeschnitten auf dein Shopify-Business.

Noch Fragen?

Lass uns das klären!

Wir haben die häufigsten Fragen samt Antworten gesammelt, damit du unsere Services besser einschätzen kannst.

Noch eine Frage offen?

Lass uns telefonieren und sie klären.

Ja. Wir arbeiten seit 2020 ausschließlich mit Shopify und Shopify Plus, und dorthin sind wir gekommen, indem wir andere Plattformen abgesagt haben. Der Tausch ist bewusst: Ein Team, das jeden Tag dieselbe Plattform sieht, weiß, welches Problem eine native Lösung hat, welches eine App braucht und welches Custom Code - dadurch fließt weniger von deinem Budget in das Wiederfinden dieser Antwort. Und wir folgen Shopifys eigenen Konventionen, statt Muster aus Magento oder WooCommerce zu übertragen. Genau das hält einen Shop nach der Übergabe updatefähig.

Strategie & Beratung, Custom Shopify Theme-Entwicklung, Custom App-Entwicklung, Shop-Migrationen, UX/UI Design, Integrationen & Middleware, laufendes Store Management und AI E-Commerce Readiness. Die meisten Projekte kombinieren drei oder vier davon: An einer Migration hängen meist eine ERP-Integration und ein Redesign, und ein Redesign legt meist ein Performance-Problem frei. Alles läuft über ein Team, dadurch werden eine Design-Entscheidung und ihre Konsequenz in der Entwicklung gemeinsam geklärt statt zwischen zwei Agenturen verhandelt.

Absolut, und es ist einer der häufigsten Einstiege zu uns. Wir auditieren zuerst den bestehenden Shop - Conversion-Pfad, Seiten-Performance und die Templates, die den größten Umsatz tragen - und gestalten dann gegen das, was das Audit gefunden hat, statt gegen ein Moodboard. Produkte, Kunden, Bestellungen und URL-Struktur bleiben, wo sie sind, damit Rankings und Shopdaten nicht in Gefahr geraten. Ein Redesign kann auch gestaffelt live gehen: erst die Seiten, die verkaufen, der Rest danach. So siehst du die Wirkung, bevor das ganze Budget gebunden ist.

Ja, von Grund auf und nicht als umgefärbtes Marketplace-Template. Ein Custom Theme heißt: genau die Sections, die dein Merchandising-Team wirklich braucht, im Theme-Editor pflegbar ohne Entwickler, und kein geerbter Code für Funktionen, die du nie nutzen wirst. Der letzte Punkt ist das Performance-Argument: Themes von der Stange tragen die Summe aller Use Cases mit sich, für die sie verkauft wurden, und du bezahlst das bei jedem Seitenaufruf in den Core Web Vitals. Wir bauen gegen deinen Katalog und dein Content-Modell und übergeben Dokumentation, damit dein Team den Shop selbst betreiben kann.

Ja - WooCommerce, Magento, Shopware und andere Plattformen, in einem gestaffelten Prozess mit minimalem Risiko. Produkte, Varianten, Kunden und Bestellhistorie kommen mit, und jede indexierte URL bekommt einen gemappten 301, damit die Rankings, die du dir erarbeitet hast, den Umzug überleben. Über die Dauer entscheidet selten die Katalogröße: Es sind Datenstrukturen ohne direktes Shopify-Gegenstück (Bundles, konfigurierbare Produkte, kundenspezifische Preise) und die Systeme, mit denen dein Shop spricht. Beides inventarisieren wir, bevor ein Cutover-Datum steht. Deshalb enden unsere Migrationen nicht mit einer Redirect-Liste, die in der Nacht vor dem Launch entsteht.

Das hängt vom Umfang ab: Fokussierte Optimierungen dauern oft 4-6 Wochen, komplette Custom Builds oder Migrationen typischerweise 8-16 Wochen. Ein Shop auf konfigurierter Theme-Basis ist meist in 4-8 Wochen live, eine vollständig individuelle Storefront eher in 10-16. Vor dem Start bekommst du eine Timeline mit definierten Meilensteinen, und diese Meilensteine sind gestaffelte Releases statt eines einzigen Launch-Termins am Ende - eine Verzögerung an einer Stelle schiebt also nicht alles Übrige nach hinten. Am stärksten bewegen späte Scope-Erweiterungen und Integrationen, die zu Beginn niemand inventarisiert hat.

Immer. Wir designen Mobile-First, weil dort der Großteil des E-Commerce-Traffics liegt und der größte Teil der Conversion verloren geht. Jeder Shop wird auf echten Geräten getestet, nicht nur im verkleinerten Browserfenster, und vor dem Livegang gegen die Core Web Vitals gemessen - Largest Contentful Paint, Interaktionslatenz, Layout Shift. Die meiste Aufmerksamkeit bekommen Bildhandling, Font-Loading und Drittanbieter-Skripte, denn meist sind es Apps, die aus einem schnellen Theme einen langsamen Shop machen. Performance ist hier eine Launch-Bedingung und kein Ticket für danach.

Ja. Unsere Store-Management-Pläne decken Shopify- und App-Updates, iterative Verbesserungen, Testing und technischen Support ab, in einem monatlichen Umfang, den du anpassen kannst, wenn sich Prioritäten verschieben. Die meisten Shops brauchen die ersten Wochen nach dem Launch stärker als erwartet: Echter Traffic findet Sonderfälle, die Staging nie erzeugt hat, und die Analytics fangen erst mit Volumen an, die Wahrheit zu sagen. Danach besteht die laufende Arbeit meist aus Conversion-Iterationen auf den umsatztragenden Templates, Support für saisonale Kampagnen und dem Aktuellhalten des Themes, wenn Shopify Plattformänderungen ausliefert.

Auf jeden Fall, und wir sagen es dir auch, wenn ein Rebuild nicht die richtige Entscheidung ist. Wir arbeiten oft in fokussierten Iterationen - ein Conversion-Audit, Performance-Optimierung oder das Redesign der wenigen Templates, die den Großteil des Umsatzes tragen - ausgeliefert als gestaffelte Releases mit messbaren Ergebnissen statt als Big-Bang-Relaunch. Für einen Shop, der bereits konvertiert, ist das meist die bessere Rechnung: Du behältst, was funktioniert, investierst dort, wohin die Daten zeigen, und vermeidest das Risikofenster, das ein kompletter Replatform öffnet. Ein Rebuild lohnt sich, wenn das darunterliegende Theme oder Datenmodell die eigentliche Grenze ist.

Buche einen kostenlosen Strategie-Call - rund dreißig Minuten, und was dabei herauskommt, behältst du in jedem Fall. Wir fragen, was du heute betreibst: Plattform, Katalogstruktur, angebundene Systeme, und was nach dem Projekt besser sein soll. Daraus bekommst du ein schriftliches Angebot mit Umfang, Timeline und Preis, mit benannten Arbeitsblöcken statt einer einzigen Zahl. Wenn das Gespräch zeigt, dass du weniger brauchst als ein Agenturprojekt, sagen wir dir das auch. Das ist für beide Seiten das günstigere Gespräch, als es im zweiten Monat zu merken.

Mehr Fragen lesen

Shopify Checkout Extensibility: Guide für Entwickler

Was ist Checkout Extensibility?

Warum Shopify checkout.liquid abgekündigt hat