ePDQ module for v1.5.0

I have just installed the latest version (Dec 2012) of Barclay's ePDQ payment interface, you can get the updated Zen Cart payment module by asking the ePDQ support team. They provide it purely "as is" ie unsupported. It seems to have been developed for version 1.3.9 but works ok with v1.5.0, there are a few issues which might cause some headaches-

1. ePDQ expects the monetary amount to be charged to the credit/debit card without a decimal point (ie in pence). The Zen module does this by multiplying the total order amount by 100, which assumes there are no fractions of a penny. You may have fractions if your shipping is a percentage of the order total - the order confirmation pages automatically round up to display the amounts, but when the data is passed to ePDQ you'll see the message

"amount too long or not numeric" or "amount not a number"

because you have a decimal point in the amount. I added a round() function on the order total amount to fix this.

2. I don't know if its just my installation but if a customer has not provided a telephone number in their account the ePDQ module fails with the message:

"unknown order/1/s"

Something to do with the SHASIGN data check on the ePDQ side of things (telephone number is not marked as mandatory but it seems to be). I added some code to default the phone number to 0 if none has been supplied to fix this.

3. You will not get ePDQ to work if the URL calling it includes the ZENID parameter eg if using a shared SSL certificate (you will probably see error "unknown order/1/r"). EPDQ needs a consistent URL to call it.

Perhaps this info will help someone else. :smile:
Mick

Thanks Mark. This has been useful information to me.

I have installed and I'm now at the testing stage. I'm stuck on your third point:

3. You will not get ePDQ to work if the URL calling it includes the ZENID parameter eg if using a shared SSL certificate (you will probably see error "unknown order/1/r"). EPDQ needs a consistent URL to call it.

My test account does contain a phone number but I get "unknown order/1/r"

Any ideas how I can resolve it? Are you saying that I need to remove or disable to SSL cert in order for ePDQ to work?

Thanks :-)

Redspan:

Any ideas how I can resolve it? Are you saying that I need to remove or disable to SSL cert in order for ePDQ to work?

Our ePDQ runs fine in a full SSL environment ie we bought an SSL certificate for the domain, the problem I found earlier was using a shared SSL certificate in a testing environment.

With shared SSL Zencart calls the ePDQ module with a variable token (zenid) in the URL and it needs to be called with a fixed URL I guess for security.

In your ePDQ technical settings for "Data and origin verification -> URL of the merchant page containing the payment form that will call the page:orderstandard.asp" make sure the URL is correct. Ours is the https domain followed by

/index.php?main_page=checkout_confirmation

If you are running with a shared certificate you will need to purchase a full SSL certificate for your domain unless you can strip the zenid out of the URL before calling ePDQ. I think the general advice is its better to not use shared SSL with Zencart for a live website.

Cheers,
Mick

I'm fairly sure my SSL cert is for the domain. I've tested both the site and checked the account where the cert is registered and everything is in order. There's no mention of it being shared and it refers to the domain itself.

I've checked that are of the settings you mentioned and it's all correct, and the SHA IN and OUT match correctly.

I've got ePDQ support to raise a ticket....

Sounds an odd problem - error "unknown order/1/r" is listed only as a mismatch between the calling URL and what you have configured in your ePDQ tech settings. If your SSL domain looks like https://<your_domain> then its not shared. The "zenid" token can show up in the URL for various reasons, search in the forum for more info.

I found it useful to see exactly what was being called and the parameters being passed - in a Chrome browser run through an order checkout, at step 2 of 3 right click the "Continue Checkout" button and choose "Inspect element". The "action" setting on the form named "checkout_payment" should match your "Data and origin verification -> URL of the merchant page containing the payment form that will call the page:orderstandard.asp" setting.

If you do "Inspect element" on the "Confirm the order" button at step 3 of 3 you see the call to ePDQ and the parameters being passed.

Support was helpful but quite slow, I hope they can sort it for you.
Cheers,
Mick

Well that got me one step closer!

I did as you suggested and the data passed includes http:// not https://, so once I'd amended the epdq settings I got to the card information screen. The amount of the transaction was there where before it was missing.

I see the test info that Barclaycard provide includes card numbers but no expiry or CSV number, so I've yet to find out how to finish the test but I expect a call to them will resolve that.

Isn't it a bit of security risk that anyone can view these same details?

Redspan:

I see the test info that Barclaycard provide includes card numbers but no expiry or CSV number, so I've yet to find out how to finish the test
It's very common that the use of "test" card numbers can be coincided with "any future date" and "any 3-digit number" for expiry/CVV respectively. Some systems use specific dates and specific CVV values to trigger a specific error response in test mode, but it should be safe to start with something like that.

You're quite right DrByte, 01/2013 and 123 work fine. Should've tried that at least - thanks!

Now, testing Visa and Mastercard with amounts and card numbers, each payment is authorised and I see the 'return to site' button.

Only trouble is, when I'm returned to the site the message is "Please accept our apologies. There has been an error in processing your payment, please try again."

Is this normal for tests?

Redspan:

Is this normal for tests?
Probably not.
You'll have to work with your gateway tech staff on that.

DrByte:

Probably not.
You'll have to work with your gateway tech staff on that.

You mean ePDQ support? I have a ticket open.

I guest the problem lies with my own site because these test ePDQ orders aren't showing up in the Orders section of the ZC admin area.

I know orders work with PayPal as the site has successfully processed such an order, but wouldn't test ePDQ orders get listed (to be deleted after the tests conclude)?

Looking at the logs, the payment was completed successfully and returned to https://www.blahblah.com/index.php?main_page=checkout_process appended with a list of parameters and values confirming the success of the payment request (shown below - this was returned for Order I.D xxxxxxxxxx

edit

In terms of the error message, as this appears on your site, it would appear that there is an issue with how you are handling the response from ePDQ.
This was their response. I guess I need to look at my site in more detail.

The message "Please accept our apologies. There has been an error in processing your payment, please try again." is a hashing mismatch on the return to Zencart, check your Zencart Passphase Out exactly matches whats in the ePDQ tech settings.
Test orders will appear like any other order once this works.
Sounds like you're not far off getting it working.
Cheers,
Mick

Redspan:

appended with a list of parameters and values confirming the success of the payment request
Can you share that list of parameters and values?

zedmick:

I have just installed the latest version (Dec 2012) of Barclay's ePDQ payment interface, you can get the updated Zen Cart payment module by asking the ePDQ support team. They provide it purely "as is" ie unsupported. It seems to have been developed for version 1.3.9 but works ok with v1.5.0, there are a few issues which might cause some headaches-

Who currently is working on this since I'd kinda like a copy and nobody I contact seems to reply...

marach:

Who currently is working on this since I'd kinda like a copy and nobody I contact seems to reply...

The ePDQ support team should give you a copy on request, can be a bit slow in replying...

I've been away but I'm still working on this. I still have a ticket open with ePDQ Support.

DrByte:

Can you share that list of parameters and values?

3:16:42 PM : https://www.blahblah.com/index.php?main_page=checkout_process&orderID=00xxxxxxx3&currency=GBP&amount=14%2E98&PM=CreditCard&ACCEPTANCE=test123&STATUS=5&CARDNO=XXXXXXXXXXXX1111&ED=0113&CN=Andy+Customer&TRXDATE=01%2F31%2F13&PAYID=xxxxxxxx&NCERROR=0&BRAND=VISA&IP=1%2E11%2E1%2E1&SHASIGN=hashhashhashhashhashhashhashhash

ePDQ's comments were:

I would suggest turning off the setting that includes the transaction parameters to your redirect URL(s), to see if the same message occurs on your page. This would confirm if it is the information being sent back that is causing the problem on your page, but ultimately we are not able to confirm anything of detail on what you should do on your site.

All we can confirm is that ePDQ has sent the parameters appended to your redirect URL, shown in my earlier email, and typically your redirect URL would handle this data.?

How do I do this? turning off the setting that includes the transaction parameters to your redirect URL(s)

Redspan:

How do I do this? turning off the setting that includes the transaction parameters to your redirect URL(s)
I'm guessing that that's a setting in your ePDQ account on their site.
Or, again guessing, maybe it's a setting in your ePDQ module in your Zen Cart admin?

Zen Cart's security system doesn't like long parameters in URLs, since that's often what hackers use when probing sites for vulnerabilities. It could be that the SHASIGN=hashhashhashhashhashhashhashhashhashhashhashhashhashhash is throwing it.

That's it :smile:

I deselected* I would like to receive transaction feedback parameters on the redirection URLs* in the edpdq settings and ran a test and the order completed correctly.

Thank you for your help and suggestions :smile:

zedmick:

The ePDQ support team should give you a copy on request, can be a bit slow in replying...

All I'm getting from them at the moment is static "I'm sorry I have no information on that, the module should be provided by zen-cart themselves"