The WooCommerce 2.1 update changed the way WooCommerce deals with URLs in account and checkout pages, away from using pages and shortcodes to what they call ‘endpoints‘. This change meant that payment gateway plugins for WooCommerce have to be rewritten to use these endpoints.

There was a free plugin for Barclays’ ePDQ payment gateway which is unfortunately no longer supported by its author. With the upgrade to WooCommerce 2.1, it stopped working. I had it in use on a client site, and the alternative was expensive, so had to get the old one working with endpoints. This was something of a palaver, with the whole experience illustrating both the strengths and weaknesses of the open source model.

Changing the code to handle endpoints was relatively straight-forward:

In class.epdq.php, change line 427 from

        return array('result' => 'success', 'redirect' => add_query_arg('order',
            $order->id, add_query_arg('key', $order->order_key, get_permalink(get_option('woocommerce_pay_page_id'))))
        );

to

        return array('result' => 'success', 'redirect' => add_query_arg('order',
            $order->id, add_query_arg('key', $order->order_key, $order->get_checkout_payment_url( $on_checkout = true )))
        );

Delete line 49

$this->notify_url   = str_replace( 'https:', 'http:', add_query_arg( 'wc-api', 'WC_Nom_EPDQ', get_permalink(woocommerce_get_page_id('thanks')) ) );

and insert the following at line 435

$this->notify_url = str_replace( 'https:', 'http:', add_query_arg( 'wc-api', 'WC_Nom_EPDQ', $order->get_checkout_order_received_url() ) );

In the Barclays ePDQ test environment this worked perfectly, however in the production environment, it failed with a ‘unknown order/1/s/’ error in the logs. This error means the SHA hashes do not match. I had identical SHA-IN and SHA-OUT settings in both the plugin settings and the ePDQ back-end, so I was really scratching my head. Why would the identical plugin code work with the test environment but not on the live environment?

The solution turned out to be that I was using different SHA keys in the test and live environments, and the test environment keys were alphanumeric i.e. contained no special characters. On the live environment, I was using more secure keys including special characters, and these characters were not being correctly encoded when passed to ePDQ, causing the SHA checking to fail. Making the SHA-IN and OUT values alphanumeric solves the problem.

Many thanks to J on the plugin support forum for his invaluable help.

Update 13/03/2014: I've just seen a fork on Github posted by ajbrowe with these code updates included for anyone who wants the complete plugin updated for WooCommerce 2.1.x.

I hope this helps anyone with the same problem. I’d be interested to hear if anyone knows why the character encoding is being mangled between the plugin and ePDQ.