bmccon02

I believe that the biggest problem of all might be WorldPay's terms and conditions. It seems as though they want the customer to know explicity when they are on the WorldPay site, if you do it all in the background by talking to the WorldPay servers, then this may upset them and they may not approve your site. They are VERY Pernickety. As a slight side note, I decicided not to do anymore work on my changes on integrating the checkout_processing into the checkout module and releasing it to the public. This is because it seems that Graeme is unwilling to make the necessary changes to the module to overcome the present 'feature' that 1 in 10 orders fail to regiseter with osc despite the 'stablility' of the design.

The changes that I suggested should be used with caution. This is because changes are made to a file that is used by all of the payment modules, namely checkout_process.php, and at the moment these changes will break other payment modules. It's not too difficult to fix this problem, it's just that I haven't got around to doing it yet (my site only uses WorldPay). This code was posted as a means of demonstrating that the WorldPay module can be improved in such a way as to no longer require the redirects. You should really wait until these changes are released as part of the main contribution before using them. If you do want to use the changes suggested my by me in the mean time then you should probably copy the checkout_process.php file and make the changes to that file instead (as suggested in an earlier post). You will also need to reference this newly copied file instead from wpcallback.php. Prior to this fix I was also having major problems with disappearing orders. For me, at least, these problems were almost always due to problems with the redirects and not callback failures (when callback failures occur WorldPay should send you an email to tell you). Hence my suggested modifications should *hopefully* solve this problem for you and other users too.

The best way to deal with this problem would be to pop another variable into the session (or rather the HTTP_POST_VARS) in wpcallback.php which would be checked in a simple if... then statement in checkout_process.php. This way you wouldn't have to copy any files or create any new database entries. I will see if I have a chance to make this change, and to tidy the code in a couple of other areas too, next week.

Thanks. You were quite right to mention that the small changes to checkout_process.php will stop other payment modules from working properly. The easiest way to deal with this problem is to make a copy of the file checkout_process.php and the to make the small modifications to that file and then to call that file instead from wpcallback.php. This way it will happily coexist with other payment modules. It's also not really necessary to change the 'redirects' at the top of checkout_process.php to 'includes' because these represent safeguards that will only ever get called when the file is processed outsight of the proper framework and not through WorldPay.

Oh dear it's getting late. I've found the first major (and obvious) bug: Change the code at the 3 lines after the comments at the top of wpcallback.php to the following if...else statement (otherwise orders go through regardless of whether the payment transaction suceeds - BAD!!!): if(isset($transStatus) && $transStatus == "Y") { $HTTP_POST_VARS['osCsid'] = substr($cartId, (strpos($cartId, '=') + 1), (strlen($cartId) - strpos($cartId, '=') - 1)); include('checkout_process.php'); } else { require('includes/application_top.php'); } In can appreciate that these modifications are become (increasingly) difficult to follow. Perhapes somebody may consider rolling these back into the main contribution and/or summarising these changes more elegantly than I can. I'll leave any other bugs out there to you guys - I'm off to bed...

Opps missed a line in wpcallback.php Change (use search to find the right line!): <tr align="right"><td><?php echo '<a href="' . tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL', false) . '">' . tep_image_button('button_continue.gif', IMAGE_BUTTON_CONTINUE) . '</a>'; ?><td></tr> to: <tr align="right"><td><?php echo '<a href="' . $url . '">' . tep_image_button('button_continue.gif', IMAGE_BUTTON_CONTINUE) . '</a>'; ?><td></tr> Sorry about that...

Okay here is the code which should help overcome the redirect problems in WorldPay since the order processing now occurs as part of the callback (where it is supposed to occur). I haven't had time to beautify the code yet, so it ain't pretty. Constructive critism and/or comments for improvement are welcomed. In fact any feedback is appreciated! There are only two files to modify: Modifications to wpcallback.php: ================================ At the very top of the file after the comments add the following: $HTTP_POST_VARS['osCsid'] = substr($cartId, (strpos($cartId, '=') + 1), (strlen($cartId) - strpos($cartId, '=') - 1)); include('checkout_process.php'); Then comment out this near the top of the file: require('includes/application_top.php'); Change the first redirect variable definition to the following (tip: search for the first occurence of '$url'): $url = tep_href_link(FILENAME_CHECKOUT_SUCCESS, $cartId, 'NONSSL', false); Modifications to checkout_process.php: ====================================== Near the top of the file change the 'tep_redirect' statements to 'include' statements as follows (tip: search for the first four occurences of 'tep_redirect'): include(FILENAME_LOGIN); exit(); include(FILENAME_CHECKOUT_PAYMENT); exit(); include(FILENAME_CHECKOUT_PAYMENT); exit(); include(FILENAME_CHECKOUT_SHIPPING); exit(); Near the very bottom of the file comment out these lines: tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL')); require(DIR_WS_INCLUDES . 'application_bottom.php'); Hope this helps. Enjoy!

Bear in mind that the way that it currently works the callback page already passes across all of the variables that the checkout_process page needs (otherwise it wouldn't work with the existing code). From having a brief look it seems as if only the cart id gets passed, and the session id gets dropped. I am looking into integrating the code now, to do away with the troublesome redirects, but I'm not too familiar with the code so it may take a while to figure how its working and what I need to change.

I am almost certain that WordPay doesn't wouldn't process somebody else's PHP script (which is what you seem to be suggesting) for several reasons: - Not least the secuirty implications of running potentially 'rogue' scripts - Having the right version of PHP with the right extensions etc etc. - And finally the most fundemental of facts - if you have set up PHP properly on your machine *nobody* should be able to download any file with a .php ending unprocessed. What I believe is happening is that WorldPay's server is calling your PHP page from their own server and then using the response from that to deliver the webpage. Hence the PHP is processed on your server just like any other PHP, but WorldPay are giving the appearance that their machine is really doing the work.

There a two reasons for discontinuities between WorldPay payments & OSC orders: 1) The callback handler on OSC called by WorldPay fails. When this happens you receive an email from WorldPay telling you that the callback may have failed. You can then try and go about the process of finding the customers original order (either by phone or using the order contribution). This is sometimes occurs for 'techincal reasons' and happens quite rarely. 2) The callback handler page fails to redirect for any one of a number of reasons after the WorldPay payment process. When this happens you don't get a notification. You can only discover this problem by manually cross-check orders & payments. This typically occurs for 'human reasons' and happens quite often (1 in 15 in my experience!). So the idea is that the business logic which is currently contained in checkout_process and is called as a seperate process after the callback handler, should really be incorporated as part of the callback handler. This is the way that WordPay is designed to operate. I am not sure where the idea that the callback handler is processed by WorldPay and not OSC came from, which would preclude this option, but from what I understand clearly this is not the case.

I have considered that contribution. However, the main disadvantage is that you still have to manually cross-check all of the WorldPay payments against the OSC orders every day. Basically, this seems like a bit of a fudge until a real solution arrives IMHO...

A site of ours recently went live and is receiving approximately 15 orders a day using the WorldPay payment gateway. However, unfortunately at least one of these orders each day seems to go astray - WorldPay receives payment but OSC doesn't record the order. This doesn't seem to be due missing/broken callbacks from WorldPay, but rather, the problem of users closing the browser window, navigating away, or the connection 'going down' on the "Please wait whilst we finish processing your order" page!!! Obviously it doen't look too professional to have to contact these customers and to ask them if they can remember what they ordered on our site. So we are currently investigating alternative approaches. I have read through the previous WP thread several times, but although it was discussed, I have been unable to conclude whether it is possible to integrate the code from checkout_success.php (which I believe records the order in OSC) with the wpcallback.php (which handles the callback from WP) thereby avoiding these problems associated with redirecting. Could somebody please enlighten me as to whether this is possible, and why this wasn't done in the first place (are there any technical reasons/limitations why this wouldn't be possible)?

Has anybody managed to modify the default layout of the WorldPay pages to the osCommerce look and feel, so that the customer doesn't even realise that they've left the osCommerce site? I've started to try and do this already, but hey if somebody out there has already managed to achieve such a feat...