Protx VSP Direct v2.0.0

Hi,

It gives us great pleasure to release version 2.0.0 of the Protx VSP Direct payment module for Zen Cart!

As of June 2006, the merchant accounts supported by Protx include those provided by the following companies:

• Royal Bank Of Scotland
• Barclaycard
• Streamline
• Lloyds TSB
• HSBC
• American Express
• Diners Club International
• JCB Cards

Full details about the contribution are available at its website:

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

I recommend that you take a look at the above site but for those who want more information first (lazy you :) ), here is the feature list:


Features

This Payment Module has been written to be as comprehensive as possible. The current feature list follows. Features new for version 2.0 have been marked as new...

Support for every Card Type handled by Protx.

Each card type can be enabled or disabled at the click of a button inside the admin. Cards supported:

• Visa
• Mastercard
• Switch/UK Maestro
• Delta
• Solo
• American Express
• Visa Electron - UKE
• Diners Club International
• JCB

Full support of all essential parts of Protx VSP Direct's 2.22 Protocol.

This includes support for the three different Transaction Types: Pre-authorization, Deferred and Immediate Charge. It also includes support for the various AVS (Address Verification) Options. Configuration of these features is accomplished using simple radio buttons in the Module's Admin Configuration.


Allows gathering of the following information:

o Card Holder Name
o Card Type
o Card Number
o Expiry Date
o CVV Code
o Start Date (Switch/UK Maestro/Solo/American Express Only)
o Issue Number (Switch/UK Maestro/Solo Only)


Retains entered Card Details right throughout the checkout process.

If a user goes back to change their Shipping Address, or realises at the Confirmation Stage of the checkout procedure that they have entered some incorrect information, when they return to the Payment Page the card details they entered previously will be automatically restored. This prevents any frustration with customers having to re-type details and should help prevent customers leaving at the last hurdle! Please note: If your server has PEAR:Crypt_Blowfish installed, this information is kept encrypted in the session so as to protect the confidentiality of the details!


Visual Validation Feedback using JavascriptVisual Feedback of Javascript Validation.

In order to catch any problems with Card Details entered by the customer as quickly and easily as possible, this module will not only alert the user to any incorrect information when they attempt to submit the form, it will actually highlight the form fields which require their attention. Again this should help to reduce customers getting frustrated and leaving at the last hurdle!


[New for 2.0] Icons for each Credit Card accepted.

If you enable the option in the admin, icons are displayed for each credit card accepted (see picture at right). Maybe not an essential feature, but it does look more professional for your shop!


Support for a Single Merchant Account Currency or Multiple Merchant Account Currencies.

Each currency that you want to accept payment in requires you to have a separate merchant account for that currency. This payment module supports the sending of payment information to Protx in any number of currencies, according to the settings you specify in the Module's Admin Configuration.


Storage and Display of Completed Transaction Information.

The Transaction Information for any order processed using this module is available directly for viewing on the Order Details page for that order in the Zen Cart Admin.


Support for Protx's VSP Simulator testing services.

This module allows you to test its operation and configuration in conjunction with Protx's extremely handy VSP Simulator service so you don't have to worry about putting through lots of bogus details. Once you are satisfied with your configuration of the module you can switch the checkout to being live at the click of a radio button!


[New for 2.0] Ability to disable Autocomplete.

Some browsers store credit card numbers entered and automatically insert them in a credit card field when a user returns to a website. This can be quite disconcerting to customers so the option to have this browser feature disabled is offered (and set by default) by the Protx Direct payment module.


[New for 2.0] Dynamic Start Date and Issue Number support.

Certain cards (Switch/UK Maestro/Solo/American Express) require a Start Date to be supplied for authorisation to take place, while certain cards (Switch/UK Maestro/Solo) also require an Issue Date to be supplied. Version 2.0.x of this module now dynamically displays the necessary form gadgets to capture this information from the user based on the cards types enabled in the admin (I.e. You don't have to do this manually any longer!). The Visual Javascript Validation has also been extended so that, if a user has selected a card that requires a Start Date or Issue Number, the checks apply to those fields also!


[New for 2.0] Debug Support.

Sometimes there can be problems sending and receiving information to/from Protx. The new debug mode allows you to see what information was sent and received so you can check your settings. Most people should never need this though and it is subsequently disabled by default.


[New for 2.0] Complete support for Zen Cart 1.3.x's Observer/Notification System.

Previous versions of this module worked with both Zen Cart 1.2.x and 1.3.x using the same code but now there are two versions, one of which makes full use of Zen Cart 1.3.x's handy new notification system to make installation even more of a breeze!


Enjoy! :thumbsup:

Please read the documentation before posting any questions in this thread so that we can hopefully keep the number of posts here down to a minimum!

Download NOW!

If you like this contribution and get a lot of use out of it, please consider making a donation!

All the best...

Conor
ceon

Quote:

---

Originally Posted by conor

[New for 2.0] Ability to disable Autocomplete.

Some browsers store credit card numbers entered and automatically insert them in a credit card field when a user returns to a website. This can be quite disconcerting to customers so the option to have this browser feature disabled is offered (and set by default) by the Protx Direct payment module.

---

Thanks, didn't know you were working on that. Thought you missed my other post. :D

...... and a big thank you for the new PEAR:Crypt/Blowfish check. Installing your new version has highlighted I've got problems there. :(

Brent

Hi Brent,

You're welcome! :)

I'm sorry to hear that your host doesn't have the Crypt_Blowfish PEAR module installed... it is very easy for them to add it. All they have to do is run the following from their command line:

pear install Crypt_Blowfish

If you, or anyone else, is having problems getting your webhost to add this simple PEAR package, you could always create a folder called "Crypt" in your shop's root directory and get the Crypt_Blowfish files from:

http://pear.php.net/get/Crypt_Blowfish-1.0.1.tgz

and copy them into that folder (so that you end up with the main file using the path: Crypt/Blowfish.php). I.e: your file structure would end up as follows:

admin
cache
Crypt/Blowfish.php
Crypt/Blowfish/DefaultKey.php
docs
...
includes
...

The warning in the admin will still show as it is output from the languages file. The code that checks if Blowfish support is installed only looks at the include paths on your server and this language file is loaded from within the "admin" folder, so it wouldn't see that you have added the necessary files. You will however be using the encryption functionality of our Protx Direct module if you have added the files as above.

To disable the warning in the admin as well, you could also copy the Crypt folder created above into your admin/ folder... it will then be seen by the languages file. This is not advised though as the better solution overall is to get the Crypt_Blowfish module installed properly (as in via the pear command)! ;)

If you require any other help or advice on this particular issue please PM or e-mail me... I don't want to clog up this thread.

Maybe a FAQ might be worth adding to the documentation though... hmmm.. more work! :P

All the best...

Conor
ceon

Hi Conor,

My Host immediately installed the Crypt_Blowfish PEAR module for me so I'm now secure thanks.

Been testing the session saving feature and there is one further place it would be very useful. My customers have to accept our terms of trading at stage 2 and if they forget to do it the CC details are lost on a screen refresh as the session doesn't appear to be saved yet.

Obviously if they come back to this page after getting to stage 3 the session is now saved and this can't be replicated. As the tick-box is very easy to miss I think this will annoy many customers. I know when testing I have a 50/50 chance of forgetting and I know I need to tick them.

Last small request :D It would be good to add the Auto complete code to the CVV Number field as well.

Regards

Brent

Hi,

A slightly updated version of the module has been released due to user feature requests! :)

Here's the snippet from the Version History:


[ADDED] Option added to disable browsers' Autocomplete functionality for the CVV field (if this field is being used).

[UPDATED] Documentation updated with information about (and fix for) Known Issue when Terms & Conditions checkbox is being used.

[BUGFIX] Extraneous comma removed from HTML for CVV field.


So not a lot different, but, the documentation describes how to fix an issue with Zen Cart's checkout logic when your shop makes use of Terms & Conditions functionality which is well worth reading (and is extremely easy to implement)!

Again, 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

Have just installed the latest version on our test site with blowfish installed (so no warning message in Admin). Have just checked with the plaintext snippet in protx_direct file and it is not showing any encrypted text. Double checked by putting a similar line in the next else statement which did print indicating that encryption has not taken place. Made sure had suitable encryption phrase less than 56 characters etc.

Previous version has worked faultlessly by the way - so many thanks for that

Hi

I've just installed this module and came across this little problem in the checkout form.

Credit Card Start Date (Solo/Switch/UK Maestro Only):

At first I though it was an installation mistake by myself but looking at this article it seems that this feature is deliberate.

Quote:

---

Start Date (Switch/UK Maestro/Solo/American Express Only)

---

Correct me if i'm wrong but doesn't Switch/Maestro always have a issue number but never a start date?

Hi there,

Thanks for downloading and installing our Module, it's good to see it getting used more and more! :)

Quote:

---

Originally Posted by frostystoo

Correct me if i'm wrong but doesn't Switch/Maestro always have a issue number but never a start date?

---

Straight from the Protx VSP Direct Protocol Guide (Pages 25 and 26):

"The Start date (required for Switch, Solo and Amex) in MMYY format"

"The card Issue Number (Switch and Solo cards only)"

...I was very careful to write this module so that it supported every card properly... that's why users have to select their credit card type as opposed to the module trying to calculate a bin code to identify it (these change too frequently to be 100% reliable unfortunately and we've gone for 100% reliability with this module!) :thumbsup:

Hope that puts your mind at rest... you won't get any disillusioned customers unable to use a valid credit card with this module! :)


Regarding the previous post... just to let you all know I'm in contact with TPHoare about his problem privately. As it turns out, there's a problem with the include path settings on his server, the encryption works perfectly if the Blowfish package is available on the catalog's side.

All the best...

Conor
ceon

Hi Conor - great work with the module. Fantastic job you are doing there.

Maybe the Protx VSP documentation is wrong then. I have two fairly recent Maestro/Switch cards; neither have a start date and both have an issue number. I have never been asked for a start date when purchasing items on the Internet with these cards. I also have 3 credit cards (2 VISA and 1 Mastercard) and all 3 have a start date for which I am always prompted for when purchasing online. None of the credit cards have an issue number.

As it is I can't use my two switch cards using Protx. One is First Direct and the other is HSBC so they are both mainstream cards.

Quote:

---

Originally Posted by frostystoo

Hi Conor - great work with the module. Fantastic job you are doing there.

---

Appreciate the support - thanks! :)

Quote:

---

Originally Posted by frostystoo

As it is I can't use my two switch cards using Protx. One is First Direct and the other is HSBC so they are both mainstream cards.

---

I've just checked out Protx's site once more and right enough they have updated their VSP Direct information page to indicate that the start date may not always be necessary for Switch/UK Maestro/Solo and that not all Switch/UK Maestro and Solo cards need an issue number.

However, their Protocol documentation still requires both for Switch/UK Maestro and Solo!

I'll get on the phone to them tomorrow and hopefully encourage them to sort this out... it's quite ridiculous that they've let their protocols go out of date - what are we paying them for?!! :)

I'll also update the module to not require start dates and issue numbers but to "suggest" that one or both might be necessary for Switch/Maestro/Solo/Amex.

Thanks for the heads up on this then.

In return, I can tell you for certain that you don't need to enter the start date for Visa or Mastercard on any occasion... I've 20 of the things and have always skipped the start date (no protocol requires it - we have experience with other payment providers/gateways also through other clients of ours). So I've saved you a little bit of time there hopefully! :P

All the best...

Conor
ceon

Thanks Conor - appreciate that. It is fairly poor if protx have got their documentation wrong - this is the first time I have used them so hopefully it isn't a sign of things to come!

One minor amendment you might want to make to the installation instructions....

Quote:

---

For this step all you need to do is find the following lines in tpl_checkout_confirmation_default.php (there are two):

---

You might want to put the full path in there. Got there in the end but isn't immediately obvious where the file is located. Also I could only find one instance of zen_href_link(FILENAME_SHOPPING_CART) in that file. Other than that, installation was a synch. Love the way you can administer everything from the Zen administration screen.

Quote:

---

Originally Posted by frostystoo

Thanks Conor - appreciate that. It is fairly poor if protx have got their documentation wrong - this is the first time I have used them so hopefully it isn't a sign of things to come!

---

Just got off the phone with them and they are saying this is all being caused by the Switch to Maestro changeover... lots of banks and choosing to operate their Switch and Maestro cards in completely different ways.... some require an issue number, some have no issue number at all!

I'm updating the module to show the fields for both but not to require them... if one or the other is required and the user hasn't supplied it then they will receive a Protx Error at the top of the payment page... I have to remove the javascript checking for these two fields now (Start Date and Issue Number)... pity!

Quote:

---

Originally Posted by frostystoo

One minor amendment you might want to make to the installation instructions....

You might want to put the full path in there. Got there in the end but isn't immediately obvious where the file is located.

---

Okay, I'll make that change... all the tpl_ files are always located in the same folder but I suppose more precise information is better than less! :)

Quote:

---

Originally Posted by frostystoo

Also I could only find one instance of zen_href_link(FILENAME_SHOPPING_CART) in that file. Other than that, installation was a synch.

---

For Zen cart 1.2.x there are two, for 1.3.x there is only one... I'll update the docs for to more accurately reflect also.

Quote:

---

Originally Posted by frostystoo

Love the way you can administer everything from the Zen administration screen.

---

Usability has to be a prime concern for us.. glad you appreciate it! :thumbsup:


Thanks for the feedback, it just makes the module that bit better!

I'll post here again when the new version has been uploaded.

All the best...

Conor
ceon

Hi Conor

Downloaded module from your site.
When I go to unzip it i get error message saying

"Cannot open file does not appear to be a valid archive, If you downloaded this file, try downloading it again"

Probably me being thick..am using Winzip to open

What am I doing wrong please?

Z

Hi Zohe

If I were you i'd uninstall winzip and download the open source software archiving program 7-Zip

http://www.7-zip.org/

Its at least as good as winzip, free to download and opens all kinds of archives in a nice Windows GUI.

I opened Conor's archive using 7-Zip with no problems at all.

Thx Frosty,

you are right works easy...

Z

Hi,

A slightly but VERY IMPORTANT updated version of the module has been released due to user feedback!

Here's the snippet from the Version History:

Quote:

---

[UPDATED] The changeover from Switch to Maestro means that some Switch cards have issue numbers while others don't. Also, some have a Start Date while some don't. The module has been updated to therefore display both these fields but require neither. This should mean that every possible variation of fields used is once again catered for!

Please note that this means that the omittance of a required Start Date or Issue Number field can no longer be checked for, using Javascript, before sending the payment details, as the individual banks only report a Requirement Error after sending the data through Protx. Of course at this point, if the customer has not supplied some required information, they will then be shown an appropriate error message and asked to supply this missing information, so no business will be lost! :)

[UPDATED] Documentation slightly updated for changing Shopping Cart link(s) to use SSL.

[UPDATED] Debug Information's layout improved. Information now includes whether Encryption was used and, if not, the include_path and safe_mode/open_basedir settings for the server.

[BUGFIX] Extraneous comma removed from HTML for Issue Number field.

---

It is highly advised that everyone using this module upgrade immediately!

Otherwise some Switch/UK Maestro/Solo customers may find that they are asked for an Issue Number and/or Start Date when their card doesn't have one or the other!

This upgrade is particularly easy as no database changes have been made so no configuration within the Admin is necessary.

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

Thanks Conor. Really appreciate your help on this.

Just tried it out and am now taking payments successfully on my development protx account at least.

just installed this module for my shop and so far all working well :) I have had a few issues with this site over the weekend so I will let you know if its all working well (seem to have lost the emails when you order :() but that is nothing to do with this module

But very easy to use/set up/install VERY glad it was ok for 1.2 as well as 1.3

If all works well over the next few weeks I will certainly be contributing to you guys as a thank you for this module

Sarah

ps on the blowfish section - do I need to do anything with it other than create a keyword? ie my host installed it on the server and I have added in the keyword in the admin area for protx direct - is that all I need to do?

Hi Sarah,

First off, thanks for the nice comments - glad to hear that the module is of use to you! :)

Quote:

---

Originally Posted by SarahL

ps on the blowfish section - do I need to do anything with it other than create a keyword? ie my host installed it on the server and I have added in the keyword in the admin area for protx direct - is that all I need to do?

---

Yes, that's everything you need to do... although you might want to confirm that the encryption is working okay by temporarily enabling the Debug Mode and checking its output (a message will indicate if encryption was used). Don't forget to turn Debug Mdoe off afterwards though as it still processes and creates the order you are using to "test"! :)

Oh, you should also use the "test" server when Debug Mode is enabled as otherwise your card will be charged.

All the best..

Conor
ceon

Hi Conor,

Thanks for your help so far, and for making this excellent mod available.

One question so far as a result of testing:

When you make a refund in the VSP admin the refunded amount doesn't appear in the shop admin on the customer's order screen (as it does with Paypal) - should it?

Thanks :)

1. ... also, (in the shop admin when you look at the customer's order) should the line that says 'Status Message:' always be blank? What sort of message might show up there?

2. With 'Store card number in database' turned off in the Protx mod, I'm getting just the expiry date showing on the card details (no start date or issue number) - no biggie, just curious if that's what I should be seeing.

Hi Dave,

Quote:

---

Originally Posted by Pixxi

When you make a refund in the VSP admin the refunded amount doesn't appear in the shop admin on the customer's order screen (as it does with Paypal) - should it?

---

The VSP Admin is a completely independent application from Zen Cart and therefore has no integration whatsoever with the cart software. Unfortunately there is no way at all to update an order as refunded automatically... you have to change the status etc. manually I'm afraid.

Quote:

---

Originally Posted by Pixxi

1. ... also, (in the shop admin when you look at the customer's order) should the line that says 'Status Message:' always be blank? What sort of message might show up there?

---

If a transaction is successful the Status Message isn't normally used. That may or may not change so I've put the capability to record and display this information in anyway... it's up to Protx what goes in there (it may never have anything though!). :huh:

Quote:

---

Originally Posted by Pixxi

2. With 'Store card number in database' turned off in the Protx mod, I'm getting just the expiry date showing on the card details (no start date or issue number) - no biggie, just curious if that's what I should be seeing.

---

As this information is all stored at Protx's side we didn't see the need to modify the orders database table to store this information also. The information's really only there because it's a standard Zen Cart feature. It would make the module more complicated to install if we added in the ability to store this extra info with no major benefit for the shop owner as they can just take a look at the transaction details in VSP Admin.

Hope that answers your questions satisfactorily! :)

All the best...

Conor
ceon

Hi,
I installed this mod but im getting a message in the admin section telling me that PEAR:Crypt/Blowfish isnt installed on your server!. My host company tell me it is.

Any ideas what the problem might be?

Cheers

Hi Chris,

Quote:

---

Originally Posted by Chris_Destructive

I installed this mod but im getting a message in the admin section telling me that PEAR:Crypt/Blowfish isnt installed on your server!. My host company tell me it is.

Any ideas what the problem might be?

---

It definitely means that it either isn't installed, your include paths are wrong or your include paths are blocked by something like open_basedir settings. There isn't any other way this message would come up.

Please contact me privately by e-mail at the address on the module's support site with a full listing from the debug output and we'll see what's wrong!

(To enable debug mode use the admin to switch it on and put through a test order - make sure you use "test" mode - don't use "live" mode as you'll be billed for the order! :) ).

All the best...

Conor
ceon

Oops, just realised you have contacted me privately. :)

Hi Conor,

Just a couple of small points that have emerged from testing ...

1. With v 2.02, if you choose Switch/UK Maestro as the payment type and enter the card details, the next page (checkout_confirmation) shows the payment type as 'SWITCH' (uppercase) rather than 'Switch/UK Maestro'. ('SWITCH' doesn't seem to be defined in the language file)

2. Since Maestro is also used in Europe, maybe that text should just be 'Switch/Maestro'?

3. In the protx_direct language file, the text 'credit card' is used in several places for display and error messages. Since the mod can also accept debit cards, perhaps these instances of text should be changed to 'credit/debit card' and 'card...' as appropriate?

Otherwise, testing is going fine so far.

Thanks for your help :smile:

Hi,

Thanks for the feedback, we're so busy at the minute that we don't necessarily get the time to have a good look over everything and ask "why" (the most important question too many programmers don't seem to be aware of!)... it's nice to have extra eyes and ears to help us with that! :thumbsup:

Quote:

---

Originally Posted by Pixxi

1. With v 2.02, if you choose Switch/UK Maestro as the payment type and enter the card details, the next page (checkout_confirmation) shows the payment type as 'SWITCH' (uppercase) rather than 'Switch/UK Maestro'. ('SWITCH' doesn't seem to be defined in the language file)

---

That output doesn't actually use the language file; instead the code for the Card Type being sent to Protx is displayed.

I think I'll change it to using the language definitions.

Quote:

---

Originally Posted by Pixxi

2. Since Maestro is also used in Europe, maybe that text should just be 'Switch/Maestro'?

---

I'm not sure what to do about this one. I deliberately chose to say "UK Maestro" as Protx accept Switch and Switch is changing to Maestro and they've said there's a possibility that the differences between the UK implentation and the rest of Europe's systems may mean that they only guarantee acceptance of UK Maestro cards, at least until the changeover is complete.

I might give them a call and see exactly where they stand on this issue as it's about 6 months since I last checked.

However, the more feedback from people about this the better so if anyone else has any thoughts, please let us know (or PM or e-mail me).

Quote:

---

Originally Posted by Pixxi

3. In the protx_direct language file, the text 'credit card' is used in several places for display and error messages. Since the mod can also accept debit cards, perhaps these instances of text should be changed to 'credit/debit card' and 'card...' as appropriate?

---

In the source code I always use "Card" without "Credit" or "Debit". I might change things to simply using "Card" in the language file definitions or I might upgrade the code to dynamically display "Credit"/"Debit" based on the card type selected.

Either way I'll make things more accurate!

In the meantime, you can simply make whatever changes to the text you like by overriding the language definition file:

/includes/languages/english/modules/payment/YOUR_TEMPLATE/protx_direct.php

All the best...

Conor
ceon

Hi Conor,

Quote:

---

That output doesn't actually use the language file; instead the code for the Card Type being sent to Protx is displayed.

---

Yes, (and sorry, I should have said) and that was why it was confusing - the card details I entered were for a Maestro card (not a Switch card) - a customer might enter their Maestro card details and see 'Switch' confirmed as the card type and think the shop has mis-recognised their card type.

I guess that might be down to Protx again, in that they may want the code to refer to both Switch and Maestro cards as 'Switch' during the changeover. As you say, using the language define instead would solve the problem.

1. Until you have time to update the mod, could you point me in the general direction of the code that needs changing to use the language file define please?

Thanks :smile:

Hi,

Quote:

---

Originally Posted by Pixxi

could you point me in the general direction of the code that needs changing to use the language file define please?

---

No.

Absolutely not.





:) I've already updated the module with all of the above changes [plus a bugfix] and just have to finish the docs before I can release 2.0.3 ;) - Thought a FAQs section would be nice!

All the best...

Conor

That's fine - I'll wait for the update then, thanks :smile:

By the way, do the two 'contact us' links defined in the protx_direct language file (near the bottom) work for you?

They're the ones for the error messages when the vendor name isn't recognised or when there's a technical problem contacting the gateway. I'm getting a '404 - page not found' when clicking either link on the error message(s).

It might also be better not to have the merchant's Protx vendor name appear on the first of those error messages - maybe just the general message (eg. 'vendor name not recognised') instead?

I have installed version 2.02 for Zen 1.2

I have got two questions:

First under admin it says You do NOT have PEAR:Crypt/Blowfish installed on your server!

I am pretty sure it is, when I do linux command "pear list" I get Crypt_Blowfist v. 1.0.1 stable installed.

I tried to to transaction in debug mode and it says Encryption NOT USED!

Any ideas how I can work out this problem.

Second question. When I am at the checkout payment page I get this in front of the cards images:

MODULE_PAYMENT_PROTX_DIRECT_TEXT_CREDIT_CARDS_ACCE PTED

And in the drop down menu for selecting credit cards:

MODULE_PAYMENT_PROTX_DIRECT_TEXT_VISA

Regards,

Baldur

Hi Baldur,

Quote:

---

Originally Posted by ofurbaldur

I tried to to transaction in debug mode and it says Encryption NOT USED!

---

If you are getting that message then PEAR:Crypt_Blowfish cannot be accessed by your php installation. This could be because it isn't actually installed, PEAR isn't on your include_path or you have an open_basedir restriction in effect which doesn't allow your php installation to use PEAR files - all three of these situations are a lot more common than I would have thought!

Please send me the debug output from a test transaction so I can see why you aren't able to use the encryption (e-mail address is on the website).

Quote:

---

Originally Posted by ofurbaldur

Second question. When I am at the checkout payment page I get this in front of the cards images:

---

Have you modified the languages file in any way?

(/includes/languages/english/modules/payment/protx_direct.php)

Somehow the full file isn't being loaded... it sounds like you have a corrupted file (extraneous apostrophe or quote somewhere maybe)?

Try copying all the files across again, overwriting the existing ones!

Hope that helps...

Quote:

---

Originally Posted by pixxi

By the way, do the two 'contact us' links defined in the protx_direct language file (near the bottom) work for you?

---

Oops, don't know how I missed that one. Fixed in 2.0.3.

Quote:

---

Originally Posted by pixxi

It might also be better not to have the merchant's Protx vendor name appear on the first of those error messages - maybe just the general message (eg. 'vendor name not recognised') instead?

---

Unfortunately that's not an option... that is the error message sent back from Protx. This should never happen on a live site though as any testing of the module before the site goes live would show this particular problem up quite easily!

Will be releasing 2.0.3 shortly, so if there's anything else you have found (thanks! :) )....

All the best...

Conor

Hi Conor,

Quote:

---

Unfortunately that's not an option... that is the error message sent back from Protx. This should never happen on a live site though as any testing of the module before the site goes live would show this particular problem up quite easily!

---

Ok. And (presumably) if you removed the 'extraerrorinfo' section from the end of that first define (which removes the 'vendor name' error info sent from Protx) you would also lose other specific error information returned from Protx that the customer might need to see?

Fine, it can stay then :yes:

Another small thing ...

1. Do you find the Visa test card number goes through the test server Ok? I'm consistently getting a 'card number error' from Protx. Real Visa card numbers go through fine.

(BTW, if anyone else gets the 'vendor name not recognised' error, it can be caused by having Amex turned on in the Protx mod in the shop admin, and processing an Amex card number when you don't have Amex enabled on your Protx account, or, of course, by having the wrong vendor name entered in the Protx mod :smile: - but as Conor says, it should never happen live unless you accidentally change your settings for vendor name or Amex on the mod in the shop admin)

Hi,

A slightly updated version of the module has been released due to user feedback!

Here's the snippet from the Version History:

Quote:

---

[UPDATED] The Language Definitions file has been extensively updated to use “Credit/Debit Card” where appropriate, rather than using “Credit Card” exclusively all the time.

[UPDATED] “UK Maestro” is now identified simply as “Maestro”.

[UPDATED] The Card Type on the Confirmation page now uses full text rather than Protx's Card Type codes.

[UPDATED] FAQs have been added the documentation due to the increasing volume of e-mail about particular issues.

[BUGFIX] The Debug Mode was ignored if an error occurred during the cURL transaction, now it runs and outputs correctly.

[BUGFIX] The Contact Us links in error messages didn't link to the correct address.

---

It is recommended that everyone using this module upgrade immediately as although the changes are minor, they may help make things clearer for your customers! Plus the "Contact Us" link working is quite handy if a customer experiences problems with Protx (although that's rare once you've configured the module properly).

Full Upgrade Instructions are available on the website and in the updated documentation!

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

Hi Conor,

Thanks for the rapid update :)

Two more small points that have emerged:

1. When you put a test transaction through on the Protx test server using the JCB test card number (assuming you have JCB enabled on your Protx account, and this account does have) the transaction is successful but the Protx results page says that the house number, the postcode, and the CVV 'were not provided'. All test transactions using any of the other test cards show green ticks (AVS and CVV successful).

2. It would be useful to also have the JCB and Electron test card numbers displayed on the mod in the shop admin (along with the test card numbers that are already displayed there) for people who want/need to test those numbers. Protx don't seem to provide the complete list of card test numbers until after you've confirmed completion of live testing (very useful :) ).

Thanks again for you help :)

Hi,

Quote:

---

Originally Posted by Pixxi

Thanks for the rapid update :)

---

Always aim to please! ;)

As far as the JCB AVS checking goes, I'm guessing it may simply not use it? I really don't know because I have no idea what a JCB card is! :)

We don't have a live account ourselves, just a test one Protx set up because I maintain this module. I could ask my clients for the numbers you mentioned but they'd probably have to look all over the place to find them... do you mind just e-mailing them to me and I'll add them in for the next version? Thanks :)

All the best...

Conor
ceon

Hi Conor,

1. The JCB AVS/CVV not showing was apparently a problem at Protx's end. Just received this reply from support:

Quote:

---

1. This was an issue with the Protx Test server. JCB is a new concept on our system, so we have just corrected that now for you. (thanks for letting us know.) Please test again and let us know if you have any further issues.
NB: We pass the AVS & CV2 results for JCB cards, it is then up to the card issuer to provide the results.

---

2. The test Visa number has been confirmed as correct and working by Protx - so not sure why it gave me 'card error' each time on the test server - but as I said, real Visa numbers went through fine, so no problem. Just a note in case anyone else has it happen.

3. I'll PM you the test numbers for JCB and Electron - would have sent them before but thought you had them already.

Thanks again for your help :)

Hi,

Quote:

---

Originally Posted by Pixxi

1. The JCB AVS/CVV not showing was apparently a problem at Protx's end. Just received this reply from support:

---

Good to know that that's sorted, thanks!

Quote:

---

Originally Posted by Pixxi

2. The test Visa number has been confirmed as correct and working by Protx - so not sure why it gave me 'card error' each time on the test server

---

That's weird... just put my own test through on the test server and, as always, it's working fine for me. Hmmm... if real Visa cards work though then that's the main thing! :P

Quote:

---

Originally Posted by Pixxi

3. I'll PM you the test numbers for JCB and Electron - would have sent them before but thought you had them already.

---

Got them, thanks.

I'll add them into the current distribution of 2.0.3, don't think it's worth advancing the version or announcing an update for something as small as that!

All the best...

Conor
ceon

Hi Conor,

Test Visa number resolved too - user error coupled with a non-standard approach on that particular test number by Protx.

Visa numbers are (as you know) 16 digits, but Protx uses 13 digits for that test number for some reason. We didn't count the zeroes, just assumed there were 11 when in fact there were 8 - hence the error we had. :smile:

Thanks again :smile:

Hi Conor,

Just had an odd thing happen with a customer using the Protx mod (v.1.2.x).

The customer would seem to have clicked the final 'confirm' button on checkout twice and generated two identical orders in the shop (the orders were timed 4 seconds apart and had consecutive order ID's).

Obviously the transaction ID info was unique, just the items ordered were the same. Both orders went through Protx so the customer was charged twice.

The shop has had a notice next to the 'confirm' button advising the customer to 'only click once then wait' since the mod was installed, but obviously some customers don't read notices :smile:

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?

Hi Pixxi,

Quote:

---

Originally Posted by 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

Hi,

A slightly updated version of the module has been released!

Here's the snippet from the Version History:

Quote:

---

[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

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

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

Hi Conor,

Don't think it's your mod either. :D

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

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

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. :D 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

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

Hi Conor,

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

Quote:

---

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.:D

Regards

Brent

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

Quote:

---

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 :D

thank you
Sarah

Hi Sarah,

Quote:

---

Originally Posted by SarahL

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

---

Yes, the module works fine with 1.3.5.

The error you are getting can't be because of the module not working correctly... the fact that you are getting this error means that the module has contacted Protx, then received and parsed the response successfully.

The fact that it says card declined could mean a problem with your card, with your merchant account itself or, possibly, the settings of your Protx account (e.g. if the address doesn't match then you would get a declined error message.)

Quote:

---

Originally Posted by SarahL

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 :D

---

I wish I could be more help on this one but I'm afraid there's nothing I can do to help you.

I'm surprised though that Protx said it was a shop fault, that's the one thing I don't think it can be!! The person answering may not have really known what they were talking about... I suggest you give them a ring, they're always very helpful on the phone.

Also, have you logged into your VSP Admin to check the transaction details for the declined transactions? If all the information looks fine there then you should see a reason for the transactions failing.

Good luck! Let me know (by e-mail) how you get on!

All the best...

Conor
ceon

Thanks Connor that is what I thought but thought that I ha dbest check to be sure

I will let you knwo what they say - and yeah I did reply to them saying excuse me ;)

we shall see I will call them tomorrow but it was out of office hours (as per usual) when I got the error

Thanks
Sarah

Hi i installed the form module and that works perfect but when i tried this module i always get the following error:

Your card could not be authorised! Please correct any details below and try again or contact us for further assistance.
(Couldnt create a transaction (VRTXInvalidIPAddress, ))


I have checked the IP address setting in the VSP admin but that is correct.

Please help

The error is telling you that the IP address the transaction is coming from (ie. your server) does not match the IP set in VSP admin.

You need to put the *server* IP address in your VSP admin - do you have that?

Following on from what Pixxi said have a look at this thread as Conor helped me with a similar problem

Hello,

This is probably a really obvious question but;

How do I set my own private keyphrase in Blowfish?

I'm sure the answer is staring me in the face but I couldn't see it!!!!

Thanks,

Gary:smile:

When you install the Protx module in admin there's a box in the settings where you can enter your keyphrase.

Thanks Pixxi, I've got that sorted now!

One more thing though. When I look in my admin panel I get the message: Warning:
You do NOT have PEAR:Crypt_Blowfish installed on your server!

I have followed the steps outlined in post #3 and have:

blowfish.php and default_key.php in my public_html folder. Also in this folder are admin (which is under a different name as I changed it), cache, docs and, includes.

Is this all ok? Am I missing anything?

Thanks,

Gary

In your public_html folder ...?

Did you follow Conor's structure:

admin
cache
Crypt/Blowfish.php
Crypt/Blowfish/DefaultKey.php
docs
...
includes
...

ie. did you create a folder in public_html called 'Crypt' and put the Blowfish.php file in there - so that you have:

public_html/Blowfish.php

and also (in the Crypt folder) you do you have another folder named 'Blowfish', with the file 'DefaultKey.php' inside it?

ie.

public_html/Blowfish/DefaultKey.php

If you have that, then don't worry - as Conor said:

Quote:

---

The warning in the admin will still show as it is output from the languages file.

---

Hi Pixxi,

yeah I do have all the files in place in that structure too. Is it possible because i've renamed the admin folder as 'gary'?

Maybe there's something else I need to install to get it to work?

Thanks

No, as Conor said in post #3:

Quote:

---

The warning in the admin will still show as it is output from the languages file. The code that checks if Blowfish support is installed only looks at the include paths on your server and this language file is loaded from within the "admin" folder, so it wouldn't see that you have added the necessary files. You will however be using the encryption functionality of our Protx Direct module if you have added the files as above.

To disable the warning in the admin as well, you could also copy the Crypt folder created above into your admin/ folder... it will then be seen by the languages file. This is not advised though as the better solution overall is to get the Crypt_Blowfish module installed properly (as in via the pear command)! ;)

---

Or you could ask your host to install Blowfish - they should do so happily.

Thanks so much Pixxi - I got it sorted now!!!

One day i'll get the hang of this whole Zencart thing! :wink2:

just an update - the module is working perfectly with 1.3.5 it was an issue with the bank itself :D

thanks Conor

My zen admin says this....

Warning:
You do NOT have PEAR:Crypt_Blowfish installed on your server!
Encryption will not be used for the Credit/Debit Card Details being stored in the Session.

but when i try to install my command line says this

[root@www logs]# pear install Crypt_Blowfish
Package 'Crypt_Blowfish' already installed, skipping

Any help???

Hi,

Quote:

---

Originally Posted by marcps

Any help???

---

This means that your PHP installation can't access the PEAR folder... either your include path is wrong or you have open_basedfir restrictions in effect.

Switch on Debug Mode in the Protx Direct module and put through a test order... it will tell you what your include path and open_basedir settings are. You can then update the include path for your server (php.ini) to also include the path to your PEAR installation (or adjust your open_basedir settings).

Once you've done that then the warning will more than likely go away.

Hope that helps!

All the best...

Conor
ceon

Hi, just wondering if it was an oversight but it seems basket contents do not get sent through the same way as they do via Protx form, What i mean is, they do get sent but via the (Description=) I looked at the way it is sent using Protx form and it looks like it wants number of lines blah blah blah ..


Just wondering if this will be or can be added to this mod?? :lookaroun

I am getting the "Couldn't create a transaction (VRTXInvalidIPAddress)" error message and can't seem to get past it even though I'm following the advice in the protx_direct faqs. I've contacted the web host to check which IP address I should use and they insist I'm using the right one. Is there any other reason why I might be getting that particular error?

Many thanks for any help!

Hi,

Quote:

---

Originally Posted by powersellersuk

Just wondering if this will be or can be added to this mod??

---

There are no plans to add it at this time as the Protx Direct module doesn't tend to fail in the same way as Protx Form sometimes can (if there is a problem with Protx Returning to the server so that the order can be created). Protx Direct carries out all the transactions via a cURL call then creates the order... it can only fail if there are server issues and the cURL call never returns (or the PHP script gets interrupted between that point and creating the order... only takes milliseconds so is unlikely!).

If you still want this feature please feel free to request a quote from us.

All the best...

Conor
ceon

Hi,

Quote:

---

Originally Posted by webfooted

I've contacted the web host to check which IP address I should use and they insist I'm using the right one. Is there any other reason why I might be getting that particular error?!

---

No. Your web host's staff are unreliable! :(

Unfortunately there are few hosts that just don't seem to understand that their clients might want to use software on their server which makes use of web services (e.g. payment systems!!).

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

Just wanted to say a public thank you to Conor. I ran the script he posted and he sent me the correct IP address to use. No more error message :-)

Now to send the web hosts a piece of my mind...

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

Quote:

---

Originally Posted by conor

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

---

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 ... :smile:

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

PHP Code:

---

        curl_setopt($ch, CURLOPT_TIMEOUT, 120); 


---

Quote:

---

Originally Posted by Pixxi

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:

Quote:

---

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.

Hi Brent and Pixxi,

Quote:

---

Originally Posted by Brent

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]

@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 ... :smile:

Thanks for your input.

Quote:

---

Originally Posted by Pixxi

...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.

Quote:

---

Originally Posted by Pixxi

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 :D

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.

Quote:

---

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.

Quote:

---

Originally Posted by Pixxi

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. :laugh:

Brent

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

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 :D

Hi

They were all there the last time I looked though.... and that was only a couple of weeks ago.

Admin Profiles was the last module I added so thats why I mentioned that.

Ta

--
Chris Woods

Hi Chris,

Quote:

---

Originally Posted by cmwoods

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

---

I can't say for sure as I've never tried that mod but it certainly does ring alarm bells in my head... I would try uninstalling that module and seeing whether or not you can configure the payment modules.

If that doesn't work then I'm afraid that, as Sarah has said, you've corrupted your installation somehow and a reinstall/fresh install might be the best way to recover.

Sorry I can't be of more help but your problem has nothing to do with the protx module itself. :(

All the best...

Conor
ceon

Sorted !!!

It was caused by me altering the basic CC module slightly, and saving the original file as cc_old in the same folder. Anything after that wasn't listed. renaming it to zz.old shows all the mods, including the one I want.

I'll try to get it working after lunch.

Thanks

--
Chris Woods

Hello, me again.

I appear to have got it working and comms with protx seem to be fine, but I cannot get the encyrption to work. I have been trying for hours but the debug log always says encyrption was not used.

Below is what the server said when I attempted to install the blowfish thingy, but as you can see here are a lot of lines saying it was unable to load various libraries. Are these important and it hasn't worked even though at the end it says it as, or are they spurious and it is working.

I have tried moving the relevant files into the catalog folder but that din't work either.

Apologies for dumping on people like this, but I have managed to get everything else up and running without seeing a command line so i'm a little stuck and eager to get up and running.

Many Thanks.

--
Chris Woods


[root@s15228855 /]# pear install Crypt_Blowfish
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/bcmath.so' - /usr/lib/php/mo
dules/bcmath.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/dba.so' - /usr/lib/php/modul
es/dba.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/ldap.so' - /usr/lib/php/modu
les/ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/ncurses.so' - /usr/lib/php/m
odules/ncurses.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/odbc.so' - /usr/lib/php/modu
les/odbc.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/pgsql.so' - /usr/lib/php/mod
ules/pgsql.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/snmp.so' - /usr/lib/php/modu
les/snmp.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/soap.so' - /usr/lib/php/modu
les/soap.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/xmlrpc.so' - /usr/lib/php/mo
dules/xmlrpc.so: cannot open shared object file: No such file or directory in Unknown on line 0
WARNING: running in safe mode requires that all files created be the same uid as the current script. PHP re
ports this script is uid: 0, and current user is: root
downloading Crypt_Blowfish-1.0.1.tgz ...
Starting to download Crypt_Blowfish-1.0.1.tgz (11,954 bytes)
.....done: 11,954 bytes
install ok: Crypt_Blowfish 1.0.1

Hi Chris,

Can you please e-mail me on the support address on the contrib's website and I'll talk you through sorting this out. :yes:

All the best...

Conor

Hi,

Protx have just sent through their latest newsletter with information about their new emphasis on 3D secure (especially for Maestro cards), the Switch changeover in June and the move from Preauth to Authorise/Authenticate.

I'm in contact with protx about how best to upgrade the Protx Direct module to cope with these changes.

I just wanted you to know that we are aware of the upgrades and that a future version of this module will fully support Authorise/Authenticate and 3D Secure (so no need to put in any requests for these features.. won't say no to any donations to aid their development though ;) ).

All the best...

Conor
ceon

Oh..Sorry Conor..

Please ignore the email you get enquiring about 3D Secure.

Serves me right for not checking the forum first.


Looking forward to seeing the new version

i have recently been having a small problem and wondered if anyone can help

it appears that customers are placing an order and getting the message that the card was declined and as such the order was not processed on our site but when i log into vsp admin it is showing that their payments have been taken

this is upsetting our customers because some of them have tried their card 3 or 4 times and have been charged 3 or 4 times and then not actually placed an order according to our site

anyone help me with this??

the site is zen 1.3.5

@ conor
when will the new version be available?

Hi,

Quote:

---

Originally Posted by modchipfitters.co.uk

it appears that customers are placing an order and getting the message that the card was declined and as such the order was not processed on our site but when i log into vsp admin it is showing that their payments have been taken

---

Quite a few people are having this problem recently unfortunately.

It's a problem at protx's end, their systems are no longer fully compatible with all the banks they work with, hence the move from the "preauth" type.

Unfortunately all you can do at the minute is refund these customers. Thankfully it's still only a very small percentage of cards this is affecting (at least it appears to be from the reports we've been getting).

As for when the new version of the module will be released, Protx don't release details of their new Authorise systems (and give out test accounts) until March. We've a few other commitments in March and April so I don't know when I'll be able to spare the time needed to release an updated version of the module as we don't get paid for developing it! Of course it'll be done as quickly as possible though, hopefully our other commitments won't take up too much time. I can't give any real timeframe though as you never know how projects will go in the wonderful world of computing! ;)

All the best...

Conor

Hi, sorry I'm new to this and am stuggling to see whether everything with the Protx integration is in it's right place.

A previous developer installed the module to my site, but I've now took over and am not sure at which point he left off.

In regards to the PEAR:Crypt_Blowfish, I do have this error on admin. However I have created a debugging output from a test transaction and there is some reference to this. Please can you view the report below and let me know if this is correct?


Original Data sent to Protx:
----------------------------
VPSProtocol=2.22&TxType=PAYMENT&Vendor=----------------------------

--------------------
Encryption NOT USED!
--------------------

------------------------------
Include paths for this system:
------------------------------

.;c:\php4\pear

----------------------
Safe mode in use?: no
----------------------


-------------------
Transaction status:
-------------------
Transaction was successful!

Thanks in advance for any help :smile:

Hi,

Quote:

---

Originally Posted by Balboa

Please can you view the report below and let me know if this is correct?

---

Sorry, your grammar is rather confusing, the focus of your question has been lost somewhat as a result.

I'm assuming that you are trying to ask if your installation has been configured properly.

It has not.

The PEAR Blowfish package has not been installed on your server.

Please log in to your server via SSH and run the following command:

pear install Crypt_Blowfish

That should install the Blowfish software in the c:\php4\pear directory and the warning in the admin should disappear.

Hope that helps!

All the best...

Conor
ceon

Hi, after the system working for a couple of months we're now getting a new error message when trying to process a payment:
(Couldn't create a transaction (VRTXVendorTransactionTypeNotValid, ))

Can anyone suggest why this would be happening?

Thanks in advance for any help!

Hi,

Quote:

---

Originally Posted by webfooted

Can anyone suggest why this would be happening?

---

That error is one returned by Protx so the module is working fine but something is wrong with your Protx account.

What "Transaction Type" are you using?

You should contact protx immediately and ask them what's up, but please also let us know what you find out! :)

All the best...

Conor
ceon

Quote:

---

Originally Posted by conor

Hi,



That error is one returned by Protx so the module is working fine but something is wrong with your Protx account.

What "Transaction Type" are you using?

You should contact protx immediately and ask them what's up, but please also let us know what you find out! :)

All the best...

Conor
ceon

---

Hi Conor

I've been on to Protx and they asked about the Transaction Type aswell, so I'm waiting to hear back about that. By transaction type do you mean transaction mode (which is live) or authorization type (set to immediate charge)?

I'll let you know if/when I get to the bottom of the error.

Cheers, Emily

Hi Emily,

I was enquiring about the authorisation type rather than the transaction mode.

All the best...

Conor

Quote:

---

Originally Posted by conor

Hi Emily,

I was enquiring about the authorisation type rather than the transaction mode.

All the best...

Conor

---

Hey Conor, it looks like it might be a case of our client's account with Protx being suspended... So, the moral of the story is ... if you get an error message like that go straight to Protx!

Cheers for your help.
Emily

Hi Emily,

Thanks for the update! :)

All the best..

Conor

Hi, we finally have our previous issues with the incorrect IP address and installing crypt_blowfish ironed out and we're able to successfully make test orders. (Thanks for the help, Conor!) Now we have two more problems.

When I have the transaction mode set to "test" and I use a test credit card with all the fields filled in correctly, the order goes through. However, if I leave any of the credit card fields blank, or if I have transaction mode set to live and I try to use the test credit card numbers, I get the following error on a blank white page:

"Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later."

It seems like when I'm supposed to be getting an error screen saying "you are missing fields" or whatever the problem was, I'm getting this message instead. Is Protx trying to send an error message, and I'm missing something on my end? Could this be because we're in a staging directory on the server, or is there some other reason why the error messages aren't showing up properly?

Here's where we have the cart installed:
http://www.bigmamaslings.co.uk/STAGING/index.php

The second problem is that when I turn on the debugging, the screen says this at the bottom:

Encryption NOT USED!

However, crypt_blowfish is now installed (there are no errors showing in the admin any more) and we have a keyphrase set. Does my client also need to set this keyphrase in the Protx admin somewhere, or change any other setting to make the encryption work?

Hi,

Something's seriously messed up with your checkout. I'm afraid I can't help without having full access to your site so I can examine your code.

Please send me your SSH details, shop login details and shop admin login details.

You have my address from before! :)

All the best...

Conor
http://ceon.net