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

Hi Tom ,

 

Not sure whats going on here I am on V4.3 all was working fine on test server till last couple of days no I cannot get any card to work weather I am using 3d secure or not. On clicking confirm it just throws me back to the card entry details. I put debug mode on and here is the result.

 

Any Idea what I have done?

 

Chris

 

Request URL=https://ukvpstest.protx.com/vpsDirectAuth/PaymentGateway3D.asp
Data string sent=VPSProtocol=2.22&TxType=AUTHENTICATE&Vendor=xxxxxxxxxxx&VendorTxCode=40-24640383425984863177806859727528&Amount=19.23&Currency=GBP&Description=Order+Number%3A+40&CardHolder=xxxxxxxxxxxx&CardNumber=4929000000006&StartDate=0505&ExpiryDate=0608&IssueNumber=&CV2=123&CardType=VISA&BillingAddress=88+the+street%2C%0D%0A%2C%0D%0Axxxxxxxt%2C%0D%0Axxxxxx%2C%0D%0AUnited+Kingdom&BillingPostCode=GU412AB&DeliveryAddress=88+the+street%2C%0D%0A%2C%0D%0AAldershot%2C%0D%0AHampshire%2C%0D%0AUnited+Kingdom&DeliveryPostCode=GU412AB&CustomerName=xxxxxxxxxx&ContactNumber=12345+12345&CustomerEMail=xxxxxxxxxxxxx&ClientIPAddress=xxxxxxxxxxx&Basket=3%3Axxxxxxxxxxxxt+0%2B%3A1%3A2.97%3A0.52%3A3.49%3A3.49%3xxxxxxxxxxxxxxxxx%3A1%3A9.57%3A1.67%3A11.24%3A11.24%3AShipping%3A1%3A4.50%3A----%3A4.50%3A4.50&AccountType=E&Apply3DSecure=2
Protx response=VPSProtocol=2.22
Status=ERROR
StatusDetail=2015 : The server encountered an unexpected condition which prevented it from fulfilling the request.
VPSTxId={D8BEA6D7-EDDD-EE4F-A0DF-60C66253CF50}
SecurityKey=DCJ1DIFGT9
TxAuthNo=
AVSCV2=
AddressResult=
PostCodeResult=
CV2Result=
3DSecureStatus=
Response array=Array
(
   [VPSProtocol] => 2.22
   [status] => ERROR
   [statusDetail] => 2015 : The server encountered an unexpected condition which prevented it from fulfilling the request.
   [VPSTxId] => {D8BEA6D7-EDDD-EE4F-A0DF-60C66253CF50}
   [securityKey] => DCJ1DIFGT9
   [TxAuthNo] => 
   [AVSCV2] => 
   [AddressResult] => 
   [PostCodeResult] => 
   [CV2Result] => 
   [3DSecureStatus] => 
)

curl_error= 

Better to be looked over than overlooked!

Link to comment
Share on other sites

In the Administration->Customers->Orders screen, if I click on any given order, it will produce the next screen with the payment method (protx direct). I can either choose to Authorise/Cancel this order. If I select Authorise, it comes back with this error :-

 

Fatal error: Call to undefined function: tep_db_fetch_array() in \catalog\admin\orders_protx.php on line 251

 

Looking in the file, this function is called in a <?php ?> block, and the failure happens at the next <php> block..

 

Not sure how to fix this. Any help appreciated.

Link to comment
Share on other sites

@clrob11 - the transaction you have posted is using the AUTHORISE/AUTHENTICATE type - if you change to DEFERRED or PAYMENT do you still get the same error?

 

@blackmogu - I can't reproduce this - that function is defined when application_top.php is called which when you load an order is done by orders.php or if you select an action the the orders_protx.php does it - have you altered your orders.php file from the standard oscomm MS2.2 (other than the change as per protx install instructions)?

 

Tom

 

PS: - In the last few days Protx have changed the software on the test server - this has resulted in a change to the URLs needed - the old ones should work but I've found some of the relase/cancel/repeat functions etc aren't working so I'll post an updated mod with the new URLs shortly

Link to comment
Share on other sites

@clrob11 - the transaction you have posted is using the

AUTHORISE/AUTHENTICATE type

- if you change to DEFERRED or PAYMENT

do you still get the same error?

 

Tom,

 

This seems to work now on all except switch\maestro it just thorws me back to the card entry details.

 

It was probably my mistake :-"

 

But it's really confusing with this 3d secure until protx can sort the issue.

I am not sure were the problem lies. I bet your getting just as fustrated as us.

 

Now if I can just get the 3d secure working......

 

Chris

Better to be looked over than overlooked!

Link to comment
Share on other sites

Tom,

 

Sorry to waste your time. I have now re tested all cards on 3d secure.

all are now working. I think on the switch card I entered an issue code of 01 and not just 1

 

This threw up the error.

 

But all is ok now many thanks

 

Chris

Better to be looked over than overlooked!

Link to comment
Share on other sites

All versions use curl - there is no php extension needed (that was only needed by very old versions).

GAH! i was looking at the contribution under the category "Payment Modules".. This is the one requiring the PHP extension, and obviously the wrong one:

http://www.oscommerce.com/community/contri...ll/search,protx

 

The module you're referring to is under the category "Credit Modules" - the correct module!

http://www.oscommerce.com/community/contri...ll/search,protx

 

these old contributions should be removed, they are causing "confusion and delay"!

Link to comment
Share on other sites

afternoon all!

 

my Protx Direct integration has suddently ceased to work.. committing the transaction in OSC now returns the following error:

 

{ED136D2F-44E9-ED27-AF30-87B472EDD156} - Your credit card could not be authorized for this reason. Please correct any information and try again or contact us for further assistance.

 

i'm assuming the GUID at the front is the transaction ID, or similar..

 

The transaction completes successfully at the Protx end, just not with OSC.

 

ring any bells?

 

Many thanks.

 

Upgrading to Protx Direct 4.3 fixed this issue. Thanks for the support.

Link to comment
Share on other sites

@blackmogu - I can't reproduce this - that function is defined when application_top.php is called which when you load an order is done by orders.php or if you select an action the the orders_protx.php does it - have you altered your orders.php file from the standard oscomm MS2.2 (other than the change as per protx install instructions)?

 

The only change I made was as instructed in the protx install.txt.

 

Is it normal when you click "Authorise", that it takes you to the login screen for admin again ? This happens every time for me when I attempt to authorise an order.

 

Notably, it's the same error I get if I call the orders_protx.php page directly in the URL bar.

Link to comment
Share on other sites

You say a login screen for admin - do you have an admin login mod or is the RC1 admin login? I haven't tested the mod with either. - it is normal for it to fail if you try calling the orders_protx.php file directly - it is not designed to be used this way. It sounds there (if returning you to a login page) that there may be sessions issues.

 

Tom

Link to comment
Share on other sites

You say a login screen for admin - do you have an admin login mod or is the RC1 admin login? I haven't tested the mod with either. - it is normal for it to fail if you try calling the orders_protx.php file directly - it is not designed to be used this way. It sounds there (if returning you to a login page) that there may be sessions issues.

 

Tom

 

I am using RC1. I expected it to fail normally from a direct call, since the initial if(..) case ought to fail.

Perhaps it is the RC1 admin login that is causing the problems with protx ?

Link to comment
Share on other sites

Hi Tom

 

I'm having some problems with users getting failed payments. When I checked the failed transactions on Protx it seems that the billing address, name, card details etc are not being passed over (or at least not saved at Protx) but the delivery address and shopping basket etc is being passed over.

 

Have you seen this before, any ideas?

 

Thanks

John

Link to comment
Share on other sites

I have just realised a problem with this module when in checkout_payment.php, the screen where you put the card numbers in.

 

1. When no card numbers/dates are entered you get the following error message near the top of the screen once you click continue to go on the next screen:

 

"The expiry date entered for the credit card is invalid. Please check the date and try again."

 

2. When the expiry date is entered and you hit continue the next screen appears (checkout_confirmation.php) with the following message on top:

 

"Warning: str_repeat(): Second argument has to be greater than or equal to 0. in /home/deviltro/public_html/includes/modules/payment/protx_direct.php on line 192"

 

and then when you hit "confirm order" in checkout_confirmation.php it redirects you to and gives you the following error message:

 

"The CardNumber should contain between 12 and 20 digits. - Your credit card could not be authorized for this reason. Please correct any information and try again or contact us for further assistance."

 

3. A series of similiar errors are produced when giving the wrong card type/number/end date/cvv/issue number in checkout_payment.php but it still allows it to proceed to checkout_confirmation.php, then when you hit 'Confirm Order' it again redirects you to the checkout_payment.php screen and gives you the following error message:

 

"Authorisation declined by bank. - Message : DECLINE - Your credit card could not be authorized for this reason. Please correct any information and try again or contact us for further assistance."

 

So, what I would like to know.................

 

A. How can all errors be notified on the checkout_payment.php screen, rather than having to click 'Continue' and 'Confirm Order' (on checkout_confirmation.php) for osc to realise the error and then take you back to the checkout_payment.php screen

 

B. Why can you proceed on checkout_payment.php by just entering the end date without entering the card number and cvv number?

Edited by blagger
Link to comment
Share on other sites

@blackmogu - I've tested it with RC1 - the admin part is losing the session if cookies are disabled (it's fine if enabled) - this is causing the errors you are seeing. I'll sort this for the next update.

 

@johnr3 - failed payments with blank details (in protx admin screen) are not normally caused by a problem with the module - they are often after it was declined by the bank (frequently CVV failure) - protx then doesn't seem to store the details for your to view. Take a look at your protx_direct table in the database - this will give you the reason for the failure in the StatusDetail field (you can match them by time).

 

@blagger - I've just tested this out - it only occurs if JavaScript is disabled - when enabled it checks for valid fields. It will be possible to build extra validation into the module to check for valid fields - I'll look at this for the next update.

 

Tom

Link to comment
Share on other sites

@blagger - I've just tested this out - it only occurs if JavaScript is disabled - when enabled it checks for valid fields. It will be possible to build extra validation into the module to check for valid fields - I'll look at this for the next update.

 

Tom

 

Thanks Tom.

 

How do I know if 3D is enabled? You updated my sight a few months ago (deviltronics.com).

 

Also there is some new stuff to do with maestro, does this interfere with this module?

 

Also how do I enable JavaScript? Does it mess other things up?

Edited by blagger
Link to comment
Share on other sites

To have 3D-Secure active you have to email protx support and ask them to activate it with your merchant bank. Once that is done you then need to switch it on in your protx admin area and setup the rulebase.

 

The version you have supports 3D-Secure once enabled at the Protx end

 

The rules for Maestro have changed and you must have 3D-Secure active to be able to accept these cards otherwise they will be declined.

 

Tom

Link to comment
Share on other sites

OK, thanks.

 

I see this module has been update again. Has there been many changes since you last updated my site?

Edited by blagger
Link to comment
Share on other sites

I'm trying to help some friends who run the protx v3.0 module (in Authorization Type PAYMENT) but am a little nervous about this upgrade so pls excuse these noob questions:

I understand they have to upgrade module before August 1st to integrate 3D, but:

When they upgrade to V4.3 of this module can they still accept CCs before activating 3D in their protx admin?

Can they update the module to v4.3 without interrupting business (accepting CCs) except for the actual upgrade down-time?

Can they test the new 3D from their Live shop somehow without letting all customers through the test?

Should Authorization Type also be set to PAYMENT in v4.3?

 

So in basic: Do they just upgrade to v4.3, turn on 3D in the protx admin, set the module to TEST, and when tested set it to Production?

 

I hope a kind person will explain these things.

Link to comment
Share on other sites

I'm trying to help some friends who run the protx v3.0 module (in Authorization Type PAYMENT) but am a little nervous about this upgrade so pls excuse these noob questions:

I understand they have to upgrade module before August 1st to integrate 3D, but:

When they upgrade to V4.3 of this module can they still accept CCs before activating 3D in their protx admin?

Can they update the module to v4.3 without interrupting business (accepting CCs) except for the actual upgrade down-time?

Can they test the new 3D from their Live shop somehow without letting all customers through the test?

Should Authorization Type also be set to PAYMENT in v4.3?

 

So in basic: Do they just upgrade to v4.3, turn on 3D in the protx admin, set the module to TEST, and when tested set it to Production?

 

I hope a kind person will explain these things.

 

Correction: They are currently using v2.3c it looks like.

Link to comment
Share on other sites

I'm trying to help some friends who run the protx v3.0 module (in Authorization Type PAYMENT) but am a little nervous about this upgrade so pls excuse these noob questions:

I understand they have to upgrade module before August 1st to integrate 3D, but:

1) When they upgrade to V4.3 of this module can they still accept CCs before activating 3D in their protx admin?

2) Can they update the module to v4.3 without interrupting business (accepting CCs) except for the actual upgrade down-time?

3) Can they test the new 3D from their Live shop somehow without letting all customers through the test?

4) Should Authorization Type also be set to PAYMENT in v4.3?

 

5) So in basic: Do they just upgrade to v4.3, turn on 3D in the protx admin, set the module to TEST, and when tested set it to Production?

 

I hope a kind person will explain these things.

 

Firstly just to correct some confusion that Protx seem to have created - the deadline for 3D-Secure was 1st July - after that date the banks may refuse any Maestro card if 3D-Secure is not attempted (although they are currently being lenient).

 

The 1st August deadline is for the change over from PREAUTH to AUTHORISE/AUTHENTICATE systems.

 

Taking your questions:

1) Yes - the 3D-Secure part of the module is only active in response to a request for 3D-Auth from the Protx server

2) Yes

3) No - if they are testing using a live site then there is always potential for customers to try to checkout at the time they are testing. I always suggest making a copy of the site and database to use purely for testing and developemtn then copying over the the live copy of the site when ready.

4) That depends on the business model - PAYMENT takes the payment immediately - suitable for immediate dispatch or download sites, DEFERRED obtains authorisation and leaves a 30 day shadow on the card, taking payment when you RELEASE it later (i.e. when you dispatch the order), AUTHORISE/AUTHENTICATE works over a longer time than DEFERRED an also allow the amount to be change from the original authorisation.

5) Yes, Yes, Yes & Yes

 

Tom

Link to comment
Share on other sites

Tom

 

After a week or so of smooth running on 4.3 with 3D Secure turned on for all cards in use I have hit another duplicate payment error - looking at the protx_direct table data shows that in the first instance the transaction returned no data to the table but was authenticated by Protx - then (I guess) the customer received an error message and re-submitted, this time the table has Protx data and Protx debited the card again. Any clues?

10538, 5906, 7276, '7276-84864634186287808377431626802291', 'PAYMENT', '359.9500', '', '', '', '', '', '', '', '', '', '', '', '2007-07-21 03:12:31'
10539, 5906, 7276, '7276-44786262062956179197621581645713', 'PAYMENT', '359.9500', '{01837DD0-5BDD-4E58-9188-C661CCAF209E}', 'OK', '', '51106305', 'yahRD4IVdm', 'ALL MATCH', 'MATCHED', 'MATCHED', 'MATCHED', 'OK', 'AAABAGRRBwAAAABFUFEHAAAAAAA%3D', '2007-07-21 03:15:39'

Edited by kdenby
Link to comment
Share on other sites

If that 1st transaction showed as successful in the Protx admin area then the only thing I can think is that the curl function is timing out hence why not data seems to be returned.

 

I suggest adding the line

	  curl_setopt($ch, CURLOPT_TIMEOUT, 90);

to the 2 curl_setopt sections in protx_process.php and see how things go after then - I can't say that I've had any problems with duplicate transactions since the latest version of the module.

 

Tom

Link to comment
Share on other sites

Firstly just to correct some confusion that Protx seem to have created - the deadline for 3D-Secure was 1st July - after that date the banks may refuse any Maestro card if 3D-Secure is not attempted (although they are currently being lenient).

 

The 1st August deadline is for the change over from PREAUTH to AUTHORISE/AUTHENTICATE systems.

 

Taking your questions:

1) Yes - the 3D-Secure part of the module is only active in response to a request for 3D-Auth from the Protx server

2) Yes

3) No - if they are testing using a live site then there is always potential for customers to try to checkout at the time they are testing. I always suggest making a copy of the site and database to use purely for testing and developemtn then copying over the the live copy of the site when ready.

4) That depends on the business model - PAYMENT takes the payment immediately - suitable for immediate dispatch or download sites, DEFERRED obtains authorisation and leaves a 30 day shadow on the card, taking payment when you RELEASE it later (i.e. when you dispatch the order), AUTHORISE/AUTHENTICATE works over a longer time than DEFERRED an also allow the amount to be change from the original authorisation.

5) Yes, Yes, Yes & Yes

 

Tom

 

Many thanks for your great reply! That did clear up a couple of things. Very kind of you!

I will have them run the tests from a copy of the shop on a sub-domain. That is a good suggestion.

 

Thank you.

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