Articles avec le tag ‘paiement’

Atos sherlocks / mise en oeuvre configuration

dimanche 20 février 2011

On peut dire, que celui ci m’a fait perdre du temps, quelque chose de bien !

Tous ca pour faire une installation plus propre, et en centralisant l’ensemble des fichier du module au même endroit.

Mais, pas possible, el module ne trouvais pas certain élément de configuration , pourtant installé et definis comme il ce doit ;

Et pas moyen de le faire fonctionner….

En fait, j’avais deporté l’ensemble des elements d’atos dans le repertoire du module de la boutique, mais le chemin vers les element de configuration de la partie sherlocks ne passait plus .

Et j’ai fini pas trouver , grace à ce memo http://www.filluzeau.com/333-solution-pour-lerreur-de-paiement-avec-sips-atos.html, la solution !

Donc , merci à Alexandre :)

Si le chemin est trop long, ben , ca marche pas.

Donc, avec tout à la racine , pas de soucis !

Blogué avec le Navigateur Flock

enregsirement des commandes / gestion des moduel de paiement

mardi 26 octobre 2010

la gestion des paiements, avec leur lots de différence entre les mode bancaire, et le fait de quitter la shop, pour y revenir ensuite, posent quelques question, quant à la transmission des information, et l’enregistrement des commandes.

L’osCSS 2 contient sur ce sujet 2  series de tables jummelle , les orders et les holding_orders.

Les holding order servaient a présent uniquement a recupérer les commande « perdu » ou non validés.

L’evolution qui devrait apparaitre, va changer quelques peu la procedure des enregistrement des orders.

La table orders, reste donc la table des comment dûment validé et confirmé, et les tables holding_orders, passe donc, de leur usage de commande perdues à un usage de pre-commande.

Cette transition permettra donc, de pre-enregsitré toutes les commandes, avant affichage et ainsi generé un numero unique de reference pour cette commande.

Ce numero pourra donc facielment être transmis au different module bancaire, comme Id unique, et utilisé lors des retour bancaire comme reference.

Dans le cas d’une confimation bancaire, arrivant sur la shop, avant le retour du client sur la page checkout, la page response du module prendra donc en charge la convertion des table holding_orders, vers order; et aussi la prise en charge de l’update du status en fonction de la reponse.

Dans le cas ou le client revient sur la boutique via la page process, c’est cette derbière qui prendra en charge la bascule de holding vers orders.
La page response dans ce cas ne prendra en charge que l’update du status.

Concretement, ces modification vont ce traduire par:

  • Ajout d’un champs dans la table orders, qui conservera l’historique de l’id de la table holding l’ayany generé
  • Evolution de la class process pour prendre en charge les holding et les orders
  • Ajout d’un methode dans la class process pou rmigrer une pre-commande en commande, et suppression de la pre-commande


il n’y a pus qu’a. :)