PCI compliance and this library

[olessavluk]

Hi 👋

Is this library required to be used by "not PCI-compliant" apps? (having "PCI DSS SAQ A-EP" compliance level)

For example in Frames for Web card details are entred by customer inside iframe element, making it impossible to access untokenized data even if my site was breached.

But there is no such "isolation layer" in this library, right? Does this mean I can ask user to enter card number into my own TextInput and make own tokenization call too?

[olessavluk]

So tl;dr to use this library you are required to have "PCI DSS SAQ A-EP" merchant compliance level (when iframe can be used with lower "SAQ A" level)

Found human-readable explanation here https://cloud.google.com/architecture/pci-dss-compliance-in-gcp

SAQ type	Description
A	Merchants that have fully outsourced payment card processing to a third-party site. Customers leave your domain (including through an <iframe> web form), complete payment, and then return to your app. In other words, your company can't touch customer card data in any way.
A-EP	Merchants that outsource payment processing to a third-party provider, but who can access customer card data at any point in the process. Merchants that can access card data include merchant-controlled page elements such as JavaScript or CSS that are embedded in the third-party payment page. In other words, your payment processing app forwards card data to a processor on the client side, or the processor renders any content hosted by you.
D	Merchants that accept payments online and don't qualify for SAQ A or SAQ A-EP. This type includes all merchants that call a payment processor API from their own servers, regardless of tokenization. In other words, if you are not SAQ A or SAQ A-EP, you are SAQ D. SAQ D differentiates between Merchants and Service Providers. Service providers are not discussed in this document, and all SAQ D references address merchants as defined in PCI DSS.

[ghost]

@olessavluk Hey! I just started implementing this library into our app, and also realized that there's absolutely no security provided by this lib. How did you handle this? Did you use WebViews with Frames JS? Or do you still use this library, just with security protocols? Or maybe you've implemented the bridge between Checkout.com iOS/Android SDKs and React Native, which would be the best?

[olessavluk]

@audrius-enb, correct, this library is purely UI. But still can save you from common mistakes, like:

• passing card details into ReactNavigation params and then logging those via Sentry or Firebase Analytics
• storing card details inside redux and later leaking them
• having http client logger that will collect card details
• etc.

So I would say it's fastest and safest to use it.

(afaik if you have malicious code it can patch WebView internals and access even iframe, so I personally see little safety benefits in using it or bridging native SDKs)

[ghost]

@olessavluk Hmm, but as far as I understand, by using this library, you automatically breach the SAQ A and SAQ A-EP levels and then need to use encryption to send card details, right? Because:

1. You (the merchant) can read user's credit card details in code
2. Card tokenization is done without any encryption

Whereas if you use WebViews and the Frames JS SDK, it's automatically SAQ A compliant because it's Checkout.com's responsibility, and just safer to use?

[olessavluk]

You should confirm with checkout what they allow, as I understand "SAQ A-EP" is perfectly fine. Tokenization is done via HTTPS so is encrypted.

Regarding 1. there are many ways for you to hack own app, even when using iframe or native SDKs. Idea is to have review process and audit trail so it's not worth doing

[audrius-savickas]

@olessavluk Hey again, talked with checkout.com's support and they unfortunately said that this library is not SAQ A-EP compliant:

For SAQ A-EP compliance, you would need to apply, given that the card form elements are technically controlled by your app rather than a CKO-hosted iframe (such as Frames on the web).
For more details, you can refer to the SecurityMetrics explanation available at: https://www.securitymetrics.com/blog/saq-ep-what-and-how

[ioan-ghisoi-cko]

Hi. First of all thanks @olessavluk for the replies. Second, perhaps I can try to summarise this in one comment so others might benefit:

Frames React Native is fundamentally a library with a UI that also does an HTTPS (encrypted) API call to our secure server to tokenize the card details. The UI elements also have their value and onChangeText props removed, so you can not technically access the card details.

Details:
In the world of web, you have iFrames, which provides a secure way to collect card details since you can display inputs that essentially live on a different server (likely the payment provider server). If you have a website that uses an iFrame solution, you simply need SEQ-A level of PCI Compliance since you "fully outsourced payment card processing to a third-party site".

The mobile environment does not have the concept of iFrame. PCI Compliance also has a grey area around mobile. However, here is the main topic that needs to be addressed:

• the raw card details should not leave your app context and reach a non-PCI server (like sending an HTTP call to your own server with raw card details in the payload)

By using Frames React Native, you don't do any API calls to your own server with raw card details. We do a HTTPS (encrypted) call (from the app context) to our secure server to tokenize. Moreover, that token received is signed with the public key, and the payment itself has to be done from your server-side, with your secure secret key (which should always live on a server-side context, and never on the front end).

Moreover, since we strip the value and onChangeText, you could even say the solution leans to only requiring SAQ-A. At the same time, the concept of having your "own" inputs and tokenizing with the payment provider leans towards SAQ-A-EP. Since there is no clear indication in the PCI documentation for mobile on this topic, and this SDK essentially falls in the middle, we default to the higher level, so we recommend having SEQ-A-EP. In either case, a PCI auditor would not consider an app using this SDK to require a level higher than A-EP (at the moment of this comment).