Paiement CM CIC

Oui il suffit d'envoyer cette url à l'adresse This email address is being protected from spambots. You need JavaScript enabled to view it. et attendre la validation en retour.
Pour ma part, cela a bien pris 24h avant d'être effectif. Ensuite tout a fonctionné parfaitement.

Bonjour,

Je dois mettre en oeuvre 2 modes de paiement par CB :

• un paiement par CB pour un achat immédiat
• un paiement par pour des abonnements, donc paiement récurrents à échéances mensuelles et montants mensuels identiques.

Selon, le centre technique Centrecom, il faut 2 n° de TPE différents pour distinguer les 2 modes de paiements. Si tel est le cas, cela signifie pour mon site que je dois paramétrer 2 modes de paiements CMCIC.

Comment peut-on faire pour indiquer que tel produit sera payé avec un mode de paiement plutôt qu'un autre?
Et enfin, à priori, tel que fonctionne le passage en caisse, le client ne peut pas commander à la fois des produits pour un achat unique (échéance unique) et des abonnements (échéances multiples), non ??

Merci par avance de vos suggestions.

Oui, j'avais bien compris pour l'instant que le plugin de paiement récurrent n'était pas dans le plugin actuel.

Toutefois, lorsque le commerçant contracte avec CM-CIC pour définir vos modes de paiement, vous obtenez 2 codes TPE par exemple pour différencier le mode de paiement sur un seul paiement du mode de paiement récurrent. En fait, le mode opératoire défini avec la banque le nombre d'échéances maxi, la date d'anniversaire du renouvellement du paiement. A priori, c'est information n'ont pas besoin d'être passées par le plugin de paiement. Il suffit de passer une commande classique et le code TPE qui permet de préciser que cette commande (donc son paiement) sera récurrent suivant les conditions contractuelles définies avec la banque.

Donc mon propos est plutôt de savoir comment je peux indiquer lors du passage en caisse que pour tel produit, le mode de paiement sera unique ou pour tel autre le mode de paiement sera récurrent.

Merci

Bonjour

Merci tout d'abord pour cette réponse, Jérôme.

Quel est le fichier Php à modifier?

Par ailleurs, pour ma part, je ne suis pas du tout en capacité de mettre à jour du php aussi facilement et donc je me trouve dans une impasse. Compte tenu de votre avis qui précise que cela "n'est pas très compliqué", et compte tenu de la plus-value que cet apport fonctionnel peut apporter à Hikashop (le mode de paiement par CB avec le groupe Crédit Mutuel - CIC est bien implanté en France au vu des autres sites marchands), pourquoi ne pas mettre rapidement dans votre road map cette fonctionnalité?

Enfin, une autre solution de la communauté???

Bonjour,

Si je comprends bien, pour utiliser CM/CIC en paiement récurrent il suffit de renseigner le bon code TPE.
Si ce code est renseigné, alors CM/CIC effectue les paiements en paiements récurrents.

Le plus simple serait de dupliquer le plugin CM/CIC, dans celui créé il faut ajouter la ligne: "$method->recurring = 1;" dans la fonction "onPaymentDisplay()" afin qu'il s'affiche uniquement lorsque des produits récurrents sont présents dans le panier.
Le contrôle des produits récurrents se fait automatiquement dans HikaShop, si le produit a une souscription récurrente alors les méthodes de paiement récurrent sont affichées.

Il faudrait aussi modifier la fonction "onPaymentNotification()" afin de récupérer les informations de l'ancienne commande pour en dupliquer les informations, et d'autres modifications sont nécessaires.
Cela requiert des compétences PHP, pour une personne qui en a il peut s'appuyer sur le plugin PayPal recurring.

Actuellement, nous sommes assez surchargés et nous n'aurons pas le temps de faire cela avant un petit moment, d'autres modifications sont pour le moment plus prioritaires.

Bonjour,

En fait, AkeebaSubscriptions n'est pas concerné par ce problème de génération de paiement,puisque si on utilise le plugin de subscription, le client arrive sur le passage en caisse d'Hikashop et donc les plugins de paiements d'Hikashop (je ne me trompe pas à priori ???).

Ainsi, aujourd'hui, soit le commerçant utilise le paiement unique (une seule échéance), soit c'est du paiement par abonnement, mais pas les deux, tels que sont prévus les plugins Hikashop. En fait, il faurdait dupliquer le plugin CM-CIC et suivant les produits dans le passage en caisse, l'un des 2 plugins est utilisé, mais pas les 2. Si des produits ont des modes de paiements différents lors du passage en caisse, c'est une erreur et donc le client retire le/les produit(s) dont le mode de paiement n'est pas le bon.
Non???

En fait, je n'ai pas été assez rapide, Xavier a entre temps répondu (lol)

Je confirme que l'on peut utiliser soit une méthode, soit l'autre. Les deux types ne sont pas possibles dans un seul passage en caisse.

En fait, la solution n'est-elle pas simplement :
le plugin original pour le paiement classique (payement type = cmcic)
dupliquer le plugin orginal et lui créer un payment type = cmcic_R (par exemple), et donc dupliquer l'ensemble des fichier php, xml s'y rapportant.

Créer un custom-field dans produit pour désigner si un produit est à échéance unique ou par abonnement

Dans le passage en caisse, détecter si tous les produits sont du même type d'échéance, sinon, afficher une erreur avertir le client qu'il y a des produits avec des échéances différentes, si OK, afficher dans le passage en caisse le plugin correspond au type d'échéance.

Trop simple peut être????

Pour afficher le bon plugin en fonction du type de produit, c'est très simple il suffit d'ajouter "$method->recurring = 1;" dans la fonction "onPaymentDisplay()" du plugin pour la récurrence.
La difficulté est pour envoyer les bonnes données relatives à la récurrence, donc la période de récurrence, et les autres informations recquises par le système de paiement.

Mais aussi, lorsque CM/CIC prélevera la somme le mois suivant, il doit l'indiquer à HikaShop afin de générer un nouveau bon de commande chaques mois. Ce bon de commande doit être identique au précédent à quelques choses prêt, tel que l'id le numéro de commande.

Pour ce qui concerne la récurrence du paiement, en fait elle est définie dans le contrat signé avec la banque :
- à date fixe le ... de chaque mois,
ou
- à la date anniversaire de la première transaction.
Par ailleurs, le commerçant précise le nombre maximal d'échéances en mois.

Donc c'est ce TPE qui permet à la banque de générer sur les échéances suivantes le recouvrement de la somme indiquée dans le premier paiement tant que le nombre maxi n'est pas atteint ou que la carte n'arrive pas à expiration ou que le commerçant a arrêter le prélèvement par une interface dédié (manuellement) ou par webservices.

Pour la commande, en fait je suis plutôt tenté de préciser pourquoi vouloir générer à chaque fois une nouvelle commande. De mémoire qd je souscris un abonnement (magazine mensuel, EDF/GDF), j'ai une première commande qui me précise les modalités de paiement, les dates d'anniversaire de recouvrement et les sommes à payer. Je suis simplement averti que j'ai eu un prélèvement réalisé au niveau de ma banque.
Pour ce qui me concerne sur le site, je peux au niveau de la commande préciser les modalités de renouvellement des échéances mensuelles, les sommes qui seront prélévés chaque mois, les conditions d'arret de l'abonnement (en plus dansle conditions de vente cela peut être à nouveau précisé). et donc cela me dédouane de mettre en place une usine à gaz pour générer une commande/facture mensuelle?

Généralement c'est apprécié d'avoir une facture même lors d'un abonnement mensuel, exemple factures de téléphonie, etc...

Cependant si vous n'avez pas besoin de cela, et pas besoin d'un suivi mensuel dans votre boutique en ligne vous pouvez alors essayer d'apporter les quelques modifications dont j'ai parlé plus haut.
Je vous suggère de faire plusieurs tests avant de réellement utiliser cette méthode.

Bonjour,
Lorsque vous écrivez "Le plus simple serait de dupliquer le plugin CM/CIC, dans celui créé il faut ajouter la ligne: "$method->recurring = 1;" dans la fonction "onPaymentDisplay()" afin qu'il s'affiche uniquement lorsque des produits récurrents sont présents dans le panier." :
Comment sont identifiés les produits récurrents des autres??

Bonjour,

Les produits récurrents sont identifiés lorsqu'ils sont associés à une souscription récurrente dans Akeeba Souscription.
Nous avons un plugin d'intégration qui ajoute une liste déroulante dans la fiche d'édition d'un produit, cette liste affiche les souscriptions pouvant être ajoutées au produit.

HikaShop est déjà en mesure de différencier les types de produits, vous pouvez retrouver de la documentation ici:
www.hikashop.com/en/support/documentatio...a-subscriptions.html

Bonjour Xavier,

La ligne: "$method->recurring = 1", je la met juste avant le test "if(!empty($methods)){"?

Par ailleurs, le plugin Akeeba subscrition créer un nouveau champ dans la fiche produit intitulé "niveau de souscription", je suppose que ce champ est testé dans un fichier php pour affecter le bon mode de paiement dans le passage en caisse?

Dans mon, ne me suffit-il pas de créer un custom fields intitulé "niveau de souscription" qui différencie les produits récurrents des autres produits et m'éviter de me prendre encore un addons (dont je n'ai rien contre pour Akeeba, mais qui encombre la structure)?

Bonjour,

Pour commencer mon nouveau mode de paiement CM-CIC pour produit récurrent, j'ai donc dupliqué le plugin cmcic (duplication des fichiers php et xml, modification du xml pour renommer les fichiers php), zipper les fichiers et installer le plugin par la gestion des extension - installation : tout est OK.
Par contre, l'affichage du nouveau plugin à partir de la liste des plugins de paiement d'hikashop, me donne le message d'erreur suivant :
"Fatal error: Call to a member function display() on a non-object in G:\.....\plugins\hikashoppayment\cmcic_recurrent\cmcic_recurrent_configuration.php on line 93" qui correspond à la construction de la liste des statuts invalide et vérifié.
la ligne php concernée dans le fichier cmcic_recurrent_configuration est : "<?php echo $this->data->display("data[payment][payment_params][invalid_status]",@$this->element->payment_params->invalid_status); ?>"

Aurais-je oublié quelque chose???
Merci