Stripe-ios: PCI Compliance for STPPaymentCardTextField

[tommanuel92]

Summary

I'm using STPPaymentCardTextField to collect card details, which is then used to create a Stripe token. This is sent to our backend to process the payment.

createToken accepts STPCardParams as a param, while STPPaymentCardTextField provides an STPPaymentMethodCardParams object. So I need to manually create the STPCardParams object by accessing the individual card details like cardNumber, expirationMonth, cvc etc.., as shown below.

Is this implementation PCI compliant? Else how do I make it PCI compliant and get the stripe token.

Code to reproduce

       var cardDetailTextfield: STPPaymentCardTextField!

        let cardParams: STPCardParams = STPCardParams()
        cardParams.number = cardDetailTextfield.cardNumber
        cardParams.expMonth = UInt(cardDetailTextfield.expirationMonth)
        cardParams.expYear = UInt(cardDetailTextfield.expirationYear)
        cardParams.cvc = cardDetailTextfield.cvc

       STPAPIClient.shared().createToken(withCard: cardParams, completion: {
            (token, error) -> Void in
            self.stripePayAPICall(token : token?.tokenId)
        })

iOS version

iOS 10 and above

Installation method

Cocoapods.

SDK version

19.4.1

Other information

[aliriaz-stripe]

Hello @tommanuel92 , as long as you're using STPPaymentCardTextField, I think you should be fine. Manually constructing STPCardParams off the public fields on STPPaymentCardTextField should be OK to create a Token (assuming the card details stay client-side).

Since you're on an SDK version > v16.0.0, your integration should ideally use PaymentMethods + PaymentIntents in which case you would just create a PaymentMethod off the cardParams property (but it looks like you're still on Tokens and Charges).

PCI compliance on mobile is documented here: https://stripe.com/docs/security/guide#validating-pci-compliance

I still think you should confirm with Stripe Support (at https://support.stripe.com/contact) on where that lands you.

[droidluv]

@aliriaz-stripe looking at the android side of things we have CardInputWidget which is similar to STPPaymentCardTextField, and the cardParams which we get from the UI component can be directly passed to the createToken function we have on the Android side, thereby allowing us to never access the raw card info and generate a token successfully, and you're suggesting using PaymentMethods but we use Stripe to generate a token and send it to our BE which will process it and use it for the concerned customer only when needed,(our payment can be immediate or deferred depending on the situation).

Additionally on a side note I noticed that in an upcoming update(it was upcoming as of Apr 16, is it released yet?) for Android we have a new CardFormView and the iOS counterpart is STPCardFormView which is seemingly the more modern approach of collecting information, and I hope it has a way to get card params of STPCardParams type so we can safely pass it onto createToken API call, without every access the raw values even for construction.

Additionally I think since we are just constructing the STPCardParams in the current scenario and never using it elsewhere we technically have a direct Customer -> Stripe flow which should be PCI compliant, but I guess support could verify that.

[aliriaz-stripe]

@droidluv hello!

Yes my read would be that you would be PCI compliant as you're leveraging the pre-built UI in the Android SDK and accessing public properties from the component but would highly recommend reaching out to Support for the confirmed answer on that.

Looking forward, for clarity: Charges and Tokens are deprecated and are considered a legacy integration. They have been since ~2019. They aren't going away but all future work is being done on PaymentIntents and PaymentMethods. I do encourage users using the newer versions of the SDK to migrate to using PaymentMethods and PaymentIntents as they are the recommended integration.

[tommanuel92]

hello @aliriaz-stripe , as you suggested I confirmed with the Stripe support.
Our app is eligible for SAQ A, so it should be fine for now. Thank you!