Aide - Recherche - Membres - Calendrier
Version complète : Problème Paybox, Oscommerce et retour http
Forum osCommerce-fr > Adapter OsCommerce MS2 > Modules de Paiement et de Livraison
Pages : 1, 2
Mateo
Bonsoir,

Je suis en pleine phase de test (avec mon compte test personnel de Paybox, pas avec le test commun accessible à tous). Donc je peux normalement utiliser le fameux retour http de chez paybox qui permet d'enregistrer la commande dès la validation du paiement (sans attendre la redirection automatique vers la page process/success).

J'ai installé une version récente de contribution Paybox pour oscommerce (trouvée sur http://www.webmaster-hub.com/lofiversion/i...php/t23416.html ). Cette contribution fonctionne très bien si je n'active pas chez Paybox le protocole httpd et si je mets donc en code retour dans le code de la contrib "tep_draw_hidden_field('PBX_EFFECTUE', tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL', false)) .". Tous mes tests ont réussis.

Cependant, si je demande à Paybox d'activer le retour http en leur donnant comme retour http www.monsite.blabla/checkout_process.php et que je modifie la contrib en mettant cette fois-ci tep_draw_hidden_field('PBX_EFFECTUE', tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL', false)), et bien là c'est le drame. Plus sérieusement, Paybox ne valide pas le retour http et me retourne une erreur 302. Réponse du service technique de Paybox : "Le code (302) signifie que cette url est redirigée au niveau de votre serveur et donc nous n'avons pas retour "200 OK" de la part de votre
serveur. Le protocole http en vigueur ne peut supporter de redirection de
l'url".

Bref, je comprends vu que checkout_process.php redirige en cas de succès vers checkout_success.php.

Et j'en arrive enfin à ma question : est-ce insurmontable et faut-il attendre que Paybox trouve la solution pour corriger leur système de retour http ou quelqu'un a une boutique qui fonctionne sous Oscommerce et qui arrive à faire marcher le retour http de chez Paybox? (bcp de si...).

Oscommerce est répandu. Paybox également. Cela serait dommage de ne pas joindre les deux bouts, enfin du moins pour cette technologie de httpd retour qui est pas mal.

Mais au pire en attendant, je ne vais pas activer le retour http, mettre chez paybox une redirection auto après paiement et garder ma superbe contrib que m'était déjà utile avec PayPal, celle qui permet d'enregistrer les commandes avant d'aller sur le paiement (je ne me rappelle plus du nom).

Merci d'avance à ceux qui voudront contribuer à ce problème (que d'autres doivent sans doute rencontrer?).

Bonne soirée,
Mateo

___
Oscommerce MS2 avec 50000 contribs.

Mateo
Malheureusement non. Je pense que rien n'a été développé pour l'instant en terme de contribution qui gère le retour http de paybox sous Oscommerce.

Donc pour l'instant j'ai désactivé le retour http et j'ai pris l'option de redirection automatique à la fin du paiement par carte bancaire.

Si quelqu'un a développé quelque chose, qu'il n'hésite pas à faire signe.

Bonne journée,
Mateo
Raph
Bonjour à tous.

J'ai eu, moi aussi ce problème de l'URL retour de paybox avec OsCommerce. L'URL retour est appelé par le serveur paybox DES que l'utilisateur clic sur le bouton de validation de sa commande après avoir entré ses coordonnées bancaires, et ceci dans tous les cas, que le paiement soit refusé ou autorisé.

Le problème qui survient vient du fait que lorsque paybox appelle cette url retour, le script de l'url ne doit pas effectuer de redirection, ce que fait malheureusement checkout_process.php qui détecte que l'utilisateur (le serveur paybox) n'est pas "connecté" au site.

Ayant fait de nombreuses recherches infructueuses sur le Net, j'ai été finalement contraint de reprogrammer la page checkout_process.php. Après de nombreuses heures de luttes et quelques bidouilles, ça fonctionne.

Pour les développeur PHP:
Etant donné que l'url retour est appelée en premier quel que soit le résultat, l'astuce consiste à valider la commande à ce moment là, en regénérant la session de l'utilisateur au moyen de son osCid (qu'il faut inclure par exemple dans IBS_CMD entre 2 '|'). Une fois la commande traitée, générez une variable session temporaire destinée uniquement à signaler au deuxième appel de la page si la commande a été autorisée (et donc gérée) ou non. Le deuxième appel (le retour boutique s'il y a), regardera cette variable et se contentera d'effectuer une redirection vers checkout_payment.php?error=xxx si la commande a échouée, et checkout_success.php sinon.


Le problème maintenant, c'est que mon script reprogrammé ne peut pas être directement adapté à tout le monde, étant donné que j'ai fixé l'osCid à un certain endroit de l'url qui n'est sans doute pas le votre.

Je m'excuse par avance pour la communauté, mais je n'ai pas le temps de développer un script générique qui marcherait pour tout le monde, étant suchargé de travail en ce moment.
Le but de ce post est donc tout d'abord d'éclaircir un peu le problème, et de donner aux programmeur PHP une idée de solution "simple" qui fonctionne.

Si vous avez également cet épineux problème et vous perdez dans le code, postez vos réponses j'essaierai quand même de vous aider.
RSODidier
Comme tout le monde, je suis confronté à ce problème mais j'ai un petit élément de réponse pour nous mettre sur la voie.

En enlevant le .htaccess le retour se fait bien !

Le problème est que ça ouvre une vulnérabilité et que ça déclenche quand même un warning 302 mais ça marche.
Je continue à chercher.

Affaire à suivre...

PS: Raph si tu peux envoi ton source en masquant par des XXX les parties contenant des valeurs qui te sont spécifiques.
Merci.
Raph
Rebonjour.

Je vous envoi donc mon code qui fonctionne. Je précise bien qu'il est nécessaire de l'adapter à votre site en fonction des paramètres que vous envoyez et recevez depuis et sur la page chechout_process.php. J'ai commenté le script PHP afin que vous vous y retrouviez un peu mieux.

En espérant que ça vous aide, voici la seule page à modifier, checkout_process.php :
CODE
<?php
/*
  $Id: checkout_process.php,v 1.128 2003/05/28 18:00:29 hpdl Exp $

  osCommerce, Open Source E-Commerce Solutions
  http://www.oscommerce.com

  Copyright (c) 2003 osCommerce

  Released under the GNU General Public License
*/

  include('includes/application_top.php');

  /*
    Gestion de l'URL retour de paybox
    Raphaël Voisin, Avril 2007
    raphael.voisin@gmail.com
  */

  /*
     Si IBS_CMD n'est pas définie, c'est que le script a été accédé
     d'une façon illogique, on peut donc effectuer les tests standards
     conduisant aux redirections standards
  */

  if(!isset($_GET["IBS_CMD"])) {
    // if the customer is not logged on, redirect them to the login page
    if (!tep_session_is_registered('customer_id')) {
      $navigation->set_snapshot(array('mode' => 'SSL', 'page' => FILENAME_CHECKOUT_PAYMENT));
      tep_redirect(tep_href_link(FILENAME_LOGIN, '', 'SSL'));
    }

    if (!tep_session_is_registered('sendto')) {
      tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
    }

    if ( (tep_not_null(MODULE_PAYMENT_INSTALLED)) && (!tep_session_is_registered('payment')) ) {
      tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));
    }

    // avoid hack attempts during the checkout procedure by checking the internal cartID
    if (isset($cart->cartID) && tep_session_is_registered('cartID')) {
      if ($cart->cartID != $cartID) {
        tep_redirect(tep_href_link(FILENAME_CHECKOUT_SHIPPING, '', 'SSL'));
      }
    }
  }

  /* On suppose d'abord qu'il s'agit du cas où le client n'a pas fermé la fenêtre paybox
     ou coupé sa connexion, et qu'il FAUT donc rediriger vers la page de succès ou d'echec.
  */
  $mustRedirect = true;

  /*
    Si la variable GET auto n'existe pas ou est nulle, c'est que le paiement a été refusé.
    Il faut pour le moment se contenter d'enregistrer l'echec en session.
    Ainsi, si l'utilisateur retourne à la boutique, le seul test à effectuer se fera sur cette variable,
    étant donné que l'appel de l'url retour s'est déja chargé d'effectuer les opérations de paiments
    (gestion de la commande, envoi des mails, etc...)
  */
  $returnURLChecking = !(!isset($_GET["auto"]) || $_GET["auto"] == '');
  tep_session_register('returnURLChecking');

  /*
    S'il s'agit du retour à la boutique, on peut l'identifier par le fait
    que IBS_CMD soit définie ainsi qu'osCid.
    Si c'est le cas, la gestion de la commande a déja été effectuée.
    Le résultat (erreur ou non) se trouve en session.
    Il suffit alors de rediriger vers la page de succès ou d'echec
  */
  if(isset($_GET["IBS_CMD"]) && isset($_GET["osCsid"])) {
    if($_SESSION['returnURLChecking']) {
      tep_session_unregister('returnURLChecking');
      tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));
    } else {
      tep_session_unregister('returnURLChecking');
      tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT."?payment_error=paybox", '', 'SSL'));
    }
  }

  /*
    S'il s'agit de l'url retour, on peut l'identifier au fait
    que IBS_CMD soit définie mais pas osCid
    C'est le serveur Paybox qui appelle le script par conséquent il n'y a pour le moment
    aucun lien avec la session de l'utilisateur. Lors de l'appel par paybox de ce script,
    la session utilisateur n'est pas encore détruite en base de données. Le paramètre IBS_CMD
    a été pré-configuré pour encapsuler l'identifiant de session utilisateur.
    Toute la difficulté résidait dans le fait de recharger la session !
  */
  if(isset($_GET["auto"]) && isset($_GET["IBS_CMD"]) && !isset($_GET["osCsid"])) {
    $mustRedirect = false;

    /*
       Les 3 lignes ci dessous sont spécifique à mon site, vous devez les modifier
       en fonction de l'endroit où l'osCid se trouve dans les paramètres de l'url retour.
       Vous constatez que pour moi il s'agit du paramètre IBS_CMD, qui a pour valeur
       une chaine de caractère séparé par des pipes (|), et l'osCid se trouve juste après
       le 3ème pipe.
    */
    $ibsCMD = $_GET["IBS_CMD"];
    $t_ibsCMD = explode("|", $ibsCMD);
    $myOsCid = $t_ibsCMD[3];

    // Remise en GET des paramètres comme si c'était l'utilisateur qui chargeait la page
    $_GET["pbx"] = 1;
    $_GET["osCsid"] = $myOsCid;

    // RESTAURATION DE SA SESSION !!!
    tep_session_id($myOsCid);
    tep_session_start();


    /*
      Et c'est donc ici que se fait la gestion de la commande...
    */

    include(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CHECKOUT_PROCESS);

  // load selected payment module
    require(DIR_WS_CLASSES . 'payment.php');
    $payment_modules = new payment($payment);

  // load the selected shipping module
    require(DIR_WS_CLASSES . 'shipping.php');
    $shipping_modules = new shipping($shipping);

    require(DIR_WS_CLASSES . 'order.php');
    $order = new order;

  // load the before_process function from the payment modules
    $payment_modules->before_process();

      if (isset($HTTP_GET_VARS['pbx']) && $HTTP_GET_VARS['pbx']==1) {
          if ( ($request_type == 'SSL') && isset($HTTP_GET_VARS[tep_session_name()]) ) {
           tep_session_id($HTTP_GET_VARS[tep_session_name()]);
          }
      }


    require(DIR_WS_CLASSES . 'order_total.php');
    $order_total_modules = new order_total;

    $order_totals = $order_total_modules->process();

    $sql_data_array = array('customers_id' => $customer_id,
                            'customers_name' => $order->customer['firstname'] . ' ' . $order->customer['lastname'],
                            'customers_company' => $order->customer['company'],
                            'customers_street_address' => $order->customer['street_address'],
                            'customers_suburb' => $order->customer['suburb'],
                            'customers_city' => $order->customer['city'],
                            'customers_postcode' => $order->customer['postcode'],
                            'customers_state' => $order->customer['state'],
                            'customers_country' => $order->customer['country']['title'],
                            'customers_telephone' => $order->customer['telephone'],
                            'customers_email_address' => $order->customer['email_address'],
                            'customers_address_format_id' => $order->customer['format_id'],
                            'delivery_name' => $order->delivery['firstname'] . ' ' . $order->delivery['lastname'],
                            'delivery_company' => $order->delivery['company'],
                            'delivery_street_address' => $order->delivery['street_address'],
                            'delivery_suburb' => $order->delivery['suburb'],
                            'delivery_city' => $order->delivery['city'],
                            'delivery_postcode' => $order->delivery['postcode'],
                            'delivery_state' => $order->delivery['state'],
                            'delivery_country' => $order->delivery['country']['title'],
                            'delivery_address_format_id' => $order->delivery['format_id'],
                            'billing_name' => $order->billing['firstname'] . ' ' . $order->billing['lastname'],
                            'billing_company' => $order->billing['company'],
                            'billing_street_address' => $order->billing['street_address'],
                            'billing_suburb' => $order->billing['suburb'],
                            'billing_city' => $order->billing['city'],
                            'billing_postcode' => $order->billing['postcode'],
                            'billing_state' => $order->billing['state'],
                            'billing_country' => $order->billing['country']['title'],
                            'billing_address_format_id' => $order->billing['format_id'],
                            'payment_method' => $order->info['payment_method'],
                            'cc_type' => $order->info['cc_type'],
                            'cc_owner' => $order->info['cc_owner'],
                            'cc_number' => $order->info['cc_number'],
                            'cc_expires' => $order->info['cc_expires'],
                            'date_purchased' => 'now()',
                            'orders_status' => $order->info['order_status'],
                            'currency' => $order->info['currency'],
                            'currency_value' => $order->info['currency_value']);
    tep_db_perform(TABLE_ORDERS, $sql_data_array);
    $insert_id = tep_db_insert_id();
    for ($i=0, $n=sizeof($order_totals); $i<$n; $i++) {
      $sql_data_array = array('orders_id' => $insert_id,
                              'title' => $order_totals[$i]['title'],
                              'text' => $order_totals[$i]['text'],
                              'value' => $order_totals[$i]['value'],
                              'class' => $order_totals[$i]['code'],
                              'sort_order' => $order_totals[$i]['sort_order']);
      tep_db_perform(TABLE_ORDERS_TOTAL, $sql_data_array);
    }

    $customer_notification = (SEND_EMAILS == 'true') ? '1' : '0';
    $sql_data_array = array('orders_id' => $insert_id,
                            'orders_status_id' => $order->info['order_status'],
                            'date_added' => 'now()',
                            'customer_notified' => $customer_notification,
                            'comments' => $order->info['comments']);
    tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array);

  // initialized for the email confirmation
    $products_ordered = '';
    $subtotal = 0;
    $total_tax = 0;

    for ($i=0, $n=sizeof($order->products); $i<$n; $i++) {
  // Stock Update - Joao Correia
      if (STOCK_LIMITED == 'true') {
        if (DOWNLOAD_ENABLED == 'true') {
          $stock_query_raw = "SELECT products_quantity, pad.products_attributes_filename
                              FROM " . TABLE_PRODUCTS . " p
                              LEFT JOIN " . TABLE_PRODUCTS_ATTRIBUTES . " pa
                               ON p.products_id=pa.products_id
                              LEFT JOIN " . TABLE_PRODUCTS_ATTRIBUTES_DOWNLOAD . " pad
                               ON pa.products_attributes_id=pad.products_attributes_id
                              WHERE p.products_id = '" . tep_get_prid($order->products[$i]['id']) . "'";
  // Will work with only one option for downloadable products
  // otherwise, we have to build the query dynamically with a loop
          $products_attributes = $order->products[$i]['attributes'];
          if (is_array($products_attributes)) {
            $stock_query_raw .= " AND pa.options_id = '" . $products_attributes[0]['option_id'] . "' AND pa.options_values_id = '" . $products_attributes[0]['value_id'] . "'";
          }
          $stock_query = tep_db_query($stock_query_raw);
        } else {
          $stock_query = tep_db_query("select products_quantity from " . TABLE_PRODUCTS . " where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'");
        }
        if (tep_db_num_rows($stock_query) > 0) {
          $stock_values = tep_db_fetch_array($stock_query);
  // do not decrement quantities if products_attributes_filename exists
          if ((DOWNLOAD_ENABLED != 'true') || (!$stock_values['products_attributes_filename'])) {
            $stock_left = $stock_values['products_quantity'] - $order->products[$i]['qty'];
          } else {
            $stock_left = $stock_values['products_quantity'];
          }
          tep_db_query("update " . TABLE_PRODUCTS . " set products_quantity = '" . $stock_left . "' where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'");
          if ( ($stock_left < 1) && (STOCK_ALLOW_CHECKOUT == 'false') ) {
            tep_db_query("update " . TABLE_PRODUCTS . " set products_status = '0' where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'");
          }
        }
      }

  // Update products_ordered (for bestsellers list)
      tep_db_query("update " . TABLE_PRODUCTS . " set products_ordered = products_ordered + " . sprintf('%d', $order->products[$i]['qty']) . " where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'");

      $sql_data_array = array('orders_id' => $insert_id,
                              'products_id' => tep_get_prid($order->products[$i]['id']),
                              'products_model' => $order->products[$i]['model'],
                              'products_name' => $order->products[$i]['name'],
                              'products_price' => $order->products[$i]['price'],
                              'final_price' => $order->products[$i]['final_price'],
                              'products_tax' => $order->products[$i]['tax'],
                              'products_quantity' => $order->products[$i]['qty']);
      tep_db_perform(TABLE_ORDERS_PRODUCTS, $sql_data_array);
      $order_products_id = tep_db_insert_id();

  //------insert customer choosen option to order--------
      $attributes_exist = '0';
      $products_ordered_attributes = '';
      if (isset($order->products[$i]['attributes'])) {
        $attributes_exist = '1';
        for ($j=0, $n2=sizeof($order->products[$i]['attributes']); $j<$n2; $j++) {
          if (DOWNLOAD_ENABLED == 'true') {
            $attributes_query = "select popt.products_options_name, poval.products_options_values_name, pa.options_values_price, pa.price_prefix, pad.products_attributes_maxdays, pad.products_attributes_maxcount , pad.products_attributes_filename
                                 from " . TABLE_PRODUCTS_OPTIONS . " popt, " . TABLE_PRODUCTS_OPTIONS_VALUES . " poval, " . TABLE_PRODUCTS_ATTRIBUTES . " pa
                                 left join " . TABLE_PRODUCTS_ATTRIBUTES_DOWNLOAD . " pad
                                  on pa.products_attributes_id=pad.products_attributes_id
                                 where pa.products_id = '" . $order->products[$i]['id'] . "'
                                  and pa.options_id = '" . $order->products[$i]['attributes'][$j]['option_id'] . "'
                                  and pa.options_id = popt.products_options_id
                                  and pa.options_values_id = '" . $order->products[$i]['attributes'][$j]['value_id'] . "'
                                  and pa.options_values_id = poval.products_options_values_id
                                  and popt.language_id = '" . $languages_id . "'
                                  and poval.language_id = '" . $languages_id . "'";
            $attributes = tep_db_query($attributes_query);
          } else {
            $attributes = tep_db_query("select popt.products_options_name, poval.products_options_values_name, pa.options_values_price, pa.price_prefix from " . TABLE_PRODUCTS_OPTIONS . " popt, " . TABLE_PRODUCTS_OPTIONS_VALUES . " poval, " . TABLE_PRODUCTS_ATTRIBUTES . " pa where pa.products_id = '" . $order->products[$i]['id'] . "' and pa.options_id = '" . $order->products[$i]['attributes'][$j]['option_id'] . "' and pa.options_id = popt.products_options_id and pa.options_values_id = '" . $order->products[$i]['attributes'][$j]['value_id'] . "' and pa.options_values_id = poval.products_options_values_id and popt.language_id = '" . $languages_id . "' and poval.language_id = '" . $languages_id . "'");
          }
          $attributes_values = tep_db_fetch_array($attributes);

          $sql_data_array = array('orders_id' => $insert_id,
                                  'orders_products_id' => $order_products_id,
                                  'products_options' => $attributes_values['products_options_name'],
                                  'products_options_values' => $attributes_values['products_options_values_name'],
                                  'options_values_price' => $attributes_values['options_values_price'],
                                  'price_prefix' => $attributes_values['price_prefix']);
          tep_db_perform(TABLE_ORDERS_PRODUCTS_ATTRIBUTES, $sql_data_array);

          if ((DOWNLOAD_ENABLED == 'true') && isset($attributes_values['products_attributes_filename']) && tep_not_null($attributes_values['products_attributes_filename'])) {
            $sql_data_array = array('orders_id' => $insert_id,
                                    'orders_products_id' => $order_products_id,
                                    'orders_products_filename' => $attributes_values['products_attributes_filename'],
                                    'download_maxdays' => $attributes_values['products_attributes_maxdays'],
                                    'download_count' => $attributes_values['products_attributes_maxcount']);
            tep_db_perform(TABLE_ORDERS_PRODUCTS_DOWNLOAD, $sql_data_array);
          }
          $products_ordered_attributes .= "\n\t" . $attributes_values['products_options_name'] . ' ' . $attributes_values['products_options_values_name'];
        }
      }
  //------insert customer choosen option eof ----
      $total_weight += ($order->products[$i]['qty'] * $order->products[$i]['weight']);
      $total_tax += tep_calculate_tax($total_products_price, $products_tax) * $order->products[$i]['qty'];
      $total_cost += $total_products_price;

      $products_ordered .= '<b>' . $order->products[$i]['qty'] . '</b> x <b>' . $order->products[$i]['name'] . '</b>  = ' . $currencies->display_price($order->products[$i]['final_price'], $order->products[$i]['tax'], $order->products[$i]['qty']) . $products_ordered_attributes . "\n";
    }

  // lets start with the email confirmation
    $email_order = STORE_NAME . "\n" .
                   EMAIL_SEPARATOR . "\n" .
                   EMAIL_TEXT_ORDER_NUMBER . ' ' . $insert_id . "\n" .
                   EMAIL_TEXT_INVOICE_URL . ' ' . tep_href_link(FILENAME_ACCOUNT_HISTORY_INFO, 'order_id=' . $insert_id, 'SSL', false) . "\n" .
                   EMAIL_TEXT_DATE_ORDERED . ' ' . strftime(DATE_FORMAT_LONG) . "\n\n";
    if ($order->info['comments']) {
      $email_order .= tep_db_output($order->info['comments']) . "\n\n";
    }
    $email_order .= EMAIL_TEXT_PRODUCTS . "\n" .
                    EMAIL_SEPARATOR . "\n" .
                    $products_ordered .
                    EMAIL_SEPARATOR . "\n";

    for ($i=0, $n=sizeof($order_totals); $i<$n; $i++) {
      $email_order .= strip_tags($order_totals[$i]['title']) . ' ' . strip_tags($order_totals[$i]['text']) . "\n";
    }

    if ($order->content_type != 'virtual') {
      $email_order .= "\n" . EMAIL_TEXT_DELIVERY_ADDRESS . "\n" .
                      EMAIL_SEPARATOR . "\n" .
                      tep_address_label($customer_id, $sendto, 0, '', "\n") . "\n";
    }

    $email_order .= "\n" . EMAIL_TEXT_BILLING_ADDRESS . "\n" .
                    EMAIL_SEPARATOR . "\n" .
                    tep_address_label($customer_id, $billto, 0, '', "\n") . "\n\n";
    if (is_object($$payment)) {
      $email_order .= EMAIL_TEXT_PAYMENT_METHOD . "\n" .
                      EMAIL_SEPARATOR . "\n";
      $payment_class = $$payment;
      $email_order .= $payment_class->title . "\n\n";
      if ($payment_class->email_footer) {
        $email_order .= $payment_class->email_footer . "\n\n";
      }
    }
    tep_mail($order->customer['firstname'] . ' ' . $order->customer['lastname'], $order->customer['email_address'], EMAIL_TEXT_SUBJECT, $email_order, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);

  // send emails to other people
    if (SEND_EXTRA_ORDER_EMAILS_TO != '') {
      tep_mail('', SEND_EXTRA_ORDER_EMAILS_TO, EMAIL_TEXT_SUBJECT, $email_order, STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS);
    }

  // load the after_process function from the payment modules
    $payment_modules->after_process();

    $cart->reset(true);

  // unregister session variables used during checkout
    tep_session_unregister('sendto');
    tep_session_unregister('billto');
    tep_session_unregister('shipping');
    tep_session_unregister('payment');
    tep_session_unregister('comments');
  }
  /*
    Fin de gestion de la commande
  */

  require(DIR_WS_INCLUDES . 'application_bottom.php');
?>
cleo
Bonjour,
Je lis ceci avec grand intérêt parce que nous passons à PayBox.
Il me semble, si je ne me trompe pas qu'il y a 2 solutions pour exploiter l'URL Retour ???

Je ne sais pas si j'ai bien compris.

1. Voici la solution proposer par bshop. Merci de le lire--il l'explique mieux que moi.
Je resume quelques points pertinents :
Bshop propose signaler l'url de retour à PayBox (pas dans le code mais leur signaler réèllement) bien comme http://www.monsite.com/checkout_process.php
ET de passer l'osc session ID dans PBX_CMD et PBX_RETOUR :
Dans catalog/includes/modules/payment/paybox.php,
CODE
tep_draw_hidden_field('PBX_CMD', tep_session_id()) .

CODE
tep_draw_hidden_field('PBX_RETOUR', tep_session_name().':R;trans:T;auto:A;tarif:M;abonnement:B;pays:Y;erreur:E') .


EN PLUS il faut changer PBX_EFFECTUE à plutôt checkout_success.php (mais pas avec la boutique de test) :

le cas de vrai compte :
CODE
tep_draw_hidden_field('PBX_EFFECTUE', tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL', false)) .

le cas de boutique de test :
CODE
tep_draw_hidden_field('PBX_EFFECTUE', tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL', false)) .


2. raph propose également de signaler http://www.monsite.com/checkout_process.php
mais avec une re-écriture de checkout_process.php, parce que PayxBox ne veut pas de url de retour qui redirecte.

Alors la grande question :
La solution bShop, elimine-t-il la nécissité de ré-ecrire checkout_process.php ?
Ca sera chic et bien la solution plus simple.

J'ai testé le code de bshop dans la boutique de test (PBX_EFFECTUE à FILENAME_CHECKOUT_PROCCESS). Tout va bien. Mais cela ne test pas le url de retour. Désolée--on aura le vrai compte pour le 1 juillet.

Merci pour vos lumières.
-i.
Je poste le code de bshop dans le prochain si je peux. Ce long poste m'est refusé par ma stupide machine fedora core 3.
cleo
Bon, rien à faire. Il faudra le lire à son emplacement original. J'ai une page blanche pour un long poste.
-i.
cleo
Désolée il semble que c'est déjà ce qu'a essayé Mateo.
Je n'ai pas compris au départ. rolleyes.gif
-i.
cleo
Forcing des cookies ok pour paybox url retour ?

Bonjour,
J'ai essayé le script de Raph (tel quel il me donnait une page blanche donc je l'ai modifé--c'est une autre histoire) mais j'ai toujours un email :

WARNING: Impossible de joindre https://www.mapetiteboutique.fr/checkout_process.php pour le paiement osCsid=4a4bff391a4f02b608784a887585f65a&trans=627617751&auto=XXXXXX&tarif=842&abonnement=0&erreur=00000 (302-0)


Je suppose que le (302-0) est l'erreur signalé par Mateo (redirection interdit).

Je me demande si le forcing les cookies empèche le retour serveur à serveur (url retour) de fonctionner. Vos idées ?
Cela sera le cas semble-t-il pour atos :
http://www.oscommerce-fr.info/forum/index....st&p=239926

Si jamais il marche avec l'url retour mon checkout_payment.php je le mettrai ici.
-i
cleo
Bonjour,
Ca ne marche pas encore...mais mieux. La commande est au faite enregistrée. On dirait que le url de retour a fonctionné malgré cet email :
CITATION
WARNING: Impossible de joindre https://www.boutique.fr/checkout_process.php pour le paiement osCsid=ceb704b8316593c5625bf03fdd38fd12&trans=627663242&auto=XXXXXX&tarif=758&abonnement=0&erreur=00000 (302-0)

Paybox confirme que 302 ci-dessus veut dire pas de redirections. Apparament j'en ai toujours...
CITATION
Le code 302 signifie que nous n'acceptons pas les redirection sur l'url de retour http.

Je peux me tromper mais je ne comprenais pas le script de raph tel quel.
D'abord, voici les changements que j'ai apporté au script de raph :


1. Déjà, changer tous les noms de les variable en IBS* à PBX*.

2. Changer
CODE
   /*
      Et c'est donc ici que se fait la gestion de la commande...
    */

    include(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CHECKOUT_PROCESS);

à
CODE
   /*
      Et c'est donc ici que se fait la gestion de la commande...
    */
    }
    include(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CHECKOUT_PROCESS);

Si non, aucune commande se faisait ni chèque ni virement et j'ai eu une page blanche.
3. Changer
CODE
/*
    Fin de gestion de la commande
  */

   require(DIR_WS_INCLUDES . 'application_bottom.php');
à

CODE
/*
    Fin de gestion de la commande
  */
   if ($mustRedirect){
      tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));
   }
   require(DIR_WS_INCLUDES . 'application_bottom.php');

Pour montrer quand même checkout success.
C'était bizarre de ne pas s'en servir de $mustRedirect après s'est donnée la peine de le renseigner.

Finalement, j'avait fait comme bshop avec :
CITATION
tep_draw_hidden_field('PBX_CMD', tep_session_id()) .

dans includes/modules/payment/paybox.php

Donc dans le code de raph, ça simplifie
CODE
  /*
       Les 3 lignes ci dessous sont spécifique à mon site, vous devez les modifier
       en fonction de l'endroit où l'osCid se trouve dans les paramètres de l'url retour.
       Vous constatez que pour moi il s'agit du paramètre IBS_CMD, qui a pour valeur
       une chaine de caractère séparé par des pipes (|), et l'osCid se trouve juste après
       le 3ème pipe.
    */
    $ibsCMD = $_GET["IBS_CMD"];
    $t_ibsCMD = explode("|", $ibsCMD);
    $myOsCid = $t_ibsCMD[3];

à
CODE
   /*
       PBX_CMD doit contenir le oscid
    */
    $myOsCid = $_GET["PBX_CMD"];


Bon ça ne marche pas encore. Comment faire du vrai debugging ? Il me manque un environnement.

Autre chose--si quelqu'un peut avoir un avis sur la compabilité de cette démarche avec le forcing des cookies ça sera très utile. J'ai enlévé mes forcing des cookies mais j'ai un bug aléatoire sans cookies (perte de session). Pour ce dernier test le forcing était à False.

-i.
cleo
tests :
1.
a. pas de forcing cookies
b. redirection dans checkout_process.php (vers checkout_success.php) en bas de page mise en commentaire

Résultat : pas d'erreur dans le mail, la commande a passé
smile.gif

2.
a. pas de forcing des cookies
b. remis la redirection (nécessaire pour accepter les cheques, virements, etc.)

Résultat : erreur de redirection dans le mail, la commande a passé
Conclusion : bug sur le renseignement de la variable $mustRedirect

3.
a. remis le forcing des cookies
b. redirection en place

Résultat : La commande n'a pas passé. Erreur de redirection.

A noter : avec forcing de cookies, il y a la redirection vers cookie_usage.php, et avec une perte de session il y a la redirection vers login.

Aujourd'hui j'abandonne en faveur de la solution simple : pas de retour url. Sauf si quelqu'un aura un avis sur ceci.
-i.
cleo
J'arrête ! Mais voici ce que j'ai appris si quelqu'un est motivé.

Bonjour,
J'abandonne mais ça marche--mais pas à 100%, (manque de ma compétence en php).
Je reste pour l'instant avec la solution classique.

Pour rappel je résume de quoi on parle :
Une solution pour enregistrer une commande
  1. malgré une coupure de connexion internet
  2. ou bien malgré une action tempestueuse d'un internaute de fermer sa fenêtre
arrow.gif Plus aucune commande perdue.


Pertinence : Il me semble que c'est de plus en plus rare de perdre les connexions internet et le retour à la boutique est rapide. Donc ceci reste vraiment un plus et pas du tout obligé.


Il faut bien sûr que le prestataire de paiement en ligne fournisse cette possibilité. PayBox l'appelle l' URL HTTP :
V -- LES URLS DE RETOUR ET « L'URL HTTP » ::
Une fois le paiement réalisé sur la page de paiement Paybox, le client a la possibilité de revenir sur le site commerçant par l'intermédiaire de 3 urls.
Le commerçant pourra gérer de façon automatique la validation de ses bons de commandes suivant le résultat de la transaction par l'intermédiaire d'une 4ème url nommée « url http ».


Si quelqu'un est motivé voici ce qui j'ai appris et une suggestion d'approche, mais je ne suis pas compétente pour le débugger.

Les points clés :
  1. Pour qu'un appel serveur à serveur enregistre une commande, il faut qu'il trouve la bonne.
  2. Cela peut être fait par une restauration de la session.
  3. La session peut être fourni dans une variable de la solution de paiement (comme PBX_CMD, utilisé par bshop) et il peut être retourné ainsi. Il peut également être retourné dans le'URL. Voire les deux.
Simple, non ?

Ce que j'ai fait (qui marchait même avec forcing des cookies), mais pas à 100% des essaies et là je ne suis plus compétente.

Pour simplifier et ne plus être obligé faire une tonne de cas pour décider s'il s'agit du retour serveur ou pas, j'ai copié checkout_process.php à checkout_process_server_return.php et c'est celui là que j'ai précisé à PayBox.
Dans ce nouveau script, j'ai enlevé tout ce qui était redirection pour l'internaute (le haut et le bas). (Je suggère plutôt d'exploiter require pour pouvoir maintenir le code dans l'avenir.)

J'ai utilisé la méthode décrit par Raph pour restaurer la session (mais sans comprendre les détails) et la méthode de bshop de stocker dans PBX_CMD uniquement la session (qui simplifie donc le code de Raph).

Et ça marche. Mais pas tout le temps et là, je ne peux pas continuer.

Si quelque d'autre veut le faire, je suggère qu'il faut savoir débugger un script avec un vrai outil (chose que je n'ai pas) pour bien suivre le retour du serveur et les valeurs des variables.


Bon code,
-i.
Gnidhal
Peut-être devrais-tu t'inspirer de ce que fait le module du CIC avec son cmcic_response.php.
C'est exactement cette méthode qui est exploitée. Il ne reste plus qu'à adapter à tes besoins.
Cela dit si tu arrives à un résultat pertinent, je veux bien essayer de pousser un peu mais je manque de temps en ce moment wink.gif
cleo
Merci Gnidhal.
Je suis alors très confortée dans la démarche. Je regarderais ça en août. (Petite soeur+moi + les 2 maris==>Italie). Ca ma première vacance depuis cette sacré aventure de commerce en ligne, debut 2005.
-i.
Delaballe
J'ai mit a disposition un nouveau module paybox avec un fichier response_paybox.php, qui gére les URL de retour !

arrow.gif http://www.oscommerce.com/community/contributions,5346
Gnidhal
Excellent ! Merci Delaballe !

Juste une petite précision aux utilisateurs, le script est en UTF-8 ce qui méritera une petite conversion si votre site est ISO-8859-1 wink.gif
Delaballe
En principe ISO OU UTF8 ne devrait avoir aucun incident car c'est juste une page blanche qui s'affiche !
cleo
Bonjour,
Merci Delaballe !
J'ai fait une tentative. (J'ai du merger quelques lignes de mon checkout_process.php modifié dans response_paybox.php mais je l'ai fait soignieusement, enfin j'éspère.)

En production, j'ai l'email (très bien, bravo pour les emails d'erreurs):

CITATION
Erreur sur la boutique : La session n'a plus ªtre ouverte ! elle est inexistante ou bien elle a expir©e

CECI EST UN MESSAGE AUTOMATIQUE, MERCI DE NE PAS REPONDRE.


Donc je conclus que l'on n'a pas pu restaurer la session.
Comment proceder pour debugger cela ?
(Pour les caractères, ça je saurais corriger.)
-i

Ajout : Dans une version par quelqu'un d'autre il y avait
CODE
tep_session_id($myOsCid);
tep_session_start();


Ce n'est pas nécessaire ?

C'est dans application_top.php.
blush.gif
Delaballe
CITATION(IndiaStarker @ 11 Aug 2007, 21:21) [snapback]246566[/snapback]
En production, j'ai l'email (très bien, bravo pour les emails d'erreurs):

CITATION
Erreur sur la boutique : La session n'a plus ªtre ouverte ! elle est inexistante ou bien elle a expir©e

CECI EST UN MESSAGE AUTOMATIQUE, MERCI DE NE PAS REPONDRE.


Donc je conclu que l'on n'a pas pu restaurer la session.
Comment proceder pour debugger cela ?


arrow.gif Tu as eu cette erreur, mais est ce que tu as juste essayé d'ouvrir la page response_paybox.php via ton navigateur ou as tu réellement effectué un paiement via la banque ?

CITATION(IndiaStarker @ 11 Aug 2007, 21:21) [snapback]246566[/snapback]
Ajout : Dans une version par quelqu'un d'autre il y avait
CODE
tep_session_id($myOsCid);
tep_session_start();


Ce n'est pas nécessaire ?


arrow.gif Ceci est géré par le fichier application_top.php qui est appelé en ligne 23 du fichier response_paybox.php
cleo
Bonsoir,
J'ai réèllement fait un paiement par la banque. Pourquoi ?
J'ai besoin d'une méthodologie pour débugger.
(Nous nous sommes croisé pour applications_top. J'ai vu après coup. Merci beaucoup quand même pour la réponse !)
-i

p.s. D'ailleurs, si j'avais juste collé l'adresse j'aurais peut-être eu ton email :
CITATION
Erreur sur la boutique : Le num©ro d'IP suivant essay© de ce connecter sur le fichier de validation de commande du module paybox alors qu'il n'en a pas l'autorisation. : 192.168.1.4

CECI EST UN MESSAGE AUTOMATIQUE, MERCI DE NE PAS REPONDRE.

smile.gif
Delaballe
C'est exact tu aurais eu cet e-mail sauf si tu avais mit ton adresse IP dans le module...

Mais la si je comprends bien, tu n'a pas installé le module bancaire en entier que j'ai mit à disposition mais tu essaye de déboguer ta version que tu as fait dans le fichier checkout_process.php ?

Ou alors j'ai pas trop compris, dans ce cas essaye de bien m'expliquer avec méthodologie tes différentes erreurs et procédure !
cleo
CITATION(Delaballe @ 11 Aug 2007, 23:17) [snapback]246580[/snapback]
Mais la si je comprends bien, tu n'a pas installé le module bancaire en entier que j'ai mit à disposition mais tu essaye de déboguer ta version que tu as fait dans le fichier checkout_process.php ?

Non j'ai installé ta contribution en entier.
(J'indiquais juste que je l'ai installé manuellement, vu que mes fichiers sont modifié--j'ai aussi paybox échéances par exemple.)
-i.
cleo
Pour être sûr que je n'ai pas créé de bug, je vais essayer ton paybox_response.php tel quel.
Même punition :
CITATION
Erreur sur la boutique : La session n'a plus ªtre ouverte ! elle est inexistante ou bien elle a expir©e

CECI EST UN MESSAGE AUTOMATIQUE, MERCI DE NE PAS REPONDRE.

-i
Delaballe
Comment ta boutique est configuré dans le menu "configuration --> session"
cleo
Titre Valeur Action
Répertoire des sessions /tmp
Utilisation de force des cookies True
Vérifiez l'identification de session False
Vérifiez l'utilisateur False
Vérifiez l'adresse IP False
Empêchez les sessions d'araignée True
Recréez une session True

**********************************
Hmmm...recréez une session--c'est suspect ?
**********************************
Merci aussi pour la très pratique, "Mode Production ou Test" que je n'ai que remettre en test pour que la boutique tourne comme avant sans déinstaller ta contrib. Peut-être un autre nom sera plus clair, "Commande par retour serveur ou retour navigateur". Ou peut-être pas...
-i
cleo
Je viens d'essayer un achat avec Recréer une session à FALSE mais c'est pareil.
(Bonne nuit j'ai sommeil...)
-i
Delaballe
J'ai contrôlé sur la boutique en production qui a le module en fonctionnement et tout est sur False (dont Recréez une session).

Peux tu également ajouter à la fin de du fichier response_paybox.php cette ligne afin que tu puisses recevoir par mail l'URL de la banque afin de voir un peu la forme qu'elle a : (Ne pas oublier de changer TON_ADRESSE_MAIL@DOMAINE.COM par ton adresse e-mail)

CODE
tep_mail('', 'TON_ADRESSE_MAIL@DOMAINE.COM', E_TRANSACTION_MAIL_ERREUR_SUBJECT . ' ' . MODULE_PAYMENT_PAYBOX_NAME_BANK, $HTTP_SERVER_VARS["REQUEST_URI"] . "\n\n" . E_TRANSACTION_MAIL_ERREUR_FOOTER, STORE_NAME, STORE_OWNER_EMAIL_ADDRESS);



cleo
CITATION(Delaballe @ 12 Aug 2007, 01:35) [snapback]246590[/snapback]
CODE
tep_mail('', 'TON_ADRESSE_MAIL@DOMAINE.COM', E_TRANSACTION_MAIL_ERREUR_SUBJECT . ' ' . MODULE_PAYMENT_PAYBOX_NAME_BANK, $HTTP_SERVER_VARS["REQUEST_URI"] . "\n\n" . E_TRANSACTION_MAIL_ERREUR_FOOTER, STORE_NAME, STORE_OWNER_EMAIL_ADDRESS);

Super idée. Résultat :
email :
/checkout_process_server_return.php?osCsid=9fe12561349c5aeeb12a7c8723fb1c45&trans=102108984&auto=748321&tarif=1982&abonnement=0&pays=FRA&erreur=00000

CECI EST UN MESSAGE AUTOMATIQUE, MERCI DE NE PAS REPONDRE.


(Le ficher de retour spécifié à paybox support était checkout_process_server_return.php.)
début de ticket PayBox :
Ref commande:9fe12561349c5aeeb12a7c8723fb1c45



CARTE BANCAIRE

le 12/08/2007 à 09:40


Variables de sessions toujours comme posté ci-dessus.
-i
cleo
Résumé : La contrib de Delaballe marche très bien quand Force cookies = False

Si c'est le cas géneral, il faut mettre cela dans installation.txt.

Détails :

J'ai essayé de nouveau avec ces variables de sessions et ça marche :

Répertoire des sessions /tmp
Utilisation de force des cookies False
Vérifiez l'identification de session False
Vérifiez l'utilisateur False Info
Vérifiez l'adresse IP False Info
Empêchez les sessions d'araignée True
Recréez une session True

Malheureusement j'ai trouvé un cas dans ma boutique qui se répète à chaque fois de perte de session si je mets le forcing des cookies à False. Donc je ne peux pas utiliser le retour serveur. C'est un peu dommage.

Coté positive, j'ai n'ai perdu aucune commande depuis l'installation de PayBox debut juillet, même si la validation de la commande chez moi est par le navigateur.
(If it ain't broke, don't fix it ?)


Sur le sujet de cookies et session, j'ai finalement trouvé une doc sur oscommerce.com : http://www.oscommerce.info/kb/osCommerce/D...plementations/4

Merci Delaballe pour tout ton aide.
Conclusion tentative: il faut ne pas forcer les cookies pour exploiter une confirmation de commande serveur à serveur dans oscommerce.

-i
cleo
idée : Peut-être il y a moyen de mettre forcing des cookies à FALSE uniquement pour le serveur paybox mais pas pour les internautes ?
cleo
Je conseille vivement cette contribution. Mais il semble que l'on peut passer un panier en commande par le serveur (PayBox ou autre) uniquement pour le cas ou les cookies ne sont pas forcés.
Si vous avez PayBox Echéances, il y a des modifs bien sûr en plus à faire dans checkout_process.php et response_paybox.php.
Vous pouvez néansmoins installer cette contrib comme votre contrib PayBox principal. Il suffit de laisser la confirmation de commande en test (ou si vous aimez mon changement de doc ci dessous, ça s'appelera confirmation commande par le Navigateur).

Détails si vous forcez les cookies.
Il suffit de garder le mode en Test et remplacer le fichier response_paybox par un fichier qui ne fait rien.

chez moi :
Coté documentation, j'ai changé mon interface (dans includes/modules/payment/paybox.php) pour lire comme ça (ou cas où en 6 mois j'aurais oublié ce que voulais dire Test et Production) :


catalog/includes/modules/payment/paybox.php
CODE
if (MODULE_PAYMENT_PAYBOX_PRODUCTION == 'Serveur') {
        define('PBX_PAYBOX_EFFECTUE', tep_href_link(FILENAME_CHECKOUT_SUCCESS, 'pbx=1&' . tep_session_name().'='. tep_session_id(), 'SSL', false));
      } else {
        define('PBX_PAYBOX_EFFECTUE', tep_href_link(FILENAME_CHECKOUT_PROCESS, 'pbx=1&' . tep_session_name().'='. tep_session_id(), 'SSL', false));
      }

et
CODE
tep_db_query("insert into " . TABLE_CONFIGURATION . " (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) values ('Mode confirmation commande Navigateur ou Serveur', 'MODULE_PAYMENT_PAYBOX_PRODUCTION', 'Navigateur', 'Vous pouvez activer le mode Serveur seulement si vous avez fournit à la banque l\'URL de retour qui permettra de valider les commandes.<br><br><u>Exemple d\'URL retour</u> : http://www.maboutique.com/response_paybox.php', '6', '2', 'tep_cfg_select_option(array(\'Navigateur\', \'Serveur\'), ', now())");


J'ai remplacé mon fichier pour le retour server avec ce fichier quasi vide. Comme ça je n'ai pas à contacter paybox services.
catalog/response_paybox.php :
CODE
<?php
/*

  $Id: response_paybox.php
  stub à remplacer quand boutique peut tourner sans cookies

*/
//stub
?>
-i
Delaballe
CITATION(IndiaStarker @ 12 Aug 2007, 11:55) [snapback]246609[/snapback]
Je conseille vivement cette contribution. Mais il semble que l'on peut passer un panier en commande par le serveur (PayBox ou autre) uniquement pour le cas ou les cookies ne sont pas forcés.


Ce qui me semble une certaine logique, car les serveurs PayBox n'accepte forcement pas les cookies pour des mesures de sécurités.

Mais des solutions peuvent être trouvé pour utilisé de force les cookies dans le site et ne pas les utiliser de force pour les réponses serveur de banque.
moamatt
hello,

je viens de lire tout le fil de la conversation, j'ai installé le module à peu près sans problemes.

Tout fonctionne sauf si je ferme le navigateur dès la fin du paiement, sans revenir à la boutique.
alors le paiement est enregistré (normal) mais la commande n'est pas enregistrée dans la boutique, le panier ne se vide pas non plus.

J'ai placé le fichier response_paybox.php que j'ai trouvé ici
j'ai envoyé le lien vers ce fichier à e.transaction (hotline du crédit agricol)

Je pense que le probleme ne peut venir que de ce fichier.

Je précise simplement que je suis sous OScss et que j'ai précédemment installé le module ATOS (du meme crédit agricol) mais qui dispose de moins d'option en back office.

Quelqu'un parmi vous a t'il été confronté au meme soucis? a t'il (ou elle) des éléments de réponse?

d'avance merci smile.gif
Delaballe
Je regrette mais le lien que tu nous donne sur la contribution qui date du 10 Août 2007 ne contient pas de fichier response_paybox.php
moamatt
autant pour moi, la fatigue surement,
en fait, le fichier response_paybox vient ... de ta contribution ! (d'ailleurs merci!)


edit : est-ce que tout fonctionne pour toi ou y a t'il le meme probleme?
Delaballe
Plusieurs choses....

1 - As tu bien mis la contribution que je fournit (version 1.2), ou à tu juste ajouté le fichier responses_paybox.php avec une autre contribution comme celle que tu as plus citer plus haut ?

2 - Est ce que tu as bien mit en false le forcing des cookies ?

3 - Est ce que le fichier includes/application_top.php à reçue des modifications sur OScss par rapport à une MS2 ?

4 - As tu reçue confirmation de la banque qu'ils avait bien mit en place sur leurs serveurs l'URL de retour vers ton fichier ?

5 - Est ce que tu reçois un e-mail lorsque tu essaye d'atteindre toi même le fichier response_paybox.php avec ton navigateur (exemple : http://mondomaine.com/reponse_paybox.php)

6 - As tu bien les bons IP du serveur de réponse de paybox d'entrée dans le module (voir documentation fournit par ta banque)

moamatt
CITATION(Delaballe @ 30 Aug 2007, 17:15) [snapback]249522[/snapback]
Plusieurs choses....

1 - As tu bien mis la contribution que je fournit (version 1.2), ou à tu juste ajouté le fichier responses_paybox.php avec une autre contribution comme celle que tu as plus citer plus haut ?

2 - Est ce que tu as bien mit en false le forcing des cookies ?

3 - Est ce que le fichier includes/application_top.php à reçue des modifications sur OScss par rapport à une MS2 ?

4 - As tu reçue confirmation de la banque qu'ils avait bien mit en place sur leurs serveurs l'URL de retour vers ton fichier ?

5 - Est ce que tu reçois un e-mail lorsque tu essaye d'atteindre toi même le fichier response_paybox.php avec ton navigateur (exemple : http://mondomaine.com/reponse_paybox.php)

6 - As tu bien les bons IP du serveur de réponse de paybox d'entrée dans le module (voir documentation fournit par ta banque)


salut,
d'abord : merci !

ensuite : 1 - non hier, mais ce matin, je viens de déinstaller l'autre module et là je viens de réinstaller intégralement le tiens.

2 - oui, c'est sur false

3 - Pour etre franc je ne n'en sais rien, mais je ne pense pas qu'il soit différent.

4 - Oui, j'ai eu un mail de la banque pour me dire que c'est ok pour le fichier.

5 - oui, il envoi un mail pour dire que l'IP de connexion n'est pas authorisée.

6 - normalement oui, je suis aussi au crédit agricole, donc à priori c'est bon.

...

encore merci !

edit : c'est bon, un pb de réglé, j'ai coché true pour pouvoir l'utiliser... c'est mieux ! reste que j'ai une erreur en ligne 71, mais je cherche...
moamatt
voila, le pb de la ligne 71 est réglé, c'est une fonction qui n'existe plus dans oscss, le "tep_draw_separator" est remplacé par des règles css...

maintenant j'ai un mail qui m'annonce :

CITATION
-- Erreur sur la boutique : Le numéro d'IP suivant à essayé de ce connecter sur le fichier de validation de commande du module paybox alors qu'il en a pas l'autorisation. : 10.100.11.101

-- Erreur sur la boutique : La session n'a plus être ouverte ! elle est inexistante ou bien elle a expirée

CECI EST UN MESSAGE AUTOMATIQUE, MERCI DE NE PAS REPONDRE.


je vais vérifier l'IP de la banque histoire de voir si elle est bien authorisée... et je vais voir dans le code ce qu'il en est de la session (et relire au passage ce topic fort intéressant!)

edit : les IP sont conformes à la doc de e.transactions ... alors je vois pas d'où vient ce 10.100.11.101
moamatt
pour éliminer (au moins temporairement) le message d'erreur numéro 2, cad le probleme de session, j'ai changé la ligne 26 de response_paybox par

CODE
$session_registered = 'true';


au lieu de false...
Est-ce grave point de vue sécurité? en fait je lui dit de croire que la session est ok peut importe le résultat du test.

puis-je faire la meme chose pour le test d'ip?

est-ce qu'il y a un risque et lequel?

je continue de chercher mais si il y a des réponses, je suis preneur !

edit : en fait maintenant, avec ou sans les modifs que j'énonce avant, en suivant le processus complet de commande, avec retour à la boutique après paeiment, mon panier ne se vide pas et la commande n'est pas enregistrée... je fait une pause là, c'est prise de tete !
cleo
CITATION(moamatt @ 31 Aug 2007, 09:04) [snapback]249578[/snapback]
.. j'ai changé la ligne 26 de response_paybox par

CODE
$session_registered = 'true';


au lieu de false...
Est-ce grave point de vue sécurité? en fait je lui dit de croire que la session est ok peut importe le résultat du test.
...


Je ne suis pas sûre de maîtriser les sessions mais je pense que si tu fais cela osc ne saura pas quel panier a été payé ! shock.gif
-i
moamatt
ça doit etre pour ça qu'il m'enregistre dans l'admin une commande .... vide !

je continue de chercher...
moamatt
bon, j'ai fait une bonne sieste, j'ai les yeux ouverts cet aprem, je m'y remet donc :

si je résume bien, j'ai placé les 4 fichiers (response_paybox, paybox dans modul et les 2 paybox pour les langues EN et FR)
j'ai cliqué sur installer dans l'admin, j'ai meme vérifié dans la base et les données sont bien inscrites.
edit : j'ai mis mes références clients dans les 3 champs de l'admin, précisé le fichier CGI, je suis en mode production. J'ai testé aussi en test et j'ai croisé ces tests avec et sans forçage des sessions. autrement dit je suis à bout de solution...

je fait ma commande, je valide et à la fin, après la confirmation de commande, le processus m'envoi vers le serveur paybox et là, c'est le drame...

CITATION
Incohérence des paramètres.
Accès refusé !


avec un joli bouton de retour à la boutique.

d'où ça vient?

meme avec la contrib que j'ai essayé hier et qui fonctionner sauf en cas de déconnexion avant le retour, meme topo, elle veut pas acceder au paiement !!!

aidez moi s'il vous plait ! blush.gif

EDIT 2 : a priori il y aurait un probleme coté e.transaction ! ça ne viendrais pas de chez moi et j'ai donc perdu 1 journée ! cool !
cleo
Bonjour moamatt,
Tant mieux si le problème est ailleurs. Néanmoins, 2 choses utiles dans ce thread :
1. plus d'info dans un email pour toi (suggestion de delaballe) :
CITATION(Delaballe @ 12 Aug 2007, 01:35) [snapback]246590[/snapback]
Ajouter à la fin de du fichier response_paybox.php cette ligne afin que tu puisses recevoir par mail l'URL de la banque afin de voir un peu la forme qu'elle a : (Ne pas oublier de changer TON_ADRESSE_MAIL@DOMAINE.COM par ton adresse e-mail)

CODE
tep_mail('', 'TON_ADRESSE_MAIL@DOMAINE.COM', E_TRANSACTION_MAIL_ERREUR_SUBJECT . ' ' . MODULE_PAYMENT_PAYBOX_NAME_BANK, $HTTP_SERVER_VARS["REQUEST_URI"] . "\n\n" . E_TRANSACTION_MAIL_ERREUR_FOOTER, STORE_NAME, STORE_OWNER_EMAIL_ADDRESS);


2. Vérifier que la confirmation par le navigateur (le cas plus simple) marche==>il suffit de cocher Test dans l'admin.
Pour garder la confirmation paiement par le navigateur en definitive, on peut :
CITATION(IndiaStarker @ 12 Aug 2007, 11:55) [snapback]246609[/snapback]
...remplacer le fichier response_paybox par un fichier qui ne fait rien.

catalog/response_paybox.php :
CODE
<?php
/*

  $Id: response_paybox.php
  stub à remplacer quand boutique peut tourner sans cookies

*/
//stub
?>


-i.
moamatt
Merci IndiaStarker,

pour l'instant, tes 2 solutions sont impossibles : je ne peux meme pas entrer le numéro de CB, au lieu de ça il me balance le message "incohérence des parametres".

Le "problème" c'est que chez e.transactions ils ont aussi ce message, ce qui leur fait dire que ça vient de chez eux...

donc pour l'instant, attendre qu'ils réagissent et réparent ce soucis, ensuite, je pourrait me pencher sur mes problemes...

Ta solution perso est donc de se passer de l'url auto réponse, donc, faire confiance au visiteur pour qu'il retourne sur le site à la fin de la transaction.

Depuis combien de temps tourne ta boutique, combien as tu eu de transaction et combien y a t'il eu de litiges dus à ce système? (s'il y en a eu!)

Merci

edit : ça y est, paybox m'a réparé le système. donc ça fonctionne mais sans retour d'url Http... faut faire confiance aux visiteurs... mais mes questions pour toi IndiaStarker restent valables rolleyes.gif
C4N4rD
Je viens de lire attentivement tout vos posts. Visiblement il y a un réel soucis avec PayBox et je fsuis rassuré d'avoir trouver ce post.

Pour ma pars j'ai instalé du Paybox sur une plateforme zen-cart, aprés plusieurs mois de prod, le 11 septembre mon client me signale qu'une commande enregistrée sur PayBox n'a pas été enregistrée sur le BackOffice de son site.

Aprés étude du problème je me suis rendu compte que chaque coupon était accompagné de l'envois d'un mail WARNING avec pour erreur: "impossible de joindre url://../checkout_process.php pour le paiement ...". Mais que les commande passaient malgré tout, sauf une!

Auriez vous une explication à me fournir pour le fait qu'une commande ait disparue ne soit arrivé qu'une fois?
En effet, aprés avoir repéré le problème nous avons effectué des test de commande et tout fonctionne "parfaitement" (à pars le 302).

En ésperant avoir été assez claire je vous remercie d'avance smile.gif
cleo
CITATION(moamatt @ 3 Sep 2007, 07:09) [snapback]249814[/snapback]
...
Ta solution perso est donc de se passer de l'url auto réponse, donc, faire confiance au visiteur pour qu'il retourne sur le site à la fin de la transaction.
Depuis combien de temps tourne ta boutique, combien as tu eu de transaction et combien y a t'il eu de litiges dus à ce système? (s'il y en a eu!)
... mais mes questions pour toi IndiaStarker restent valables rolleyes.gif

Réponse (un peu tardif faut dire) : PayBox depuis juillet 2007 (très content).
Retour par le navigateur et un seul non-retour et il y a longtemps. Je ne sais pas combien de txn wink.gif Dison que nous sommes à bien moins que 1% de problèmes de ce genre.
-i
Tom Pillibi
Bonjour,

Je relance le sujet car on a un vrai problème avec Paybox.

J'avais installé des contrib "simples" qui faisait le retour après le paiement sur "checkout_process.php"

Mais la commande ne s'enregistrait pas (alors que le paiement est débité au client bien sur).

J'ai pensé que la contrib avait un problème j'ai donc enlevé l'ancienne et remplacée par celle de Delaballe (merci).

Mais j'ai toujours le même problème, la commande ne s'enregistre pas dans l'admin.

les paramètres d'admin signalés dans ce post sont ok (par exemple forçage cookies sur false etc)

Chez paybox nous avons bien demandé le retour vers response_paybox.php.
Leur réponse est la suivante :

Citation
Sur l’application, nous avons 4 urls.

Url de paiement effectué

Url de paiement annulé

Url de paiement refusé

Url de retour http



L’url que vous nous avez communiqué a été mise en place sur les 3 premières.

Sur cette url, (la quatrième) qui contact votre serveur directement quelque soit l’action de l’internaute (cf documentation), il n’y a rien de paramétré actuellement.


Quelqu'un peut-il nous aider, je pense notamment aux personnes qui avaient le même problème que nous et l'ont résolu.

Merci beaucoup.
cleo
Bonjour,
Citation (Tom Pillibi @ 5 Jul 2008, 09:29) *
Quelqu'un peut-il nous aider, je pense notamment aux personnes qui avaient le même problème que nous et l'ont résolu.

Ben je n'ai jamais eu ces problèmes avec PayBox--peut-être je ne devrais pas répondre ;-D
D'abords j'avoue que je n'ai pas regardé la contribe de Delaballe depuis l'année dernière donc merci de vérifier mes propos.

Résumé selon ma mémoire :
Retour par le navigateur = retour sur la page checkout_process.php, qui est la page (par défaut) qui passe le panier en commande.
Ceci est appelé mode Test dans la contribe de Delaballe.
(Je l'ai renommé chez moi retour par le navigateur).

Retour serveur à serveur est ce que PayBox appelle le retour http. Pour PayBox il faut par contre que la page ne soit pas checkout_process.php parce cela fait un redirect vers checkout_sucess.php et PayBox ne souhaite pas de redirects--donc l'utilité du fichier reponse_paybox.php élaboré par Delaballe.
Il y a par contre TOUJOURS un retour par le navigateur, mais pour ne pas créer la commande en double il faut éviter le retour vers checkout_process.php qui fera encore une commande. La solution proposée est de faire le retour par le navigateur à checkout_success.php (variable PBX_EFFECTUE) parce que l'achat est déjà confirmé par l'appel serveur à serveur.
Recap :
Donc dans la contribe de Delaballe, PBX_EFFECTUE sera checkout_process.php pour le mode test (commande confirmé par le retour par le navigateur). (Chez nous, nous restons dans ce mode parce que le retour par le navigateur nous convient.)

Pour le mode production (cookies non forcés), la commande sera confirmé par le retour url http que vous avez fourni à PayBox : reponse_paybox.php.
PBX_EFFECTUE sera par contre dégradé à checkout_success.php


@Tom :
==> PayBox marchait-t-il déjà avec le module de test (pas production) fourni par PayBox? (Il vaut mieux tenter les choses simple avant de compliquer des choses).

Qui se passe t-il après paiement ?
D'autre systèmes de paiement marche-t-il ?
Peux-tu déjà faire un achat dans cette boutique ?

Mets en place les infos supplémentaires email qu'a suggéré d'autres dans ce thread.

Je ne suis pas sur d'avoir compris. Peux tu afficher les lignes dans catalog/includes/modules/payment/paybox.php qui commence comme ceci :
Code
tep_draw_hidden_field('PBX_RETOUR', ...
tep_draw_hidden_field('PBX_ANNULE', ...
tep_draw_hidden_field('PBX_REFUSE', ...
tep_draw_hidden_field('PBX_EFFECTUE', ...


A savoir, tu as la main sur ces 3 premiers url de retour et donc n'as rien a signaler à PayBox. (Uniquement pour le 4ième url). Mais tu as dit,
Citation (Tom Pillibi @ 5 Jul 2008, 09:29) *
Chez PayBox nous avons bien demandé le retour vers response_paybox.php.
Leur réponse est la suivante :

Citation
Sur l’application, nous avons 4 urls.
Url de paiement effectué
Url de paiement annulé
Url de paiement refusé
Url de retour http

L’url que vous nous avez communiqué a été mise en place sur les 3 premières.

Sur cette url, (la quatrième) qui contact votre serveur directement quelque soit l’action de l’internaute (cf documentation), il n’y a rien de paramétré actuellement.



En lisant ton poste on dirait que PayBox a mis reponse_paybox.php sur ANNULE REFUSE EFFECTUE et cela m'étonne et je ne pense pas que c'était l'intention de l'auteur. (Je pense que reponse_paybox.php est pour le retour serveur à serveur, ce que PayBox appel retour http.)
____________________________________________________________

Je rappelle à tous que le retour par le navigateur est automatique et l'internaute n'a rien à faire. Il est moins "fiable" en principe que le retour serveur à serveur parce qu'il pâlie le cas d'une fermeture tempestueuse de la fenêtre par l'internaute ou une panne d'internet chez lui au moment de l'achat.
Chose se révèle au fait extrêmement rare, au moins pour nous : Ca tient, comme j'ai dit nous avions un seul cas de non retour depuis l'installation de PayBox en juillet 2007.
Le petit plus : La soluce de Delaballe en serveur à serveur marchait très bien pour nous, mais je reste en mode navigateur parce que je préfère forcer les cookies pour une autre raison qui n'a rien à voir (perte de session très occasionnelle mais réelle et j'ai du arrêter de travailler sur cela.)

Autre chose : En mode navigateur (ce que Delaballe appel mode "Test") il conviendrait peut-être d'enlever le bouton retour à la boutique qui provoque un achat en double si l'internaute clique dessus :
Code
tep_draw_hidden_field('PBX_BOUTPI', 'nul')



@C4N4rD :
Citation
WARNING avec pour erreur: "impossible de joindre url://../checkout_process.php pour le paiement ...". Mais que les commande passaient malgré tout, sauf une!

L'explication peut-être : Le mauvais fichier de retour par http est indiqué à PayBox : checkout_process.php (non modifié)
et/ou cookies sont forcés.
PayBox en mode serveur à serveur ne doit pas tomber sur un fichier qui fait une redirection.
Donc la commande s'effectue par le retour par la navigateur à checkout_process.php (comme chez nous) et comme nous il y avait un seul cas de non retour (sans doute une fermeture de la fenêtre ou perte d'internet au moment de l'achat?)
Si tu veux arrêter les messages "impossible de joindre" une solution sera de demander à PayBox d'enlever ton retour http. Si non, de le changer à un ficher qui ne fait rien (ce que j'ai fait, pour laisser la porte ouverte si jamais j'enlevais le forcing des cookies pour le paiement), soit installer et tester la soluce serveur à serveur sans forcing des cookies. (Je ne le ferais pas pour 1 seul cas mais c'est mieux...)

-i
Tom Pillibi
Merci pour ces explications smile.gif

En fait si j'ai compris ton post, Paybox serait actuellement en retour navigateur et le module de Delaballe serait lui en mode "serveur à serveur".....

Je vais essayer de voir avec Paybox pour changer ce mode, je vous tiens au courant si ça change quelque chose. biggrin.gif
cleo
Actuellement mon conseil est de faire marcher correctement le retour par le navigateur dans un premier temps avant d'embêter PayBox.
Le module de Delaballe marche pour les deux. Mets Test. (Modif: C'est dans l'administration de la boutique)
-i
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'informations, la mise en page et les images, veuillez cliquer ici.
Invision Power Board © 2001-2024 Invision Power Services, Inc.