Protx VSP Direct 3.x

Hi,

I have been used Protx Direct for a while, it works very well. Tahnk you ceon! However, recently, when the cusomer use Visa Debit card from Halifax and put the issue no in, the web page went blank. the URL will become "index.php?main_page=checkout_payment&payment_error=protx_direct&error=|lt%3B|h3+class%3D%22ErrorInfo%22|gt%3B|Your+card+could+not+be+authorised!+Please+correct+any+details+below+and+try+again%2C+try+another+card+or+|lt%3"

this also happen to Maestro card as well. It seems the somehow, the module cannot handle this kind of error. But I believe the mudule has worked before, it gave error warning in red colour wording if such error occured. I suspect might be I changed codes somewhere it break the module, but I cannot figure it out. This was happened to Protx version 3.42 and I have upgraded to version 3.61, but the problem still here.

The module is still working only if the customers put all of card information correctly.

Have any Protx user got similar issues?

How can I figure it out?

thank you in advance!

Hi Henry,

I don't think the module's failing but instead the code on your site which is supposed to be outputting error messages seems to be failing and causing a PHP error (which - with error reporting turned off - appears as a blank page!).

Please get in contact with me privately, sending me some temporary FTP and admin details and I can log in and take a quick look to see if I can see what's gone wrong!

All the best...

Conor
Ceon

Thanks to Conor, the problem has been fixed. It was some bad codes outside the module which preventing the module from working correctly. This is another example which proves this Protx Direct module is a well-coded module. Also, the owner of this module, Conor, he is not only a genie in coding, he is also a very kind person who always stepping to help if he can! I am glad I've chosen this module. Thank you very a million to Conor!

Hi Conor , I have bought / installed and running your ( ver 3.6.0 ) Mod now for 2 weeks , I have just looked through our transaction logs on VSP and some of the address matching is failing . On the transaction report , it looks like the first line and last line of the address are the only ones to be send to Protx , I wonder if this is why the address does not match . Is this normal ? the transactions are still processing as they match on the post code.

Is this something I should ask Protx about ? Thanks for any advice.

Mark.

Hi

Conor would probably elaborate more, but from:

http://en.wikipedia.org/wiki/Address_Verification_System

'AVS verifies the numeric portions of a cardholders billing address. For example, if your address is 101 Main Street, Highland, CA 92346, AVS will check 101 and 92346.'

I hope this helps.

Craig

Hi Mark,

crazycucumber:

I have just looked through our transaction logs on VSP and some of the address matching is failing . On the transaction report , it looks like the first line and last line of the address are the only ones to be send to Protx

As far as I know the algorithm used to perform the address matching is extremely limited to the point of being fairly useless.

It gets the digits from the first line of the address and the digits from the postcode, combines them and performs the check against that.

We ourselves noticed lots of fails with AVS matching enabled so we have had it disabled for the past year and a half and rely solely on CV2 code and 3D-Secure.

crazycucumber:

I wonder if this is why the address does not match

No, it isn't. It's the fact that many people enter free text addresses differently.. only the first line is used so if they enter something "strange" [unexpected] there (a house name or flat number instead of the street number for example) then the match will fail.

It's a bit annoying that the algorithms are so limited but we've found CV2 code checks (plus additional 3D-Secure checks when appropriate) to be more than reliable, with not one false transaction reported to us yet.

What level of checking you use is of course up to you, I'm just letting you know my own **personal **thoughts on this.

Hope that helps!

(Thanks Craig for your input while I was in the middle of replying! ;) )

All the best...

Conor

Hi,

We set up our Account parameters in the VSP admin as follows:

              **Allow                     No Data Matches**![](https://ukvps.protx.com/vspadmin/images/cross.gif)
              **

Allow Address Match Only**

Allow CV2 Match Only

****Allow Data Not Checked
**
**Allowing Address Match Only results in failed transactions.

Obviously we don't want to allow no data matches.

Data not checked sounds ominous but is unlikely to be used, it's a fallback for banks that don't check the data. I'm not aware of any that operate like this any longer (there used to be some years ago though).

All the best...

Conor

Thanks all for the promt replies .. I will go through and check my settings . We have not turned on 3d secure as yet as we launched in a hurry and not had time to run a few tests yet. hence we are keeping a close eye on the transactions at the moment. Thanks again for the reassurance.

All the best
Mark .

Hi!

Having implemented the ProTX module (which by the way, just plugged in to zen cart with no issues) and done all the tests via the simulated protx server, however now we are on the live server we can process normal payments, however when we switch on 3D-Secure we get a 406 error, any ideas?

Thanks!

Which version are you using? You need 3.6.1 for 3D support.

Regards,

Brent

Brent:

Which version are you using? You need 3.6.1 for 3D support.

Regards,

Brent

Hi

yes I have 3.6.1, without 3D checks payments are fine, it just when the 3D is on I get the 406 error.

Thanks!

Hi.

Have you fixed this yet?

I had a similar 406 error a while ago. I added the following code to this file:

includes/application_top.php

as instructed here:
https://www.zen-cart.com/tutorials/index.php?article=320

And removing the code removed my problem.

Craig

I've just installed 3.6.1 onto 1.38 Zen Cart.

I don't yet have a protx account for this installation, so I'm using the VSP Simulator to try and connect to.

The first issue I had - the VSPProtocol was being sent as 2.22, but the Simulator (I assume) was expecting 2.23. I manually edited the php file to correct the version, but I stiall have a problem...

When I confirm the payment, I get:

Your card could not be authorised! Please correct any details below and try again, try another card or contact us for further assistance.
(If the BillingPostCode is supplied, you must provide all non optional Billing details.)

The Billing Address is complete, with no missing fields. I've tried with (and without) the test billing checkbox ticked, and with/without the AVS and 3dSecure settings enabled in the protx setup.

Starting to tear my hair out... what have I done wrong?

Hi,

Happy St Paddy's day!

timetex:

The first issue I had - the VSPProtocol was being sent as 2.22,

I'm sorry you've had trouble with the module. You are indeed correct, the simulator no longer works with 2.22, which is what versions 3.6.1 and below support.

Protx introduced the new protocol with a whole 4 days notice, all of which I was on holiday for so I had no chance to update the module for 2.23 in time!

Version 3.8.0 is complete and due for release tomorrow. However I can send you a version now if you contact me privately.

timetex:

but the Simulator (I assume) was expecting 2.23. I manually edited the php file to correct the version, but I stiall have a problem...

Lol, I'm afraid just changing the number won't work, some of the fundamentals of the protocol have changed.

As I said, you can get in contact with me for the new version, wait for the new version, or simply carry out your testing using the Test server instead of the Simulator as it is backwards compatible with 2.22 (and will be for some time reassuringly)!

Once again, sorry you encountered these problems, it's impossible to write software for a protocol if the company doesn't inform you it's going to change, with sufficient notice!

All the best...

Conor
Ceon

conor:

Hi,

Happy St Paddy's day!

I'm sorry you've had trouble with the module. You are indeed correct, the simulator no longer works with 2.22, which is what versions 3.6.1 and below support.

Protx introduced the new protocol with a whole 4 days notice, all of which I was on holiday for so I had no chance to update the module for 2.23 in time!

Version 3.8.0 is complete and due for release tomorrow. However I can send you a version now if you contact me privately.

Lol, I'm afraid just changing the number won't work, some of the fundamentals of the protocol have changed.

As I said, you can get in contact with me for the new version, wait for the new version, or simply carry out your testing using the Test server instead of the Simulator as it is backwards compatible with 2.22 (and will be for some time reassuringly)!

Once again, sorry you encountered these problems, it's impossible to write software for a protocol if the company doesn't inform you it's going to change, with sufficient notice!

All the best...

Conor
Ceon

Thanks for the quick response, Conor... I'm giving up for the day, but would appreciate an early look at the 3.8 release, I can be emailed - [email protected].

I have rechanged the protocol version back to 2.22 and am trying against the VSP Test, as I dug out the login details for our other site and added the IP address accordingly.

I tried 2 cards, both returned "Declined by the bank"... so at least it is checking something now (it wasn't before).

Hi,

timetex:

Thanks for the quick response, Conor... I'm giving up for the day, but would appreciate an early look at the 3.8 release

No problem. Once again, my apologies that you had to waste time on this!

All the best...

Conor
Ceon

Im having an issue similar to what a user a few posts ago had. We originally had the free version of this module installed and it worked great, but we needed support for Meastro so we upgraded to the 3.61 version.

Now in test mode, successful transactions are fine, but ones that fail bring the user to a blank page with error in the get variables of

|lt%3B|p+class%3D"ErrorInfo"|gt%3B|The+card+number+entered+is+invalid.+Please+check+the+number+and+try+again%2C+try+another+card+or+|lt%3B|a+href%3D"index.php%3Fmain_page%3Dcontact_us"|gt%3B|contact+us|lt%3B|%2Fa|gt%3B|+for+further+assistance.|lt%3B|%2Fp|gt%3B|

Trying to solve this on my own, I can see that includes/modules/pages/checkout_payment/header_php.php checks to see if $_GET['payment_error'] is set and then sets $error to the payment modules function get_error. It then adds $error to the message stack.

So I went to protx_direct.php and the get_error function seems sound.

So, Im confused as to where the error comes with this. if I change the error from that big mess of hooplah to something simple like "error" it does not break. So i figure something is going wrong with either parsing that get string, or with the function that sets that get string. Cause something with that string is breaking the site.

Any help?

Hi,

ajlisowski:

Now in test mode, successful transactions are fine, but ones that fail bring the user to a blank page with error in the get variables of

This isn't a problem with the module or Zen Cart but the server settings.

mod_security must be installed on your server and is causing the blank page because it only allows the query string to have a short length. The long error messages are exceeding this setting.

Please get in contact with me privately and I'll see what I can do to help you get this fixed!

All the best...

Conor
Ceon

Hi,

Just want to post here to inform those using the Protx Direct module about the fact that Protx have changed their name to SagePay.

The module will be discontinued and a new SagePay module will be released instead. It'll essentially be the same except for changing the name. It'll simply be renamed to sagepay_direct instead of protx_direct and will have both the Protx and Sage Pay logos. There's a good 6 months for everyone to upgrade (no charge of course) so there's no rush.

All you'll have to do is install the module, copy across your configuration settings, disable the "old" protx_direct module and that's it, just use the sagepay_direct module as if nothing had happened!

Once customers get used to "SagePay" (or "Sage Pay"), the Protx logo can be disabled in the sidebox.

All the best...

Conor
Ceon

hi
i've recently had this module installed and when checked with our test account with sagepay the 3d secure worked... but now that we have gone live with the module, we can receive payments but the 3d secure bit never happens (i've tried 3 cards, one of which is definitely registed for Verified by Visa)... is there something i'm missing in the configuration?
I have turned on 3d secure in the admin of sagepay and have ticked the "Perform the 3D-Secure Authentication" box in the rules section... and in my cart admin the 3d secure option i have selected is: If 3D-Secure checks are possible and rules allow, perform the checks and apply the authorisation rules. (Default)

hopefully someone can shed a bit of much needed light on the matter!
thanks
john