Barclays ePDQ help please:)

[tryfan]

OK, so one thing I've just found is that both epdqresponse.php and epdq_response.php refer to this database table: tblTransLog, however, my table is actually called tbltranslog - so I have to simply change the name to lower case in both files.

This ePDQ situation is ridiculous, we really do need to get the mod on here as one set of files for 1.3.8 - does anyone actually have them, or are we all about to get there at the same time?

[Greybeard]

Im having problems with the final return to the store. I can take payment, but the final return doesnt work. I get a problem with the translog thing to.

When im looking at my database though, i cant see tblTransLog...

Where is yours?

Cheers Rob

[rtnewton]

Hi Guys i have just installed a new zencart and the epdq mod.
Havin major problems with this mod and not really getting anywhere.

When submitting an order to epdq all i get is:

Sorry, there has been a problem processing your payment.

Mandatory information not present.

Not sure weather its a security thing or the mod isn't working correctly or i have installed wrong, any ideas?

[kuroi]

@rtnewton - Did you fill out all the information requested when you installed the mod? In particular the passphrase?

@thesoapycaldron - if you're using the current Zen Cart mod for the CPI service there is no need to password protect any directories.

everybody else ... no idea what this translog table is. What ePDQ services are you trying to access? What mod are you using? Where did you get it from?

[kuroi]

@thesoapycaldron

Are you using CPI? If so the references in the ePDQ documentation to password protecting a directory are to protect the script that would be executed when transaction information is returned from ePDQ. However, the ePDQ mod in the free add-ins area above, doesn't support this. Presumably store owners would need to reconcile orders with payments via their CPI admin page.

Moreover, there seems to be a gaping compatibility issue between ePDQ and Zen Cart. ePDQ CPI assumes that an order is created prior to calling it to to process the payment. Zen Cart is built on the assumption that you don't want your database cluttered up with faled orders, so doesn't create one until payment is received.

And it gets worse.

ePDQ assumes that you already have the order recorded, takes the payment but doesn't force the customer to return, so you have money, but no order. The information is sitting there (at least temporarily) in the customer's basket recorded in the database - but may be lost or changed if the customer subsequently returns to the site.

Can it get worse? Well, yes!

If a client returns to the site from ePDQ, the mod in its current treats that as a success, even if the payment was declined. Order for processing, but no money. Ouch. Those reconciliation processes that the ePDQ docs bang on about are rather important. BUT, worse still, the only reference that ePDQ has for the transaction is a random number generated by the mod and then thrown away. Aie, aie, aie.

The only way that I can see to get around this at the present, is to re-order the Zen Cart checkout, to create an order with a new "unpaid" status before going to ePDQ, and expand the ePDQ mod to take full advantage of the POST information.

If somebody has a better idea, I'd really love to hear it!!!

[rpain]

I see what you mean and yuck, those are nasty scenarios.

I've just finished (well so I thought) a site for a guy using the epdq system and so far the site's quiet so there haven't been any problems but if someone can come up with a solution - maybe a few of us can club together to pay for someone to come up with one then I'd be happy to. If, and hopefully when, his business grows the last thing I want is for there to be payment problems.

Thanks,

Richard

[kuroi]

Hi Richard

We actually sorted this. After several long and sometimes useful, sometimes unproductive conversations with Barclays we got to the bottom of all that what was happening.

For the record, the earlier statement has proven to be completely accurate. And don't be fooled by the message on the final ePDQ page that implies that in fact a transaction is only confirmed if a customer presses that last button. This is not the case, the transaction has been done and the wording is just to try to encourage customers to return to your store.

We therefore built a version that notified Zen Cart as soon as the transaction had gone, and had Zen Cart immediately create a corresponding order. Perfect. Except that after working perfectly on our test server, it reused to work in the same way on the client's web host's server (a Zen Cart-certified host).

So we ended up building two process flows with a switch. One of the flows is optimal, the other has a hole, but with a way to catch and deal with anything falling through it.

Along the way we added an audit trail table and took advantage of more of the ePDQ options (such as not requiring that customers re-enter their shipping information).

I'll post this as an add-in. I'd be interested to know how it works for other people. Won't be supporting it though. I was glad to see the back of it and wouldn't recommend ePDQ unless absolutely necessary.