Per un decennio, “checkout.liquid” è stato lo strumento di potenza definitivo per gli sviluppatori Shopify Plus. Ci ha fornito l’accesso HTML/JS grezzo alla cassa. Ne abbiamo abusato. Ci siamo impegnati in “DOM Scraping” per nascondere le tariffe di spedizione. Abbiamo utilizzato i cicli “setInterval” per hackerare i regali gratuiti. Abbiamo inserito 50 diversi pixel di tracciamento che hanno rallentato il caricamento della pagina a 8 secondi. Era flessibile, ma era fragile e insicuro.

Shopify lo ha deprecato. La sostituzione è Estensibilità Checkout. Questo non è solo un aggiornamento; è un cambiamento di paradigma. Stiamo passando dagli “hack lato client” alle “funzioni lato server”. Stiamo passando da “jQuery” a “Rust & React”.

Presso Maison Code Paris, abbiamo migrato oltre 50 commercianti su Extensibility. Ecco la guida tecnica.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

1. L’architettura: potenza sandbox

Perché Shopify ha fatto questo?

Sicurezza: gli script in checkout.liquid potrebbero tecnicamente rubare numeri di carta di credito. Le estensioni sono sandbox.
Prestazioni: le estensioni vengono eseguite in un Web Worker o sul Server (WASM). Il thread principale rimane libero.
Sicurezza dell’aggiornamento: poiché non puoi toccare il DOM, Shopify può riprogettare completamente il checkout (ad esempio, One Page Checkout) e la tua estensione semplicemente “funzionerà”.

Ci sono due componenti principali:

Estensioni UI: rendering dei pixel sullo schermo (simile a React).
Funzioni: Logica aziendale sul server (Rust/WASM).

2. Componenti dell’interfaccia utente: il modello di “rendering remoto”.

Scrivi codice che assomiglia a React, ma non viene visualizzato direttamente nel DOM. Invia un albero JSON a Shopify, che esegue il rendering dei componenti nativi. Questo è il motivo per cui non puoi utilizzare <div> o classname. Devi utilizzare le primitive di Shopify.

“tsx // estensioni/messaggio-regalo/Checkout.jsx importare { reactExtension, Campo di testo, BlockStack, testo, utilizzareApplyAttributeChange } da ‘@shopify/ui-extensions-react/checkout’;

esporta default reactExtension(‘purchase.checkout.block.render’, () => );

funzione Messaggio Regalo() { const applyChange = useApplyAttributeChange();

const handleInput = (valore) => { applicaCambia({ tipo: ‘attributoaggiornamento’, chiave: ‘_nota_regalo’, valore: valore }); };

ritorno ( <Text size=“medium”weight=“bold”>È un regalo? ); }


**Vincolo chiave**: non è possibile accedere a "finestra" o "documento".
Se hai bisogno di recuperare dati, devi utilizzare l'hook "useQuery" fornito dalla sandbox o effettuare chiamate "fetch" al tuo proxy.

## 3. Funzioni Shopify: logica al limite (Rust)

Questa è la parte più potente.
In precedenza, per eseguire gli "sconti a scaglioni" (acquistandone 5 ottieni uno sconto del 20%), utilizzavi **Shopify Scripts (Ruby)**.
Gli script erano pieni di bug, difficili da testare e avevano limiti rigidi della CPU.
**Le funzioni di Shopify** sono compilate in WebAssembly (Wasm).
Vengono eseguiti in **<5ms**.

Li scriviamo in **Rust** perché è il linguaggio più performante per Wasm.

### Caso di studio: sconto sulla quantità

"ruggine".
// src/esegui.rs
usa shopify_function::prelude::*;
usa shopify_function::Risultato;

#[shopify_funzione]
fn run(input: input::ResponseData) -> Risultato<output::FunctionResult> {
    let mut sconti = vec![];

    per la riga in input.cart.lines {
        let quantità = riga.quantità;
        
        // Definisce la logica
        let percentuale = se quantità >= 50 {
            25,0 // Commercio all'ingrosso
        } altrimenti se quantità >= 10 {
            10.0 // In blocco
        } altrimenti {
            0,0
        };

        se percentuale > 0,0 {
            discounts.push(Sconto {
                valore: ValoreSconto::Percentuale(percentuale),
                messaggio: format!("Sconto volume ({}%)", percentuale),
                obiettivi: vec![Obiettivo::ProductVariant(line.merchandise.id)],
            });
        }
    }

    Ok(output::FunzioneRisultato {
        sconti,
        discount_application_strategy: DiscountApplicationStrategy::Massimo,
    })
}

Questo binario viene caricato su Shopify. È scalabile all’infinito.

4. Convalida: blocco degli ordini errati

Ai vecchi tempi, per evitare che P.O. Spedizione in scatola, abbiamo utilizzato la convalida JS. Gli utenti esperti (o bot) hanno disabilitato JS e hanno ordinato comunque. Ora utilizziamo le Funzioni di convalida del carrello. Questo viene eseguito sul backend prima che il checkout possa procedere.

# Domanda di input
interrogazione Ingresso {
  carrello {
    gruppi di consegna {
      indirizzo di consegna {
        indirizzo1
        città
        countryCodice
      }
    }
  }
}

Se la funzione ruggine restituisce un errore, il pulsante “Paga adesso” è disabilitato a livello API. È impossibile aggirarlo.

5. Pixel web: la soluzione al tracciamento

I team di marketing odiano la migrazione perché “perderemo il monitoraggio GTM!” In realtà, Extensibility corregge il tracciamento. L’API Web Pixel si iscrive agli eventi di pagamento (checkout_completed, payment_info_submission) in un sandbox sicuro. Poiché utilizza l’API Browser Beacon, è sorprendentemente resistente agli annunci bloccanti. Notiamo un aumento del 15% nelle conversioni monitorate dopo la migrazione ai Web Pixel.

// analitica.js
analytics.subscribe('checkout_completato', (evento) => {
  const totale = event.data.checkout.totalPrice.amount;
  // Invia a GA4
  gtag('evento', 'acquisto', { valore: totale });
});

6. Checkout headless vs estensibilità

Per anni, “Headless Checkout” è stato l’unico modo per ottenere la personalizzazione. Ma era pericoloso. Sei diventato responsabile della conformità PCI. L’estensibilità di Checkout elimina la necessità di Headless Checkout. Ottieni il 90% della flessibilità (campi personalizzati, upsell, logica) con lo 0% di manutenzione. A meno che tu non sia Nike o Apple, non hai bisogno di una build di cassa personalizzata. Attenersi alla piattaforma (Shopify) garantisce di ricevere immediatamente gli aggiornamenti di Apple Pay, PayPal e Shop Pay.

7. Mercati globali: pagamento localizzato

Vendere in Francia o negli Stati Uniti?

USA: è necessario il menu a discesa “Stato”.
Francia: necessita della gestione “Cedex”.
Giappone: necessita della “Prefettura”. Con Extensibility utilizziamo l’API di localizzazione. Le nostre estensioni riproducono campi diversi in base al “contesto.mercato”. Possiamo mostrare l’istruzione “Leave at Door” per gli ordini statunitensi, ma nasconderla per gli ordini tedeschi (dove potrebbe essere illegale/non comune). Questo è il rendering dinamico ai bordi.

8. API di branding: niente più CSS

Non puoi più modificare “checkout.css” o “checkout.scss”. Utilizzi l’API di branding (GraphQL). Tu definisci:

Colori primari.
Raggi degli angoli (arrotondati vs quadrati).
Caratteri (Carica WOFF2).
Layout di intestazione/piè di pagina.

Il “punto di vista dello scettico”: “Ma non riesco a spostare il pulsante di 5px a sinistra!” Contropunto: Buono. Non dovresti. Ogni volta che modifichi il layout, interrompi l’accessibilità. Shopify ha speso milioni per testare il layout ottimale. Fidati della piattaforma. Concentrati sul Contenuto e sulla Logica, non sul riempimento.

7. Estensioni post-acquisto: il momento d’oro

La cassa non finisce quando pagano. La Pagina di ringraziamento è il settore immobiliare con il più alto tasso di conversione nell’e-commerce. Tasso di apertura: 100%. Attenzione: 100%. Con Extensibility, possiamo inserire qui un “Upsell con un clic”. “Hai comprato le scarpe da ginnastica. Vuoi il detergente per € 10? (Nessun costo di spedizione).” Poiché disponiamo di order_id e payment_token, possiamo elaborare questa transazione senza reinserire CVV. Questa funzionalità da sola paga l’intero costo di migrazione in 1 mese.

8. Test: l’ambiente sandbox

Ai vecchi tempi del “liquido”, testavamo in produzione. Terrificante. Ora disponiamo della Sandbox Partner Dashboard. Puoi simulare:

Rete lenta (3G).
Errori API (errore di inventario).
Mercati diversi (USD vs EUR). Scriviamo Unit Test per le nostre funzioni Rust. Il “test del carico” viene eseguito in 10 ms. Dimostriamo che “Acquista 5 e ottieni uno sconto del 10%” funziona matematicamente prima di implementarlo in un negozio che elabora 1 milione di dollari al giorno.

9. Conclusione

L’estensibilità di Checkout è un filtro. Filtra gli “hacker” e mantiene gli “ingegneri”. Ti costringe a scrivere codice pulito, modulare e testabile. Il risultato è un’esperienza di pagamento più veloce, più sicura e pronta per i prossimi 10 anni di e-commerce.

Panico per la scadenza?

La data di ritiro di “checkout.liquid” si avvicina.

Prenota il tuo audit di migrazione. Leggi informazioni sui Prezzi B2B e sul Clean Code.

La migrazione di un negozio complesso richiede 4-8 settimane.

Audit: esporta checkout.liquid e mappa ogni blocco <script>.
- Annunci Google -> Pixel web.
- Logica di spedizione -> Funzioni di consegna.

Slider Upsell -> Estensione dell’interfaccia utente.

Dai priorità: “Must Haves” vs “Legacy Junk”. Di solito il 30% degli script sono codici morti.
Sviluppo: crea estensioni localmente utilizzando “shopify app dev”.
Test A/B: puoi pubblicare il nuovo checkout con lo stato “Bozza” e visualizzarne l’anteprima.
Go Live: cambia il flag nelle Impostazioni di pagamento.

8. Conclusione

Panico per la scadenza?

La data di ritiro di “checkout.liquid” si avvicina.

Prenota il tuo audit di migrazione. Assumi i nostri architetti.

Perché Maison Code ne parla

1. L’architettura: potenza sandbox

2. Componenti dell’interfaccia utente: il modello di “rendering remoto”.

4. Convalida: blocco degli ordini errati

5. Pixel web: la soluzione al tracciamento

6. Checkout headless vs estensibilità

7. Mercati globali: pagamento localizzato

8. API di branding: niente più CSS

7. Estensioni post-acquisto: il momento d’oro

8. Test: l’ambiente sandbox

9. Conclusione

Panico per la scadenza?

8. Conclusione

Panico per la scadenza?

Privacy