X-Cart forums

[DogByteMan]

From your suggested thread:

The intent of PA-DSS is to facilitate/allow PCI-DSS compliance by merchants not to force/enforce it. Therefore PA-DSS does not require encoding the software so it can't be modified. PA-DSS only requires the vendor to develop their software in a PCI-DSS compliant manner. Any modifications would be custom development for that one merhcant and as such those modifications would not be subject to PA-DSS. Custom developed payment applications fall under the merchants PCI-DSS assessment. For most of us smaller merchants that means we would need to attest in our self assessment questionnaire that we followed PCI-DSS guidelines in developing our modifications and no outside verification would be required. That's the same thing that PA-DSS is doing for vendors - making sure they follow PCI-DSS guidelines in developing their software. PA-DSS requires that vendors get outside certification because their application will be used by many merchants and magnifies the impact of insecure development.

Another example of how PA-DSS only facilitates compliance and does not mean that a vendor must prevent you from shooting yourself in the foot and implementing their software in a non-PCI-DSS compliant manner. PA-DSS only requires that the vendors software *can* be implemented to be PCI-DSS compliant and the vendor has documented for the user how to implement it securely. IOW, its ok for the application to have the an option to store CVV numbers. But the documentation with the application has to tell the user that option must be turned off to be PCI-DSS compliant.

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.

[Duramax 6.6L]

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.

[DogByteMan]

The payment application system/Internet device is not connected to any other systems within your environment.

So the storefront is considered an "other system"?

[Duramax 6.6L]

Will Xpayments handle recurring billing for subscriptions?

[balinor]

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.

[DogByteMan]

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?

[ambal]

Originally Posted by Acquamarina

Does it solve the mandatory partial payment acceptance for credit cards/gift cards?

Is this the solution for:

http://forum.x-cart.com/showthread.php?t=53163

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

[ambal]

Originally Posted by DogByteMan

Since I have much work to do to get ready (Upgrade Shop for PHP 5.3.x and have the X-Payments altered for 4.1.12) I really would appreciate a description of how the interface works. Yes, I have completely read the manual. What I am wanting is a description of what happens from when the customer clicks checkout to order completion. Where are they entering their info, Checkout (I have One Page Checkout) or are they entering it within the X-Payments module. I can't install yet, but need to plan. A description would be nice, screen shot with it, even better.

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

[ambal]

@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.

[ambal]

@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.