Jump to content
Sign in to follow this  
perfectpassion

Protx Direct v2.22

Recommended Posts

The problems I was having with the error message "Bank Unavailable" was in fact an error that was at the Protx end. Apparently, it was down to a TID number not being associated to the account which is a number that directs payment information to your bank.

 

I thought it maybe useful to post this in case it happens to someone else as it has taken a very long time for the error to be found :blink:

Share this post


Link to post
Share on other sites

Ok now I am able to send to Protx I have been running some test POSTS. I have installed v2.4a from version3 and am now experiencing a new problem.

 

I have 3 currencies that a customer can choose from the default being the Euro. Everything is fine for posting Euro transactions yet if the currency is changed to one of the others i.e sterling the amount is shown correctly on screen (i.e it has been converted ok) the emailed invoice shows the correct value for the order yet the amount sent to Protx is the value in Euros but being charged in sterling. e.g

 

Total cost £69.64 - value sent to Protx £103.74 (which is what it would be if it were in Euros).

 

Any help most gratefully accepted.

 

John

Share this post


Link to post
Share on other sites

in protx_process.php find this line:

Amount => number_format($HTTP_POST_VARS['ord_total'], 2, '.', ''),

 

and change to:

Amount => number_format($HTTP_POST_VARS['ord_total']*$currencies->get_value($currency),$currencies->get_decimal_places($currency),'.',''),

 

I haven't been able to test it properly as my Protx account is single currency. Please let me know if it works and I'll include it in the next update.

 

Tom

Edited by perfectpassion

Share this post


Link to post
Share on other sites

Tom,

 

Thanks for your reply.

 

I rolled back to v2.4 due to all of the problems and have kept that version so I made the modification in

 

includes\modules\payment\protx_direct.php at line 310

 

I sent a test Post through and I received the following error:

 

Fatal error: Call to a member function on a non-object in /homepages/2/d179581832/htdocs/catalog/includes/modules/payment/protx_direct.php on line 310

 

I am pressuming that this would also have been returned if I had used it in V3 as well.

 

Sorry for the delay in responding...Tax Return time! :angry:

Share this post


Link to post
Share on other sites

if you are using v2.4a open includes/modules/payment/protx_direct.php

 

find:

function before_process() {
  global $HTTP_POST_VARS, $order, $cart, $currency;

 

amend to:

function before_process() {
  global $HTTP_POST_VARS, $order, $cart, $currency, $currencies;

 

I haven't tested this but i think it should do the job.

Tom

Share this post


Link to post
Share on other sites

Thanks for the info Tom. If I used a brain cell it might help at times!

 

I have made the ammendment and the correct values are now being sent to Protx...(verified by checking in debug mode). However, I am now experiencing a VPSTxID error on both simulator and test servers. According to the Protx documentation that is down to a unique identifier that has not been sent from Protx....is that correct or am I not using that brain cell again ?

 

Many thanks for your time...it is very much appreciated.

 

John

Share this post


Link to post
Share on other sites

Hello all, and thanks for that great contribution!

I'm just about to go live and am doing some checkout tests etc ... and got a weird error message.

 

When filling in the card details, if I choose SOLO and enter everything correctly and leave the Issue number field empty, I can still click on CONTINUE and go to the Order Confirmation page.

But when I click on CONFIRM ORDER, I'm sent back to the Payment Information page with an Error Message not in the actual page but in the URL:

 

checkout_payment.php?error_message=The%20card%20issue%20number%20is%20required%20but%20missing%20or%20invalid%20-%20Your+credit+card+could+not+be+authorized+for+this+reason.+Please+correct+any+i
nformation+and+try+again+or+contact+us+for+further+assistance.&osCsid=42ca6d76ecfeab66d8cc0b4489a9dbe0

 

Any idea on how to fix this?

 

Many thanks

Share this post


Link to post
Share on other sites

When testing the solo are you using live or test server mode?

 

Are you using a real card or the test card number from Protx (6334 9000 0000 0005)? - the test number will only work if you use an issue number of 1.

 

Tom

Share this post


Link to post
Share on other sites

I'm using the test number in test server mode.

 

If it's working when turning the website live, that's fine for me.

 

But is it really working ok because I own a SOLO card myself and I don't have any Issue Number on it, so if I'm inputing everything in the shop is it going to work ok?

 

Thanks for your help Tom ;)

Share this post


Link to post
Share on other sites

Hi. I have installed the Protx Direct 3 module on my clients shop but even when I install and enable it in the Admin pages it does not show up on the Payment options page. Any ideas?

 

Thanks in advance...

Share this post


Link to post
Share on other sites

@nanouchman: not all SOLO cards (esp. newer ones) have issue numbers. The solo test number does need the issue number or it will fail - if you want to make sure test your personal card in live mode (use deferred mode) then go into protx admin area and abort the transaction - that way you woin't be charged.

 

@Thieving_Gypsy: I don't think this is a problem specific to the protx module - I would start by looking at payment zones to make sure that part is all setup correctly for protx to appear for the country selected.

 

Tom

Share this post


Link to post
Share on other sites

Tom,

 

As requested (sorry for the delay) the error message I'm receiving

 

VPSProtocol=2.22 Status=OK StatusDetail=VSP Direct transaction from VSP Simulator. VPSTxId={DC6712B3-D48E-4EA7-A880-98C621EFED66} SecurityKey=VRTJ4XSIYD TxAuthNo=7171 AVSCV2=SECURITY CODE MATCH ONLY AddressResult=MATCHED PostCodeResult=NOTMATCHED CV2Result=MATCHED VPSProtocol=2.22&TxType=PAYMENT&Vendor=dargle123&VendorTxCode=5318126935841437&
Amount=203.48&Currency=GBP&Description=Order+Number%3A+1&CardHolder=John+Me&
CardNumber=4929000000006&StartDate=0305&ExpiryDate=0308&IssueNumber=&CV2=555&
CardType=VISA&CustomerEMail=unbridledmarketing%40dsl.pipex.com&
ContactNumber=01823+480589&BillingAddress=fairhaven%2C%0D%0A
Beercrocombe%2C%0D%0ATaunton%2C%0D%0ASomerset%2C%0D%0AUnited+Kingdom&
BillingPostCode=TA3+6AJ&DeliveryAddress=fairhaven%2C%0D%0ABeercrocombe%2C%0D%
0ATaunton%2C%0D%0ASomerset%2C%0D%0AUnited+Kingdom&
DeliveryPostCode=TA3+6AJ&CAVV=&XID=&ECI=&ClientIPAddress=81.179.109.140&
Basket=3%3AKilmartin+Chocolate+Milk%3A1%3A79.95%3A16.79%3A96.74%3A96.74%3A
Baltimore%3A1%3A79.95%3A16.79%3A96.74%3A96.74%3A
Shipping%3A1%3A10%3A----%3A10%3A10&3DSecureStatus=

Share this post


Link to post
Share on other sites

Just a word of caution for people who use "Must Agree To Terms and Conditions" in their checkout - this latest Protx Direct version breaks it and you end up in a perpetual loop (because the validation for the MATTAC contribution fails).

 

Vger

Share this post


Link to post
Share on other sites

Checkout payment posts a variable to checkout process for this contrib which , if agreed, passes the person on to checkout confirmation. What's happening now is that checkout payment goes to protx_process, the variable is not passed, so when it gets to checkout process it gets slung back to checkout payment just as if the person did not agree.

 

e.g. in checkout_process.php

 

if ($HTTP_POST_VARS['agree'] != 'true') {

 

tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'error_message=' . urlencode(ERROR_NO_CONDITIONS), 'SSL'));

 

}

 

I don't have time until next week to look at this, hence the warning to other users with this contrib.

 

Vger

Share this post


Link to post
Share on other sites

I see - this is as a result of the changes made to "must agree to terms" for those with javascript disabled.

 

Later versions of "must agree to terms" have a "paypal fix" - this is required for the protx direct module (v3+) - it deals with any payment module that requires redirection to another file or site before checkout_process (such as the standard paypal module).

 

Try updating to the latest version of "must agree to terms" and let me know if it's still causing probs.

 

Tom

Share this post


Link to post
Share on other sites

No, That's not it. I think I have a fix now, but will need to check it out tomorrow. If it works i'll post it here.

 

Vger

Share this post


Link to post
Share on other sites

thanks Vger for looking into it.

 

Can you please confirm which "agree to term" contrib you have found the problems with. The contrib I have on my live site and tested with is the one I posted above - the problem is the code you posted above for checkout_process.php is different to that in the install instructions for the latest version of the contrib - I have it as:

// BEGIN OF MUST AGREE TO TERMS - JAVASCRIPT DISABLED FIX - By Phliplip
// INCLUDES PAYPAL-FIX - By red-ray.de
if(empty($HTTP_POST_VARS['agree']) and ($HTTP_POST_VARS['check_agreestatus']=='true')) {
include(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CHECKOUT_PROCESS);
tep_redirect(tep_href_link(FILENAME_CHECKOUT_CONFIRMATION, 'terms_not_agreed='.urlencode(CONDITION_AGREEMENT_ERROR), 'SSL'));
 }
// END OF MUST AGREE TO TERMS - JAVASCRIPT DISABLED FIX - By Phliplip

This does not have the problem you describe.

 

Tom

Share this post


Link to post
Share on other sites

The fix that I thought may work does not. However, I do not see why using a particular version of "Must Agree To Terms" would make any difference to this, as it still leaves the problem of how the variable 'agree' is passed from protx_process.php to checkout_process.php - that's where it is breaking down.

 

Have you modified protx_process.php or your version of "Must Agree To Terms"?

 

Vger

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×