3

I'm working for a startup and we generate prepaid Mastercards from a card issuer. In our database we save a card reference id, not the 16 digit PAN or CVC. Later we do an API to the card issuer to get the PAN and CVC and POST these to a retailer online store (the retailer is using Salesforce Commerce Cloud). On the retailer site, the PAN and CVC are processed by the payment processor.

All communication (from our servers to the card issuer and from our servers to the retailer store) is done over SSL. I think because we do not store the PAN or CVC, and instead act as a pass-through, we do not need to be PCI compliant. Is this correct?

  • If the API would allow you to receive the reference from the retailer online store and provide a parameter to the issuer API informing where the PAN and CVC should be posted to, you could remove your systems from transmitting or processing the cardholder data. A challenge you have and a reason why you're in scope is that you get the cardholder data before you POST it. – AndyMac Jul 6 '18 at 15:03
3

From: https://www.pcicomplianceguide.org/faq/#2

The PCI DSS applies to ANY organization, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data

As you have stated in the above, you both accept and transmit cardholder data from yourselves to the retailer, so yes, you need to be PCI compliant.

0

As another answer says, since you have any level of deliberate visibility into PANs, you need to meet PCI requirements.

There are structural carve outs, like ISPs do not have to submit reports on compliance for PANs transiting in the clear over their wires, because those PANs are the responsibility of customers of the ISP. But the question describes a clear scenario of minting and exchanging PANs, so you can be shown to bear responsibility and should maintain a compliance practice.

The level of compliance is dependent on the number of transactions you participate in, which in your case since you seem to see the PAN on every cardholder transaction, could be substantial. There is also a material difference in compliance requirements that depends on whether you are "storing" the PANs "at rest" or just working with them "in transit", with the latter involving fewer requirements.

It sounds like you should be able to keep your compliance to the in-transit conditions, however you can easily find yourself with an at rest architecture if you do simple things like "temporarily" cache PANs in a redis.

That all said, I am curious about one thing- with whom do you need to have this compliance relationship. It should be through the acquiring bank backing your card issuer- if they are not themselves a bank- and your contract with the issuer should contain language to this effect. If it does not- if you are already in this business and you do not currently know to whom or with whom you need to submit a RoC or similar, you may have created a lot of liability for yourself.

PCI is fundamentally just a bunch of commercial contracts, not a governmental regulation like HIPAA. If you are participating in the minting and exchanging of PANs and something goes wrong and you have no contractual provisions and protections around this, or insurance that covers you for this, a lawsuit will appear that will put you out of business.

I would advise going through the language of your agreement with your issuer first, there has to be something there.

0

PCI DSS compliance is contractual, so the important question is who do you have a contract with that requires you to be compliant and who will ask you to validate your compliance. In this case your relationship is with a prepaid Mastercard issuer, so your contract with them will undoubtedly require you to comply with PCI DSS and provide a Report on Compliance (RoC) to them.

0

So, there's different levels of PCI DSS compliance:

Read & understand :

https://www.pcisecuritystandards.org/documents/SAQ-InstrGuidelines-v3_2_1.pdf?agreement=true&time=1530916849303

Quite lengthy, but it's your compliance at stake.

I believe (and don't take my word for it) you fall under SAQ C IF YOU ARE USING A 3rd PARTY PAYMENT PROCESSOR to generate these.

If you have a hook into mastercard (being a startup i doubt it, but possible), SAQ D might be worth looking at.

0

PCI compliance is a good thing. However, it is no cheap in several aspects. Ultimately, a business decision needs to ba made whether you need to process credit card data yourself.

I recommend reading PCI DSS documentation regarding SAQ. Dependending on the architecture and transaction volume, you might fit in one of SAQ categories which isolates your system from a full fledged PCI DSS compliant environment. It is very likely that you'll need to outsource some of your credit card processing pipeline to a PCI compliance supplier though.

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.