Is zinc.io PCI compliant (/does it need to be)?

Question

zinc.io provides shopping API to programmatically purchase items on Amazon, Best Buy, and Walmart to name a few. A brief observation of its API tells us credit card information is definitely being sent to and used by their server: example.

It seems that security-wise they:

1. use SSL encryption
2. never store the CC information (though they do say they may have it in memory)

From their FAQ: "We use industry-grade 256 bit SSL encryption on all API endpoints. Your card number and login details are in memory on the server only for the duration of each request."

That's it (although truthfully there is no way to tell for SURE if they're not PCI compliant, but nothing on their website seems to suggest otherwise).

My question is, if I wanted to offer similar service (i.e. make purchases on behalf of consumers with their cc info), must I (/are they?) be PCI compliant? Or, is it simply enough to (1) use SSL on my site and (2) never write CC info to my DB?

EDIT:

So I did end up getting a reply from the folks over at zinc.io after all! Here's what they had to say:

Hey there,

Sorry for the delayed response -- we noticed your question here as well :) We are very much still operating.

The response you received there was very detailed and mostly accurate. However, we are indeed PCI compliant -- at our scale of operation it is self-enforced, so the comment about "getting their quarterly ASV scans and not mentioning it" doesn't apply here. We do comply with everything on the SAQ.

Cheers, Max

Answer 1

Disclaimer: I Am Not A QSA; I Am Not A Lawyer

My question is, if I wanted to offer similar service (i.e. make purchases on behalf of consumers with their cc info), must I (/are they?) be PCI compliant? Or, is it simply enough to (1) use SSL on my site and (2) never write CC info to my DB?

Yes, you would need to be PCI compliant. You would be transmitting and possibly processing cardholder data on behalf of merchants. Storage of cardholder data is only one of the three things that are sufficient to put you in scope.

You might be able to do it without PCI compliance anyway. You might be outside the normal methods of PCI enforcement. Visa might not care enough to send lawyers. That being said, I would not advise testing those possibilities at all.

I'll expand upon this by addressing the rest of your question.

Zinc.io appears to meet the PCI definition of a service provider:

Service Provider: Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity.

At the very least they're transmitting cardholder data - they receive it and then send it along to the merchant. They may or may not be processing it.

They do not show up on the Visa Global Registry of Service Providers. That may simply mean that they're a Level 2 Service Provider, because "Entities that wish to be on the Global Registry of Service Providers must validate as a Level 1 provider."

(IANAQSA, but the only times I've heard a QSA mention level 2 SPs it was to dismiss them).

I'm assuming that PCI considers the cardholder an "entity" for the purposes of that definition. If not, that might be an interesting loophole. Because the really interesting thing is that it's not clear that Zinc is in the PCI enforcement chain:

Without actually establishing a working relationship with Amazon, Zinc has been able to simplify the ordering process down to just one call to the API.

Ordinarily, a merchant or service provider would be required to

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

but Zinc doesn't work with merchants, or service providers, they inject themselves as a middleman between the customer and the merchant without the merchant's knowledge or consent. They're not being held responsible to PCI, so they very likely may not be performing the steps necessary to provide mandated protection for customers' card data.

Since they don't list anything about the PCI DSS, or their compliance with it, on their web site, they may very well be working under the assumption that they aren't subject to it - or they may be choosing to ignore it, knowing that the usual leverage used to enforce it can't be used on them (to wit, being dropped by merchants, being dropped by processors/acquirers, or being fined within the context of their PCI relationships). Or, who knows, they could be carefully doing their SAQ and getting their quarterly ASV scans and not mentioning it... have you asked them?

Personally, I'd be leery of entrusting them with my card data. Their TLS configuration doesn't convince me they care deeply about securing it - as of this writing, a B with RC4, SHA-1, weak DH, and a cert signed by StartCom. Nothing that violates existing PCI requirements, but not indicative of a company that's putting the right focus on security.