Prix d'abonnement dans les Checkout UI Extensions Shopify

Une extension d'interface de paiement (checkout UI extension) Shopify ne peut pas réécrire le prix récurrent qu'un abonné voit au moment du paiement. Ce montant provient de la politique de prix (pricing policy) du plan de vente (selling plan), donc quand il semble faux après un changement de produit, la correction se fait sur le plan, pas dans l'extension.

Un vendeur gérant un abonnement de bougies a constaté que le Recurring Subtotal affichait en permanence le prix de départ, même après que des clients soient passés à une variante de recharge moins chère, comme décrit dans un fil de la communauté Shopify. Nous observons la même confusion dans notre propre file de support : 13 questions sur le paiement des abonnements en 90 jours, avec des vendeurs qui ne savent pas ce que le paiement promet par rapport à ce qui est réellement facturé.

D'où vient vraiment le prix récurrent

Shopify organise les produits d'abonnement en groupes de plans de vente (selling plan groups). Chaque plan porte une politique de prix, qui prend deux formes : fixed, un seul ajustement pour tout l'abonnement, ou recurring, un ajustement différent une fois une période initiale terminée. Le paiement lit directement la politique attachée à cette ligne.

Les extensions d'interface de paiement se placent à côté de ce montant, pas dedans. Shopify les documente comme des blocs ou du contenu statique placés avant ou après les sections du paiement. Le calcul du prix est géré séparément, par Shopify Functions, pas par une extension d'interface.

Si tu n'as pas encore audité tes extensions de paiement et de compte depuis la dernière échéance, c'est un bon point de départ avant d'en ajouter une de plus.

Deux choses que l'on appelle "changement de produit"

Distingue ces deux cas avant de dépanner : un changement de cycle intégré au plan, comme le prix de départ d'une bougie puis le prix de recharge sans action du client, et un changement manuel de produit par l'acheteur en cours d'abonnement. Le cas du forum ci-dessus est du premier type. Un changement manuel est une action différente, mais il met à jour le même objet de politique de prix en dessous.

L'audit : trouver ce qui est cassé

1. Récupère le plan de vente derrière le produit, depuis le tableau de bord de ton application d'abonnement ou via la requête Admin GraphQL sellingPlanGroups, et regarde ses politiques de prix.
2. Vérifie s'il porte une seule politique ou deux. Une seule politique signifie que les deux cycles afficheront et factureront le même montant, par conception.
3. Si tu attends deux prix, ajoute la politique recurring manquante via ton application d'abonnement, pour que le premier cycle facture le prix de départ et les suivants le prix après changement.
4. Enregistre la modification, passe une vraie commande d'abonnement test et vérifie sa première charge à venir dans ton application d'abonnement avant de dire à qui que ce soit que le problème est résolu.
5. Si les deux politiques sont déjà correctes et que le paiement reste confus, c'est un problème de formulation, pas de prix. Passe à la section suivante au lieu de modifier le plan à nouveau.

Pourquoi régler ça avant la prochaine migration

Un abonné qui voit un prix au paiement et un autre sur son relevé annule souvent ou dépose un litige bancaire. Cela apparaît souvent justement quand les boutiques changent d'application d'abonnement.

Nous avons aussi vu des tickets de support où les moyens de paiement tombaient en panne indépendamment du prix, par exemple une question "iDEAL/Mollie payments not working" après un changement de prestataire. C'est une panne distincte, à vérifier séparément.

Si tu hésites sur l'intérêt d'une migration, notre analyse des coûts d'abonnement détaille les frais que la plupart des boutiques ratent.

Quand le montant est juste mais le texte non

Les applications construites sur le modèle de prix natif de Shopify stockent un changement de la même façon que Shopify. Progus Subscriptions, par exemple, conserve les politiques de prix de chaque plan sous forme de paires type d'ajustement et valeur d'ajustement, le même objet que lit le paiement, donc l'audit ci-dessus fonctionne de la même façon quelle que soit l'application qui gère l'abonnement.

Si le montant facturé est déjà correct et que tu veux juste du contexte supplémentaire avant le changement, un développeur peut ajouter une extension d'interface de paiement près du résumé de commande. Elle peut lire un prix futur stocké dans un metafield et l'afficher comme une note. Cette note ne change pas la ligne Recurring Subtotal, elle répond seulement à la question à côté.

Shopify limite les extensions d'interface de paiement sur les étapes informations, livraison et paiement aux boutiques sur un plan Shopify Plus. Les extensions près du résumé de commande suivent un type de cible différent, donc confirme ton emplacement exact avant de promettre quoi que ce soit.

Conclusion

Les extensions d'interface de paiement sont une couche de présentation, pas un moteur de prix. Quand un montant semble faux, vérifie d'abord la politique de prix du plan de vente, et ne construis une extension personnalisée qu'une fois le montant facturé confirmé correct.

Les applications d'abonnement changent par acquisitions, migrations et prestataires qui retirent des fonctionnalités, plus souvent que la plupart des marchands ne l'imaginent. Retestes la politique de prix et la configuration du moyen de paiement séparément après chacun de ces événements, car l'un peut tomber en panne sans l'autre.