Orders failing when using PayPal

Hello,
We are not seeing inconsistent responses from eCart in regards to passing session variables back to eCart after a PayPal transaction.

We've gotten some live orders where the UserID column is not getting properly set or passed back from PayPal so the order fails on the confirm page.

Unfortunately now with the update to Yosemite, eCart is not working properly (screen shot attached). Will move to Laptop running Mavericks to review and update in more depth.

The problem we are finding is that Sometimes the value for UserID is available on the Confirm page after a response from PayPal and other times it is not available or properly passed / set.

You can see from the attached screen shot that the UserId is only being set sometimes. Each time it fails the Customer is presented with an error and they have to return to repurchase. The instances are increasing and because in our tests it works we are in a bad state ...

Have other encountered this?

Also you can see that other columns are passing properly such as start and end dates but the UserID is the one that is not consistently passing causing a fatal error and loss of revenue.

What are you using for the User ID value?

for the error, reset the workspace layout:
go to Window -> Work Space layout -> Reset '<your layout name>'

and Delete the Dreamweaver Cache file from the users configuration folder:
http://www.webassist.com/tutorials/Common-installation-issues

""What are you using for the User ID value?""

Integers... Not sure of your question. would you like to elaborate?

Each user has a UserID which we set as an eCart column. It is then used in the Order Table and also Order Detail tables once the order is submitted.

Yosemite based issues are now gone. Using the latest eCart 6.09 I believe

how are you setting the UserID in the code?

If I had to make a guess without any information on how the User ID gets into the cart, I would have to say it is probably domain switching.

The User ID is probably a session, sessions are based on the domain cookie, what this means is if yoou log in at:
http://mydomain.com/login.php

then get redirected using the www address to the car page:
http://www.mydomain.com/cart.php

the login session is no longer set because the session browser cookie sees that as 2 separate domains.


you can prevent this by using htaccess to always force www or not:
http://www.htaccessbasics.com/force-www-nonwww-domain/

Check the two screen shots as it shows the values being inserts on the confirm page.

Order Summary uses:
<?php echo $_SESSION['SecurityAssist_UserID']; ?>

Order Detail follows suit of the other values being set and is using:
<?php echo $eCart1->DisplayInfo("UserID"); ?>

Additionally the confirm page does not send a confirmation email. Maybe due to using PayPal to take the users info? Or this value in the To: area of the email sending dialog:

<?php echo (WA_getSavedFormValue("CheckoutWizard_NewFromBlank_Default","First_Name")); ?>|WA|<?php echo (WA_getSavedFormValue("CheckoutWizard_NewFromBlank_Default","Email_Address")); ?>


This is secondary in nature to the errors people are getting once submitting a live order.

BTW Ray never contacted me when I tried to open a paid ticket the other day. Too busy or emails lost ?

like I said it is probably domain switching.

Does the session in the orders table work? if so change the order details to use the same session instead of the cart column.

as for the email, i would need to see the code, see PM

I forwarded your premiere request to Ray and have asked him to follow up.

Private message

I've changed to the session value and will continue to monitor and test.