Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Protx Direct v2.22


Guest

Recommended Posts

  • Replies 1.2k
  • Created
  • Last Reply

Top Posters In This Topic

the reason I asked is the only other person i've known with a blank screen with no errors on checkout_process.php was on GoDaddy. They needed a specific curl setting to work.

 

The info is here it may apply to you (but with a different proxy server) - it would be worth checking with your hosts

 

Tom

Link to comment
Share on other sites

Thanks for another great Protx module, been using it since 2.0.

 

I installed the latest update about 2 weeks ago and tested it with as many different cards as I could including maestro with 3d secure. Everything is working fine, but today Ive had a customer atempt payment twice and both times he's been forwarded to his account page and not checkout success. The payment has gone through in the protx admin but doesnt show on the site. Ive tried to repeat the problem with the same products and card but couldnt. Could it be his cookie setings are to blame?

Link to comment
Share on other sites

I am trying to debug it now - I have established that it happily gets all the way to almost the end of the checkout_process.php file. I have altered the end so that it echos the link it is about to go to:

 

  echo('this is the link:' . tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));

 tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));

 require(DIR_WS_INCLUDES . 'application_bottom.php');
?>

 

This confirms that the link is created correctly - but it doesnt actually go to that link. I.e. it gets to checkout_process.php, does all the stuff in there (hence order goes through fine) and prints the link it wants to go to e.g. <mystore>/shop/checkout_success.php?osCsid=7b24f576ac592fc7b12e94b11ddaf14c but doesnt actually go there. If I copy and paste that link in the address bar it goes there fine and the successful checkout is reported etc...

 

So, tep_redirect() doesnt seem to be making the page redirect to that link...

Link to comment
Share on other sites

Reuben - glad it's sorted, thanks for letting us know.

 

Cai - when you say account details - do you mean the account login? The module will redirect to the login and the order not processed if the session is dropped (which shouldn't happen) or the customer isn't logged in (which would only happen if the session was dropped). It certainly could be related to a bad cookie though if cookies are blocked it should be using the osCsid in the urls

 

Tom

Link to comment
Share on other sites

Hi Tom,

 

I have a strange problem here with V4.4. I have a shop that's working inasmuch as the dosh is being taken from the customer's card, the db table for protx_direct is being updated, but the order doesn't process at all. I've really tried to solve this, but would appreciate some help, please (it's a live site).

 

What's happening is that I'm getting 'Credit Card Error!' on paying with a card, so have modified that string in includes/languages/english.php to change the Protx error message from 'Credit Card Error!' to 'Credit Card Error in Protx!', which message now appears after posting to Protx. I did that because there are several files with that string in, and I wanted to narrow down whence it comes.

 

Protx takes the money from the card, but nothing seems to come back to the shop, no order, no emails, nothing. A valid record is written in the protx_direct table, however.

 

In test mode, using a test card, it returns to the credit card page with this URL:

 

https://shop.playwoodtoys.com/checkout_paym...c_expires_year=

 

 

Another trip through the payment process, with a real card, AND via 3DSecure (which worked, the money was taken, db updated properly) led to this URL:

https://shop.playwoodtoys.com/checkout_paym...c_expires_year=

 

which is exactly the same as the one above!

 

I'm sure that there's a clue in the fact that it keeps thinking the expiry date is incorrect (it isn't).

 

At all stages the user interaction seems ok, and all forms, fields and confirmations are also correct.

 

I've ripped out and reinstalled protex direct, checked and re-checked, and I can't find the cause. HELP!!!

 

Cheers, Laurie.

Edited by brownowl
Link to comment
Share on other sites

Hello

 

My client is still getting large numbers of failed transactions (£2600 last month) due to the order not being completed. More investigation leads us to believe that the problem occurs on this page; protx_process.php?action=process

 

And that just seems to be the new meastro cards without issue numbers!

 

Any ideas anybody? My client is a bit frantic now and is considering going back to Protx Form...

 

Andy

Link to comment
Share on other sites

We've just put a card through the protx management screens successfully, and then tried the same card through the site. We get the usual error as described above. This is not good, and I'm at my wit's end to see where this might be going wrong.

 

Cheers, Laurie.

Link to comment
Share on other sites

I've just done a test transaction and a live transaction, both failed as described above, but this time, here's the debug info:

 

Test transaction with "test" card:

 

Request URL=https://ukvpstest.protx.com/vspgateway/service/vspdirect-register.vsp

Data string sent=VPSProtocol=2.22&TxType=PAYMENT&Vendor=******&VendorTxCode=25**-74669753405113456032259062******&Amount=3.00&Currency=GBP&Description=Order+Number%3A+2532&CardHolder=*****+***&CardNumber=5404000000000001&StartDate=0103&ExpiryDate=0108&IssueNumber=&CV2=123&CardType=MC&BillingAddress=********%2C+************+**%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&BillingPostCode=IP**+***&DeliveryAddress=********%2C+Grundisburgh+Rd%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&DeliveryPostCode=IP**+***&CustomerName=*********&ContactNumber=07736******&CustomerEMail=*********%40*******************&ClientIPAddress=10.0.1.152&Basket=2%3AColoured+Bookmarks%3A1%3A1.00%3A0.00%3A1.00%3A1.00%3AShipping%3A1%3A2%3A----%3A2%3A2&AccountType=E&Apply3DSecure=0

Protx response=VPSProtocol=2.22

Status=OK

StatusDetail=0000 : The Authorisation was Successful.

VPSTxId={954A6DC6-CCE4-2694-1ED1-EE82BF7*****}

SecurityKey=W8AKPS****

TxAuthNo=3583***

AVSCV2=SECURITY CODE MATCH ONLY

AddressResult=NOTMATCHED

PostCodeResult=NOTMATCHED

CV2Result=MATCHED

3DSecureStatus=NOTCHECKED

Response array=Array

(

[VPSProtocol] => 2.22

[status] => OK

[statusDetail] => 0000 : The Authorisation was Successful.

[VPSTxId] => {954A6DC6-CCE4-2694-1ED1-EE82BF7*****}

[securityKey] => W8AKPS****

[TxAuthNo] => 3583***

[AVSCV2] => SECURITY CODE MATCH ONLY

[AddressResult] => NOTMATCHED

[PostCodeResult] => NOTMATCHED

[CV2Result] => MATCHED

[3DSecureStatus] => NOTCHECKED

)

 

curl_error=

 

Live card, live transaction:

 

Request URL=https://ukvps.protx.com/vspgateway/service/vspdirect-register.vsp

Data string sent=VPSProtocol=2.22&TxType=PAYMENT&Vendor=******&VendorTxCode=25**-52881278035046185963675275******&Amount=5.70&Currency=GBP&Description=Order+Number%3A+2532&CardHolder=*****+***&CardNumber=****************&StartDate=&ExpiryDate=0909&IssueNumber=7&CV2=802&CardType=MAESTRO&BillingAddress=********%2C+************+Rd%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&BillingPostCode=IP**+***&DeliveryAddress=********%2C+************+**%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&DeliveryPostCode=IP**+***&CustomerName=*****+***&ContactNumber=07736******&CustomerEMail=*********%40*******************&ClientIPAddress=10.0.1.182&Basket=2%3ABells%3A1%3A2.99%3A0.00%3A2.99%3A2.99%3AShipping%3A1%3A2.71%3A----%3A2.71%3A2.71&AccountType=E&Apply3DSecure=0

Protx response=VPSProtocol=2.22

Status=OK

StatusDetail=0000 : The Authorisation was Successful.

VPSTxId={5BA2D632-6DC6-AF80-D47C-1D38C47*****}

SecurityKey=QY7EGN****

TxAuthNo=5868****

AVSCV2=SECURITY CODE MATCH ONLY

AddressResult=NOTMATCHED

PostCodeResult=NOTMATCHED

CV2Result=MATCHED

3DSecureStatus=NOAUTH

Response array=Array

(

[VPSProtocol] => 2.22

[status] => OK

[statusDetail] => 0000 : The Authorisation was Successful.

[VPSTxId] => {5BA2D632-6DC6-AF80-D47C-1D38C47*****}

[securityKey] => QY7EGN****

[TxAuthNo] => 5868****

[AVSCV2] => SECURITY CODE MATCH ONLY

[AddressResult] => NOTMATCHED

[PostCodeResult] => NOTMATCHED

[CV2Result] => MATCHED

[3DSecureStatus] => NOAUTH

)

 

curl_error=

 

Once upon a time I was a professional programmer, not in php unfortunately, and although I can mostly make sense of it, debugging it is difficult as it seems hard to get values and stuff at different stages of the processes.

 

Cheers, Laurie.

Link to comment
Share on other sites

Help

Protx Direct v4.4

 

Fatal error: Call to undefined function: curl_init() in w:\home\test1.com\www\protx_process.php on line 339

 

Post 210 onwards in this very topic (page 11) will answer your question. You need curl installed to use this plug-in, and you don't appear to have it.

 

Cheers, Laurie.

Link to comment
Share on other sites

sorry I haven't posted here for a little while - my net access is patchy at the moment!

 

brownowl - I'm not sure what's going on here. To clarify from your posts: you attempt a transaction +/- 3D-Secure, it is successfully completed at the Protx end, the details are correctly recorded in the protx_direct table but the customer is directed back to checkout_payment.php with the "Invalid expiry date" error instead of checkout_success.php and there is no record of the order. This suggests something going wrong either in the protx_process.php file or early on in checkout_process.php. However, the expiry date message is only generated in one place in the module - the pre_confirmation() function and this is called between checkout_payment.php and checkout_confirmation.php (i.e. before anything is sent to Protx) therefore leading to my confusion. The debug is correct and should go through ok. Have I interpreted the situation correctly?

 

thieving_gypsy can you confirm which version of php you are using? Just looking through the code today I've spotted a function that I've only recently discovered only works with PHP5 - it'll only come to light when there's a problem with either the issue number or start date (i.e with maestro cards) and will cause PHP to drop out with a fatal error in protx_process.php

 

Tom

Link to comment
Share on other sites

sorry I haven't posted here for a little while - my net access is patchy at the moment!

 

No problem, we all have our "challenges", but I must admit I was getting worried!

 

brownowl - I'm not sure what's going on here. To clarify from your posts: you attempt a transaction +/- 3D-Secure, it is successfully completed at the Protx end, the details are correctly recorded in the protx_direct table but the customer is directed back to checkout_payment.php with the "Invalid expiry date" error instead of checkout_success.php and there is no record of the order. This suggests something going wrong either in the protx_process.php file or early on in checkout_process.php. However, the expiry date message is only generated in one place in the module - the pre_confirmation() function and this is called between checkout_payment.php and checkout_confirmation.php (i.e. before anything is sent to Protx) therefore leading to my confusion. The debug is correct and should go through ok. Have I interpreted the situation correctly?

 

Tom

 

Yes, you have. That is exactly what's happening.

 

Thanks for the clues as to where this might be happening.

 

I've checked the site, and I can confirm that the following files are unchanged:

 

protx_process.php

includes/languages/english/checkout_process.php

 

These have been changed:

 

checkout_confirmation.php

checkout_payment.php

checkout_process.php

checkout_success.php

 

They were changed for some plug-in or other, and I'll find out which and see if I can spot the problem.

 

Cheers, Laurie.

Link to comment
Share on other sites

Just double-checked, and these have not been changed:

 

checkout_payment.php

checkout_process.php

checkout_success.php

 

This has been changed:

 

checkout_confirmation.php

 

It looks as if it's the change to force shoppers to accept the Ts & Cs prior to purchase, so I'll revert to the original code and re-test.

 

Cheers, Laurie.

Edited by brownowl
Link to comment
Share on other sites

Ok, I've reverted to the original code, and the error is just the same. Same message with a pink bar underneath. I'm sure there's supposed to be a message in there somewhere...

 

Cheers, Laurie.

Link to comment
Share on other sites

sorry I haven't posted here for a little while - my net access is patchy at the moment!

 

brownowl - I'm not sure what's going on here. To clarify from your posts: you attempt a transaction +/- 3D-Secure, it is successfully completed at the Protx end, the details are correctly recorded in the protx_direct table but the customer is directed back to checkout_payment.php with the "Invalid expiry date" error instead of checkout_success.php and there is no record of the order. This suggests something going wrong either in the protx_process.php file or early on in checkout_process.php. However, the expiry date message is only generated in one place in the module - the pre_confirmation() function and this is called between checkout_payment.php and checkout_confirmation.php (i.e. before anything is sent to Protx) therefore leading to my confusion. The debug is correct and should go through ok. Have I interpreted the situation correctly?

 

thieving_gypsy can you confirm which version of php you are using? Just looking through the code today I've spotted a function that I've only recently discovered only works with PHP5 - it'll only come to light when there's a problem with either the issue number or start date (i.e with maestro cards) and will cause PHP to drop out with a fatal error in protx_process.php

 

Tom

 

Hi Tom

 

The server is running php5.2

 

Andy

Link to comment
Share on other sites

brownowl - if the error text is not appearing in the pink message box it may be due to a templating system such as STS. Do you have that installed?

 

Thieving_gypsy - ignore my previous comment - I was looking at the wrong code - there shouldn't be any PHP5 issues (that I'm aware of). However there is a typo so that the error messages regarding start dates/issue numbers are incorrect.

 

In protx_process.php find (164-169):

		  if ($response_code == '5015') {
		if (stristr($responses['StatusDetail'],'Issue')) { 
  			  $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_ISSUE;
		} elseif (stristr($responsed['StatusDetail'],'Start')) {
		  $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_START;
		}

and replace with

		  if ($response_code == '5015') {
		if (stristr($responses['StatusDetail'],'Issue')) { 
  			  $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_ISSUE;
		} elseif (stristr($responses['StatusDetail'],'Start')) {
		  $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_START;
		}

and again further down (497-502)

 

Tom

Link to comment
Share on other sites

in reply to nahi_sonu's problem where he had just a blank page after confirming an order we have solved the problem.

 

It affects anyone who uses GoDaddy shared hosting.

 

You need to edit the protx_process.php file and add the line

	  curl_setopt ($ch, CURLOPT_PROXY,"http://proxy.shr.secureserver.net:3128");

in the TWO curl_setopt sections

 

Tom

 

 

Hello,

 

I am having a blank page problem, I have tried everything that has been talked about on the board but with no success, done the usual settings changes and looked at the curl on and off options in protex_process

 

I get as far as protx_process.php/action/process and the page goes blank

 

Server info is

 

HTTP Server: Apache/1.3.37

PHP Version: 4.4.4 (Zend: 1.3.0)

 

CURL support enabled

CURL Information libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 ** (IS THIS VERSION OKAY? ) **

 

No information is being stored on the site and no information is being sent to Protx test server

 

My Host is Xcalibre and is using a dedicated SSL on a shared server.

 

I would be so grateful if anyone could help I have been going round in circles for hours.

 

 

Thanks

 

Peter

Link to comment
Share on other sites

protx_process.php/action/process
implies you have "Use Search Engine Safe URLs (still in development)" set to true in your admin (Configuration -> My Store) - set to false and you should be fine.

 

I recommend Chemo's Ultimate SEO URLs contrib.

 

Tom

Link to comment
Share on other sites

i am having problems using protx through test. I have transferred my website to a test domain and hosting service.

 

the setting I have are:

 

Vendor name: testvendor

 

transaction mode: test

 

any ideas?

Link to comment
Share on other sites

you need to change "testvendor" to your actual vendorname

 

Tom

 

Hi Tom

 

Yes I tried that but get this error:

 

Your credit card could not be authorised. Please correct any information and try again or contact us for further assistance. (4020 : Information received from an Invalid IP address. The value was 212.**.**.***.)
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...