Pendant une décennie, « checkout.liquid » a été l’outil puissant ultime pour les développeurs Shopify Plus. Cela nous a donné un accès HTML/JS brut à la caisse. Nous en avons abusé. Nous avons procédé au « DOM Scraping » pour masquer les tarifs d’expédition. Nous avons utilisé les boucles setInterval pour pirater des cadeaux gratuits. Nous avons injecté 50 pixels de suivi différents qui ont ralenti le chargement de la page à 8 secondes. C’était flexible, mais c’était fragile et non sécurisé.

Shopify l’a rendu obsolète. Le remplacement est Extensibilité de paiement. Il ne s’agit pas simplement d’une mise à niveau ; c’est un changement de paradigme. Nous passons des « Client-Side Hacks » aux « Server-Side Functions ». Nous passons de « jQuery » à « Rust & React ».

Chez Maison Code Paris, nous avons migré plus de 50 marchands Plus vers Extensibility. Voici le guide d’ingénierie.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

1. L’architecture : la puissance en bac à sable

Pourquoi Shopify a-t-il fait cela ?

Sécurité : les scripts dans « checkout.liquid » pourraient techniquement voler des numéros de carte de crédit. Les extensions sont en bac à sable.
Performance : les extensions s’exécutent dans un Web Worker ou sur le serveur (WASM). Le fil principal reste libre.
Mise à niveau de la sécurité : comme vous ne pouvez pas toucher au DOM, Shopify peut repenser entièrement la caisse (par exemple, One Page Checkout) et votre extension « fonctionnera » simplement.

Il y a deux composants principaux :

Extensions UI : rendu des pixels sur l’écran (type React).
Fonctions : Business Logic sur le serveur (Rust/WASM).

2. Composants de l’interface utilisateur : le modèle de “rendu à distance”

Vous écrivez du code qui ressemble à React, mais il n’est pas rendu directement dans le DOM. Il envoie une arborescence JSON à Shopify, qui restitue les composants natifs. C’est pourquoi vous ne pouvez pas utiliser <div> ou classname. Vous devez utiliser les primitives de Shopify.

// extensions/message-cadeau/Checkout.jsx
importer {
  réagirExtension,
  Champ de texte,
  BlockStack,
  Texte,
  useApplyAttributeChange
} depuis '@shopify/ui-extensions-react/checkout' ;

exporter la réactionExtension par défaut('purchase.checkout.block.render', () => <GiftMessage />);

fonction CadeauMessage() {
  const applyChange = useApplyAttributeChange();

  const handleInput = (valeur) => {
    appliquerChange({
      tapez : 'updateAttribute',
      clé : '_gift_note',
      valeur : valeur
    });
  } ;

  retour (
    <Espacement BlockStack="tight">
      <Text size="medium"weight="bold">Est-ce un cadeau ?</Text>
      <TextField label="Note cadeau" multiligne onChange={handleInput} />
    </BlockStack>
  );
}

Contrainte clé : vous ne pouvez pas accéder à « fenêtre » ou « document ». Si vous avez besoin de récupérer des données, vous devez utiliser le hook « useQuery » fourni par le bac à sable, ou effectuer des appels « fetch » vers votre propre proxy.

3. Fonctions Shopify : logique à la périphérie (rouille)

C’est la partie la plus puissante. Auparavant, pour effectuer des « remises échelonnées » (achetez-en 5 et obtenez 20 % de réduction), vous utilisiez Shopify Scripts (Ruby). Les scripts étaient bogués, difficiles à tester et avaient des limites strictes en matière de CPU. Les fonctions Shopify sont compilées sur WebAssembly (Wasm). Ils s’exécutent en <5 ms.

Nous les écrivons en Rust car c’est le langage le plus performant pour Wasm.

Étude de cas : remise sur volume

// src/run.rs
utilisez shopify_function::prelude::* ;
utilisez shopify_function :: Résultat ;

#[shopify_function]
fn run(input: input::ResponseData) -> Result<output::FunctionResult> {
    laissez mut réductions = vec![];

    pour la ligne dans input.cart.lines {
        soit quantité = ligne.quantité ;
        
        // Définir la logique
        soit pourcentage = si quantité >= 50 {
            25,0 // Vente en gros
        } sinon si quantité >= 10 {
            10.0 // En vrac
        } autre {
            0,0
        } ;

        si pourcentage > 0,0 {
            réductions.push(Remise {
                valeur : DiscountValue : Pourcentage (pourcentage),
                message : format ! ("Remise sur volume ({}%)", pourcentage),
                cibles : vec ![Target::ProductVariant(line.merchandise.id)],
            });
        }
    }

    Ok (sortie :: FunctionResult {
        des réductions,
        discount_application_strategy : DiscountApplicationStrategy : Maximum,
    })
}

Ce binaire est téléchargé sur Shopify. Il évolue à l’infini.

4. Validation : bloquer les mauvaises commandes

Autrefois, pour empêcher les P.O. Expédition en boîte, nous avons utilisé la validation JS. Les utilisateurs avertis (ou robots) ont désactivé JS et ont quand même commandé. Maintenant, nous utilisons les Fonctions de validation de panier. Cela s’exécute sur le backend avant que le paiement puisse avoir lieu.

# Requête d'entrée
requête Entrée {
  panier {
    groupes de livraison {
      adressedelivraison{
        adresse1
        ville
        codepays
      }
    }
  }
}

Si la fonction rust renvoie une erreur, le bouton “Payer maintenant” est désactivé au niveau de l’API. Il est impossible de contourner.

5. Pixels Web : le correctif de suivi

Les équipes marketing détestent la migration car « Nous allons perdre notre suivi GTM ! » En fait, Extensibility corrige le suivi. L’API Web Pixels s’abonne aux événements de paiement (checkout_completed, payment_info_submit) dans un bac à sable sécurisé. Parce qu’il utilise l’API Browser Beacon, il est étonnamment résistant aux bloqueurs de publicités. Nous constatons une augmentation de 15 % des conversions suivies après la migration vers Web Pixels.

// analytique.js
Analytics.subscribe('checkout_completed', (événement) => {
  const total = event.data.checkout.totalPrice.amount ;
  // Envoyer à GA4
  gtag('événement', 'achat', { valeur : total });
});

6. Paiement sans tête vs extensibilité

Pendant des années, le « Headless Checkout » était le seul moyen d’obtenir une personnalisation. Mais c’était dangereux. Vous êtes devenu responsable de la conformité PCI. L’extensibilité du paiement élimine le besoin du paiement sans tête. Vous bénéficiez de 90 % de flexibilité (Champs personnalisés, Ventes incitatives, Logique) avec 0 % de maintenance. Sauf si vous êtes Nike ou Apple, vous n’avez pas besoin d’une version de paiement personnalisée. S’en tenir à la plate-forme (Shopify) garantit que vous obtenez instantanément les mises à jour Apple Pay, PayPal et Shop Pay.

7. Marchés mondiaux : paiement localisé

Vendre en France vs USA ?

USA : nécessite une liste déroulante “État”.
France : nécessite la gestion “Cedex”.
Japon : nécessite une “Préfecture”. Avec l’extensibilité, nous utilisons l’API de localisation. Nos extensions affichent différents champs basés sur « context.market ». Nous pouvons afficher une instruction « Leave at Door » pour les commandes américaines, mais la masquer pour les commandes allemandes (où cela peut être illégal/rare). Il s’agit d’un rendu dynamique à la limite.

8. API de branding : plus de CSS

Vous ne pouvez plus modifier « checkout.css » ou « checkout.scss ». Vous utilisez l’Branding API (GraphQL). Vous définissez :

Couleurs primaires.
Rayons de coin (arrondi ou carré).
Polices (télécharger WOFF2).
Dispositions d’en-tête/pied de page.

Le “Point de vue du sceptique” : “Mais je ne peux pas déplacer le bouton de 5 px vers la gauche !” Contre-point : Bien. Vous ne devriez pas. Chaque fois que vous piratez la mise en page, vous interrompez l’accessibilité. Shopify a dépensé des millions pour tester la mise en page optimale. Faites confiance à la plateforme. Concentrez-vous sur le Contenu et la Logique, pas sur le remplissage.

7. Extensions post-achat : le moment d’or

Le paiement n’est pas terminé lorsqu’ils paient. La Page de remerciement est l’immobilier le plus converti en commerce électronique. Taux d’ouverture : 100 %. Attention : 100 %. Grâce à l’extensibilité, nous pouvons injecter ici une « vente incitative en un clic ». “Vous avez acheté les baskets. Voulez-vous le nettoyant pour 10 € ? (Aucun frais de port).” Parce que nous avons le order_id et le payment_token, nous pouvons traiter cette transaction sans ressaisir le CVV. Cette fonctionnalité paie à elle seule la totalité du coût de la migration en 1 mois.

8. Tests : l’environnement Sandbox

Autrefois « liquide », nous effectuions des tests en production. Terrifiant. Nous disposons désormais du Partner Dashboard Sandbox. Vous pouvez simuler :

Réseau lent (3G).
Erreurs API (échec d’inventaire).
Différents marchés (USD vs EUR). Nous écrivons des Tests unitaires pour nos fonctions Rust. Le « test de fret » s’exécute en 10 ms. Nous prouvons que « Achetez-en 5, obtenez 10 % de réduction » fonctionne mathématiquement avant de le déployer dans un magasin traitant 1 million de dollars/jour.

9. Conclusion

L’extensibilité de la caisse est un filtre. Il filtre les “Hackers” et retient les “Ingénieurs”. Cela vous oblige à écrire du code propre, modulaire et testable. Le résultat est une expérience de paiement plus rapide, plus sûre et prête pour les 10 prochaines années de commerce électronique.

Panique à propos de la date limite ?

La date de dépréciation de « checkout.liquid » approche.

Réservez votre audit de migration. Découvrez les Tarifs B2B et le Clean Code.

La migration d’un magasin complexe prend 4 à 8 semaines.

Audit : exportez checkout.liquid et mappez chaque bloc <script>.
- Google Ads -> Pixels Web.
- Logique d’expédition -> Fonctions de livraison.

Curseur de vente incitative -> Extension d’interface utilisateur.

Donner la priorité : “Must Haves” vs “Legacy Junk”. Habituellement, 30 % des scripts sont du code mort.
Développer : créez des extensions localement à l’aide de « shopify app dev ».
Test A/B : vous pouvez publier la nouvelle commande au statut « Brouillon » et la prévisualiser.
Go Live : activez le drapeau dans les paramètres de paiement.

8. Conclusion

Panique à propos de la date limite ?

La date de dépréciation de « checkout.liquid » approche.

Réservez votre audit de migration. Engagez nos Architectes.

Pourquoi Maison Code en parle

1. L’architecture : la puissance en bac à sable

2. Composants de l’interface utilisateur : le modèle de “rendu à distance”

3. Fonctions Shopify : logique à la périphérie (rouille)

Étude de cas : remise sur volume

4. Validation : bloquer les mauvaises commandes

5. Pixels Web : le correctif de suivi

6. Paiement sans tête vs extensibilité

7. Marchés mondiaux : paiement localisé

8. API de branding : plus de CSS

7. Extensions post-achat : le moment d’or

8. Tests : l’environnement Sandbox

9. Conclusion

Panique à propos de la date limite ?

8. Conclusion

Panique à propos de la date limite ?

Confidentialité