0

I have an eWallet application that lets the user (owner of the Virtual Visa) see his virtual card information if he wants to make an online purchase.

We are not storing the credit card data in our servers in any way.

There is this company Novopayment that actually stores the credit card info and is PCI compliant.

When the user requests to see his virtual card info, the app sends a request to Novopayment´s endpoint and brings back the hashed PAN, CVV and ExpDate we decode it and show it to the user but don´t store anything.

Is there something we should consider in this scenario regarding PCI?

TikalDog
  • 1
  • 1

2 Answers2

1

This is a multi-faceted question. And I'm sorry but much of this answer consists of questions you need to answer:

1. PCI Compliance

Compliance with any of the 15 PCI standards is a contractual requirement, so firstly it is important to understand who is asking you to comply with which PCI standard. I'm going to guess that may well be Novopayment which appears to be a Visa Member and so has an issuing license. Again, a guess, but it will probably be just compliance with PCI DSS - the Card Production standard is the other one that is most commonly applicable in issuance, BUT it is focussed very much on physical plastic.

The next question is whether you actually have a PAN or an Visa Digital Token complaint with the EMVCo Token Specification. If it is a Token, PCI DSS is not applicable see PCI SSC FAQ 1326 How does PCI DSS apply to EMVCo Payment Tokens? https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-does-PCI-DSS-apply-to-EMVCo-Payment-Tokens

Finally, there may be separate Visa security rules that you are required to comply with that are separate from any PCI standards compliance.

All that said, because an issuer is generally going to bear the cost of any fraud caused by the issuer's poor data security, card brands (i.e. Visa) tend to be more relaxed about telling issuers what to do. But my starting point would be to look at your contract and to ask Novopayment.

2. Security and Compliance

Let's assume you have a requirement to comply with PCI DSS.

Generally a consumer's (ie a cardholder) own device is outside the scope of any PCI requirements, however the app provided by an entity in the payment ecosystem is not.

Also, if your internal infrastructure could "affect the security of cardholder data" then it too could be in scope of PCI DSS's requirements. Only a Qualified Security Assessor would be able to advise you.

For the app an assessor would look to make sure that the relevant parts of PCI DSS requirement 6 were in place.

Although not specifically focused on your issuance use case, the PCI SSC guidelines PCI Mobile Payment Acceptance Security Guidelines for Developers https://www.pcisecuritystandards.org/documents/PCI_Mobile_Payment_Acceptance_Security_Guidelines_for_Developers_v2_0.pdf contains useful information on developing mobile apps that protect cardholder data.

I'd also highly recommend that you start to follow the PCI Secure Software Standard https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_1.pdf because in the future that is a standard that you will be most likely to required to comply with.

3. Security

In addition to @mentallurg's very valid security observations.

In your question you stated:

brings back the hashed PAN, CVV and ExpDate we decode it and show it to the user but don´t store anything.

Hashing is intentionally a one-way, non-reversible cryptographic function. I guess you don't mean hashed but encrypted and your app has the capability to decrypt it. The reason I mention this is if someone supplies you with a hash of a PAN their assumption is that you don't need access to the PAN itself, and that you wouldn't try to reverse (e.g. brute force) the hash back to the PAN. You should check this!

withoutfire
  • 1,000
  • 4
  • 7
  • So much appreciated. Actually the concerns came for our own team and there are no experts in the matter in our company. Yes I meant encrypted. – TikalDog Nov 05 '21 at 20:00
0

This a question/answer web site, not an audit company. Do not expect that somebody here tells you "yes, this is compliant with requirements A, B, C of standards D, E, F".

It is impossible to evaluate it without knowing all the details about your app. Here are some points that you need to check.

  • Your implementation of authentication, including password policy.

  • Your implementation of authorization. Your description makes an impression, that the target system does not distinguish users and thus allows any user to request PAN, CVV and ExpDate data of any person. If this is true, this is a security disaster.

  • If you have some backend (besides Novopayment): What security policies you use, what firewall configurations you use; who has access to the environment the application is running on, who can deploy code, who can configure the application, how do you design and test the application, how do you track access to important data.

  • How is communication between the app and the target system secured? Do you use encryption? What certificates your app trusts?

mentallurg
  • 8,536
  • 4
  • 26
  • 41