Vad Checkout Extensibility ersatte och varför
Shopify tog bort stödet för checkout.liquid för alla Shopify Plus-handlare i augusti 2024. Den gamla modellen lät byråer modifiera checkoutens HTML, CSS och Liquid-logik direkt. Den var flexibel men skapade problem: trasiga uppgraderingar när Shopify pushade plattformsändringar, inkonsekvent mobilbeteende, PCI-compliance-risk och långsam prestanda från ackumulerad custom-kod.
Checkout Extensibility är ersättaren. Det är ett begränsat, väldefinierat API för att anpassa checkout via tre mekanismer: Shopify Functions (server-side-logik), UI Extensions (visuell anpassning vid specifika extension points) och Web Pixels (analytics). Varje har sitt syfte, sitt scope och sina gränser. Avvägningen är explicit: ni förlorar den gamla "modifiera allt"-flexibiliteten men får en checkout som uppgraderas automatiskt, fungerar på alla enheter och förblir PCI-compliant.
För de flesta nordiska handlare är avvägningen värd det. För handlare med djupt anpassad checkout-logik krävde migreringen verkligt arbete.
Shopify Functions, server-side-logik
Functions är där affärslogiken bor. De är små server-side-program skrivna i Rust, JavaScript eller annat WASM-mål-språk. De körs vid specifika punkter i orderlivscykeln och returnerar strukturerad data som Shopify agerar på.
De huvudsakliga Function-typer som är relevanta för checkout:
Discount Functions. Ersätter de gamla Scripts. Hanterar anpassad rabattlogik som trappad prissättning, B2B-kundspecifika rabatter, bundlerabatter och tidsbaserade kampanjer. Input är varukorg och kunddata. Output är en rabattstruktur som Shopify applicerar.
Payment Customisation Functions. Dölj, visa, ordna om eller namnge om betalmetoder baserat på varukorgsinnehåll, kund eller orderattribut. Vanliga användningar: visa Klarna bara över vissa varukorgsvärden, dölja B2B-fakturabetalning för konsumentkonton, visa Swish bara för svenska kunder.
Delivery Customisation Functions. Samma mekanism för fraktmetoder. Dölj hemleverans för specifika postnummer, namnge om fraktalternativ baserat på varukorgsinnehåll, ordna om leveransalternativ för specifika kundgrupper.
Cart Transform Functions. Modifiera varukorgsinnehåll i checkout. Används för bundles som expanderar till komponentprodukter, konfigurerbara produkter med beräknad prissättning eller varukorgs-nivå-ändringar som inte kan uttryckas som rabatter.
Functions är snabba (sub-100ms-mål), komponerbara (ni kan köra flera), och versionsstyrda. De ersätter mycket av det som användes att bo i checkout.liquid eller Scripts, på ett strukturerat sätt.
UI Extensions, visuell anpassning
UI Extensions låter er lägga till eller modifiera UI-element vid fördefinierade extension points i checkoutflödet. Extension points inkluderar checkout-headern, varukorgssammanfattningen, leveransadressblocket, betalningssektionen och orderbekräftelsesidan.
Vad UI Extensions kan göra:
- Lägga till anpassade formulärfält (orgnr, leveransinstruktioner, presentmeddelande)
- Lägga till anpassade innehållsblock (trust-badges, kampanjbanners, informationsblock)
- Lägga till bekräftelse- eller varningsmeddelanden baserat på varukorgstillstånd
- Lägga till post-purchase-merförsäljning eller korsförsäljning
Vad UI Extensions inte kan göra:
- Flytta eller ta bort kärn-checkout-element
- Style om checkouten bortom de tillgängliga theming-kontrollerna
- Avbryta kärn-betalflödet
- Modifiera HTML-strukturen i checkout direkt
Extension points är fixerade. Om Shopify inte har definierat en extension point där ni vill anpassa kan ni inte anpassa där. Det är avvägningen för uppgraderingssäkerhet.
Web Pixels, analytics och spårning
Web Pixels ersätter de gamla custom-skripten som injicerades i checkout för analytics. De körs i en sandboxad miljö med åtkomst till en standardiserad event-ström (page views, cart updates, purchase completions, payment events).
Vanliga användningar: Google Analytics 4, Klaviyo, Meta Pixel, TikTok Pixel, anpassad server-side-spårning. Sandboxen hindrar pixels från att störa checkoutupplevelsen eller nå kunddata utanför sitt permission-scope.
För de flesta handlare är Web Pixel-uppsättningen rakt på sak via Customer Events-sektionen i Shopify admin. För komplexa multi-pixel-uppsättningar med anpassad event-mappning behövs en liten mängd ytterligare konfiguration.
Nordiska handlares edge cases
Nordiska handlare behöver ofta anpassning som tänjer på extension-modellens gränser. Vanliga scenarier och hur de fungerar:
Orgnr-validering för B2B. Svensk orgnr, norsk orgnr, dansk CVR, finsk Y-tunnus. En UI Extension kan lägga till fältet och validera format client-side. En Function kan validera mot extern registerdata efter submission. Fungerar rent i extension-modellen.
Affärssystemsdriven kundspecifik prissättning. B2B-kunder behöver se sina förhandlade priser i checkout. Prissättningen behöver komma från affärssystemet via integrationslagret. En Discount Function tar emot kundkontexten och applicerar rätt prisnivå. Se vår Shopify affärssystemsintegrationsguide för hur affärssystem-sidan kopplar.
Swish-integration med villkorad visning. Swish ska visas för svenska kunder. En Payment Customisation Function döljer Swish för icke-SE-marknader. Fungerar rent. Se vår Shopify Markets-guide för multi-market-betalningsvisningslogik.
Klarna-specifika checkout-overrides. Klarna har specifika flöden för faktura, delbetalning och direktbetalning som skiljer sig mellan marknader. Shopifys Klarna-integration hanterar huvudflödena. Marknadsspecifik betalningsvisning hanteras av Payment Customisation Functions. Anpassad Klarna-specifik UI är mer begränsad och kräver ibland Klarna Checkout-komponenten snarare än Shopifys native checkout.
Anpassade B2B-godkännandeflöden. B2B-ordrar som kräver chefsgodkännande före betalcapture. Checkouten själv placerar ordern; godkännandeflödet körs efter via anpassad app-logik kopplad via Admin API. Checkouten kan inte pausas mitt i flödet, vilket är en arkitektonisk begränsning att arbeta runt snarare än igenom.
Fakturabetalning med kreditprövning. Faktura för B2B med automatisk kreditprövning. Payment Customisation Function kan visa faktura bara för kunder med godkänd kredit (customer metafield fylld från affärssystemet). Själva kreditprövningen sker utanför checkout, antingen vid kundregistrering eller via schemalagda jobb från affärssystemet.
Ålderskontroll för begränsade produkter. UI Extension lägger till verifieringsfältet och blockerar submission utan bekräftelse. Server-side-validering via en Function för audit-trail.
Det som den gamla anpassningsmodellen inte kan byggas om i
Vissa anpassningar från checkout.liquid-eran har inga rena motsvarigheter i Checkout Extensibility:
Djupa visuella överhalningar. Om er föregående checkout var en visuellt distinkt upplevelse som avvek från Shopifys default ger den nya modellen er theming men inte layoutfrihet. Närmaste motsvarighet är headless checkout, vilket är ett annat arkitektoniskt beslut. Se vår Shopify headless-guide för när det passar.
Anpassade stegflöden. Den gamla modellen lät er lägga till anpassad pre-checkout- eller inter-steg-logik som avbröt det normala flödet. Den nya modellen har fixerade checkout-steg. Logik som behöver köras mellan steg sker via Functions (som inte pausar flödet) eller via extension-UI (som körs vid sidan av flödet).
Server-side-varukorgsmanipulation via Liquid. Det gamla mönstret att skriva om varukorgsinnehåll via Liquid-logik ersätts av Cart Transform Functions. Förmågan är liknande men den mentala modellen är annorlunda.
Migrering från checkout.liquid, praktisk approach
Om ni fortfarande är på checkout.liquid (vilket inte ska vara fallet för Shopify Plus-handlare per augusti 2024) är migreringsapproachen:
Inventera nuvarande anpassningar. Lista alla icke-default-beteenden i nuvarande checkout. Kategorisera varje som: extension-kompatibel, behöver omarbetning eller inte längre behövs.
Mappa till extension-typer. För varje extension-kompatibel anpassning, identifiera om den hör hemma som Function, UI Extension eller Web Pixel. Vissa anpassningar behöver kombinationer.
Bygg om i extension-modellen. Börja med Payment Customisation Functions (vanligen enklast), sedan Discount Functions, sedan UI Extensions. Använd Shopifys CLI och development store för iteration.
Testa över enheter. Den nya modellen beter sig konsekvent på mobil och desktop, vilket är en förbättring. Men all anpassad logik behöver fortfarande enhetstestning.
Fasad cutover. Kör den nya checkouten på en delmängd trafik först. Bevaka konvertering, felprocent och supportfrågor. Full cutover när den nya uppsättningen är stabil.
Tidplan och kostnad
Att bygga Checkout Extensibility-anpassningar på ett nytt Shopify Plus-projekt lägger typiskt till 2 till 4 veckor och 80 000 till 250 000 kr på projektet, beroende på hur många Functions och UI Extensions som behövs. Att migrera en befintlig checkout.liquid-anpassning till extension-modellen hamnar på 150 000 till 500 000 kr beroende på komplexiteten i den ursprungliga anpassningen. För djupa B2B-flöden med affärssystemsdriven prissättning, betalningsanpassning och B2B-godkännandelogik är budgetar från 300 000 kr och uppåt realistiska.
Kontakta oss för en scoping-diskussion om era specifika checkout-anpassningsbehov.
