WorldPay Module for ZenCartv1.3x

Loutka,

Did you set the callback URL in the WorldPay Control Panel in the TEST environment and not the PRODUCTION environment?

Alan

duncanad:

Did you set the callback URL in the WorldPay Control Panel in the TEST environment and not the PRODUCTION environment?

Yep! I changed setting in TEST to:
https://<wpdisplay item="MC_callback">

but you said to change it to:
https://<wpdisplay item="MC_callback"

I thought you forget closing brackets... So I tried it both ways...

It's same - change is just when I modify worldpay.php in Zen-Cart.

As I said:

1. no redirection when $callback_url set to contain https
2. no SSL when $callback_url not set to have https

Loutka

Loutka,

Sorry about the typo - yes there should be a closing bracket.

I would change everything back to non SSL mode - this is the way it was working for you before anyway.

Is your site now working in LIVE mode? Do you get the same SSL error in LIVE mode?

Alan

duncanad:

Is your site now working in LIVE mode? Do you get the same SSL error in LIVE mode?

Payments are still set to work in TEST mode, because I don't want to set to LIVE mode, before I'm sure all transactions are secure.

Our site is live - costomers are coming and they want to shop...

Thanks, Loutka

Loutka,

I have discovered that two of my customers have upgraded accounts which appear to have been working perfectly in LIVE mode for some time. Now that I know they have been upgraded I have been able to do some testing on them. One of them works perfectly in TEST mode (apart from the no VISA payment option issue) and the other also works but I get a warning message in IE just prior to callback asking if I want to view both secure and non secure elements on the page. If I click 'Yes' the callback completes successfully.

I have no idea why I am getting this warning message in IE - it doesn't happen in Firefox - and for only one of the accounts although I am using the one Zencart site for testing both. This warning is not necessarily a security issue. It just means that IE thinks there are some elements on the page which are being called by http rather than https e.g. a script or image called from an external URL. My guess is that this may not happen on a live transaction and even if it does it's an annoyance rather than an issue.

I suggest that now the callback is working in TEST mode you try putting through a low value LIVE transaction to test what happens in LIVE mode.

If you do this could you please post back here with the result.

Alan

Alan,

• Missing VISA payment is not issue - according to WorldPay this is new setting for TEST mode
• IE warning message is for same reason as broken SSL lock in Firefox -> SSL is broken (as you said)
• When SSL is broken it's really hard to say which content is unsecure -> I wouldn't shop on such site and I'm not allowed to go to LIVE mode
• it's part of WorldPay policy / strategy that you should be able to make succesfull / secure transaction in TEST mode, before you go LIVE
• hopefully I'll get answer from WorldPay regarding broken SSL by tomorrow
• tomorrow or on Thursday I should get in touch with people who deal with payments so hopefully I will be able to test LIVE mode transaction

Keep in touch...

Thank you, Loutka

I've just been on the phone to WorldPay re the callback issue. They told me that the issue is due to the timing on the meta refresh. They said the refresh was coming through so quickly that it was missing the callback (or something along those lines)..

Does that sound feasible?

Ok, I've sorted my callback problem. Meta refresh..? no, of course it wasn't! I'm afraid it was far more basic. I'd forgotten that I had the site down for maintenance. I'm happy its now sorted and gutted that my stupidity wasted me so much time!

So am I only one who can't make secure payments with working callback? :shocking:

loutka:

So am I only one who can't make secure payments with working callback? :shocking:

I am unable to get the secure payments to work with the callback.

I go though the checkout procedure in Zen Cart. Then I enter in all the credit card information (in test mode). The transaction is accepted, but then nothing happens. I just sit at a page that says the "transaction was accepted". From my understanding, I should be re-directed back to ZenCart, so that the store can process the payment. Am I correct?

Soundstream:

I go though the checkout procedure in Zen Cart. Then I enter in all the credit card information (in test mode). The transaction is accepted, but then nothing happens. I just sit at a page that says the "transaction was accepted". From my understanding, I should be re-directed back to ZenCart, so that the store can process the payment. Am I correct?

Yes I think you are correct, I'm having same problem when SSL switched ON.

If I don't use SSL I'm redirected back to our website with broken SSL, but it't not good... we need SSL ON :huh:

I haven't tried with SSL off, since we have to have it on. I wonder if the callback is not working because we are in TEST mode ... perhaps if it was in LIVE mode, it would send you back to the store. But I don't want to be making actual payments to test that.

Success! (well some anyways).

Not sure if this is the same problem as you have, but I had not noticed/completed all of the changes that were mentioned in this post: http://www.zen-cart.com/forum/showpost.php?p=522334&postcount=263. I was missing the 'SSL' at the end of the first line.

So now the test server will "callback" to my Zen Cart site.

Although I do have some questions ... when it goes back to the Zen Cart site, the URL that it is redirected to is: https://secure-test.ims.worldpay.com/wcc/card?op-PMGetNextPage&PaymentID=1205513468815. Is the URL not supposed to be my own domain, not a WorldPay domain?

The actual page that it re-directs to is only half visible. The header, and left hand side is displayed. But the center column, right hand column, and footer are NOT displayed. Checking the source, it is as if the PHP page has just stopped outputting any more code.

Also, the actual order does not show up in the database.

So I am closer, but I have no clue what is happening now. Anyone have any suggestions?

cplam999:

The modules works fine for me, it is great!:thumbsup:

by the way, I have a suggestion.
The tansaction ID is not record in the admin page,
sometimes I get confuse.. I don't know which order# related to which transaction#..

If in can record order# and transaction ID like PayPal IPN does,
It is perfect!

:P

Anyway, thank you !
Have you managed to do the worldpay to store the response in comments like paypal does?

So, I managed the get the HTTPS callback response working. It seems I had missed a small change to one of the lines of code that requires an 'SSL' parameter at the end of it.

My (hopefully) final question is this ... when WorldPay returns the shopper to the Zen Cart store in test mode, Zen Cart says that the order was not processed, and no order shows up in the database. Now I believe that this is because WorldPay is returning an code stating that no money took place because it was a "test transaction".

Is this the expected behaviour of a successful test? Or in a successful test, would Zen Cart display that everything worked (even though it was in test mode), and then add the order to the database.

If what has occurred is correct, I'd like to submit my site for approval by WorldPay, but don't want to waste their time if there is more for me to do on my end.

Soundstream,

When you put through a 'Successful' test transaction everything should happen as would on a live transaction EXCEPT no payment should be made. So the customer should receive two emails, one from your Zencart and one from WorldPay and the merchant should also receive two emails, one from Zencart and one from WorldPay. The TEST order should appear in your Zencart Admin as would a LIVE order.

The shopper response pages are 'grabbed' (technical term) by WorldPay and displayed on their server hence their domain and not yours appears in the address window of your browser.

If you want to see how all this works in action make a test purchase on my test site at rcm.testingit.net This is currently in permanent test mode. Just ignore the warning message about the Security Certificate problem. Zencart have installed a security certificate for a different domain from their test URL domain which is causing the warning. It doesn't happen with a live transaction so it isn't a big issue. I have reported it to WorldPay but have had no response as yet.

If you open an account on my test site remember, no matter what junk you enter for your personal details, use a valid email address so that you can receive the response emails.

The Zencart module on my test site is a prototype re-write of the module so it may look slightly different from yours. I have two live sites running correctly with the currently downloadable version of the module so you should be able to get everything working with the current version.

Hope this helps,

Alan

After doing some further readin, yes, you are right, I should see the order show up if the transaction was successful.

What I have found since my previous post ...

• The reason for the unsuccesful page being displayed was due to a change I made where someone suggested trying to change the line of code that checks $transStatus. So I have reset that back to what it was.

• while my site not appears to have regressed, it is actually more correctly setup. The page that starts to load just simply "dies" and the PHP code just kind of ends abruptly (see snippet):

            <img src="includes/templates/theme041/images/spacer.gif" alt="" width="1px" height="7px" /><br><!--// eof: whatsnew //-->
  </div>

</td>
	<td width="1px" class="l5_c3"><img src="includes/templates/theme041/images/spacer.gif" alt="" width="1px" height="1px" /></td>
<td valign="top" class="l5_c4"><div class="l5_c44">
<!-- bof  breadcrumb -->
<!-- eof breadcrumb -->


<!-- bof upload alerts -->
<!-- eof upload alerts -->

What I have discovered is that the $transStatus comes back as "Y" and it starts to work it's way through the tpl_wpcallback_default.php module. It gets to the first line that says:

require(DIR_WS_MODULES . 'checkout_process.php');

It is inside checkout_process.php where it appears to die. From my crude debugging it somehow loses the $SESSION['customer_id'] and then attempts a re-direct to the timeout page. After that I see nothing happening and the page just dies.

If anyone can be of assistance, I am willing to pay to have this problem solved. I am very close to completing this site, and this is the only piece that is holding me up.

duncanad, your PM boxes are full. Can you please clean out some room (either in your Inbox or your Sent Items), as I have a response for you.

Thanks

Hello,
I received another response from WorldPay:

You have a callback URL of http://<wpdisplay item="MC_callback"> set for installation 14115 so you should not be passing http or https in the value of MC_callback, can you confirm that $callback_url populates the value of MC_callback.

Anyone understands this better than me..?

Thank you...

Loutka,

The following lines of code define the value of the callback URL which is passed to WorldPay as "MC_callback"

includes/modules/payment/worldpay.php lines 128 and 129

      $callback_url = zen_href_link(FILENAME_WPCALLBACK, $zenId);
      $worldpay_callback = explode('http://', $callback_url);

and at line 148

        zen_draw_hidden_field('MC_callback', $worldpay_callback[1]);        

The function zen_href_link() is defined in includes/functions/html_output.php as follows:

zen_href_link($page = '', $parameters = '', $connection = 'NONSSL', $add_session_id = true, $search_engine_safe = true, $static = false, $use_dir_ws_catalog = true)

If any of the variables are not included then the default value is used so basically line 128 defines $callback_url as the full non-ssl path to the callback script as defined (FILENAME_WPCALLBACK). This might look something like this:

http://www.yourdomain.com/index.php?main_page=wpcallback&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f

Note $zen_id is not strictly required since this is the session_id which by default is included anyway hence it is included twice in the url.

Line 129 splits $callback_url into an array with two values:

 $worldpay_callback[0] = http:// 
$worldpay_callback[1] = www.yourdomain.com/index.php?main_page=wpcallback&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f

and line 148 passes $worldpay_callback[1] to WorldPay as "MC_callback"

Therefore the short answers to WorldPay's questions are that neither http:// nor https:// is passed in the value of MC_callback and it is not $callback_url that populates MC_callback but $worldpay_callback[1].

If you want to pass a secure URL as MC_callback you firstly must have SSL set up on your server and SSL enabled and your secure path defined in your configuration files. Lines 128 and 129 then become:

      $callback_url = zen_href_link(FILENAME_WPCALLBACK, $zenId, 'SSL');
      $worldpay_callback = explode('https://', $callback_url);

This sets $callback_url to something like:

https://www.yoursecuredomain.com/index.php?main_page=wpcallback&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f

and $worldpay_callback[1] becomes

www.yoursecuredomain.com/index.php?main_page=wpcallback&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f&zenid=2e9b83e61e7dd9d3c63ea1bb15e0b58f

and this is passed to WorldPay as MC_callback.

Of course if you are using secure callback you must set the callback URL in you WorldPay control panel as https://<wpdisplay item="MC_callback">

I hope this explains things,

Alan