Protx VSP Direct v2.0.0

[conor]

Hi Pixxi,

Would it be possible to disable the action of the 'confirm' button (for that particular customer, maybe based on session ID) once the customer has clicked it to prevent this happening?

Unfortunately this is a problem with many e-commerce shops, one that is caused purely by users accidentally due to their own inexperience (and normally impatience! :) ).

There are ways that this could be avoided more so than they are now...

as you've said, the module could check if a Protx transaction for the shop has been recorded for that customer within the past few seconds and, if so, warn them, but the internet (or rather the TCP/IP protocol) doesn't guarantee that requests are served in any order and while the server is running the "existing order check" the duplicate order request could just be running. I would therefore have to make sure that the fact that a call to Protx is going to be made is recorded before making any such request, so that a check could be made that a call's not in progress.

This is all possible but it could again be circumvented by latency in the database SQL calls as Zen cart doesn't use transactions.

As this problem affects all Zen Cart payment methods which must communicate with other servers (as in not just record a number for manual processing later) this is something they may be fixing in a coming version.

So I'm not sure it's worth my time putting in the effort to get this particular method working?!

Another method would be to insert some javascript into the form checking code to disable the submit button after it has been pressed once.

Personally I find that quite inconvenient normally, as the webmail software we use used the same idea, but I found a few times that things would mess up and I'd have to reload the whole page; I noticed recently that this functionality has been taken out of more up-to-date versions of the webmail software so I guess I wasn't the only one having difficulties with this "kludgy" attempt to fix the problem.

So all in all, due to the relative infrequency of occurance of this problem, I'd be inclined to say that this is an error that may best just be suffered and handled manually.

I'm interested in yours (and other people's) thoughts on this though.

All the best..

Conor
ceon

[conor]

Hi,

A slightly updated version of the module has been released!

Here's the snippet from the Version History:

[BUGFIX] Tests were being made against the POSTed values of CVV Number, Start Date and Issue Number even if these options weren't enabled.

[UPDATED] Removed the form_action_url property as it was not used by the module.

[UPDATED] Documentation updated to give more accurate information for Zen Cart 1.3.5.

There is no need for anyone running 2.0.3 to upgrade as so little has changed. It's easy to upgrade if you want to though - instructions are on the website.

You can always find the latest versions at the contribution's site:

http://dev.ceon.net/web/zen-cart/protx_direct

Enjoy!

All the best...

Conor
ceon

[Brent]

Hi Conor,

As you know I've had the duplicate order problem in the past but I've now got one where Protx has charged the card twice but no order has been registered.

I was wondering if there is any way to manually process the order or could DrByte's PayPal Session Viewer be modified to do the same for Protx?

Regards

Brent

[conor]

Hi Brent,

I'm sorry to say but I've no idea what has happened there. Are you having server problems?

I don't see how the Protx Transaction could take place but the order not be created... as with all other Payment Modules, once the before_process method has been called the after_process call is made and the order created by the Zen Cart code.

The only three ways this could not have happened is if Debug mode was on, if the Protx call was sent (and processed by Protx) but never returned or if your server crashed after the call to Protx.

As you can see, in those last two cases adding code to save the session would make no difference as it, just like the order creation code, would never get a chance to run.

There is no way to manually process the order. However, the Unique Transaction ID (VendorTxCode) is made up of the time then the customer's id then the customer's surname, so you can identify the customer, refund their card and contact them to ask them to put it through again.

I'm sorry I couldn't be more help than that but there's really nothing at all I can do to help in this occasion, it's not a problem with the module I'm afraid!

All the best...

Conor

[Brent]

Hi Conor,

Don't think it's your mod either.

Probably the same as the PayPal issue that occurs occasionally. You get an email from PayPal confirming you have funds but there is nothing in the store. Happens when PayPal doesn't send the confirmation back to the store. Surely the same could happen with Protx?

With all orders the info is sitting in the database waiting to be processed as soon as PayPal returns its payment confirmation. When PayPal doesn't do its bit the order just sits there. DrByte wrote a mod that allows you to view these stuck orders and then manually push them across as orders.

I think your second suggestion is probably the reason. I know that PayPal tries for days to return its response. I had an issue a while back where my host tightened up their mod_security rule set. This blocked PayPal's IPN response but when the problem was fixed a day and a half later my orders started appearing. I wonder if Protx does the same? If so this would rule out server problems my end as when the server came back it would then accept Protx's confirmation.

Regards

Brent

[conor]

Hi Brent,

Just took a look at that mod and can see what it's doing...

The Paypal payment module is recording the details of the order before it attempts to send it. That way, if there's any problem in getting a response, the order information can be rescued.

It does indeed sound like Protx didn't reply properly (or your server didn't listen properly, could have been right in the middle of a httpd restart or something) but Protx doesn't work in quite the same way as Paypal. Paypal registers a callback URL and then processes the returned information using the order information it stored earlier, however Protx Direct actually calls Protx (via cURL) and waits for the response there and then. If your php script times out or stops running before this response is received then the order isn't created even though the card may have been charged. I can't think of any technical way around this as there is no way to "keep a tabs on the progress of a cURL session" - if you could, then a check on how it's going and how long the php script has left to run, according to max_execution time, could be made).

It's quite unlikely that this will happen often but if I can ever think of a way to get around the problem (basically if I can sort out how to check the progress of the cURL transaction) I may update the module to record the order info before sending so that it could be recovered manually if the script failed. I currently don't think it's possible though.

One other thing... the user will never have got to the "Order Successful" page so a refund and a request to put the order though again may be better business practice!

All the best...

Conor
ceon

[Brent]

Hi Conor,

Yes, no confirmation at all and as it was a tiny order the customer just assumed our store wasn't functioning and moved on. He then got his CC statement before we had had a chance to reconcile our Protx Batch details with our orders.

He noticed we had charged his card twice and rang us. As the attempted order was place a couple of weeks ago I've just placed the order for him using the master password.

To be honest your Mod and Protx have been so rock solid I haven't really monitored anything on a daily basis and concentrated on order processing. My fault. With PayPal you get the email from them but nothing from the store so alarm bells ring immediately. I'll just monitor Protx more closely in future.

Once again thanks for all your help.

Regards

Brent

[conor]

Hi Brent,

Do you not get a Protx email as well? If not, I think you can set it up so you can... that way if you get a Protx confirmation e-mail but no corresponding ZC order e-mail then you'll know something's happened.

Regardless, I may update the module with a status database separate to the main payment features of protx (so that all transactions which were started but never completed are highlighted in the admin - on the homepage in BIG writing! :) ).

We're really, really busy at the minute so it may be a few months before I get round to doing that.

All the best...

Conor

[Brent]

Hi Conor,

There are no configurable email settings in the Protx Control Panel so I dropped them a line. Here is their response:-

If you want to add an email address where your transaction notifications go to each time a transaction is processed, you can this within your shopping cart settings. Each time your website sends us a transaction it passes us a Vendor email address to which we send the notification email.

You will need to consult your web developer or the shopping cart software support to find out where this address can be changed.

Regards,

Protx Support

I presume this would need to be a function of your Mod and not ZC? Another item for your to do list.

Regarding further updates no rush as what I already have is perfectly sufficient for my needs.

Regards

Brent

[SarahL]

Hi Conor - or anyone

Do you have this working in the latest v1.3.5 version of Zen Cart?

Its just it was working on protx test server - wentto live server and I keep getting this error

Your card could not be authorised! Please correct any details below and try again or contact us for further assistance.
(Authorisation declined by bank. - Message : DECLINED)

Used 2 different cards (visa and mastercard) any ideas?

I have emailed protx who said its a shop fault and to speak to the web developer - lol which is me :):)

Any ideas or pointers would be great :) as its a great mod and works perfectly on the other shops I use it on

thank you
Sarah