Protx Direct v2.22

[Guest]

Fixed, somehow the includes/languages/english/checkout_success.php was deleted!

[PJ2006]

When we get a phone order we just create an invoice in excel and send the item that way. We then reduce the stock from the site.

 

Have a problem of my own:

 

A couple of customers have phoned up and told us that they get a fatal error during the Protx Process. The order still goes through fine. Anyone had the same problems, if so how do you fix it.

 

Thanks for the tip!

[PJ2006]

Thanks for the tip!

Does anyone know how to submit details to protx flagged as "AccountType=M", it really would be great to get this working properly - I'm sure many people take telephone orders and would like this implemented properly. Unfortunately the php kit is currently missing from the PROTX site, I thought I might have been able to figure it out from there.

 

If I ever do figure it out, I'll post back or provide a contribution so others can get this going.

 

Thanks

[Guest]

If you look in your admin->payment modules under the Protx settings, you'll see "Merchant Account" with the options of E, C or M. You can make the change you are asking about here - bearing in mind all transaction will go through with this flag until changed back.

 

Tom

[PJ2006]

If you look in your admin->payment modules under the Protx settings, you'll see "Merchant Account" with the options of E, C or M. You can make the change you are asking about here - bearing in mind all transaction will go through with this flag until changed back.

 

Tom

 

Thanks!

[veral]

Hi all,

 

I'm currently using Protx Form (as I thought this would allow me to be always current with the latest versions of the Protx back end, and would mean that I would not have to deal with storing CC information on my site). Is it a better idea to use Protx Direct?

 

I've been having issues lately where the Protx payment (form) occurs, but no orderID is generated (and no order placed) on my site.

 

Would you a) know of a fix, or B) recommend that I switch over to Protx direct instead.

 

 

Thank you in advance for any insights on advantages you might be able to give.

[Guest]

I don't know enough about the form code to suggest a fix - if it's like the standard paypal then there may not be one!

 

I would recommend Direct wholeheartedly - the customer gets a better experience - they never leave your site, you don't need to mess around with custom templates.

 

The admin allows you the void/release/repeat/authorise/refund payments etc

 

No card details are stored on your site at all so that's still not a problem.

 

The only requirements are that you have SSL (dedicated or shared) and cURL installed on the server.

 

Tom

[PJ2006]

Thanks!

 

I'm really sorry to keep going on about this, but if I change it to M, wont any orders put through by customers also go through flagged as 'M' during this time until I change it back to 'E'?

 

Thanks

 

Lotti

[Guest]

yes, that's what I meant by:

bearing in mind all transaction will go through with this flag until changed back.

[PJ2006]

yes, that's what I meant by:

 

So is there any other way to flag as 'M'? I am expecting to take telephone orders and web orders at the same time and this solution does not allow for that. I am really sorry to be such a pain, I just want to make sure I am doing everything legally correctly.

 

Thanks

[Guest]

Unfortunately not unless you create a custom system to take orders in the back-end and have the flag as M.

 

Tom

Edited December 4, 2007 by perfectpassion

[kdenby]

Hi

 

Still getting the occasional 'double card debit but only one order' from one of my Protx Direct sites. The most recent was on 3rd Dec and the two debits are 10 minutes apart

11621, 5365, 8161, '8161-82056271503113463288085348463387', 'PAYMENT', '73.0000', '{24FD78BE-7B61-6A40-7E08-A5F7CE91FACD}', 'OK', '0000 : The Authorisation was Successful.', '66073457', '48OPPRCPBZ', 'SECURITY CODE MATCH ONLY', 'NOTMATCHED', 'NOTMATCHED', 'MATCHED', 'NOTCHECKED', '', '2007-12-03 22:52:44'
11620, 5365, 8161, '8161-32439602646219811509671607244862', 'PAYMENT', '73.0000', '{BC0973AF-BAC1-EE4F-602D-FCE8CB003AEC}', 'OK', '0000 : The Authorisation was Successful.', '66072066', '6EQZNV9TDO', 'SECURITY CODE MATCH ONLY', 'NOTMATCHED', 'NOTMATCHED', 'MATCHED', 'NOTCHECKED', '', '2007-12-03 22:42:20'

 

Could there be some sort of timing problem here? .... .These errors are pretty rare and therefore very hard to trap.

 

Any suggestions anyone?

 

Cheers

[PJ2006]

Unfortunately not unless you create a custom system to take orders in the back-end and have the flag as M.

 

Tom

 

If you have any tips for how I would start doing this I'll give it a try!

 

Thanks

[Guest]

I creasted a custom solution like this for a site based on "Order Editor" v5.0.6 and added the main code from protx_process.php to it (without all the 3D-Secure stuff as this only applies to e-commerce transactions).

 

Tom

[zeeshop]

Hi All,

 

JUst intslled Protx latest version, I have STS instaled which stoping popups CVV and 3d check) to display properly any solution for this?

 

Second and big issue , my test account from protx been set up but using this this module when in setting i chose server ip test.

when I do test trasncation next page open with this error

 

VPSProtocol=2.22&TxType=PAYMENT&Vendor=zopop&VendorTxCode=506-96460015443517682126823873263360&Amount=12.43&Currency=GBP&Description=Order+Number%3A+506&CardHolder=jaooba+haq&CardNumber=4929000000006&StartDate=0104&ExpiryDate=0609&IssueNumber=&CV2=123&CardType=VISA&BillingAddress=ijjjkjkjk%2C%0D%0Akjjk%2C%0D%0Akjkjjkjk%2C%0D%0AAberdeen%2C%0D%0AUnited+Kingdom&BillingPostCode=kjjkkjjk&DeliveryAddress=ijjjkjkjk%2C%0D%0Akjjk%2C%0D%0Akjkjjkjk%2C%0D%0AAberdeen%2C%0D%0AUnited+Kingdom&DeliveryPostCode=kjjkkjjk&CustomerName=jaopa+haq&ContactNumber=95588989&CustomerEMail=zeop%40gmail.com&ClientIPAddress=87.155.184.53&Basket=2%3AKodak+%283937752%29+Premium+Photo+Paper+10x15+60+sheets%3A1%3A5.21%3A0.91%3A6.12%3A6.12%3AShipping%3A1%3A6.31%3A----%3A6.31%3A6.31&AccountType=E&Apply3DSecure=2

 

I have Curl Enable in server and Full SSL on dedicated server.

 

Please advise solution..

Regards

 

Zee

Edited January 22, 2008 by zeeshop

[LBateman]

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

 

PHP5, Mysql5.

 

PHP Warning: constant() [<a href='function.constant'>function.constant</a>]: Couldn't find constant MODULE_PAYMENT_PROTX_DIRECT_USE_ in ******\protx_process.php on line 279

 

Any ideas?

[Guest]

Hi All,

 

JUst intslled Protx latest version, I have STS instaled which stoping popups CVV and 3d check) to display properly any solution for this?

 

Second and big issue , my test account from protx been set up but using this this module when in setting i chose server ip test.

when I do test trasncation next page open with this error

 

 

I have Curl Enable in server and Full SSL on dedicated server.

 

Please advise solution..

Regards

 

Zee

 

 

That shows that there is a problem communicating with the Protx servers - switch the module to "Test" and "enable debug" - try a transaction and post what that shows.

 

Tom

[Guest]

PHP5, Mysql5.

 

PHP Warning: constant() [<a href='function.constant'>function.constant</a>]: Couldn't find constant MODULE_PAYMENT_PROTX_DIRECT_USE_ in ******\protx_process.php on line 279

 

Any ideas?

 

 

I'm guessing with your server upgrade that register_long_arrays is set to off.

 

You can either enable this or replace all occurences of $HTTP_POST_VARS with $_POST and $HTTP_GET_VARS with $_GET - the first is the preferable option for best comptability with osC and other contribs.

 

Tom

[gatzo]

Hi,

Not sure if this is a stupid question, sorry if it is:

 

In v.4.4, Authorisation Type set to Payment, what happens if a payment is rejected by Protx? Is an order created before this stage? Or is the customer just sent back to checkout_payment.php?

 

Thanks.

[Guest]

If the payment is declined the customer is returned to checkout_payment.php with an error message detailsing the reason for failure for them to ry again.

 

The order will only be logged in osC if the payment is successful (though there will be a record of the decline in both your protx_direct table and on the Protx Admin website).

 

Tom

[gatzo]

Thanks Tom for a clear answer!

[♥richandzhaoyan]

I would recommend Direct wholeheartedly - the customer gets a better experience - they never leave your site, you don't need to mess around with custom templates.

 

The admin allows you the void/release/repeat/authorise/refund payments etc

 

No card details are stored on your site at all so that's still not a problem.

 

The only requirements are that you have SSL (dedicated or shared) and cURL installed on the server.

 

Tom

 

 

Hi Tom,

 

I am currently using HSBC but am looking to change over to Protx as I really need osC admin to authorise payments (would save a huge amount of time) however I am concerned that the Protx website states that to use VSP Direct you will need:-

 

Certification under the PCI audit. As credit card details are collected by you and not by Protx, you may be required to undergo an audit to ensure that credit card data is kept secure.

 

I believe that you mentioned above that you had been in contact with Protx about this and that the PCI audit was not a concern... Is this true? And if so why not?

 

TIA for any input and thanks for all the work you (and others) have put into this contribution.

 

Cheers,

Rich

[Guest]

I have discussed this with Protx and their reply was that as long as no credit card data is stored then you do not undergo an external PCI DSS audit.

 

The PRotx Direct module does not store any card data so satisfies this requirement. Your acquiring bank may send you a self-assessment PCI compliance questionaire but that should be the extent of the audit unless you process very large volumes.

 

Tom

[♥richandzhaoyan]

Thanks for the reply Tom.

 

Reading the Protx blurb again, it does only state that "you may be required to undergo an audit" so I guess judging by what they have told you, it is unlikely.

 

I am certainly considering the switch from HSBC to Protx as I really need to simplify the payment processing for my site.

 

Cheers,

Rich

[Guest]

I would recommend Direct wholeheartedly - the customer gets a better experience - they never leave your site, you don't need to mess around with custom templates.

 

No card details are stored on your site at all so that's still not a problem.

 

The only requirements are that you have SSL (dedicated or shared) and cURL installed on the server.

Tom

 

Hi there, I am getting ready to use protx for the first time.

 

I very much would like the benefits of keeping the customer on the site for the whole transaction and only sending encrypted data to Protx which I believe is what is happening with Protx Direct.

 

When I look at the protx site though, is the self certification necessary because the CC details are transmitted from the secure server to protx and not done directly on their site?

http://www.protx.com/products/vsp_direct.asp

"Certification under the PCI audit. As credit card details are collected by you and not by Protx, you may be required to undergo an audit to ensure that credit card data is kept secure. Click here for more information"

 

ie. credit card details are only transmitted between server and protx not stored on server?

 

Thanks,

Ally