Le guide complet pour l'implémentation de Hyvä Checkout

Hyvä Checkout est la pièce à retour sur investissement le plus élevé de la gamme de produits Hyvä. Le taux de finalisation des paiements sur mobile augmente de 8 à 15 % dans les constructions que nous avons mesurées. La charge utile JavaScript au moment du paiement diminue d'environ 70 %. Le gain visuel et UX est évident pour quiconque a utilisé le processus de paiement par défaut de Magento sur un Android de milieu de gamme.

Mais l'implémentation est plus nuancée que ce que le marketing laisse entendre. Voici le guide complet, ce qui est impliqué, ce qui peut vous poser problème, et le calendrier réaliste.

Ce qu'est réellement Hyvä Checkout

Un processus de paiement sur une page avec Alpine.js qui remplace le processus de paiement multi-étapes par défaut de Magento basé sur Knockout + RequireJS. Le backend PHP (tarifs d'expédition, traitement des paiements, calcul des taxes, passation de commandes) ne change pas. Seule la couche de rendu est modifiée.

Installable de deux manières :

• Sur le thème Hyvä, le plus courant ; la vitrine est déjà Hyvä, le processus de paiement suit.
• En tant qu'île de paiement uniquement sur Luma, le reste du site reste sur Luma, seule la page de paiement est rendue par Hyvä.

Les deux fonctionnent. La première est plus simple car le système de style est déjà en place.

Pré-vol : ce dont vous avez besoin avant la semaine 1

1. Licence Hyvä Checkout, facturée directement par Hyvä Themes, environ 1 000 à 3 000 £ par domaine.
2. Inventaire actuel des modules de paiement + expédition + fraude, fournisseur + version + statut de licence pour chacun.
3. Liste de tous les champs de paiement personnalisés, message cadeau, instructions de livraison, capture du numéro de TVA, champs B2B.
4. Une base de commande de test, enregistrez le taux de finalisation mobile actuel maintenant, afin que vous puissiez mesurer l'augmentation après le lancement.

Le pré-vol est un exercice de 3 à 5 jours. À faire avant le lancement afin que la semaine 1 soit consacrée à la construction, pas à l'administration.

Mise en œuvre semaine par semaine

Construction autonome de Hyvä Checkout (2 à 5 semaines au total)

Semaine 1, installation + style de base

• Package Hyvä Checkout installé (composer require hyva-themes/magento2-default-theme-checkout ou équivalent pour votre licence)
• Configuration de la marque appliquée aux modèles de paiement
• Les formulaires d'adresse, le sélecteur de méthode de paiement, le sélecteur de méthode d'expédition sont tous rendus sous Hyvä
• Bloc récapitulatif du panier sur le rail droit (ou quel que soit le layout que vous avez licencié)

Semaine 2, intégration des paiements + expédition

• Chaque méthode de paiement active re-modélisée pour Hyvä Checkout
• Intégrations des transporteurs d'expédition re-modélisées si nécessaire
• Logique de calcul des taxes + TVA vérifiée dans les juridictions applicables
• Flux de carte enregistrée / adresse enregistrée / paiement invité testés

Semaine 3, fraude + couche de complexité

• Modules de fraude / risque (Signifyd, Riskified, etc.) intégrés
• Champs de paiement personnalisés ajoutés (message cadeau, instructions de livraison, champs B2B)
• Flux de passation de commande testé de bout en bout avec de vraies commandes de test
• Données structurées Schema.org Order + InvoiceableOrder préservées

Semaine 4, performance + accessibilité

• Audit mobile Lighthouse sur la page de paiement, 90+ comme critères de sortie
• Passation d'accessibilité, navigation au clavier, lecteur d'écran, étiquettes ARIA
• QA inter-navigateurs sur iOS Safari, Android Chrome, bureau

Semaine 5, UAT + basculement

• UAT pré-lancement avec de vraies commandes sur la mise en scène
• Base de taux de conversion capturée avant le basculement pour une comparaison mesurable
• Basculement le dimanche hors pointe, fenêtre de maintenance de 30 à 60 minutes
• Surveillance post-lancement de 72 heures avec le taux de finalisation des commandes surveillé en temps réel

Pour une construction sur un thème Hyvä existant, le calendrier est généralement de 2 à 3 semaines. Pour une construction de paiement uniquement sur Luma, 3 à 5 semaines car les points d'intégration ne sont pas standards.

Passerelles de paiement, ce qui fonctionne, ce qui ne fonctionne pas

Intégrations Hyvä Checkout prises en charge par le fournisseur à partir de 2026 :

Passerelle	Support Hyvä Checkout
Stripe	Fournie par le fournisseur
Adyen	Fournie par le fournisseur
Klarna	Fournie par le fournisseur
PayPal	Fournie par le fournisseur
Worldpay	Fournie par le fournisseur
Braintree	Fournie par le fournisseur
Mollie	Fournie par le fournisseur
Authorize.Net	Intégration personnalisée nécessaire
Sage Pay	Intégration personnalisée nécessaire
La plupart des passerelles régionales au Royaume-Uni	Personnalisée, généralement 1 à 2 semaines de construction

Pour les passerelles sans intégration fournisseur, un module de méthode de paiement Hyvä Checkout personnalisé nécessite généralement 1 à 2 semaines de travail. Nous avons construit ces modules pour une demi-douzaine de passerelles de niche ; le schéma est bien établi.

Expédition + fraude, le point sous-discuté

Les intégrations des transporteurs d'expédition se poursuivent généralement sans trop de travail, la plupart sont des calculs de tarifs côté serveur qui ne touchent pas le frontend. L'exception est les calculateurs de tarifs au moment du paiement qui rendent l'interface utilisateur dans le bloc de méthode d'expédition (affichage des tarifs en direct, sélecteurs de date de livraison, localisateurs de retrait). Chacun de ces éléments nécessite une re-modélisation Hyvä, 1 à 2 jours par intégration.

Les modules de fraude (Signifyd, Riskified, Kount, ClearSale) ont généralement un hook frontend qui se déclenche lors de la passation de commande. Le hook lui-même fonctionne sur Hyvä ; l'interface utilisateur visible (par exemple, un iframe de défi 3DS) peut nécessiter une re-modélisation selon l'approche d'intégration du fournisseur. Prévoyez 1 semaine pour les tests d'intégration de fraude sur de vraies commandes.

B2B Checkout, les surfaces supplémentaires

B2B Magento (et Adobe Commerce B2B) a des surfaces au-delà du processus de paiement B2C standard :

• Capture du numéro de bon de commande
• Commande multi-comptes (passer une commande au nom d'un autre contact d'entreprise)
• Conversion de devis négociés (transformer un devis existant en commande)
• Flux de travail d'approbation (les commandes supérieures à un seuil nécessitent une approbation du manager)
• Affichage des prix segmentés par client
• Ajout rapide à la liste de réquisition

Chacune de ces fonctionnalités est un modèle + flux Hyvä séparé. Hyvä Checkout B2B ajoute 2 à 4 semaines par rapport à Hyvä Checkout B2C, et le cycle de QA est significativement plus long car vous avez besoin de scénarios de test B2B réels (multi-utilisateur, multi-entreprise, etc.).

Ce qui pose problème, par ordre approximatif

Après environ 15 constructions de Hyvä Checkout, les points de rupture les plus courants :

1. Défis de paiement 3DS. L'iframe / popup 3D Secure se comporte différemment sous Hyvä que sous Luma en raison des changements dans l'environnement JavaScript environnant. Prévoyez des scénarios de test 3DS spécifiques dans l'UAT, une vraie carte d'une vraie banque, pas seulement un sandbox.

2. Adyen + Klarna coexistant. Les deux fournisseurs ont un JS frontend agressif qui souhaite contrôler le DOM autour du sélecteur de méthode de paiement. Lorsque les deux sont présents, des conflits apparaissent qui ne se produisent pas avec l'un ou l'autre seul. Testez explicitement la combinaison.

3. Calculateurs de tarifs d'expédition personnalisés. Tout ce qui rend une interface utilisateur en direct dans le bloc de méthode d'expédition (sélecteurs de date de livraison, retrait, tarifs de coursiers en direct) nécessite généralement une re-modélisation Hyvä que le fournisseur n'a pas fournie.

4. Affichage des prix spécifiques aux groupes de clients. Si votre magasin affiche des prix différents aux clients connectés par rapport aux clients invités, cette logique se réapplique au moment du paiement. Cas particulier : un client se connecte en cours de paiement et le bloc de prix doit se rafraîchir sans rechargement complet de la page.

5. Surfaces de calcul des taxes dans les lignes d'articles. Certaines juridictions exigent un affichage détaillé des taxes par ligne. Le modèle de ligne par défaut de Hyvä Checkout peut ou non gérer cela selon votre configuration fiscale Magento. Vérifiez avant de supposer que cela fonctionne.

Performance, à quoi s'attendre

Dans nos constructions de Hyvä Checkout :

• Performance mobile de la page de paiement Lighthouse : généralement 88 à 95
• LCP au moment du paiement : généralement 1,5 à 2,5 s sur mobile 4G (contre 4 à 7 s sur le paiement par défaut de Magento)
• TBT au moment du paiement : généralement 100 à 400 ms (contre 1500 à 4000 ms sur le paiement par défaut de Magento)
• Charge utile JS au moment du paiement : 400 à 700 Ko (contre 2 à 4 Mo sur le paiement par défaut de Magento)

La réduction de la charge utile JS est la source de l'augmentation des conversions. Sur un Android bas de gamme, le temps de parsing seul pour le JavaScript de paiement par défaut de Magento peut être de 3 à 5 secondes. Hyvä Checkout réduit cela à moins d'une seconde.

Augmentation des conversions, ce que nous voyons réellement

Dans les implémentations que nous avons mesurées :

• Taux de finalisation des paiements sur mobile : +8 à 15 % typique
• Taux de finalisation des paiements sur desktop : +2 à 5 % typique (plus faible car le desktop n'était pas aussi contraint par le JS)
• Valeur moyenne des commandes : stable, Hyvä Checkout ne change pas le contenu du panier, juste la friction pour finaliser
• Augmentation des acheteurs de première fois par rapport aux acheteurs récurrents : plus importante pour les premières fois (appareils plus lents, moins de patience pour un processus de paiement lent)

Ces chiffres sont des agrégats. Votre augmentation dépendra de votre mix de trafic (pourcentage mobile, niveau d'appareil), du taux de finalisation des paiements précédent (des bases plus élevées ont moins de marge pour augmenter) et de toute complexité de flux personnalisée.

Tarification de Hyvä Checkout, la licence + la construction

• Licence Hyvä Checkout : environ 1 000 à 3 000 £ par domaine, facturée par Hyvä Themes
• Implémentation autonome (sur le thème Hyvä) : 8 000 à 15 000 £, 2 à 3 semaines
• Implémentation autonome (sur la vitrine Luma) : 10 000 à 20 000 £, 3 à 5 semaines
• Dans le cadre d'une construction complète de Hyvä Commerce : ajoute 2 à 3 semaines + 8 à 15 k £ au coût de construction du thème

Coûts supplémentaires par extension :

• Intégration de passerelle de paiement personnalisée : 2 k à 6 k £ par passerelle
• Intégration de module de fraude personnalisée : 2 k à 4 k £ par module
• Re-modélisation de calculateur de tarifs d'expédition personnalisé : 1 k à 3 k £ par calculateur
• Surfaces spécifiques B2B (devis, multi-comptes, approbations) : 5 k à 12 k £ au total

Devriez-vous attendre Hyvä Checkout 1.4 ?

Question courante. La réponse honnête : Hyvä Checkout 1.3 est prêt pour la production et la prochaine version 1.4 ajoute des fonctionnalités incrémentales plutôt que de corriger des problèmes fondamentaux. Ne retardez pas une migration de paiement à fort retour sur investissement en attendant une version ponctuelle.

Lorsque 1.4 sera disponible, le chemin de mise à niveau sera simple, mise à jour du compositeur, test de régression, déploiement. Nous n'avons jamais eu de mise à niveau de Hyvä Checkout prenant plus d'un sprint.

Prochaines étapes

• Consultez la page de service Hyvä Checkout pour plus de détails sur le service
• Lisez Hyvä Commerce vs Hyvä Theme pour comprendre le contexte de la suite
• Réservez un appel de cadrage pour un devis à prix fixe par rapport à votre liste de modules de paiement + expédition
• Parcourez l'entrée du glossaire Hyvä Checkout pour le primer technique