Deprecate PxAccess

I'm thinking we just deprecate PxAccess. AFAICT it offers no functionality over PxPay, and adds (or suggests) additional requirements.

Thinking I'll add a warning to migrate to PxPay in 7.x-1.x-dev.

I asked DPS whether there would be implications for sites using PxAccess if we dropped that module in favour of PxPay.

I'm wondering if it's worth retaining both PxAccess and PxPay in the module, given that PxPay seems to offer feature parity and appears simpler.

According to your website, PxAccess requires a Windows COM component - but the PxAccess module woks without this on Linux.

Can you help me understand why someone would choose one over the other? Are there situations where one or the other is not appropriate to deploy? Are there features only offered by one or the other?

Mohammad replied,

PxPay and PxPost is our widely used API. PxAccess is quite similar to PxPay, the big difference between PxPay and PxAccess is how we encrypt the data.
The end object is the same for PxPay and PxAccess i.e they both redirect to DPS hosted page.

PxAccess is not worth implementing since you have already implemented PxPay.

I asked again to be sure, if there would be implications for existing PxAccess sites if we retired support for that version.

Mohammad again,

PxPay and PxAccess both have the same username, key and have the same setup in our system. So if a users decideds to update to use the new PxPay module you have created, they will be fine.

Based on this, I intend removing PxAccess in the 7.x-1.x branch, and I'd welcome input on how to handle this for the 6.x branch.

I must be missing something because looking at the Drupal 6 version of the PxPay module I can't see where the data is encoded or decoded? It looks like unencrypted XML which doesn't make sense without an SSL connection, or as a GET variable.

If I can figure it out I'll compare to the PxAccess result object to see what if any difference it will make, particularly with regard to the Internet Explorer URL length restriction.

Connections to the PxPay (and PxAccess) server are HTTPS (from 'uc_dps_pxpay_server' variable) so the MifMessage is XML over an encrypted transport. We don't encrypt, but we do validate the data sent and received based on a hash of the submitted values and shared secret which is known only to each end.

The response received is not over HTTPS though which is one of the main reasons we use this method, makes it cheaper and easier with small sites. I'm sure I read somewhere on the DPS site that PXPay does not require SSL either.

The PXAccess code in pxaccess.inc both encrypts the message sent and decrypts the response using mcrypt (also base64 encoding/decoding for shortening in the later version), I don't see the equivalent in the PXPay_curl.inc code.

If PXPay does indeed require an SSL connection for the response then that would be a dealbreaker for some sites which would make keeping PXAccess worthwhile. I can see that there is no point in implementing one method if you are already using the other as they are functionally equivalent particularly from the user's perspective, but if they have different requirements like this then its a different story.

I must be missing something though...?

You're right, the reply from DPS may be unencrypted.

We share a pre-arranged secret: ABCDEF. I send you an order with some values: { AccountID: 12345, Amount: 50 }. You ping me back with a response: { AccountID: 12345, Amount: 50, Response: 'ok', Hash: '4936a39d5b208f3c3f3cfafab2b08f79' }. I remove Hash: FOO from your reply and insert Secret: 'ABCDEF' in its place. Then I hash the reply including the secret, and compare the generated hash with the one you supplied. If the hashes match, then you know the shared secret and are not an impostor*.

An imposter may listen in on the conversation, but without knowing the shared secret they can't participate (assuming both ends bother to check the hashing).

* or, you stole the hash

Ah I see it now sorry - only the hash is sent clear in the URL, everything else uses cURL (with POSTed data over SSL) and gets the response directly.

Compared to PXAccess:

• Since the hash is far shorter than having the entire response encrypted into the URL, there isn't really any way that the Internet Explorer URL length issue will arise.
• I'm not completely convinced that all the issues with user/session are resolved by using the PXPay module over the PXAccess one; it redirects to cart/checkout/complete rather than calling uc_cart_complete_sale() itself but the same issues apply. Some session tweaks have been made though and either way it can't be any worse (if there is a problem here it belongs in a separate issue anyway)
• When it comes down to it I do agree that they are functionally equivalent, PXAccess requires mcrypt whereas PXPay requires cURL. I'm guessing that PXAccess has its roots in the Windows COM object even though it can be used by anything that supports the encryption hence the slightly unusual methodology, the PXPay version is much closer to the norm for a web payment gateway.

Given the assurance from DPS above that they offer both of these options interchangeably to the same customers I agree that its pointless to support both, and the PXPay method is a bit cleaner and more reliable in the Ubercart context. Not sure now why I even started using PXAccess? I will use PXPay in future, might look at changing existing clients at some stage.

Thanks

Any feedback you can give on transitioning clients is most welcome.

Rather than curl I'll prob rewrite the include to use drupal_http_request() and built in php XML. Current code is for php4, don't need those dependencies now.

Thanks!

To switch from PxAccess to PxPay, add your PxAccess MAC key to the end of your PxAccess key to obtain your PxPay key.

Tested transition on a 6.x site yesterday, worked fine.