Implement DPS PxPay 2.0

Here's a re-roll to keep this live in the meantime. For me, it's not working (transaction is not completed on checkout) but I suspect that's due to PXPay 2 not being enabled on my dev a/c.

Patch no longer applies.

The implementation is not exactly the same apart from the POST URL.

The Generate Request response is also different:

PxPay 1:

<Request valid="1">
  <URI>https://sec.paymentexpress.com/pxpay/pxpay.aspx?userid=TestAccount
&request=e88cd9f2f6f301c712ae2106ab2b6137d86e954d2163d1042f73cce130b2c 88c06daaa226629644dc741b16deb77ca14ce4c59db84929eb0280837b92bd2ffec 2fae0b9173c066dab48a0b6d2c0f1006d4d26a8c75269196cc540451030958d257c1 86f587ad92cfa7472b101ef72e45cda3bf905862c2bf58fc214870292d6646f7c4ad 02a75e42fc64839fc50cea8c17f65c6a9b83b9c124e2f20844b63538e13a8cff17ec d8f165aee525632fd3661b591626f5fb77725ade21648fed94553f43bfa69acf3557 0ff8fdcbaf8a13a3fa7deb244017e41749e652a3549a5dbe20c6c3a7a66aa5901e3f 87150f7fc</URI>
</Request>

PxPay 2:

<Request valid="1">
<URI>https://sec.paymentexpress.com/pxmi3/EF4054F622D6C4C1B4F
9AEA59DC91CAD3654CD60ED7ED04110CBC402959AC7CF035878AE
B85D87223</URI>
</Request>

Note the absence of a query string in the latter. The response to commerce_dps_pxpay_generate_request($transaction) needs to be handled differently for PxPay 2 to avoid an "invalid index" error.

Patch updated for current dev, and the Generate Request response is checked for the presence of a query before doing anything with it.

I'm somewhat confused by all this

I am using 7.x-1.0 (not dev) with two production systems using PxPay2, and both work fine.
I'm developing another now, and with 7.x-1.0 I get a "Success" back from PxPay2 (I've had my Dev account altered to a PxPay2 account) though I get an error in the log "checkout//payment/return/ - page not found"
Payment status is success though and order balance is 0

When I try to use the patched dev version of the module, I get payment declined, but no error in the log.

Why is the patch required? PxPay2 seems to work fine (almost) with the released version of the module.

I do have an issue in that a rule I create with a condition that order balance <= 0 doesn't match the condition, despite the balance being 0 when I check the order. Is this somehow related to the error I get in the log?
(Maybe I should be filing a new issue against the released version? Sorry if this is in the wrong place)

At the very least, I need to patch current dev with #2658546: Invalid transaction amount error, otherwise I get an invalid transaction request in the log, and an endless loop on payment redirect.

After that patch, the transaction succeeds but I still need this one to fix an Undefined index: query log message, which is due to the changed URL format for PxPay 2.

Spoke to DPS on this - my account (which is tested fairly often) is PxPay2 and works with the current (dev) code.

DPS advised that if you land on the PxPay1 URL, you will be transparently redirected to the new URL if you have a PxPay2 account. This explains why I hadn't observed missing functionality myself - they are taking care of the first part of the patch attached.

No harm in us offering the option while there's a transition in place; apparently the only people still on PxPay1 are merchants who have specifically requested to do so.

Thanks - will review this change - not sure if I need to (or want to) request a PxPay1 a/c to test that edge case .....

--- a/commerce_dps_pxpay.module
+++ b/commerce_dps_pxpay.module
@@ -366,12 +372,15 @@ function commerce_dps_pxpay_order_form($form, &$form_state, $order, $settings) {
     $parts = parse_url($url);
     $form['#action'] = $parts['scheme'] . '://' . $parts['host'] . $parts['path'];
     $form['#method'] = 'get';
-    parse_str($parts['query'], $data);
-    foreach ($data as $name => $value) {
-      $form[$name] = array(
-        '#type' => 'hidden',
-        '#value' => $value,
-      );
+    // PxPay 1 includes data in the query, PxPay 2 does not.
+    if (isset($parts['query'])) {
+      parse_str($parts['query'], $data);
+      foreach ($data as $name => $value) {
+        $form[$name] = array(
+          '#type' => 'hidden',
+          '#value' => $value,
+        );
+      }
     }
     $form['submit'] = array(

No harm in adding this isset, but I am still seeing commerce_dps_pxpay_generate_request() return a URL with query params here. Which appears to NOT be what you're seeing @JohnPitcairn? I get back -

https://sec.paymentexpress.com/pxmi3/pxpay1.aspx?userid=XXXXXXXXXXXX&req...

(I believed DPS when they told me I'm on PxPay2 but that pxpay1.aspx looks pretty suss.)

Ummm ... yes it does. I definitely get a URL without a query.

OK, seems like our two PxPay 2 accounts are behaving differently, & we need to understand why.

Mine is a developer a/c, and has been upgraded from 1 to 2.

Will come back to this and work with you to identify what's behaving differently :D

Patch reroll against latest dev.

I also have a dev account that's upgraded, not seeing query. Have you explicitly saved DPS settings again?

Patch #12 works for me against latest dev version, thanks Berend.

Spoke to DPS today, hoping to get this committed shortly, just want to confirm my account is *really* acting like a PXPay2 account before I do so.

Update to come ...

DPS confirm the account I'm testing with is PXPay2.

Marking this closed and will cut a release of Commerce DPS accordingly.