OSCOMMERCE SUPPORT CALL 702-453-3332

The debug line you posted shows that your site is correctly formatting the data to send to Protx but that there is no reply from the protx server.

You have already said that cURL (with ssl) is installed and uncommenting those lines out didn't help so that rules those out.

Does your host have any firewall settings that may be blocking you from connecting to the protx server?

Tom

hey guys


Im using this great contrib and its working fine, its just I wanted to change the font color of the error messages?? Could you please show me where this code is located?

Hi all,

Sorry I haven't posted back with an update.
Cracked most of it the other day. Transpired libCurl had been rebuilt in PHP on our shared server recently but without ssl. I uploaded the test PHP scripts that protx provide and ran them on the server (as they gave better debug info) and this alerted me to the problem (protx have logged it before on their support site). Was then just a case of getting the server administrator to rebuild libCurl again and everything then ran fine!

As for my other problem, it appears as though I am still blocked from the protx site. Have contact my ISP who assure me that it is nothing from their end as they say they use protx themselves! Am at a total loss although the most important thing is that the module in now up and working again!

Many thanks for your help and advice

dwarren

The error message formatting is not controlled by the payment module. It is done in checkout_payment.php. You need to modify the infoBoxNotice and infoBoxNoticeContents section of stylesheet.css

Known problems:

1. Some builds of IE 6 - upgrade to 7 or use Firefox
2. Norton Anti-Virus ports being closed. Solution - uninstall and use AVG instead.

Vger

Just want to check something guys, I use Protex 2.22.

Is this 3D secure ready. I have read through all the posts but still not 100% sure. I can not see any settings in admin for 3D secure however 3D secure is being rolled out by protex.

Thanks
Steve

the Protx module from v3 is 3D-Secure ready - you need to contact Protx to activate with your merchant bank then setup your rules in the Protx administration area.

Tom

Hi

I Think I am having a problem with Protx Direct , I say think , because i'm a bit unsure what info i should have in my database for failed transactions , if any.

This is my problem , I hope someone can help me.

I am getting quite a few failed transactions , about 5 -10 per day , some of these end up as successful and some do not. All the failures that end up as succesful show as being about 10-20 secs apart when i check in protx Admin. They all contain no address , postcode or any other data apart from the customers e-mail address and an order number.

I contacted Protx support and they asked me for -

"In order for us to investigate further please could you supply the Status and Status Detail we returned to you in the Protx Response to the Transaction Registration POSTs for a few of the failed transactions (send four of five examples).

In regards to the failed transactions which are then authorised please could you supply us with the VendorTxCodes and customer name of an example of these failed transactions"


I checked in the database and returned the info to Protx as below (customer info edited out)

From Protx admin

Vendor TX Code: **************** A.customer (Failed) Order Number: 2991

Vendor TX Code: **************** A.customer (Failed) Order Number: 2991

Vendor TX Code: **************** A.customer (Failed) Order Number: 2991

Vendor TX Code: **************** A.customer (Failed) Order Number: 2991

Vendor TX Code: **************** A.customer (Failed) Order Number: 2991

Vendor TX Code: **************** A.customer (successful) Order Number: 2991

Our Database entry -

order ID = 2991 Vendortxcode **************** txtype PAYMENT vpstxid {****************} staus OK statusdetail BLANK

The above is one example of many , the failures are about 10-20 secs apart and the error is "transaction declined by the aquiring bank". I am assuming it's declined in most of these cases because the address and other data is missing.

The last reply i had from protx support is below -

"We will always *always* return a status as long as the transaction is registered with us. So for all of those failed transactions, a status would have been returned - for some reason it either didn't reach you or you didn't log it.

There is a distinct reason for the failures, probably malformed data, incorrect card type, incorrect card number length or something - but without the status on the failed ones I cant tell you what it could be"



Should a status be recorded for failed transactions in the database ?

If yes , what could be the reason for me not having this data ?

Any help would be appreciated , i have been trying to sort this for some weeks now.

The current Protx Direct module does not store failed transactions in the database - only successful ones. It would not be too much work to store failed transactions but the problem would be when you came to troubleshooting it could be difficult to follow becuase the order number stored would only be a provisional order number - osc does not generate the order id until after payment is successful so the protx direct module simply takes the last order_id from the orders table and increments it by 1.

I have also found that when transactions fail many of the details are blank in the protx admin area - this is not due to fault with the module that I have found but for some reason protx don't always seem to store the details when it is declined for some reasons - I have found some of the commonest reasons for declined/failed transactions are customers selecting the wrong card type or failing the AVS check becuase the billing address doesn't match the cardholder's address.

If you think it would be a good idea to store failed transaction let me know and I can point you in the right direction and may include it in the next update.

Tom

Hi,

I'm having a problem where I can't get the values entered in the module admin page to be saved. You can click 'edit' & change values such as vendor name etc. but when you click 'update' the values go back to their defaults.

I am guessing maybe this is because I installed the protx direct module & db tables on another dev server, but then realised I needed SSL installed, so I re-hosted my whole osCommerce set-up to my live servers with the protx code & sql tables already installed. I've tried re-running the sql create statements but that didn't work.

My other databased information e.g. products, are updating OK.

Many thanks in advance,

Ben

read this thread: http://forums.oscommerce.com/index.php?sho...+payment+module

Thanks Tom , I just needed to confirm that nothing odd was happening with my Protx Module.

I couldn't work out why some payments were failed 4-5 times in a row , and then ended up being authorised. They were so close together ( 10 -20 secs apart) , i thought this was too short a time for someone to change details and try again.

That worked, many thanks Tom

Hello Tom
Thank you for all your hard work on this.
Since moving from v2.4 to v3.0c I (and my customers) occasionally get this error message:


Sometimes it is necessary to log out and log back in before the payment will be accepted but usually if you try it again it is OK.

Any pointers as to where to start looking for the cause of this would be greatly appreciated.

I haven't seen this error before so I contacted Protx - they say that this means a 2nd or subsequent transaction is attempted with the same VendorTxCode but different value as a previous transaction.

I'm not sure how this is happening - the VendorTxCode is generated using the tep_create_random_value function each time the module is called - I'm not sure how it is generating the same value more than once.

What steps are needed to recreate the problem?

Tom

I have seen this happen before with other payment modules. Provided it doesn't conflict with Protx try setting INT(16) to a higher figure in the database table 'protx_direct' in the vendortxcode field via phpMyAdmin. Tom will know if increasing that figure will cause problems with Protx.

Vger

I have tried to reproduce the problem by first putting through a transaction with incorrect cvv or expiry date and then doing it again with correct details but have not been able to after quite a few tries, however after a little more investigation the error does seem to be after a failed attempt (due to incorrect cvv or expiry date) but otherwise it is quite random.

I think what is happening is that the random 16 digit value is not as random as it should be hence creating the smae value again.

Try editing protx_process.php:


to



no change needs to be made to the database - the field size is already set to 40 (the maximum) - this increases the number of digits and should make it less likely that the same 'random' value appears more than once.

Tom

I think what is happening is that the random 16 digit value is not as random as it should be hence creating the smae value again.

Try editing protx_process.php:


to



no change needs to be made to the database - the field size is already set to 40 (the maximum) - this increases the number of digits and should make it less likely that the same 'random' value appears more than once.

Tom

The vendortxcode field in the protx_direct table, at least on the version I am using, is set to INT(16) in the database.

Vger

I do apologise. Mine is set to 40 - I forgot that I increased it a short while ago as part of some work I'm doing developing the module - you are correct - the field size will need increasing.

Tom

Hi guys,

Am I missing something with the vendor tx code, why use a random number? Wouldnt the order number be more useful when reported out of protx?

It would be useful to have the order number but there are some problems with that approach:
1. The VendorTxCode has to be unique - if the order number was used it would have to be appended with a unique random number for each attempt to achieve that
2. osCommerce doesn't assign an order number until after the payment has been successful. Assigning a number beforehand would need quite a bit of modification to osc (as has to be done for paypal ipn)

Tom

Thanks for the super speedy response!

I was just thinking that:

$VendorTxCode = $uid . $new_order_id;

would at least append the expected order number to the random number as the protx reports dont contain the description field (order number), so reporting is improved if the reports contain something that can link the payment to an order.

On another point, is the protx_direct table supposed to have the VendorTxId in the vendortxcode field?

Nice work by the way!

that is reasonable - as long as people don't take the order number as given when reconciling transactions (btw, the module does already pass the expected order number if you check in protx admin).

I will perhaps make that change for the next release - I'm currently working on incorporating having the results of AVS/SVV/3d secure visibile in the osc admin and also a release/refund functionality for those that use deferred transactions, just refund for payment mode. I'm not adding anything for preauth as this is not deprecated and support will be stopped by protx in June.

It should be storing the vendortxcode in the protx_direct table however I have found that there is a bug in the current and previous versions of the module that means it is not stored correctly but this is fixed in the release i'm working on (i think!)

Tom

All sounds good.

BTW - Shipping tax isnt being sent to Protx in the Send Basket option

Am I too tired and missing something??????

I've just updated from v2.4 to v3.0c. Everything works ok in Simulator and Test modes (i.e. I'm getting sent to the 3D Screen) but when I go to Production my "live card tests" are just getting authorised as normal from the customer perspective. However, when I log into my VSP admin I can see the message:

The initial authentication request returned an ERROR. No 3D-Authentication occurred! Please e-mail support@protx.com to inform us of this error.

I have informed Protx who have said:

The site is not redirecting the customer to the 3D Secure pages because you are using VSP Direct, this means your developer will need to ensure that the ************* system passes the customer to the 3D Secure pages. Full instructions for doing this can be located in the Intergration Guide this can be found on the URL bellow.

I have 3D Secure "ON" and have checked the upgrade again. (I've even amended the 16 to 32 INT length for vendortxcode in the previous posts).

Hope this is really one of those "DOH !" moments..........

If it works in simulator and test modes then their is no problem with the module.

Have Protx enabled 3D-Secure with your merchant bank? - that needs to happen before it will work in live mode

Tom

Hi Tom,

You're right on the money as usual !

Although Protx had said it was all set up, they have now come back and said that Natwest Streamline are still testing 3D Secure with Protx and expect to get it signed off within the next couple of months.

So it looks like Natwest Streamline may not be up and running until May time (although you think you have turned 3D Secure on in your Protx Account parameters).

Thanks again.

Bob

New Version (v3.1) uploaded to http://www.oscommerce.com/community/contributions,4026

New features:
- Ability to release deferred transactions via admin order page.
- Ability to refund transactions via admin order page.
- AVS/CVV/3D-Secure checking results shown in admin order page.
- Logging of failed transaction attempts in database (these will show in admin if order is eventually successful).
- VendorTxCode now in format order_id-randomnumber for easier matching in Protx admin and increased length of random number
- Improved debug reporting including cUrl failure message
- Minor bug fixes / code tidying

KNOWN ISSUE:
- Release / Refund functionality DOES NOT WORK with transactions made prior to upgrading to this version (due to a problem with the storing of VendorTxCode)

Upgrade instructions in package

Any problems please let me know.

Tom

Hi, I am just upgrading and i get the following error:


"The VendorTxCode you supplied is an invalid length. VendorTxCodes should be between 1 to 40 characters long. - Your credit card could not be authorised for this reason......"

I have checked the table and the VendorTxCode is the order ID, I notice the old VendorTxCode in the table are all the same number. (not sure what version it is -- its been running fine for 12 months)

The order ID is 36545821 so is between 1 and 40 characters.

I am in production mode, correct vendor, and I.P. address registered.

It is late and I've been "upgrading" for hours........maybe something simple

Thanks

Hi

Nice to see that this invaluable contrib is being constantly updated

Thanks perfectpassion.

Onto the error

I tried a refund and catalog>admin>orders_protx.php (line 52) attempted to find tep_create_random_value.

This does not exist in my version of osC, just tep_rand which is obviously not the same thing.

Sorry for that omission - tep_create_random_value if a standard osC function but is only on the catalog side and I forgot I'd copied across to admin.

Insert the following into admin/includes/functions/general.php


Tom

"The VendorTxCode you supplied is an invalid length. VendorTxCodes should be between 1 to 40 characters long. - Your credit card could not be authorised for this reason......"

tried a number of things, not having much success is this an error any one has encountered before?
really appreciate your help.

Thanks

Darren

In your protx_direct table

reset the field vendortxcode to varchar(40)

error in orders_protx.php - Version 3.1

Effect: Refunds don't work due to missing vendortxcode

Line 57



should be ..

Thank you babygurgles for pointing that out - it was late last night as I put the package together (at least that's what I'm blaming on my silly mistakes!)

I've updated the install instructions to include the tep_create_random_value function and corrected orders_protx.php as you pointed out.

Thanks, Tom

Less of the (at least that's what I'm blaming on my silly mistakes!) please!

I for one am grateful that you a) Do this at all .. and That you update it so regularly.

Glad I was of some help.

thank you i did that but i had the same error

I changed:

$VendorTxCode = $new_order_id . '-'. $uid;

to remove the - and it works just fine now.

Protx will not accept a VendorTxCode of more than 40 chars - $uid is 32 digits so if removing the '-' works it must mean that $new_order_id is 7 digits long. $new_order_id is creasted by getting the last order id from the orders table and incrementing it by 1. This must mean that your order numbers are > 999999.

Instead of removng the '-' you could change the $uid=tep_create_random_value('32','digits) to a lower value and this would shorten the random value (but don't have it to short as the shorter the greater the chance of having 2 values the same)

Tom

Thanks Tom.

My order numbers are 8 chars so they are spot on 40 without the - I now understand the logic and will ammend.
(I was over 40 chars before)
Thanks again,

Darren

I'm in trouble here. My payment system isn't working.

Symptoms:

Goes straight from checkout_payment to checkout_sucess without going through the PROTX system.

What I have done:
1) changed vendortxcode in admin to VARCHAR(40)
2) Installed the new version of PROTX 3.1a (worked on my test site.
3) Uninstalled and uploaded from back up .. still the same.

Help lol I'm losing lots of money ..

Well it is working.

I think it was never broken.

It certainly wasn't a problem with the contrib just to make that clear. Whatever it was/is was caused by me.

Looking into it.

LOLZ I think I'm a bit over optimised

I have caches all over the place. I think I upgraded to 3.1a then forgot to clear the configuration cache

There's a warning to everyone who is capable of being as stupid as I am

Hey guys

just a quickie, im using the new update and have a little problem?

When I click refund im getting this error :

Fatal error: Call to undefined function: tep_create_random_value() in /home/www/norfolklights.com/public_html/admin/orders_protx.php on line 52

Can anybody advise?

You are missing a function in admin>includes>functions>general.php

The function was updated in the latest contrib, also theres a change to another file (orders_protx)

Sorry to bring bad news, but I've just been to have a look at your site, and found the product images won't load on the front page, neither in the product description! I clicked on the contact page, that wouldn't load either, I got this instead The click here won't function either.

BTW I'm using Firefox, but I get the same in explorer

Thanks for the speedy response I feel a bit of a dipshit because the answers were on the previous page lol.

Has anybody managed to fix the refund error yet? I got it to start the refund and then I get problems with the Vendor TX Code?

heheh and that has been sorted, it was me playing with things. Take a look now

Right I can get order_protx.php to read the vender code from mysql but it looks like the vender code is stored incorrectly there?

How is that number generated? via the protx module when a payment is sent or does protx generate this code?

Let me know and I think i can sort this little problem out.