Protx VSP Direct v2.0.0

[limbo90]

I found this script most helpful when trying to ascertain the IP my host uses (as opposed to the IP my domain is situated at.

For less techy readers, you can use this script by replacing the ceon.net domain with one of your own. You can then locate your raw log files (usually called access.log), open it up in a text editor and check the last few entries for the string WHATISTHISSERVERSIP. Or if you have a command line access then use the 'tail' command to find the last few entries like so:

tail access.log

cheers

limbo90

Hi,

The IP address your server is using is different from the IP address your site is hosted at.

Please upload the following script to your server and call it from your browser:
-------
<?php

$url = 'http://ceon.net/WHATISTHISSERVERSIP';

$contents = @file_get_contents($url);

print "Contact me now to let me know that you've carried out this test and I'll get the IP address from my logs!";

exit;

?>
------
As the message says, please let me know when you've done this and I can see what IP address your server contacted mine from.

All the best...

Conor
ceon

[Pixxi]

Just an FYI ...

We've had a couple of transactions now where the customer has received the error message 'Technical problem contacting the Protx gateway' and no order has appeared in the shop, but Protx has actually authorised the transaction and taken the funds from the customer's card.

On one of these occasions the customer tried (and 'failed') twice with Protx before emailing us. We checked in the Protx admin and no transactions were being shown as received/authorised for the customer, so we suggested he used Paypal instead - and the transaction went through fine.

(We also checked the Protx admin the next day - no transactions for the customer were showing then either).

The customer has just emailed us on getting his card statement and it seems his card was debited twice by Protx. We've just checked the Protx admin again today (3 weeks since the transaction) and it now shows the two authorisations.

Obviously, the transactions apparently not showing in the Protx admin is a Protx problem, and nothing to do with the mod - but it's something to be aware of if anyone has any customers who get the 'Technical error contacting payment gateway' error.

With respect to the 'Technical problem contacting the payment gateway' error, there's a post on the (new) Protx forum here:

https://support.protx.com/forum/Topic277-22-1.aspx

that suggests that the default cURL timeout might be set too low for times when Protx and/or the banks are busy - the default in the Protx integration kit is 30 seconds, same as in the Protx module.

We've upped the timeout to 120 seconds to see if that helps to avoid the problem, although, obviously, customers are likely to give up anyway if they have to wait that long ...

includes/modules/payment/protx_direct.php, line 950:

        curl_setopt($ch, CURLOPT_TIMEOUT, 120); 

[Brent]

On one of these occasions the customer tried (and 'failed') twice with Protx before emailing us. We checked in the Protx admin and no transactions were being shown as received/authorised for the customer, so we suggested he used Paypal instead - and the transaction went through fine.

I've had the same thing happen to me about 4 or 5 times. When I queried this with Protx they came back with the following:

This was because the transactions took a long time to archive. This will have been caused by the response from Streamline taking longer then normal to be sent resulting in the response timing out and the customer receiving no finalisation to the order. The VSP Admin area only displays archived transactions this is the reason you could not view the transactions in the Admin area.



Regards

Protx Support

I'd be interested to hear the results of increasing the timeout as Protx have advised me to do the same.

[conor]

Hi Brent and Pixxi,

I'd be interested to hear the results of increasing the timeout as Protx have advised me to do the same.

I'd appreciate it if you could keep us up to date on this.

If timeouts should be increased I may change the default for the module. However, PHP scripts themselves normally default to timing out after 30 seconds so the timeout limit for the PHP installation would also have to be increased. On most servers a simple call to ini_set should be enough for this though and I would also add that line to the module's code.

I'll leave things as they are for the minute but as I said, please keep us up to date... it's probably better for just a few people to keep in contact with protx about this rather than lots of us contacting them separately.

Oh, as for customers giving up, a nice "processing" animation and warning that it could take up to two minutes would alleviate most customers' worries... once people have pressed "confirm" they'd be pretty nervous to just abandon the site. Disabling of the confirm button/form submission after having been pressed/submitted once would become an essential additional feature but that's not much work (and should possibly be part of the mod now anyway).

Thanks for taking the time to post here and Happy New Year! :)

All the best...

Conor
[protx-module-making-type-person]

[Pixxi]

@Brent

Thanks for confirming you have also experienced this - I'll also have a word with Protx tomorrow and see if it's possible to clarify the 'archiving' thing. I would have thought that the transaction should show up pretty quickly in the Protx admin (it usually does, within a few seconds), but if it's delayed like this we won't be able to let the customer know if the transaction has gone through for (possibly) several hours.

@Conor

Earlier in this thread Brent was asking about the confirmation email that Protx can send to the shop owner if the mod requests it. Maybe it would be helpful to implement that, then at least the shop owner will have a warning that the transaction(s) has/have gone through (even if no order appears in the shop) and can refund/contact the customer.

Your point about the PHP script timeout is apt ...

Could you perhaps post the ini_set code and the file(s) it needs to go in, then we can test both timeouts together, so to speak? No point, of course, increasing the timeout on the mod to 120 secs if the PHP script timeout is still set at 30 secs ...

Thanks for your input.

[Brent]

...I'll also have a word with Protx tomorrow and see if it's possible to clarify the 'archiving' thing. I would have thought that the transaction should show up pretty quickly in the Protx admin (it usually does, within a few seconds), but if it's delayed like this we won't be able to let the customer know if the transaction has gone through for (possibly) several hours.

When this last happened I had an email from a regular customer saying they had attempted to complete an order twice but nothing happened - no errors etc. I checked VSP Admin but there was nothing there. I then called my customer got their card details, logged into their account and attempted to place the order but got the card declined message. Checked VSP Admin but still nothing. Approximately an hour must have passed by now.

Protx said all was well their end so decided to call Streamline. Turns out my attempt was blocked as fraud was suspected with 3 attempts in short succession. Streamline confirmed 2 successful transactions.

Eventually all transactions appeared in VSP Admin.

It would be good to hear what Protx tell you as it seems recently that the advice does seem to depend on who you get on the other end of the phone. A case in point is the email issue discussed below. Also when I asked them about the timing issues I was also told their server continued to attempt to contact my server to confirm the transaction at 15 minute intervals increasing over time until it timed out. Another member of staff later then told me this was not the case and did not apply to VSP Direct but only Form.

Earlier in this thread Brent was asking about the confirmation email that Protx can send to the shop owner if the mod requests it.

Unfortunately when about a month later I pushed Protx asking for further instructions I was informed their original advice was incorrect. This is not an option with VSP Direct as the whole transaction is completed in one session.

Pixxi, Have you ever had cases of double charging? ZC reports 1 order but VSP Admin records two unique transactions?

I've even had the ultimate with a combination of both problems with no order recorded in ZC but funds being taken twice from the customers card.

It would be useful if Conor's Mod could store the order details as the PayPal one does. That way you could at least force/recover the order. When I last asked him about this some time back he thought he could do it but would require a substantial re-write. I have already sent him a "thank you" when I installed his mod but would be happy to contribute again. Perhaps if enough of us put a fund together we could see if he would add this functionality?

Brent

PS. For anyone about to install this mod I don't want them to get the impression it is all doom and gloom. As a total percentage of all orders these problem ones are only tiny fraction. Probably about 5 over the space of 12 months. I highly recommend Conor's mod

[Pixxi]

Hi Brent,

My call to Protx tech support was similar to yours - the guy didn't really know much about anything (kept putting me on hold to talk to the guy sitting next to him and was quite disinterested) but the following points emerged:

1. The Protx timeout is 60 seconds (allegedly ...) not 30 seconds as they have in their integration kit.

2. Protx compiles it's transactions from the previous day between midnight and 2am; then settles them with the banks between 2am and 4am - tech support claim that transactions aren't 'archived' (ie. don't appear in the VSP admin) until after the settlement run ends - which seems absolutely ludicrous for a real-time transaction processing system. Did you have missing Txs during the day?

3. The email confirming the Tx to the vendor is only in VSP Form.

I've asked tech support to send a request to the Protx dev team to add the vendor confirmation email (and also for a confirmation of refund email) to VSP Direct, and asking them to investigate the delay in 'archiving' - I've also posted on their forum to the same effect.

In the meantime, perhaps the best interim solution would be to increase the PHP timeout to at least 60 seconds.

Have you ever had cases of double charging? ZC reports 1 order but VSP Admin records two unique transactions?

Only where the customer has clicked the 'Confirm' button twice - then we got two Txs authorised through Protx timed a few seconds apart, but (I think) only one order in the shop.

[Brent]

2. Protx compiles it's transactions from the previous day between midnight and 2am; then settles them with the banks between 2am and 4am - tech support claim that transactions aren't 'archived' (ie. don't appear in the VSP admin) until after the settlement run ends - which seems absolutely ludicrous for a real-time transaction processing system. Did you have missing Txs during the day?

Hi Pixxi,

The first bit is correct but as you suspect the last bit is cobblers. If this is the case maybe they would like to explain what the "Void" feature is for?

I have on numerous occasions voided transactions before they are settled as there are then no refund charges applicable.

Also if you think back when you first installed the mod did you run a few live transactions after testing was finished? The transactions appeared almost immediately when I did.

I find it now better to email Protx as they seem to pass anything complicated on to somebody who is competent to answer whereas when you call them you get put on hold and then told the something to get rid of you. This is what they want however as their primary form of contact is via email. The problem is despite what they say you do get a quicker answer if you ring. Only problem is it may be wrong.

Brent

[cmwoods]

Sir,

I am trying to install your mod but cannot get it to appear in the payment modules list for installation, in fact most of them are missing and I cannot edit the ones which are there.

As anyone else got this prob or am I missing something really obvious. I have followed your instructions and successfully installed a number of other mods previously with no probs but this has me stumped.

Running 1.3.5 Would Admin Profiles be the cause as that was the last mod I installed?

Please help as I'd like to get this module set up and tested.

Many Thanks

--
Chris Woods

[SarahL]

Hi Chris - if I am honest it sounds like your initial install went wrong for zen cart itself - otherwise you would be able to see all the standard payment modules

which means you either have to roll back to the inital install or redo it from scratch and make sure its all working "out-of-the-box" before you start adding anything new

I doubt it has anything to do with this module - as it just well works