X-Cart forums

[exsecror]

Originally Posted by canuck

I'm not totally following your process here. Your customer clicks checkout and then they enter the credit card information on your page right? If so that mechanism needs to be certified from what I can see. I spoke with our processor (Beanstream) who said if your page accepts the card# then that mechanism must be PA-DSS certified.

I looked at USA Epay's site and they seem to have a similar API but I'm told if it's an API you need certification.

At this rate I'm going to be flipping all my payments through regular Paypal. With 4 business days left we don't have a certified gateway. It wouldn't be such a panic for me but this whole php5.3 requirement has me very worried. I'm having to set up a test server, and see what is going to break under 5.3 - I know some of my apps/modules are zend encoded which doesn't work under 5.3

Is there a smiley on here for screaming?

I think Beanstream is not quite understanding how HTTP POST logic works. Yes we are hosting the input submission form for credit card information on our site because that's where the page is being rendered but the action of the HTTP POST is going to usaepay.com not hardwareandtools.com. So when a customer clicks to process the order their browser is sending the SSL encrypted HTTP POST to usaepay.com directly and that POST is not even touching hardwareandtools.com (because the communication is occurring between the Customer's Computer and USAePay only) so our site is not aware of the credit card data and is not processing the POST and not transmitting it via a backend through payment_cc.php. This means it does not have to be PA-DSS certified because it is not touching X-Cart at all and the only thing being returned to us by USAePay is the Authentication Token and Transaction ID. There's also the fact I re-wrote about 40% of the Payment backend for X-Cart (had too for eBillme and USAePay) as well as the fact I deleted every payment module and supporting code minus the custom USAePay, eBillme and PayPal so it's not the stock X-Cart payment system.

This is how transparent gateways work that Braintree, USAePay and a few other processors support and any Payment Middleware app (e.g. X-Payments, PayPal Express Checkout, Google Checkout, Amazon Payments) supports. Here is the Transaction API that USAePay uses (and that we use):

http://wiki.usaepay.com/developer/transactionapi

[canuck]

Originally Posted by exsecror

so our site is not aware of the credit card data and is not processing the POST and not transmitting it via a backend through payment_cc.php. This means it does not have to be PA-DSS certified because it is not touching X-Cart at all and the only thing being returned to us by USAePay is the Authentication Token and Transaction ID. There's also the fact I re-wrote about 40% of the Payment backend for X-Cart (had too for eBillme and USAePay) as well as the fact I deleted every payment module and supporting code minus the custom USAePay, eBillme and PayPal so it's not the stock X-Cart payment system.

I see now. Based on this additional info that make sense.
Doesn't help me stop ripping my own hair out unfortunately since I can't rewrite the modules or quickly switch processors... but now I understand.

Maybe I should be hiring you instead!

Next issue is that I'm hearing of people using iframes. I'm not a programmer - just dangerous with source code. But I thought iframes were almost deprecated already and soon to disappear completely? I don't want to turn this in to an html discussion but it's something to consider.

[Duramax 6.6L]

Has anyone come up with a better installation manual. Installation instructions and user manual is pretty vague on the installation details of x-payments.

[enterfusion]

I'm stuck now, why the reliance on PHP 5.3? Thats makes all but the most recent X-carts incompatible with the setup for X-payments?

Is there a way this will run on 5.2? Would be good to know.

[enterfusion]

PHP 5.3 is going to totally hose my X-cart installation, has anyone has any success getting X-payments to run on 5.2.X?

What's in 5.3 that X-payments absolutely must have?

[Vacman]

Originally Posted by enterfusion

PHP 5.3 is going to totally hose my X-cart installation, has anyone has any success getting X-payments to run on 5.2.X?

What's in 5.3 that X-payments absolutely must have?

Welcome to my nightmare. Had to install PHP 5.3 - After which, my old X Cart 4.1.8 (which was running perfectly) went completely down the tubes.

Now I can't even get 4.3.2 up and running because of the FedEx bug on that system....

I am now loosing about $600 US per day. We are now on day #6.

All to meet the 7/1/10 deadline that we didn't know about...

[enterfusion]

Look here (the link below), they released patches to make 4.1.12 compatible with 5.3, you should be able to apply the same patches to 4.1.8.

http://forum.x-cart.com/showthread.php?t=53097&page=3&highlight=x-payments+5.2

[exsecror]

Originally Posted by canuck

I see now. Based on this additional info that make sense.
Doesn't help me stop ripping my own hair out unfortunately since I can't rewrite the modules or quickly switch processors... but now I understand.

Maybe I should be hiring you instead!

Next issue is that I'm hearing of people using iframes. I'm not a programmer - just dangerous with source code. But I thought iframes were almost deprecated already and soon to disappear completely? I don't want to turn this in to an html discussion but it's something to consider.

iframes are deprecated but most people still practice the use of them, when used in moderation and properly iframes are fine though.

[balinor]

Ok, it is now Monday - the regs kick in on Thursday - where are you with the final, certified version? Can we get an update please?

[cflsystems]

I think we're all screwed or it seems