Flipping the switch from test to live

Hello,
I just wanted to confirm that from the side of eCart the only changes necessary for moving to Live when using Authnet

On the confirm page, simply change the test request to FALSE:

$AuthNet_required[0][$nextIndex] = "x_test_request";
$AuthNet_required[1][$nextIndex] = "FALSE";



Then if not already done turn the checkout page to an httpS target link.
I reviewed this support file but it seemed focused on setting an SSL checkout page during the initial cart creation.
ecart_ssl_ht.php

How about after you have a site created with the wizard in eCart (Latest version of course)?

Is it just a matter of targetting the full URL in SSL from the Form action in the checkout.php page?

I'm going to retest and look for other links that need to point to an SSL (https) absolute secure path but if there are conditions within the eCart framework I should also consider please let me know.

Thanks,

Steve

The single point change (update form action target to absolute SSL URL) worked perfectly for moving the subsequent pages to being in a SSL secure environment.

New issue:
On the confirm page I have two different shipping cost options shown in a select list.
When moving from the default, the following page (display.php) is NOT updated with the selection.

Do I need add an Update button and some additional form processing to recognize a change to the shipping type?

it "looks" as though the new value should submit on change:

<td class="eC_SummaryLabel">Shipping</td>
                        <td>$8.65                        <select name="shipSelect" id="shipSelect" onchange="document.getElementById('checkoutForm').submit()" >
                          <option value="8.65" selected="selected">Ground $8.65</option>
                          <option value="16.93" >2nd Day Air $16.93</option>
                        </select>
                        </td>

Though no update is happening...


Firebug console is stating: " document.getElementById("checkoutForm") is null "

please send a copy of the page so i can see the entire page code.

Originally Said By: Steve272190

  The single point change (update form action target to absolute SSL URL) worked perfectly for moving the subsequent pages to being in a SSL secure environment.  

The above poster mentioned redirecting the form action on the cart page to target an absolute SSL URL for the checkout page and subsequent pages. It appears in the header of my cart page, I have 4 copies of the code for this action.

<?php
//WA eCart Redirect Check Out
if (isset($_POST["eCart1_Checkout"]) || isset($_POST["eCart1_Checkout_x"]))     {
  $Redirect_redirStr="checkout.php";
  if ($Redirect_redirStr != "")     {
    if (isset($_SERVER['QUERY_STRING']) && $_SERVER['QUERY_STRING'] != "")     {
      if (strpos($Redirect_redirStr, "?") < 0)     {
        $Redirect_redirStr .= "?".$_SERVER['QUERY_STRING'];
      }
      else     {
        $Redirect_redirStr .= "&".$_SERVER['QUERY_STRING'];
      }
    }

    $eCart1->redirStr = $Redirect_redirStr;
  }
  $eCart1->cartAction = "Checkout";
}
?>

Why 4 copies of this code? If I change the-- $Redirect_redirStr="checkout.php"; --to an absolute SSL URL, does this allow all subsequent pages of checkout procedure to be in a secure environment?

The multiple versions of the checkout behavior may happen for a few reasons, most likely is applying the Display manger to the page multiple times, but not removing the code above the doctype when deleting the code from the body.


Yes, pointing to the SSL directory on the checkout action will cause each page after to be in the secure ssl.

Thank you, Jason!

So I attempted the above, to redirect to an absolute SSL URL within the Redirect Checkout function in the header, and instead, the site stalls on the customercart.php page. It will not proceed to the checkout.php page. Even after recoding back to the original link to checkout.php, it still continues to stay on the customercart.php page when the checkout button is clicked. Any help please?

I have created a support ticket so we can look into this issue further.

To view and edit your support ticket, please log into your support history:
supporthistory.php

If anyone else is experiencing this same issue, please append to this thread.