Expresso Store v2.5.1 and EE v2.8.1, WorldPay doesn't redirect after successful order?

Question

For some reason after a successful test order I am not being redirected back to the site after paying via WorldPay.

I have made sure that the settings tally up and are correct as per the docs here: https://www.exp-resso.com/docs/payment_gateways.html#worldpay

I have also checked the return URL is correct and even tried making it an absolute link, but again no luck.

I have also tried disabling secure forms via the config file using the below as v2.8.1 doesn't have the option to turn off secure forms now: $config['disable_csrf_protection'] = 'y';

The orders are successful as I can see them in the CP afterwards, it also works when registering a new member, but again doesn't redirect.

Another small issue I have, which may or may not be related, is the Freemember logout link gives an error regarding not being authorized, see below: "You are not authorized to perform this action"

Any ideas before I resort to trying an EE upgrade to v2.9.3 would be helpful please? Ideally I'd rather not have to update it at this time.

Thanks in advance!

EDIT: Latest update

After updating EE to v2.10.2 the issue is still present (no redirection after payment at WP TEST server), orders go through successfully and are added to the CP as status 'new'.

I am now receiving error emails from WP to see what's happening, I get the following:

Error reported: Callback to http://www.example.com/?ACT=39&H=9daf75637f356b4deff064a7aa93333e: NOT OK, recevied HTTP status: 302

And the response attachement shows the following:

HTTP/1.1 302 Moved Temporarily Server: nginx Date: Mon, 01 Feb 2016 11:03:37 GMT Content-Type: text/html Content-Length: 0 Connection: close X-Powered-By: PHP/5.4.45 Set-Cookie: exp_last_visit=1138964616; expires=Tue, 31-Jan-2017 11:03:36 GMT; path=/; httponly Set-Cookie: exp_last_activity=1454324616; expires=Tue, 31-Jan-2017 11:03:36 GMT; path=/; httponly Set-Cookie: exp_csrf_token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; httponly Set-Cookie: exp_csrf_token=1afab38559e3fdd5f89351e6bae32f562a49b981; expires=Mon, 01-Feb-2016 13:03:36 GMT; path=/; httponly Location: http://www.example.com/shop/order/2defc3fdfcc028fc36a4c1b3e3607ec9 X-Powered-By: PleskLin MS-Author-Via: DAV

I'm not sure what any of this means as I haven't experienced this type of issue/error before.

Any ideas please anyone?

Answer 1

WorldPay's hosted payment confirmation pages (successful or unsuccessful) won't automatically redirect back to the EE Store order confirmation page under your own domain, if the callback (Payment Response) is unsuccessful.

If your orders are appearing as Order Status New in EE : Store : Orders, the callback should be working OK, but if they're marked Incomplete, the callback is failing (a problem I had). WorldPay's CP can be configured for an error email to be sent in this case: Payment Response failure email address. See WorldPay documentation.

In the past for another shopping cart, I've needed to hardcode into WorldPay's ResultY.html and ResultC.html files a return link variable, either as a meta refresh tag or anchor. I don't know if this is required in this case.

Here are the WorldPay settings that work for me:

• Payment Response URL: <wpdisplay item=MC_callback>
• Payment Response enabled? tick
• Shopper Redirect URL (blank)
• Shopper Redirect button enabled? (blank)
• Enable Recurring Payment Response (blank)
• Enable the Shopper Response: tick
• Suspension of Payment Response (blank)
• Payment Response failure email address: (your email)
• Attach HTTP(s) Payment Message to the failure email? tick
• Merchant receipt email address: (blank)
• Enable Mobile Pages? (blank)
• No Worldpay Header enabled? (blank)
• Remove Breadcrumb? (blank)
• Info servlet password (blank)
• Payment Response password: enter and confirm pwd also in Store settings
• MD5 secret for transactions: enter and confirm pwd also in Store settings
• SignatureFields: (blank)

Answer 2

It turns out that trying to use radio buttons to choose a payment method was the cause of the issue here, which I'm still not 100% sure why. I was allowing a choice bewteen 'Manual' for invoice based payment and 'WorldPay' for online payment.

So changing over to the default method of using the select box field, as below, seemed to make the difference:

{payment_method_options}

The checkout process now works fine, phew!