X-Cart forums

[BritSteve]

We get scanned daily and are PCI compliant, and I fill in the SAQ-D every quarter and send it off you our processor. We would also be charged the $20 a month if we didn't send the stuff to them.

We accept FAX credit card information, so we need to fill in the SAQ-D because we have access to the credit card numbers.

I will wait and see if our processor checks on the cart we are using. X-payments doesn't sound like a good solution for us, unless we make some significant changes to it, or the way we extract data for our other systems.

Steve

[Duramax 6.6L]

I changed processors because they were going to charge a 20.00 a month no compliant fee. They also required a membership at a scan company of there choice that was 700.00 a year, did not matter if you had the scan report or not, you had to use theirs.

[Duramax 6.6L]

As for changes to x-payments, they said the code will be encoded, so I do not think we will be able to alter the code

[Asiaplay]

Why is RBS-World-pay gateway absent from this list?

As you know, we have spent a lot of time and money developing our site using X-Cart, based on the fact it supported a payment gateway we could use here in Asia...
i.e. without world-pay support we have wasted our time it seems...

Before I hit the roof and start getting really hacked off... please explain ASAP, what our options are going to be? - thanks, Asiaplay

Originally Posted by 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.

[xplorer]

Originally Posted by Asiaplay

Why is RBS-World-pay gateway absent from this list?

As you know, we have spent a lot of time and money developing our site using X-Cart, based on the fact it supported a payment gateway we could use here in Asia...
i.e. without world-pay support we have wasted our time it seems...

Before I hit the roof and start getting really hacked off... please explain ASAP, what our options are going to be? - thanks, Asiaplay

A quote from PA-DSS standard:

The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties

With the RBS Worldpay's gateway integrated with X-Cart 4.x (I mean Hosted Payment Page - HTML Redirect API) customers enter credit card data on a Worldpay's server, and neither your server nor X-Cart stores, processes or transmits cardholder data. So, from the standard's point of view, your X-Cart is just another web application installed on your server. As far as I know PCI DSS standard doesn't require all web applications to be certified as PA-DSS compliant. So, you don't need X-Payments in order to be PCI DSS compliant. Just make sure that all CC functions are disabled in your X-Cart. I believe it would be better if you clarify it with your acquirer. And I would appreciate if you let us know their response on this matter.

[Asiaplay]

Dear Xplorer,

Ok - thanks... I will discuss this with more with RBS Worldpay then

I guess we will have to get PCI Compliance Vulnerability Scanning done quarterly and complete the self assessment document anyway - there seems no way around this part since our site is modified heavily... so even if X-Cart was PA DSS validated (which I understand it isn't and never will be), it seems we can not avoid that cost anyway...

Cheers, Asiaplay

[happyscott]

I have just spoken to Sagepay who tell me that because we use vspform it is they who have to be pci compliant and not our site.

However because I also take payments via the phone I have to have a 'certificate'.

Looking more into this but if this is correct then that's really good news as am currently looking for an alternative shopping cart in fear that x-cart will not be ready in time.

[wolff]

So, after reading through this thread, am I correct that a valid option to anyone using x-cart that wants to be compliant and avoid the PA-DSS software requirements, is to integrate a compliant 3rd party payment gateway using an iframe?

If this is true, wouldn't it be a good idea for someone to start cranking out iframe integration modules for the various 3rd party gateways?

...or am I missing something with all of this?

A related question: With all of the iframe injection issues that have gone around, even if the above is true, would there be possible problems in relying on an iframe for this purpose?

Thanks

[just wondering]

Originally Posted by wolff

So, after reading through this thread, am I correct that a valid option to anyone using x-cart that wants to be compliant and avoid the PA-DSS software requirements, is to integrate a compliant 3rd party payment gateway using an iframe?

If this is true, wouldn't it be a good idea for someone to start cranking out iframe integration modules for the various 3rd party gateways?

...or am I missing something with all of this?

A related question: With all of the iframe injection issues that have gone around, even if the above is true, would there be possible problems in relying on an iframe for this purpose?

Thanks

I don't trust iframes as far as I can throw them. They are evil when it comes to SEO and as you say, iframe injection is a real & serious worry. I point blank refuse to use them anywhere.

[BritSteve]

USAEpay appear to have a configurable page that is hosted on their secure server, and can be made to look like it is still on your site. Haven't tried it yet, but it may be a solution.

The only possible drawback is that xcart may not support this method.

Steve