2

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

  • 1
    Any credit card flowing through a system is required to be PCI compliant. I suggest to read up at the PCI Counsil website before getting in to this business: pcisecuritystandards.org/index.php – Jeroen Jun 7 '15 at 4:51
  • 1
    @Jeroen-ITNerdbox this might be a futile question, but just how feasible is it for a small business to become PCI compliant? It doesn't really seem like the guidelines for smaller businesses are any easier than those for the bigger ones, and it just seems like it would take a lot of time and resources for something that (at this point) I think might not even end up making that much money. – youngrrrr Jun 7 '15 at 6:49
  • @youngrrrr You ask a very loaded question. It all depends on the size and scope of the environment, as well as whether or not your processor or business partners require you to get an AOC (Attestation of Compliance). This is typically dependent on the number of transactions you process. Most small business won't have to go through a full blown PCI audit which can cost as much as 20-30k or more (size and scope dependant). Most small businesses will just have to fill out an SAQ (self assessment questionnaire). The SAQ C-VT is "easy" to meet in comparison to the others if you can limit the scope. – JekwA Jun 9 '15 at 0:29
  • @JekwA true, that was a very loaded question. considering my work is very small in scope, it seems as though all I'll have to do is fill out some forms and go through some basic checklists, as you mentioned. I had a different impression googling PCI compliance for small businesses. Thanks for your reply! – youngrrrr Jun 9 '15 at 0:45
  • @youngrrrr That should get you started. One very big caveat though is to make sure you do all your research ahead of time. There are a VERY large number of moving pieces involving processing credit card payments, the PCI DSS, the card brands ect... Don't take my above comment as any sort of legal or business advice. Just like gowenfawr I'm not a QSA or a lawyer. I was just trying to give you some insight from what I've seen in the past. PCI audits can be very expensive and if certain moving parts line up you may be required to have one completed to produce a full PCI audit report and AOC. – JekwA Jun 9 '15 at 18:09
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.

  • yes I did try emailing their contact a few days ago, but so far no word. It appears as though they have discontinued working on their product. If I had the reputation to upvote you a million times (or even just once!) I would!!! Thank you so much for that incredibly, very detailed answer. StackExchange needs more folks like yourself! – youngrrrr Jun 7 '15 at 6:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.