X-Cart forums

[cflsystems]

Thank you for looking at this Ralph. I already have a quote form QT for integration, good advise to ask Quantum for a demo page, I will. Will this integration take the store out of the PCI-DSS / PA-DSS scope?

[geckoday]

Originally Posted by xplorer

It is almsot the same what X-Payments does:
http://www.cresecure.com/pages.php?CDpath=4

The only difference is that with X-Payments the payment form is on a merchant's website, not on our servers

Not exactly. It looks like their templating system is pretty sweet at least from the marketing material. You setup a payment page on your server using your standard site template but missing the payment fields. They suck it into their server and plug in the payment fields then serve it up from their servers.

But overall I agree. Its not all that much better than just using Authorize.Net SIM or the like. I don't think I would put another server layer between my checkout and the bank and I don't want somebody elses URL to show up to my customers.

[geckoday]

Originally Posted by cflsystems

Thank you for looking at this Ralph. I already have a quote form QT for integration, good advise to ask Quantum for a demo page, I will. Will this integration take the store out of the PCI-DSS / PA-DSS scope?

Yes it will remove it from PCI-DSS scope and X-Cart will not be the payment application so there will be no need for it to be PA-DSS compliant. The iframe is like a mini browser within your page. The customers browser will contact the Quantum server to get the payment fields page and load it into the iframe on your page. When the customer enters the card information it will post directly to the Quantum server keeping your server totally out of PCI scope.

[geckoday]

Originally Posted by kulture

The real question is can a merchant who is SAQ C (which I suspect is the vast majority here) continue to use older versions of xcart or any version of Litecommerce, and if so under what circumstances (third party gateway, off site processing or direct on site processing)

Sure. You've just got to remove X-Cart as the payment application. This can be done on any version of X-Cart by using a gateway hosted payment page (Authorize.Net SIM, Paypal Payflow Link, etc.). This will also remove your server from PCI scope and depending on your business model this might even move you down to SAQ A. If you don't like that approach you could have a one-off payment module written just for you to use a fully integrated API (Authorize.Net AIM, Paypal Payflow Pro, etc.). A one-off module isn't subject to PA-DSS and would just be part of your normal PCI-DSS assessment. The only problem with that might be your card processor won't like it and still insist you use a PA-DSS certified shopping cart even though its technically not required.

[cflsystems]

Thank you Ralph. This is something to consider then. Will save a lot of headache

[amy2203]

Interesting article on One Page Checkout...

http://www.getelastic.com/single-vs-two-page-checkout/

[TL408]

Xplorer: Is the X-Payments module currently scheduled to be released together with the Xcart 4.4 some time in March/April timeframe? Or should the question be......Are you still releasing Xcart 4.4.x? Or is it going straight from 4.3.x to the new V5.0 instead? Just need some clarification so we can do some planning internally. Thank you!

[xplorer]

Hi!

1. Most likely we will release 4.4

2. X-Payments release is not tied to 4.4. Its release date depends on results of beta testing (will launch soon) and on results of PA-DSS certification

3. We plan to support the following payment methods in X-Payments v1.0:

• ANZ eGate - Virtual Payment Client (merchant hosted)
• Authorize.Net - Advanced Integration Method
• Beanstream - Process Transaction API
• Global Gateway - Direct model
• BluePay
• Caledon - Real-time interface
• DIBS - API integration
• DirectOne - Direct interface
• ECHOnline
• ePDQ - MPI XML
• eProcessing Network - Transparent Database Engine
• eSec - Web Direct Model
• eSelect - DirectPost
• eWay - Realtime Payments XML
• GoEmerchant - XML Gateway API
• HSBC Secure ePayments - API integration
• Innovative Gateway - PHP Connection
• iTransact - XML connection method
• Global Gateway - API (North America)
• Global Gateway - API (EMEA)
• Netbilling gateway - Direct Mode 3.1
• Netregistry eCommerce Gateway - HTTPS method
• Ogone e-Commerce - DirectLink integration
• PayPal - Website Payments Pro
• PayPal - Website Payments Pro Payflow Edition
• PayPal - Payflow Pro
• WebXpress - XML method
• Sage Pay - Direct protocol
• PSIGate - XML API
• Quantum Gateway - Transparent QGWdatabase Engine
• SecurePay - Non-recurring Interface
• SkipJack
• USA ePay - CGI Transaction Gateway API
• Virtual Merchant - Merchant Provided Form
• CyberSource - SOAP Toolkit API
• Manual credit card processing

4. X-Payments v1.0 requires the payment form to be displayed by X-Payments (on your domain) and doesn't allow the payment form to be integrated into a checkout page displayed by a shopping cart system. We will check (when will be certifying X-Payments by a PA-QSA) whether it is not against PCI DSS, and perhaps future X-Payments versions will support this feature.

[amsruned]

Is xcart 4.4 from 4.3 going to be just a simple upgrade or will it require a whole nother redesign?

[just wondering]

We use Streamline & SagePay Direct.

We've been told that as we're not storing any Card Details at all we DON'T need a Server Scan & only have to fill in the PCI-DSS Form "C". Even though we're on Shared Hosting.

So I'm sat here thinking "Do we even need the X-Payments Addon"?