Jump to content
Sign in to follow this  
dynamoeffects

PayPal WPP Direct Payments & Express Checkout Support

Recommended Posts

anyone got the solution for the error on Rc2.2a when trying to checkout using PayPal express?

shopping_cart.php?error_message=Security header is not valid

 

thanks

Share this post


Link to post
Share on other sites

Seem to be having trouble using this module with Store Mode 1.3, posted in January 2009. I'm getting errors in the main function of paypal_wpp_include.php around lines 9 & 26 when I attempt to view Orders from the administration panel. The errors mention not finding

includes/paypal_wpp_include.php, when it is [in fact] there.

 

Of course, I don't want to copy and paste the error messages for security reasons.

 

I'm wondering if I should patch this module in before I patch in the Store Mode module....(????)

Share this post


Link to post
Share on other sites

 

Of course, I don't want to copy and paste the error messages for security reasons.

 

Of course, if you don't post the error message, I can't figure out where the problem lies. Put asterisks or 'x' in place of the data you don't want to share, but leave the osC folder structure intact.

 

WPP is known by me to work with Store Mode 1.3, as I have them both installed. I don't recall doing anything special to make them work together.

 

--Glen

Share this post


Link to post
Share on other sites

anyone got the solution for the error on Rc2.2a when trying to checkout using PayPal express?

shopping_cart.php?error_message=Security header is not valid

 

thanks

 

Please describe the error in more detail. Have you run wpp_diagnostics.php that is included with the package? Did it pass?

 

--Glen

Share this post


Link to post
Share on other sites

Im revisiting the installation of OSC that has been put on the back burner from being deployed (for various reasons). When i left the installation, the base functions were working properly, including a paypal payment module for express checkout (this contrib: http://www.oscommerce.com/community/contributions,4791).

 

I began to revisit the project and look at now working on securing my cart, but wanted to test the checkout one last time before I installed Security Pro, to make sure there were no problems BEFORE restrictions.

 

As i attempted to purchase via sandbox, i noticed it would never allow me to fully complete the transaction. When i clicked 'Pay' after returning from paypal express checkout, it would simply take me back to the login page as if i had a new session or was not authenticated in account. I read into this problem and found some information about Paypal recently changing the way transactions are handled, and i noticed the contrib was way out of date, so i took this opportunity to install Paypal WPP Direct Payments & Express Checkout.

 

installation went fine with some small hiccups i was able to figure out on my own. The diagnostics passes now with flying colors.

 

HOWEVER

 

The exact same problem shows itself while attempting to check out via WPP! On the final step i click to pay and complete the transaction, and send me right back to the login page! Can anyone push me in the right direction, ive been looking for a solution like crazy and not sure which to apply.

 

Thanks to everyone in advance.

 

erihp

Share this post


Link to post
Share on other sites

follow-up to my above post... i attempted the fix on page 185:

 

Hello, I did have the same error I guess.

 

What I found out (It works for me now) ist to change 1 line in catalog/includes/modules/payment/paypal_wpp.php:

 

 

change Line 580: $order_info['PAYPAL_RETURN_URL'] = tep_href_link(basename($_SERVER['SCRIPT_NAME']), 'action=express_checkout', 'SSL');

 

to:

 

//$order_info['PAYPAL_RETURN_URL'] = tep_href_link(basename($_SERVER['SCRIPT_NAME']), 'action=express_checkout', 'SSL');

$temp_return_link = tep_href_link(basename($_SERVER['SCRIPT_NAME']), '', 'SSL');

$order_info['PAYPAL_RETURN_URL'] = $temp_return_link . '&action=express_checkout';

 

Maybe it will work for you too.

ToSam

 

 

It is now sending me back to the shipping method pages when i click on the express checkout after logging in with my sandbox buyer account. any ideas???

Share this post


Link to post
Share on other sites

After some digging (I promise im doing all i can to fix this myself!) i found this from Glen:

 

Yes, it's because the oscSid gets lost on the trip to PayPal if the ampersand isn't correctly escaped. This happens when the session ID is in the URL and not a cookie. It seems to be more of a problem with the PayPal sandbox than on live servers.

 

Try this:

 

In catalog/includes/modules/payment/paypal_wpp.php, find near line 616:

	  $order_info['PAYPAL_RETURN_URL'] = tep_href_link(basename($_SERVER['SCRIPT_NAME']), 'action=express_checkout', 'SSL');
  $order_info['PAYPAL_CANCEL_URL'] = tep_href_link($redirect_path, $redirect_attr, 'SSL');

 

Replace with:

	  $order_info['PAYPAL_RETURN_URL'] = htmlspecialchars(tep_href_link(basename($_SERVER['SCRIPT_NAME']), 'action=express_checkout', 'SSL'));
  $order_info['PAYPAL_CANCEL_URL'] = htmlspecialchars(tep_href_link($redirect_path, $redirect_attr, 'SSL'));

 

 

STILL does not work! Same results as before. What is going on here =\

Share this post


Link to post
Share on other sites

After some digging (I promise im doing all i can to fix this myself!) i found this from Glen:

 

 

 

 

STILL does not work! Same results as before. What is going on here =\

 

My September fix does essentially the same thing as ToSam's fix from April and is incorporated into the current release of the WPP module. Both of patches these fix a problem that occurs when the customer's browser does not accept cookies and the session ID must be stored in the URL.

 

There is another issue that comes up with some installations, for which I still haven't come up with a universal fix. That is where the variable $_SERVER['SCRIPT_NAME'] is not set to the name of the current PHP file, but is something like "PHP4". Check Admin->Tools->Server Info. The value of $_SERVER['SCRIPT_NAME'] displayed on that page should be "/catalog/admin/server_info.php" or something similar if you have moved or renamed your admin folder. It should always end in "server_info.php". Please check this and let me know if it is different.

 

--Glen

Edited by SteveDallas

Share this post


Link to post
Share on other sites

Thanks for the prompt reply Glen. I downloaded the release from the main contrib page and grabbed the one at the top of the list. Neither your nor ToSams fixes were present in the file, i was able to apply them both... could that be causing a problem? Im pretty sure i attempted each indiviually and it did not seem to change.

 

My _SERVER["SCRIPT_NAME"] appears to be correct.. it reads: /~sharedhostuser/catalog/admin/server_info.php (replaced current/correct values with generics).

 

Any other ideas?

Share this post


Link to post
Share on other sites

Thanks for the prompt reply Glen. I downloaded the release from the main contrib page and grabbed the one at the top of the list. Neither your nor ToSams fixes were present in the file, i was able to apply them both... could that be causing a problem? Im pretty sure i attempted each indiviually and it did not seem to change.

 

My _SERVER["SCRIPT_NAME"] appears to be correct.. it reads: /~sharedhostuser/catalog/admin/server_info.php (replaced current/correct values with generics).

 

Any other ideas?

 

Oops... I forgot to include that fix in v1.0.7. I just posted it up to the latest development release on github. However, it doesn't appear that this fix relates to the issue you are experiencing. Please PM or email me the link to your site so I can see what is happening and possibly suggest a solution.

 

--Glen

Share this post


Link to post
Share on other sites

Thanks a million Glen, just PMd you but message was sent prematurely.. it will not allow me to send a 2nd PM just yet, but i will email you or reply to your PM with more info, hope we can nail this one down!

Share this post


Link to post
Share on other sites

Glen is a a godsend and a lifesaver rolled into one!

 

He went above and beyond to help me resolve my issue, which was boiled down to a problem with code the old paypal module id been using. It had been breaking the code applied for the WPP DP & EC module.

I cant say thanks enough to everyone here on the support forums for all the knowledge and guidance. This is what a community is all about!

 

Again, infinite thanks.

Share this post


Link to post
Share on other sites

Hi,

 

Like many others, I would like to first thank your team for providing this module. Here's a summary of what's happening:

 

My client used a custom template, which wasn't much of a problem, but made the install instructions a little tricky. I believe I've followed all the instructions except for header.php, I didn't modify this file but looking at the code, it doesn't seem to be "necessary" to have, so I left header.php unchanged. If this is not the case, please let me know.

 

So when we upload everything, if we select "check out", it would load the page EXCEPT for the shipping module, so the page loads fine but missing all the options. While toying around with the code, I removed this line out of checkout_shipping.php: "tep_paypal_wpp_checkout_shipping_error_display($ec_checkout);"

 

Then everything worked, the shipping modules displayed without any issues. However, the next problem is if I select "continue" (which would post an action of "process"), I get a blank screen. The read me file indicates that blank php files usually indicate the cert file is not being pointed to the right location. But I checked the location and everything seems right. I had spend some time and see that the blank page was a result of this line of code in checkout_shipping.php: "tep_paypal_wpp_checkout_shipping_redirect($show_payment_page, $ec_enabled);"

 

Any idea what would resolve this? I appreciate any input anyone may have.

 

Thanks,

 

Sam

Share this post


Link to post
Share on other sites

I've seen a couple of posts with this problem, but have not been able to find the solution anywhere.

 

In my admin, if I click the Issue Refund button, I get the next screen where you select Full/Partial, etc, but when I click the Refund button, it redirects to my Admin's login. The api call for the refund is not sent to Paypal.

 

If it matters, beforehand, checkout does an authorization and then I manually do a capture in the admin. I'm using version 1.0.5.

 

Does anyone happen to know the solution for this?

 

Thanks!

Share this post


Link to post
Share on other sites

I have the latest version and it is working well however occasionally a customer is able to check out...or should I say pay without actually checking out. So oscommerce has no record of the sale but the payment via PayPal express is successful. Does this have anything to do with the customer not returning to the shop after paying?

I have had this problem occasionally, but it seemed to be with customers using the PayPal IPN contribution, not this module. I can tell the difference on the PayPal side, as EC customers show cart details and shipping address, while IPN customers don't even show the shipping address. One of these days, I'm going to stop using the IPN contribution.

 

--Glen

Share this post


Link to post
Share on other sites

In my case the shipping address and cart details are there on paypals end, it's just my cart didn't get the information regarding the transaction. I suppose this could be a network problem. Does the customer have to absolutely return to the cart or is this done via an api call?

 

This problem only occurs about 1 out of 50 times.

 

The information comes back to the module via an API call, and it is not dependent on the customer doing anything, unlike some other modules. I've used the module since it was first released and cannot recall this ever happening on my own web site, nor do I recall any other reports of similar problems.

 

--Glen

Share this post


Link to post
Share on other sites

I've seen a couple of posts with this problem, but have not been able to find the solution anywhere.

 

In my admin, if I click the Issue Refund button, I get the next screen where you select Full/Partial, etc, but when I click the Refund button, it redirects to my Admin's login. The api call for the refund is not sent to Paypal.

 

If it matters, beforehand, checkout does an authorization and then I manually do a capture in the admin. I'm using version 1.0.5.

 

Does anyone happen to know the solution for this?

 

Thanks!

 

paypal_wpp_refund shows this code for the refund and cancel buttons:

 

<td colspan="2" align="center"><input type="submit" name="refund_submit" value="<?php echo WPP_SUBMIT_REFUND; ?>"> <input type="button" name="cancel" value="<?php echo WPP_CANCEL; ?>" onclick="window.close();"></td>

 

The cancel button works.

 

Should there be an onclick= for the refund button?

Share this post


Link to post
Share on other sites

paypal_wpp_refund shows this code for the refund and cancel buttons:

 

<td colspan="2" align="center"><input type="submit" name="refund_submit" value="<?php echo WPP_SUBMIT_REFUND; ?>"> <input type="button" name="cancel" value="<?php echo WPP_CANCEL; ?>" onclick="window.close();"></td>

 

The cancel button works.

 

Should there be an onclick= for the refund button?

 

Ok, I found out the answer to that is no.

 

What I did to fix the problem of it redirecting to the login screen was to change the following line in paypal_wpp_refund.php from this:

 

include(DIR_FS_DOCUMENT_ROOT . DIR_WS_INCLUDES . 'configure.php');

 

to this:

 

include('includes/configure.php');

 

After I changed that, clicking Refund would send the Paypal transaction, however it failed with an error 10009. That error occurs because when you do an authorization you get one transaction id, and then when you do the capture, the auth transaction id becomes the parent transaction id, and a new transaction id is assigned to the capture. The refund has to be executed with the capture transaction id, but the current code executes it with the auth transaction id, so it fails.

 

So I'm trying to decide if I should modify the code to overwrite the auth transaction id with the capture transaction id. My store isn't live yet, so I don't have experience using the admin a whole lot yet, and consequently, I don't know if that would cause any problems with anything else. In Paypal, I can find the transaction with either id.

 

Advice, anyone? Greatly appreciated!

Share this post


Link to post
Share on other sites

Ok, I found out the answer to that is no.

 

What I did to fix the problem of it redirecting to the login screen was to change the following line in paypal_wpp_refund.php from this:

 

include(DIR_FS_DOCUMENT_ROOT . DIR_WS_INCLUDES . 'configure.php');

 

to this:

 

include('includes/configure.php');

Good catch. I fixed this in the instructions for admin/orders.php, but didn't notice that the charge, refund and capture pages also had this. In all three, the line should be:

 

include(DIR_FS_CATALOG . DIR_WS_INCLUDES . 'configure.php');

 

After I changed that, clicking Refund would send the Paypal transaction, however it failed with an error 10009. That error occurs because when you do an authorization you get one transaction id, and then when you do the capture, the auth transaction id becomes the parent transaction id, and a new transaction id is assigned to the capture. The refund has to be executed with the capture transaction id, but the current code executes it with the auth transaction id, so it fails.

 

So I'm trying to decide if I should modify the code to overwrite the auth transaction id with the capture transaction id. My store isn't live yet, so I don't have experience using the admin a whole lot yet, and consequently, I don't know if that would cause any problems with anything else. In Paypal, I can find the transaction with either id.

 

Advice, anyone? Greatly appreciated!

 

As written, it should work correctly if Payment Action is "Sale". It won't work for Payment Action is "Authorization" for the reason you mentioned. I need to look into this issue, as it is tied up with the non-working IPN code.

 

Personally, I don't think that one should overwrite anything, to maintain an audit trail. Instead, we should add a new transaction record that reflects the capture, and the refund code should look for the capture transaction if the original transaction was an authorization. I don't do captures within osC; I use the PayPal Batch Capture function as part of my workflow. I'll research this and see what I can come up with.

 

--Glen

Share this post


Link to post
Share on other sites

I've googled this forum and thread looking for the answer but all related posts are very dated...

 

Is the current version 1.0.7a compatible with Multi Vendor Shipping 1.22?

 

I've read that additional code has to be added modified to make it work but I do not know which code, or where, or what, or if the modifications are still even needed. From what I have read, if paypal has its own checkout_process seperate from the osc file, some changes ar e/were required...

 

Thanks for the reply!

 

Dave


-Dave

Share this post


Link to post
Share on other sites

I've googled this forum and thread looking for the answer but all related posts are very dated...

 

Is the current version 1.0.7a compatible with Multi Vendor Shipping 1.22?

 

I've read that additional code has to be added modified to make it work but I do not know which code, or where, or what, or if the modifications are still even needed. From what I have read, if paypal has its own checkout_process seperate from the osc file, some changes ar e/were required...

 

Thanks for the reply!

 

Dave

 

The PayPal WPP module uses the standard checkout_process.php. It should work correctly with MVS, though I have not used the two together. I know that the PayPal IPN module intercepts checkout_process and would require additional code.

 

--Glen

Share this post


Link to post
Share on other sites

As written, it should work correctly if Payment Action is "Sale". It won't work for Payment Action is "Authorization" for the reason you mentioned. I need to look into this issue, as it is tied up with the non-working IPN code.

 

Personally, I don't think that one should overwrite anything, to maintain an audit trail. Instead, we should add a new transaction record that reflects the capture, and the refund code should look for the capture transaction if the original transaction was an authorization. I don't do captures within osC; I use the PayPal Batch Capture function as part of my workflow. I'll research this and see what I can come up with.

 

--Glen

 

 

Thanks so much Glen! I agree with you on keeping the audit trail. When I had thought about inserting a new record for the capture trans, I wasn't sure how to link it back to the auth transaction, or how it would be displayed on the orders page, and I wasn't sure if there was anything else it would effect. I just don't know enough about all the moving pieces yet.

 

If you use the batch capture in Paypal, do you go back and update your orders in osc? I would love to know more about the workflow that you (and others) use to process orders.

 

Thanks again!

Share this post


Link to post
Share on other sites

I am wanting to use Discount Coupons (or any other method of supplying a discount) with this excellent contribution, I have tested it against it and it appears that it will work with Direct Payments but not Express checkout, am I correct? If so is there a solution to it? I have searched the forum but cant find anything appropriate can anyone help?

 

Regards

 

Philip

Share this post


Link to post
Share on other sites

I am wanting to use Discount Coupons (or any other method of supplying a discount) with this excellent contribution, I have tested it against it and it appears that it will work with Direct Payments but not Express checkout, am I correct? If so is there a solution to it? I have searched the forum but cant find anything appropriate can anyone help?

 

Regards

 

Philip

There shouldn't be any reason that something that works correctly with Direct Payments not work with Express Checkout, other than if Discount Coupons requires that you enter the coupon code on the Payment page (checkout_payment.php). In this case, change the setting Express Checkout: Display Payment Page to True in the module settings. Please test and let us know if that resolves the issue.

 

--Glen

Share this post


Link to post
Share on other sites

It could be because I have the paypal checkout link on my login page, shipping page and payment page. Is this allowed?

 

The number or placement of the links to engage Express Checkout will have no effect on this behavior. The standard integration method for this module displays the EC button in several places to provide the customer every opportunity to choose Express Checkout. This is most certainly allowed.

 

--Glen

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×