Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Protx Direct v2.22


Guest

Recommended Posts

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

Link to comment
Share on other sites

  • Replies 1.2k
  • Created
  • Last Reply

Top Posters In This Topic

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

 

 

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

Edited by dwarren
Link to comment
Share on other sites

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?

 

 

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

Link to comment
Share on other sites

it appears as though I am still blocked from the protx site

 

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

Link to comment
Share on other sites

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

I don't bother doing backups. I love the thrill of screwing it all up!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

 

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.

Link to comment
Share on other sites

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:

Couldn\'t create a transaction (VRTXDupTxAmountMismatch, ) - Your credit card could not be authorized for this reason. Please correct any information and try again or contact us for further assistance

 

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.

Best wishes

Steve

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Edited by Vger
Link to comment
Share on other sites

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

Best wishes

Steve

Link to comment
Share on other sites

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:

$uid = tep_create_random_value(16,'digits');

 

to

 

$uid = tep_create_random_value(32,'digits');

 

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

Link to comment
Share on other sites

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:

$uid = tep_create_random_value(16,'digits');

 

to

 

$uid = tep_create_random_value(32,'digits');

 

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Edited by perfectpassion
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...