Abonnement et paiements récurrents (encore !)

Bonjour,

J'ai parcouru les nombreux posts à ce sujet. Mais un point n'est pas clair. Nous souhaitons gérer des abonnements à l'utilisation d'un site. Les personnes payent au mois. Tant que leur abonnement est à jour, elles peuvent utiliser le site. Sinon, elles redeviennent "simple utilisateur" et n'ont plus accès aux fonctions avancées (changement de groupe d'utilisateur).
Plusieurs extensions existent pour Joomla dont Akeeba and Emerald qui sont interconnectées avec HikaShop.
Pour les deux, la seule façon d'avoir des paiement récurrents semble d'être l’utilisation de PayPal recurring.

Ces outils permettent-ils de gérer la commande automatique mensuelle ? En d'autres termes, nous souhaitons qu'à chaque date anniversaire, une "commande" hikashop soit générée avec un mail au client et sa facture mensuelle et le débit de sa CB correspondant à cette facture mensuelle sans intervention humaine. Est-ce automatique ? Automatisable ? Côté hikashop ou côté Akeeba/Emerald ?

Par ailleurs, seriez-vous intéressé par une implémentation du système d'abonnement de SIPS/ATOS (SogenActif pour notre part) qui couvre cette fonctionnalité ? Si oui, nous envisagerions de participer financièrement. Dans ce cas l'automatisme décrit plus haut sera-t-il effectif ? Il est important que le client n'ait pas à intervenir, soit informé (mail) chaque mois de ce débit et puisse, bien entendu, l'interrompre à tout moment.

Merci pour votre retour,

Cordialement,

Laurent

Bonjour,

Actuellement via la méthode de paiement "Paypal recurring" vous pouvez le paramétrer pour avoir une récurrence sur les commandes et non sur des produits. Pour l'option "Type of subscription" il faut sélectionner "Global recurring".

Donc tous les mois la commande sera renouvelée automatiquement et prélevée, si le client interrompt ce prélèvement auprès de Paypal, cela stop la récurrence. Si il l'a souhaite de nouveau il devra passer une commande manuellement.

Par contre, cette méthode ne permet pas de changer de groupe d'utilisateur automatiquement, il faudra créer un plugin pour cela.
Un plugin basé sur la fonction "onAfterOrderUpdate(&$order,&$send_email)".
www.hikashop.com/support/documentation/6...mentation.html#order

Merci. C'est très clair. Effectivement, le plugin onAfterOrderUpdate doit pouvoir récupérer l'information du paiement ayant échoué et modifier le statut de l'utilisateur en conséquence. Cela ne semble pas très compliqué.

Et pour l'implémentation du récurrent SIPS/ATOS ? Cela n’intéresse pas les équipes d'HikaShop ? Le problème vient de réticences de certains utilisateurs à utiliser PayPal, surtout pour un abonnement....

Entendu. On va faire avec Paypal pour l'instant.

Concernant le paramétrage des champs "hikashop". Qu'attend le champ "période paiement récurrent" ?

Je n'ai pas trouvé d'info là-dessus. Le déroulant a 3 choix (regular, global et installment). Il semble que le dernier corresponde à un étalement du paiement sur "n" fois. Global serait donc l'abonnement. Qu'en est-il de "regular" ? C'est juste un paiement en une fois comme avec le plugin Paypal "normal" ?

Lorsqu'on choisit "global", le front-end affiche un déroulant avec, je suppose, la possibilité de choisir une période d'abonnement. Pourquoi est-ce un choix client dans ce cas ? S'agirait-il plutôt de la durée de l'abonnement plutôt que la fréquence ? Peut-on faire apparaître ce choix dans le mail et la facture ?

PS : quand on désactive le plugin (unpublish), il reste dans le front-end. Il faut mettre une restriction sur une monnaie "exotique" pour être sûr de ne plus le voir....

Bonjour,

Le champ "période de paiement récurrent" attend un nombre en jours.

Comme dit dans mon précédent message:

Pour l'option "Type of subscription" il faut sélectionner "Global recurring".

Regular permet la récurrence sur un seul produit, installment permet de payer en n fois, et global permet la récurrence de la commande complète

La liste déroulante en frontend affiche les différentes possiblités de périodes de récurrences, mais ce choix étant défini en backend si une seule option est proposée, l'utilisateur ne pourra pas changer la valeur. Du coup ce champ peut potentiellement être caché.

Bonjour,

Nous avons fait pas mal de tests et tout à l'air de bien fonctionner.

J'ai néanmoins deux interrogations :

1/ pour revenir sur votre réponse précédente :

La liste déroulante en frontend affiche les différentes possiblités de périodes

Qu'attend ce champ exactement ? Juste une série de chiffres "30,60,90" par exemple ? comment se fait la relation entre ce choix offert et les actions effectivement réalisées par Paypal ? Dans le cas du choix "global", on met juste un chiffre (nb de jours ?) et on cache le champ en front-end. C'est bien cela ? Aucun intérêt de multiplier les choix ?

2/ il est (assez !) facile pour le client d'annuler ses récurrences en se connectant à son compte paypal et en annulant l'abonnement en question. Cela provoque une "annulation" dans le mécanisme Hikashop qui stoppe les prélèvements et permet de récupérer l'info via l'API. C'est ok. Mais est-il possible d'annuler la récurrence depuis le Back-end Hikashop ? D'arrêter les prélèvements via une action dans HikaShop à l’initiative du commerçant ?

Merci pour vos éclairages.

Laurent

Bonjour,

1/ En effet, ce champ attend une série de chiffres. L'intérêt du champ en frontend est que si vous paramétrez les jours comme ceci: 30,60,90 le client à alors le choix sur la période de récurrence, et du coup il choisit la récurrence qu'il préfère.
C'est ce choix qui est envoyé à Paypal. Si jamais il n'y a qu'un choix possible, alors oui en frontend l'affichage du champ devient peu utile si ce n'est qu'il informera le client sur la périodicité.

2/ En backend, pour annuler une récurrence il faut changer le status de la commande principale. Une fois qu'elle ne sera plus dans un status "confirmé" la récurrence sera alors stoppée.

Merci.

Salut Jerome, je voudrais savoir si vous avez réussir à faire le développement pour le paiement récurrent(gestion des abonnement) pour ATOS.Merci