PA-DSS or service provider with DSS?

[tjl]

Hi all,

I'm just starting some work with a client to help them find their PCI direction on the road to compliance. The question of PA-DSS has come up, in that their product has a POS component, as one module of many. However, there is a service provider element as well; the software sends data via SSL (I believe) to my client, who handles the actual authorization and settlement on behalf of the retail merchant.

At this point, the process is finding out how much work lies ahead, and PA-DSS might not be a bad idea for them (eventually), but is it required? It seems somewhat murky at this point.

Thanks,
T.

[DanB]

It is my understanding from doing research in this area for the last six months that any Module that touches, carries Card Holder Data (CHD) falls in PCI-DSS. At the very least, the remote application should be PA-DSS as far as the capture and transmissions modules go, the data should be encrpyted and the recieving side should be PA-DSS as well. The network that carries the CHD falls under the PCI-DSS scope and should be looked at as well.

Cheers,

[El_Luke]

Is this software something that they sell to multiple clients, like off the shelf software? (needs to be PA-DSS compliant and certified)
Or is it custom made for just the one client? (Needs to be compliant but not officially certified)


If you client is handling the authorization and settlement of their clients, then your client acts as a service provider and must go thru PCI compliance. I would highly suggest that your client change their business model and stop handling authorizations and settlement. I'm not joking and yes, I understand that is a very big deal, but so is getting to full PCI compliance. I would bet that changing the business model and software would be cheaper and easier than becoming PCI compliant, which they will need to do if they are a service provider.

[tjl]

Yeah, the business model appears to be more of a hybrid at this time. Yes there is software which (in my current understanding) is sold, probably not heavily customized. I'm still waiting on more information, but it looks like they would go for PCI compliance in any case. The PA-DSS part is what I'm less sure about, but I think we need more data on the application itself.

Thanks!

[ADail]

Isn't the litmus test for PA-DSS whether or not it supports Authorization? If it's part of authorization it's in scope for PA-DSS?

[tjl]

Isn't the litmus test for PA-DSS whether or not it supports Authorization? If it's part of authorization it's in scope for PA-DSS?

The spec and FAQ appear to be more open, to the extent that if the application is distributed or licensed to a third party, and it handles CC data, it's in scope. There are some specific exceptions, databases, operating systems, and dumb terminals which connect only to the acquirer/processor. In the end though, whether it is mandatory is determined by the card brands.

[PCIJeff]

This was copied from the PA-DSS program guide:

To Which Applications does PA-DSS Apply?
For purposes of PA-DSS, a payment application is defined as one that stores, processes, or transmits cardholder data as part of authorization or settlement, where the payment applications is sold, distributed, or licensed to third parties.

Only applications that are part of the authorization and/or settlement process can go through PA-DSS certification.

[tjl]

Right, and in this case, it is passing information to the service provider, which is part of the authorization process.

In this particular case, it turns out that the payment processor will accept service provider DSS validation, so PA-DSS is not required at this time. After all, the "must" part is passed down from the card brands.

Thanks all.