<p>This was an email template problem. While the template loaded fine in a browser, it was failing when being sent by Craft Commerce on a status update. The only clue was when manually updating a status in the control panel and receiving a Javascript alert saying 'Undefined'. Nothing in any logs. I feel quite fortunate to have happened to have stumbled across the solution with only a day's work.</p>

CC BY-SA 3.0
2017-10-13T14:03:27.247Z
2018-01-19T11:00:52.187Z
2018-01-19T11:00:52.187Z
Clive Portman
<p>I'm having problems with Worldpay and their notorious dislike of 302 redirects with the payment response. I remember this problem last year and Luke fixed it but it seems to have returned.</p>

<p>Within Commerce_PaymentsService there is code targeting Worldpay and some other gateways, around line 15 in the latest version. I believe that was to avoid the 302 redirect problem from last year.</p>

<p>What I've done is added code to log where the script is getting to, and it seems it never even reaches this code. You can see from the sample below</p>

<pre><code>    if ($success &amp;&amp; $transaction-&gt;status == Commerce_TransactionRecord::STATUS_SUCCESS)
    {
        CommercePlugin::log('Commerce_PaymentsService line 814', LogLevel::Info, true);
        craft()-&gt;commerce_orders-&gt;updateOrderPaidTotal($transaction-&gt;order);
    }
    CommercePlugin::log('Commerce_PaymentsService line 817', LogLevel::Info, true);

    // For gateways that call us directly and usually do not like redirects.
    // TODO: Move this into the gateway adapter interface.
    $gateways = array(
        'AuthorizeNet_SIM',
        'Realex_Redirect',
        'SecurePay_DirectPost',
        'WorldPay',
    );
</code></pre>

<p>The line saying 'Commerce_PaymentsService line 817' is not being reached. I've currently following the trail and am several functions within Commerce_OrdersService applying the same metho to figure out what's happening.</p>

<p>Does anyone know of a change in the way Commerce works that would bypass this Worldpay test?</p>

<p>I made a support request yesterday, but no response yet, which is why I'm on here.</p>

<p>UPDATE: the latest version of Craft Commerce has changed things with Customer Emails. I've got some deprecated notices in the control panel. I'm wondering whether there is an email problem which is stopping things proceeding.</p>

<p>UPDATE 2: rolled back two versions before the email change and it's still broken. I've noticed that when you update an order's status in the control panel the email is not being sent and a popup error saying 'Undefined' is being shown. There's nothing in any of the logs so it looks like more trawling through Craft Commerce. Test emails from Craft work fine, and the email template is fine when viewed on the front end.</p>

<p>UPDATE 3: Removing the emails from the order statuses allows the order status to be updated fine. So there is definitely a problem with the emails. Then I've updated to use a test email containing nothing but static text - that processes, send and even redirects from Worldpay fine. It's my order email template.</p>

<plugin-craftcommerce>
Craft Commerce Worldpay 302 error
# Craft Commerce Worldpay 302 error

(Asked by: username_0 on 2017-10-13)

I'm having problems with Worldpay and their notorious dislike of 302 redirects with the payment response. I remember this problem last year and Luke fixed it but it seems to have returned.
Within Commerce_PaymentsService there is code targeting Worldpay and some other gateways, around line 15 in the latest version. I believe that was to avoid the 302 redirect problem from last year.
What I've done is added code to log where the script is getting to, and it seems it never even reaches this code. You can see from the sample below
    if ($success && $transaction->status == Commerce_TransactionRecord::STATUS_SUCCESS)
    {
        CommercePlugin::log('Commerce_PaymentsService line 814', LogLevel::Info, true);
        craft()->commerce_orders->updateOrderPaidTotal($transaction->order);
    }
    CommercePlugin::log('Commerce_PaymentsService line 817', LogLevel::Info, true);

    // For gateways that call us directly and usually do not like redirects.
    // TODO: Move this into the gateway adapter interface.
    $gateways = array(
        'AuthorizeNet_SIM',
        'Realex_Redirect',
        'SecurePay_DirectPost',
        'WorldPay',
    );

The line saying 'Commerce_PaymentsService line 817' is not being reached. I've currently following the trail and am several functions within Commerce_OrdersService applying the same metho to figure out what's happening.
Does anyone know of a change in the way Commerce works that would bypass this Worldpay test?
I made a support request yesterday, but no response yet, which is why I'm on here.
UPDATE: the latest version of Craft Commerce has changed things with Customer Emails. I've got some deprecated notices in the control panel. I'm wondering whether there is an email problem which is stopping things proceeding.
UPDATE 2: rolled back two versions before the email change and it's still broken. I've noticed that when you update an order's status in the control panel the email is not being sent and a popup error saying 'Undefined' is being shown. There's nothing in any of the logs so it looks like more trawling through Craft Commerce. Test emails from Craft work fine, and the email template is fine when viewed on the front end.
UPDATE 3: Removing the emails from the order statuses allows the order status to be updated fine. So there is definitely a problem with the emails. Then I've updated to use a test email containing nothing but static text - that processes, send and even redirects from Worldpay fine. It's my order email template.

**Tags:** plugin-craftcommerce

---

## 1 answers

### Answer by username_0 on 2017-10-13. Score: 1 | Accepted answer

This was an email template problem. While the template loaded fine in a browser, it was failing when being sent by Craft Commerce on a status update. The only clue was when manually updating a status in the control panel and receiving a Javascript alert saying 'Undefined'. Nothing in any logs. I feel quite fortunate to have happened to have stumbled across the solution with only a day's work.


---

