Re: X-Payments 1.0 beta5 announcement
 

From your suggested thread:


If the above is correct, all PA DSS requires is a standard for X-Cart going forward that assures merchants that they can be compliant using the software provided. The Merchant GOAL is still PCI DSS compliance, which according to McAffee and the questionaire I fill out there, I am compliant now. Where am I wrong here? If I am wrong where is the official PA DSS document that states the new method by which cc info must be transmitted? Exactly how does the current payment module not meet the requirement? Surely they can not simply say DO IT without providing the proper information. Probably not, but they may be the world's biggest organized crime ring leading us to slaughter. I'm just an old man, but I need to read for myself what the requirements are to send cc data starting July 1 and I have not received it or any communication about it from First Data.

Re: X-Payments 1.0 beta5 announcement
 

Here are a few reg for:

SAQ Validation Type 4 / SAQ C: Merchants with Payment Application Systems
Connected to the Internet
SAQ C has been developed to address requirements applicable to merchants whose payment application
systems (for example, point-of-sale or shopping cart systems) are connected to the Internet (via highspeed
connection, DSL, cable modem, etc.) either because:
1. The payment application system is on a personal computer that is connected to the Internet (for
example, for e-mail or web browsing), or
2. The payment application system is connected to the Internet to transmit cardholder data.
Merchants in Validation Type 4 process cardholder data via payment application systems connected to
the Internet, do not store cardholder data on any computer system, and may be either brick-and-mortar
(card-present) or e-commerce or mail/telephone-order (card-not-present) merchants. Merchants in
PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v1.2 October 2008
Copyright 2008 PCI Security Standards Council LLC Page 10
Validation Type 4 must validate compliance by completing SAQ C and the associated Attestation of
Compliance, confirming that:
 Your company has a payment application system and an Internet
connection on the same device;
 The payment application system/Internet device is not connected to any
other systems within your environment;
 Your company retains only paper reports or paper copies of receipts;
 Your company does not store cardholder data in electronic format; and
 Your company’s payment application software vendor uses secure
techniques to provide remote support to your payment application system.

I hig lighted a section that applies to us as online venders.

Re: X-Payments 1.0 beta5 announcement
 

So the storefront is considered an "other system"?

Re: X-Payments 1.0 beta5 announcement
 

Will Xpayments handle recurring billing for subscriptions?

Re: X-Payments 1.0 beta5 announcement
 

Dog, read here: https://www.pcisecuritystandards.org/index.shtml

If you process credit cards you MUST use a certified cart - and believe me, you won't be able to afford to certify a cart that was built for you. The credit card companies are sick of losing money by home made shopping carts with no security. This is their way of ensuring that the data transmitted from the cart to the gateway is absolutely secure - if there are any security holes, the cart won't pass the certification test. Qualiteam is getting by the requirement for now by making X-Payments handle the cc data, not the core X-Cart. So therefore the cart itself doesn't need to be certified. It isn't a load of crap, this is actually a very good idea and one that is long overdue. I can't tell you how many people come to me and have thousands of credit card numbers stored unencrypted in their database and don't even know it. This eliminates that from ever happening. Makes me feel better about online shopping, I can tell you that.

Aqua, you won't have to upgrade, BCS Engineering will be making the module compatible with prior versions - just waiting on the final release of X-Payments before they release their 'bridge' application.

Re: X-Payments 1.0 beta5 announcement
 

OK, got both carts upgraded to be ready for PHP 5.3 and I have let Emerson go on getting that done. Ryan, you say BCSE is going to release connectors or just code patches for the connectors. What about X-Cart, aren't they going to release connectors for 4.1,4.2 & 4.3?

Re: X-Payments 1.0 beta5 announcement
 

No, X-Payments has nothing to do this requirement of MasterCard/Discover
X-Cart v4.4 is going to have it met.

Re: X-Payments 1.0 beta5 announcement
 

Screenshots were published at
http://forum.x-cart.com/showthread.php?p=289568#post289568

Re: X-Payments 1.0 beta5 announcement
 

@DogByteMan

> I had sales-n-stats enterprise, which used a connector I assume is
> similar to what they are using here, I paid $400+, it didn't work so
> good. Does this connector seem to work better?

SnS Connector has nothing to do with the X-Payments one. They are very different. SnS connector was posting data about your web-site visitors behavior real-time while X-PaymentConnector is to pass a buyer from X-Cart into X-Payments to handle payment stuff.

Re: X-Payments 1.0 beta5 announcement
 

@Duramax 6.6L:

> Will Xpayments handle recurring billing for subscriptions?

X-Payments doesn't handle recurring billing itself. You are to use a payment gateway that supports recurring billing. I.e. you can sell a recurring product via X-Cart couples with X-Payments but maintaining recurring billing cycles are to be done by the payment gateway.

Re: X-Payments 1.0 beta5 announcement
 

So to meet compliance while using authorize.net, is X-payments a must have, or will my current version 4.3.2 and aurhorize.net be all I need.

Re: X-Payments 1.0 beta5 announcement
 

You need X-Payments as well.

Re: X-Payments 1.0 beta5 announcement
 

When is the final PA-DSS compliant version going to be approved?
I need to get my site finished and opened.

Re: X-Payments 1.0 beta5 announcement
 

I use Moneris in Canada to process CC payments. Moneris informed me that if I use the Moneris Hosted PayPage I will be compliant BUT they also said that the shopping cart must be compliant. What kind of compliance is required in the shopping cart since it will not be collecting any CC information?

Re: X-Payments 1.0 beta5 announcement
 

Can the Authorize.net SIM method be used eliminating the need for x-payments?

Re: X-Payments 1.0 beta5 announcement
 

That is incorrect piano, if you use an external cc gateaway the cart does not need to be certified. Aqua, yes, SIM will eliminate the requirement.

Re: X-Payments 1.0 beta5 announcement
 

Are you sure BCSE is still doing their bridge? Their last email to me said "X-Cart is now offering the connector so we are no longer developing this."

Re: X-Payments 1.0 beta5 announcement
 

See post 11 above:

It also looks like they were speculating other vendors would assist:

That implies the "tweeks" for 4.1 and 4.2 are something that other developers can see and replicate. (Hopefully).

Re: X-Payments 1.0 beta5 announcement
 

...in the 24 hours they will have between release and deadline :?

Re: X-Payments 1.0 beta5 announcement
 

We decide to use SIM instead of Xpayment. Is it a good idea?
We do many custom mods, and we worried if we upgrade to php 5.3, some of the mods may have problem.

Re: X-Payments 1.0 beta5 announcement
 

Hi Everyone,

JFYI, I posted some information at http://forum.x-cart.com/showthread.php?p=290311#post290311

@babydollcosmetics
> We decide to use SIM instead ...

Using a web-based payment processor like Authorize.net SIM or Paypal Express Checkout is the best idea IMHO. It will save you tons of time, money and efforts as your web-site visitors won't have to enter credit card details on your web-site and thus you won't have to make your web-site PCI-DSS compatible.

Re: X-Payments 1.0 beta5 announcement
 

Unfortunately sending a customer to an external url can cost you that sale. With all the scams out there, people are leery when the url changes on them. On top of that, it just isn't professional looking. An easy solution yes, a professional solution, no.

Re: X-Payments 1.0 beta5 announcement
 

Yes, Padraic, I do agree with you it can be an issue as well, but researches show that informing a buyer before redirecting to an external payment page about the redirect and some kind of payment page co-branding (your logo at least) works quite well.

Re: X-Payments 1.0 beta5 announcement
 

If by "quite well", you mean a 30%-50% reduction in sales, then yes.

This is QT's problem. They have no idea about the business side of things. They don't take into account conversions, sales, revenues etc of the people using their cart. They just throw together a band aid and say "Here you go! We're compliant!"

You want us to use a 3rd party because your solution isn't ready nor compliant and I can't blame you for that. However, don't try to blow smoke up everyone's arse and say it's the best solution, because it's not!

Re: X-Payments 1.0 beta5 announcement
 

This is all starting to turn into one gigantic headache for everyone :\

I looked into X-Payments but have no plans on using it, not that it matters considering that as of this morning we're on a transparent gateway with USA ePay so we're no longer in scope.

Re: X-Payments 1.0 beta5 announcement
 

DPM, that was my personal opinion. It is up to a merchant what way to use. We use 2Checkout.com secure payment form and it works just fine for us. For someone else such setup won't work at all. I guess it is related to nature of a business as well.

JFYI, we are awaiting for the final approval from QSA and this is the only reason we are not releasing X-Payments officially.

Re: X-Payments 1.0 beta5 announcement
 

Hi Alan,

We are using USAEpay as well, and are looking into using the transparent gateway to get around this x-payments mess. How does it look from the customer side? Does it look as though they are still on your website?

Also, does the gateway return data back to x-cart so the order is authorized, and does it pass back stuff like the card type?

Sorry for the questions, but I am in a position where I don't know where to turn next.

Thanks,

Steve

Re: X-Payments 1.0 beta5 announcement
 

I have to agree with Balinor. It is the easiest solution but not the best. It simply does not look good to a customer. I would feel odd about a site if the url changed on me during a purchase, mostly if it did not happen before when I shopped at that site. At least PayPal has some sort of name recognition, but unfortunately, the association isn't always good.

I understand the delays and difficulties in providing a viable and professional solution. What I am upset about is the last minute venture and the confusion around it. This solution should have been completed sometime ago so there would be time to test it and improve it to work with the enormous assortment of x-cart versions and mods currently live. At least a heads up that the older x-cart versions would require patches and upgrades. Many x-cart users are not coders, we run shops and are not always on top of these things. There are just not enough hours in a day to keep up with it. I found out about this on Friday when I received the newsletter from QT. No time to plan or prepare anything. After all is PHP 5.3 that recent? I could not find that release date.

Accepting credit cards is at the core of e-commerce. When I read the newsletter and came to the forum to learn more I was shocked that some threads started in March and yet, I had no idea. And I am not alone. Had I known sooner I could have prepared better, budget the upgrades, patches and probable additional work that will be needed. At least make a decision without all this stress.

Sorry for the rant but I am very upset about this as it adversely impacts my business and my livelihood.

Re: X-Payments 1.0 beta5 announcement
 

So, the best bet is to go with x-payments and aim processing thru Authorize.net. Not ideal, but best for the situation?

So how would I go about getting it installed? Would I need to reinstall once it is certified to be compliant?

This is so damn confusing. I am just trying to get opened up again.

Re: X-Payments 1.0 beta5 announcement
 

Fins, AIM and X-Payments is the way to go IMHO, yes. Don't install it yet, wait for the final, certified release.

Re: X-Payments 1.0 beta5 announcement
 

I finally got X-Payments installed using Authnet AIM. This involved me upgrading to PHP 5.3.2, which I was real nervous about doing but which actually gave me zero problems. The biggest problem I would say is all of the different steps and configuration you need to do, none of which are really "hard" but there are quite a few and the steps that need to be taken and the order which they need to be taken are not that well spelled out. Not sure why they didn't just include x-connector as part of x-payments, it's located under "tools" and is really necessary.

Anyway, the beta version is installed here, it's working, it looks real nice when you checkout, and I would say that it is the best option for those who are on 4.3+ version carts. I'm definitely going to use it. The Authorize-net SIM looks like crap frankly, you will probably lose sales if you stick with that.

Re: X-Payments 1.0 beta5 announcement
 

I have confirmation from QT that X-Payments and X-Connector have fully open code. To me, this means that once I pay to have them "tweek" it for a 4.1.12 and 4.2.3 cart for me - then I will have access to the required changes. Then - I can decide if it is easier to pay them to do it for the rest of my carts, or do it myself.

I think this means the required tweeks will be available (not hidden). Not in patch form - but perhaps something that your favorite developers on this forum can duplicate for you, or you can have QT do it for $75 or points. I think we can't be sure yet - but it appears if you have a pre 4.3 cart - you will have options to get the "tweeks" from QT, or someone else who has seen the required changes and replicate them.

Of course - this is speculation on my part. I'm still working on the php 5.3 upgrades, so I have a bit to go before I get to the end yet.

Re: X-Payments 1.0 beta5 announcement
 

I am running PHP 5.2.9 does xpayments need php 5.3 to work?

Re: X-Payments 1.0 beta5 announcement
 

Yes, you need to upgrade PHP

Re: X-Payments 1.0 beta5 announcement
 

Well isn't that just special?
Anyone running CentOS is probably on php 5.1.6 unless they have chosen to run with the unsupported 5.3.x version.
This keeps getting better and better each day.

Re: X-Payments 1.0 beta5 announcement
 

Requirements say 5.3 or later:

http://help.qtmsoft.com/index.php?title=X-Payments:System_requirements

Re: X-Payments 1.0 beta5 announcement
 

Hi Steve,

My apologies on late replies I've been extremely busy with new projects and relocation to another state. The transparent gateway does not take the customer off your site, instead it's sending the HTTPS POST to USA ePay (thus the customer's computer is transmitting the credit card information, not your webserver) rather than payment/payment_cc.php. I had to make significant core changes to X-Cart's payment system to get it to work but the customers do not notice anything different from when we were on Authorize.net. Also in terms of what it returns, it returns back any error codes or approval information but it does not return the type of card used.

Re: X-Payments 1.0 beta5 announcement
 

Uh we run CentOS but I don't use the RPMs for Apache, PHP or PostgreSQL (we ported to PgSQL from MySQL) because they're not well optimized for a high volume site so it's all custom compiled and aggressively tuned.

Re: X-Payments 1.0 beta5 announcement
 

Glad to see you can do that, but thats kind of beyond the scope of most of us to be able to accomplish.

Re: X-Payments 1.0 beta5 announcement
 

There are unofficial RHEL packages available from Oracle http://oss.oracle.com/projects/php/